UNIVERSIDAD NACIONAL DEL

CENTRO DEL PERU

FACULTAD DE INGENIERA DE SISTEMAS

TESIS

ANLISIS, DISEO E IMPLEMENTACION DE UN

SISTEMA DE INFORMACIN PARA MEJORAR LA
EFICIENCIA OPERATIVA PARA MICROEMPRESA
FUNNGER SYSTEM

PRESENTADO POR:

CASTRO NEZ HENRY JOEL

PARA OPTAR EL TTULO PROFESIONAL DE:

INGENIERA DE SISTEMAS
HUANCAYO PER
2014
 ASESOR
Mg. Fidel Arauco Cantorn

ii
 AGRADECIMIENTOS
A la Universidad Nacional de Centro del Per por brindarme la oportunidad de realizarme
como profesional.
A los docentes de la Facultad de Ingeniera de Sistemas, por los conocimientos brindados y
experiencias transmitidas a lo largo de mi formacin profesional.
A la Srta. Erika Aylas Ricapa, quien me impulso y me apoyo para el desarrollo del presente
proyecto de investigacin.
A mi asesor de tesis el Mg. Fidel Arauco, quien me apoyo en la elaboracin del proyecto de
investigacin.
A los compaeros de aula y de la facultad por el compaerismo y el apoyo brindado durante
mi formacin profesional.

iii
 DEDICATORIA
La presente tesis est dedicada a mi familia y
en especial a mi madre quien fue mi soporte a
lo largo de toda mi formacin profesional y
quien es la persona que me impulsa a realizar
todo lo propuesto en la vida.

iv
 RESUMEN
El gran desarrollo de las microempresas dedicadas a la comercializacin de accesorios de
computo exige a todas las microempresas que laboran en este rubro operar de manera
eficiente y aprovechar al mximo las oportunidades que se presentan con el fin de asegurar
una permaneca exitosa en el mercado y lograr as un crecimiento como empresa, es as
que el presente trabajo se desarrolla en la microempresa Fungger System, microempresa
que labora en el sector de comercializacin de accesorios de computo con fin de colaborar
en los dos aspectos ya mencionados.
Actualmente los registros de la informacin de los procesos de la microempresa se realiza
en hoja de Excel y en algunos casos hojas de cuaderno en consecuencia genera cierto
retraso en los procesos que desarrolla, por otra parte se observa que las decisiones que se
toma son poco apropiadas para rumbo de la empresa debido a que la informacin registrada
no colabora en esta actividad, tambin se observa la prdida de clientes y productos
provocando un impacto negativo en el logro de objetivos, crecimiento empresarial y la
permanencia exitosa en el mercado. Por tal motivo el presente trabajo de investigacin tiene
por objetivo mejorar esta deficiencia operativa para lo cual se realizar el anlisis, diseo e
implementacin de un sistema de informacin, la cual acelerar ciertas actividades, adems
de servir para el control de las actividades y la toma de decisiones colaborando de esta
manera el desarrollo de los procesos operacionales en la microempresa Funnger System.
La implementacin del sistema de informacin se realizar mediante software libre debido a
que la microempresa no cuenta con los suficientes recursos econmicos para solventar el
desarrollo del presente proyecto. Para el desarrollo del presente proyecto se optar por
metodologas agiles tanto para la gestin del proyecto como para el desarrollo de la
solucin, teniendo como base los conceptos de la ingeniera de sistemas y a la metodologa
RUP, adems de la herramienta UML mediante el cual se realizarn algunos modelados y
abstracciones y para finalizar se presentar algunos indicadores el cual reflejarn la mejora
de la empresa con respecto a la etapa inicial.

v
 ABSTRACT
The great development of the micro working dedicated he demands to everyone to the
accessories commercialization computing them micro working that labor in this item to bring
about of efficient manner and geting the most out of the opportunities that turn up with the
aim of insuring one was remaining successful on the market and achieving thus a growth as
company , it is well then present work he develops in her micro working Fungger System ,
micro working that labors in the commercialization sector of accessories computing with end
of collaborating with in both aforementioned.
At present the records of the information of her processes micro working sells off in sheet of
Excel and in some cases notebook leaves himself in consequence generate true delay in the
processes that he develops , on the other hand observes itself than the decisions that one
takes little music than adapted in order to the company's direction because the information
once was searched does not collaborate with herein activity , also the loss of clients and
products provoking a negative impact in the objectives , entrepreneurial- growth achievement
and the successful permanence are observed on the market.
present fact-finding work has for objective to improve this operating deficiency For such
motive stop it as he will accomplish the analysis, design and an information system's
implementation, her as he will accelerate true activities, besides serving in order to the
activities's control and the decision makings collaborating with this way the development of
the operational processes in her micro working Funnger System. The implementation of the
information system will come true by means of freeware once should have been owed to
micro working does not consider with plenties economic resources to solve the present
project's development than her.
Point in order to the steps of the project same as for the solution's development, having as
base the concepts of the engineering of systems and to the methodology will choose agile
methodologies itself In order to the present project's development RUP, in addition to the tool
intervening UML some modelings and abstractions will accomplish which themselves and
which will show some indicators itself to finalize they will show the improvement of the
company regarding the initial stage

vi
 NDICE
pg.
PORTADA i
ASESOR ii
AGRADECIMIENTO iii
DEDICATORIA iv
RESUMEN v
ABSTRACT vi
NDICE vii
INTRODUCCIN 1
CAPITULO I: GENERALIDADES
1.1 Planteamiento del problema 3
1.1.1 Micro y pequeas empresas en el Per 3
1.1.2 Microempresa FunggerSystem Huancayo 7
1.2 Formulacin del problema 10
1.3 Objetivos 10
1.4 Justificacin 10
1.4.1 Justificacin Terica 10
1.4.2 Justificacin Metodolgica 10
1.4.3 Justificacin Prctica 10
1.4.3 Justificacin Prctica 10
1.5 Hiptesis 11
1.5.1 Hiptesis General 11
1.5.2 Operacionalizacin de Variables 11
1.6 Diseo metodolgico 11
1.6.1 Tipo de Investigacin 11
1.6.2 Nivel de la Investigacin 11
1.6.3 Diseo de la Investigacin 11
1.6.4 Poblacin y Muestra 11
CAPTULO II: MARCO DE REFERENCIA
2.1 Antecedentes 13
A1. Sistema de Informacin en la parte operativa (ventas e importaciones),
para la empresa importadora Gran Andina Ltda 13
A2. Anlisis, Diseo e Implementacin de un Sistema de Informacin para una Tienda de
Ropa con Enfoque al Segmento Juvenil 14
vii
A3. Anlisis, Diseo e Implementacin de un Sistema de Planificacin de Procesos
Productivos para Pymes de Textiles y Confecciones 15
A4. Desarrollo de un Sistema de Informacin para Soporte de Decisiones en el Proceso
de Planificacin de Compras en una Mype Comercial de Productos para Bisutera 16
A5. Anlisis Diseo e Implementacin de una Solucin de Inteligencia de Negocios
Para el rea de Compras y Ventas de una Empresa Comercializadora de
Electrodomsticos. 17
2.2 Marco terico 18
2.2.1 Sistemas de Informacin 18
2.2.2 Ciclo de vida de un Sistema de Informacin 19
2.2.2.1 Definicin del Problema. 19
2.2.2.2 Recopilacin de la Informacin 20
2.2.2.3 Anlisis de la Informacin 21
2.2.2.4 Diseo del Sistema 23
2.2.2.5 Programacin 24
2.2.2.6 Pruebas del Programa 24
2.2.2.7 Documentacin 25
2.2.2.8 Implantacin 25
2.2.3 Metodologa RUP 26
2.2.4 Lenguaje Unificado de Modelado (UML) 27
2.2.4.1 Diagramas UML. 28
2.2.5 MYSQL 37
2.2.5.1 Caractersticas MYSQL 37
2.2.6 Lenguaje de Programacin 38
2.2.6.1 Java 39
2.3 Modelo aplicativo 39
2.3.1 Conceptualizacin 40
2.3.2 Anlisis 40
2.3.3 Diseo 41
2.3.4 Implementacin 41
2.3.5 Pruebas 41
2.3.6 Implantacin 41
2.4 Marco conceptual 41
CAPTULO III: INTERVENCION METODOLGICA
3.1 Conceptualizacin 43
3.2 Modelado del Negocio 44
3.3.1 Identificacin de Procesos 44
viii
3.3 Definicin de Requerimientos 50
3.3.1 Determinacin de los Requerimientos del Sistema 50
3.3.1.1. Requerimientos Funcionales 50
3.3.1.2. Requerimientos No Funcionales 53
3.4 Anlisis y Diseo 54
3.4.1 Modelo de Casos de Uso del Negocio 54
3.4.1.1 Matriz de Trazabilidad 58
3.4.2 Diagramas de Secuencia 59
3.4.3 Diseo de la Base de Datos 63
3.4.3 Diagrama de Despliegue 65
3.5 Implementacin 65
CAPTULO IV: ANLISIS DE RESULTADOS
4.1 Indicadores de la Situacin Mejorada y de la Hiptesis 72
CONCLUSIONES 78
RECOMENDACIONES 79
REFERENCIAS BIBLIOGRAFICAS 80
ANEXOS 81

ix
 NDICE DE GRFICOS
Pg.
Grafico N 1.1 Distribucin porcentual de las empresas en Per 4
Grafico N 1.2 Creacin de nuevas microempresas en el Per: 2007-2012 4
Grafico N 1.3 Distribucin de las MYPES segn actividad econmica. 5
Grafico N 1.4 Micro y Pequeas empresas segn regiones 6
Grafico N 1.5 Tiempo en das en realizar un inventariado 7
Grafico N 1.6 Monto de prdidas expresado en soles 8
Grafico N 1.7 Nmero de clientes perdidos 9
Grafico N 1.8 Variables de la Hiptesis 11
Grafico N 2.1 Objetivos Generales y Especficos del Diseo de Sistemas 23
Grafico N 2.2 Fases de la metodologa RUP 27
Grafico N 2.3 Representacin Grfica de un Actor 28
Grafico N 2.4 Representacin Grfica de Caso de Uso 29
Grafico N 2.5 Representacin Grfica de una Asociacin 29
Grafico N 2.6 Lnea de Vida en un diagrama de secuencia 30
Grafico N 2.7 Lnea de Vida en un diagrama de secuencia 31
Grafico N 2.8 Representacin Grfica de envo de mensajes 31
Grafico N 2.9 Creacin y Destruccin de mensajes 32
Grafico N 2.10 Representacin de una clase 33
Grafico N 2.11 Representacin grfica de herencia. 34
Grafico N 2.12 Agregacin por referencia en el diagrama de clases 35
Grafico N 2.13 Asociacin en el diagrama de clases 36
Grafico N 2.14 Dependencia entre Clases 36
Grafico N 2.15 Modelo Aplicativo 40
Grafico N 3.1 Proceso-compra de productos 44
Grafico N 3.2 Proceso-almacenamiento de productos 45
Grafico N 3.3 Proceso-distribucin de productos 46
Grafico N 3.4 Proceso-venta 47
Grafico N 3.5 Diagrama IDEFF-Fungger System 48
Grafico N 3.6 Diagrama IDEFF-Sub Funciones Fungger System 49
Grafico N 3.7 Requerimientos Funcionales Compra de Productos 51
Grafico N 3.8 Requerimientos Funcionales Venta de Productos 52
Grafico N 3.9 Requerimientos Funcionales Control de Productos e Inventario 53
Grafico N 3.10 Requerimientos no Funcionales 54
Grafico N 3.11 Caso de uso compra de productos 55

x
Grafico N 3.12 Caso de uso almacenado y distribucin de productos 56
Grafico N 3.13 Caso de uso venta de productos 57
Grafico N 3.14 Caso de uso control de compras, ventas e inventario 58
Grafico N 3.15 Matriz de Trazabilidad 59
Grafico N 3.16 Diagrama de secuenciacompras 60
Grafico N3.17 Diagrama de secuencia-almacenamiento y distribucin de productos 61
Grafico N 3.18 Diagrama de secuenciaventas 62
Grafico N 3.19 Diagrama de secuencia-control de ventas, compras e inventariado 63
Grafico N 3.20 Diseo de la Base de Datos 64
Grafico N 3.21 Diagrama de Despliegue 65
Grafico N 3.22 Interfaz validacin de usuario 66
Grafico N 3.23 Interfaz proveedores 66
Grafico N 3.24 Interfaz registrar compra 67
Grafico N 3.25 Interfaz registrar venta 68
Grafico N 3.26 Interfaz mantenimiento de producto 68
Grafico N 3.27 Interfaz agregar marca 69
Grafico N 3.28 Interfaz mantenimiento clientes 69
Grafico N 3.29 Interfaz personal 70
Grafico N 3.30 Interfaz agregar usuario 70
Grafico N 4.1 Tiempo en das en realizar un inventariado antes de la intervencin. 72
Grafico N 4.2 Tiempo en realizar el control de inventarios despus de la intervencin 73
Grafico N 4.3 Monto de prdidas expresado en soles-Antes de la Intervencin 74
Grafico N 4.4 Monto de prdidas expresado en soles-Despus de la Intervencin 74
Grafico N 4.5 Nmero de clientes perdidos 75
Grafico N 4.6 Nmero de clientes perdidos despus de la intervencin 75
Grafico N 4.7 Aceptacin del Sistema de Informacin 76
Grafico N 4.8 Utilidad del Sistema de Informacin 76

xi
 INTRODUCCIN
En los ltimos aos se podido apreciar el crecimiento econmico en el Per, esto se
evidencia a travs de algunos indicadores econmicos como las importaciones,
exportaciones y otros. Este crecimiento sin lugar a duda ha influido de manera considerable
en el desarrollo del comercio y en consecuente la creacin de la MYPES.
La regin Junn y en especial la ciudad de Huancayo no es ajena a todo este desarrollo
pues en los ltimos aos se ha dado un gran desarrollo en el sector comercial en particular
el sector comercial orientado las comercializacin de equipos de cmputo y tecnologas de
informacin en general, esto es de mucha notoriedad dado que en los ltimos aos se
incrementado el nmero de MYPES orientadas a este sector, es as que las MYPES en la
ciudad de Huancayo vienen a ser un factor muy importante en el desarrollo de la economa,
debido a que generan muchos puestos laborales con pequeos capitales.
Las MYPES debido al poco conocimiento y a la escaza asesora con la que cuentan no
aprovechan de manera adecuada la informacin con la que cuentan y registran, generando
poco o nada de valor agregado para poder desenvolverse de mejor manera en sus procesos
operativos, en tal sentido el trabajo de investigacin se orientara a mejorar el eficiencia
operativa para lo cual se desarrollara un sistema de informacin, es en este contexto que se
desarrolla la tesis titulada anlisis y diseo de un sistema de informacin para mejorar
la eficiencia operativa en la microempresa FunngerSystem.
En el CAPITULO I de Generalidades se abordar la contextualizacin y descripcin de la
microempresa en la cual se realizar el trabajo de investigacin, adems se formulara el
problema central y se mostrarn datos los cuales buscarn evidenciar el problema central,
el cual es motivo de esta investigacin, adems se plasmar los objetivos que se quiere
lograr con el trabajo de investigacin las hiptesis o las posibles respuestas a nuestro
problema central.
En el CAPTULO II de Marco de Referencia se plasmar el basamento terico con el cual
se desarrollar la investigacin y el cual tambin nos servir de soporte al cual se aadir
algunos trabajos de investigacin realizados en la misma rea de investigacin, y para
finalizar el captulo se mostrar el modelo aplicativo lo cual a su vez es producto de una
sntesis de todo el fundamento terico.
En el CAPTULO III respecto a la Intervencin Metodolgica se proceder a intervenir la
situacin problemtica teniendo como soporte la teora descrita en el captulo II y en forma
particular al modelo aplicativo, producto del cual se obtendr el sistema de informacin para
mejorar la eficiencia operativa de la microempresa donde se viene realizando el trabajo de
investigacin.

1
En el CAPTULO IV de Anlisis de Resultados se analizar los resultados que se obtuvieron
producto de la intervencin metodolgica los cuales determinarn si hay una mejora de la
situacin final con respecto a la situacin inicial y en qu medida se dio esta mejora, por otra
parte ayudar a comprobar si se cumpli con los propsitos establecidos en el trabajo de
investigacin.

EL AUTOR

2
 CAPTULO I
GENERALIDADES
En el presente captulo se realizar una descripcin del problema lo cual busca reflejar la
situacin problemtica con la que convive la microempresa Fungger System, adems se
abordar los objetivos en lo cual nos presentara una visin de lo que se quiere lograr con el
trabajo de investigacin y finaliza con el diseo metodolgico del presente trabajo de
investigacin.
1.1 PLANTEAMIENTO DEL PROBLEMA
1.1.1 MICRO Y PEQUEAS EMPRESAS (MYPES) EN EL PER
La importancia de la Micro y Pequea Empresa (MYPE) dentro de la estructura
econmica en el Per es indiscutible, tanto por su importancia numrica, como por
su capacidad de absorcin de empleo y por el aporte que tienen a la economa del
Per. El Per actualmente expone buenos indicadores macroeconmicos, una
economa slida, mayores exportaciones, negociaciones de acuerdos comerciales
con muchos pases, por lo que este optimismo y nimo de la economa se traslada
al consumo privado, dado que la poblacin est demandando mayores bienes
para consumo lo que conlleva a un mayor desarrollo de las MYPES, para la cual
necesitan orientacin en el desarrollo de sus actividades y tomar las decisiones
ms acertadas.
Seguidamente se mostrar el criterio que se tiene para la clasificacin de las
empresas (microempresa, pequea empresa, mediana y gran empresa), lo cual
est en funcin al nivel de ventas anuales y el cual esta normado en la LEY
N30056 que tiene por objeto establecer el marco legal de las micro, pequeas y
medianas empresas.
Microempresa: Hasta 50 UITs.
Pequea Empresa: Ms de S/.50 UITs hasta 1700 UITs.
Mediana y Gran Empresa: Ms de 1700 UITs.

3
Despus de haber dado a conocer el criterio de la clasificacin de las empresas
seguidamente se mostrar el grfico 1.1 en la cual se detallar una distribucin
porcentual de las empresas en el Per.
Grfico N1.1
Distribucin porcentual de las empresas en Per

Fuente: BASE DE DATOS SUNAT-2012

Elaboracin: MINISTERIO DE LA PRODUCCION
En el grfico mostrado se puede apreciar que las microempresas representan la
mayor cantidad del sector empresarial, confirmando de esta manera la
importancia que revisten en el estrato empresarial y la influencia en la economa
del Per.
As como ya sabemos de la importancia de participacin de las microempresas en
el sector empresarial, tambin es necesario conocer del crecimiento del nmero
de microempresas para lo cual se presenta el grafico N1.2 en la que se muestra
el nmero de microempresas que se vienen creando anualmente.
Grfico N1.2
Creacin de nuevas microempresas en el Per: 2007-2012

Fuente: BASE DE DATOS SUNAT-2012

Elaboracin: MINISTERIO DE LA PRODUCCION

4
En el grafico mostrado anteriormente se puede apreciar que ao tras ao viene
incrementndose el nmero de microempresas creadas, lo que hace que sea
determinante su participacin en la economa del Per.
Por otra parte las MYPES participan en el proceso productivo nacional realizando
un conjunto de actividades heterogneas como: el comercio, produccin,
servicios, etc. pero la actividad econmica que mayor resalta es la del comercio
debido a que requiere menor inversin y por su mayor facilidad de adaptacin a
los cambios. Para una mejor referencia se muestra el grfico N1.3 en el cual se
plasma las diferentes actividades a las que se dedican las MYPES
Grfico N1.3
Distribucin de las MYPES segn actividad econmica.

Fuente: SUNAT BASE DE DATOS-2012

Elaboracin: PRODUCE-Direccin de Estudios Econmicos de MYPE e Industria
En el grfico mostrado se puede apreciar que hay una gran concentracin de
empresas que se dedican a la actividad econmica del comercio, convirtindose
en el eje de la economa del Per, adems de la importancia que tienen estas en
la generacin de empleo, pues las MYPES son las mayores generadoras de
empleo pero con menor financiamiento, tambin se considera como auto
empleadora esto debido a que en sus inicios las microempresas son creadas con
el fin de salir del desempleo y generar un ingreso propio, segn datos del
ministerio de la produccin las MYPES contribuyen con aproximadamente el 60%
de toda la fuerza laboral del Pas.
Habiendo mostrado la situacin de las MYPES en el contexto nacional, en el
siguiente grafico se mostrar las Micro y Pequeas empresas segn regiones a fin
de entender el contexto regional

5
 Grfico N1.4
Micro y Pequeas empresas segn regiones

Fuente: SUNAT BASE DE DATOS-2012

Elaboracin: PRODUCE-Direccin de Estudios Econmicos de MYPE e Industria
En el grafico mostrado anteriormente se puede apreciar que la regin Junn se
ubica en el sexto lugar en relacin al nmero de microempresas, esto se debe
principalmente a que la regin Junn es una regin bastante comercial siendo su
mayor fuente de ingreso el comercio.
Como se puede apreciar las MYPES tienen un rol fundamental en toda la
economa del Per, no solo porque son en mayor cantidad, sino por la
contribucin que hacen en la generacin de empleos y en el desarrollo, teniendo
en consideracin que la actividad econmica principal dentro de las MYPES es la
del comercio, pero por otra parte conocemos por investigaciones y estadsticas
realizadas, que ocho de cada 10 MYPES fracasan en sus primeros 5 aos; siendo
uno de los principales factores no contar con informacin actualizada y
consistente y al instante, que les permita tomar las decisiones concretas y
6
 correctas para satisfacer la demanda de un determinado mercado en condiciones
competitivas, sea ste nacional o internacional.
1.1.2 MICROEMPRESA FUNGGER SYSTEM-HUANCAYO
Fungger System es una microempresa que viene operando en la ciudad de
Huancayo desde mediados del 2004 es microempresa dedicada principalmente al
comercio de equipos de cmputo, accesorios y afines; tambin brinda servicio de
soporte tcnico de los mismos. El capital promedio con el que cuenta esta
microempresa es aproximadamente de S/.80, 000 y es as que solo cuenta con
pocos personales que laboran en esta microempresa
El promedio de ingresos brutos por da es de S/.1, 000 a S/.1, 200 eso sin tener
en cuenta los contratos pequeos, medianos y grandes que realiza, para lo cual
tendremos en cuenta lo siguiente:
Contrato pequeo considerado de S/.500 hasta S/.1, 500.
Contrato mediano considerado de S/.1, 500 a S/.8, 000.
Contrato grande considerado de S/.8, 000 en adelante.
En la actualidad est microempresa presenta poca organizacin de la informacin
con la cual opera, aun se puede apreciar que la forma de registrar sus
transacciones y operaciones lo realiza en hojas de Excel, aunque anteriormente lo
realizaba en cuadernos. Es as que le permite tener poco control de inventarios,
pues cada vez que realiza el proceso de inventariado le toma muchos das debido
a la variedad y cantidad de productos con los que cuenta.
A continuacin se muestra el grfico N 1.5 en el cual se plasma el tiempo que le
demora a la microempresa realizar un proceso de inventariado.
Grfico N1.5
Tiempo en das en realizar un inventariado

tiempo en dias
5
4.5
4
3.5
3
2.5
2
1.5
1
0.5
0
nov-10
jul-10

jul-11

jul-12
may-10

may-11

may-12
mar-10

sep-10

mar-11

sep-11
nov-11

mar-12

sep-12
nov-12
ene-10

ene-11

ene-12

ene-13

Fuente: Fungger System

Elaboracin: Propia.
7
Como se puede apreciar en el grfico N1.5 el tiempo promedio que le toma a la
microempresa realizar un proceso de inventariado es de 3.7 das y segn
transcurre el tiempo les toma un tiempo mayor debido a que cada vez cuentan con
mayor existencia de inventarios, por el cual se realizan 3 procesos de inventariado
al ao permitindoles tener poco control.
El poco control de mercadera que se presenta en el interior de la microempresa
trae consigo otro efecto que es la prdida de mercadera en el interior de la
microempresa generando prdidas econmicas y en algunas ocasiones el despido
de algunos de los personales.
Seguidamente se muestra el grfico N1.6 en la cual se registran las perdidas
percibidas por la microempresa expresado en trminos econmicos.
Grfico N1.6
Monto de prdidas expresado en soles

Monto de perdidas en soles

1800
1600
1400
1200
1000
800
600
400
200
0
monto de perdidas expresado en soles

ene-10 may-10 sep-10 ene-11 may-11

sep-11 ene-12 may-12 sep-12 ene-13

Fuente: Fungger System

Elaboracin: Propia.
Se puede observar que en cierta manera a lo largo de toda su operatividad ha
mejorado el control de inventarios esto debido a la experiencia de ir operando,
pero esta mejora no es suficiente pues se sigue generando demasiadas prdidas
teniendo un promedio trimestral de prdidas por un monto de S/.1, 260, esto
debido al poco control de productos que lleva la microempresa.
La Microempresa viene llevando informacin de manera tradicional la cual es poco
conveniente pues no permite aprovechar de manera eficiente toda est data,
generando poco valor agregado la cual tampoco permite generar conocimiento,
conocimiento con la que se puede contar en la parte operacional de la empresa,
as desarrollar de mejor manera las actividades comerciales y lograr aprovechar al

8
mximo las oportunidades que se puedan presentar logrando de esa manera un
mayor beneficio para la microempresa (organizacin).
Para hacer ms evidente la deficiencia operativa a continuacin en el grfico
N1.7 se muestra un registro de clientes perdidos, producto del tiempo que tienen
que esperar los clientes mientras se verifica la disponibilidad de los productos que
los clientes desean adquirir.
Grfico N1.7
Nmero de clientes perdidos

70

60

50

40

30

20

10

0
ago-12 sep-12 oct-12 nov-12 dic-12 ene-13 feb-13

Fuente: Fungger System

Elaboracin: Propia.
El grfico presentado se realiz por intervalos de tiempo para evidencia de mejor
manera la deficiencia operativa debido a que la microempresa no percibe el
impacto de la prdida de clientes en el da a da, del grfico se tiene que el
promedio de clientes perdidos en cada mes es de 64 y la utilidad que se podra
generar a travs de estos clientes haran que la microempresa tenga mayores
ganancias
Como se ha podido demostrar a travs de cada cuadro mostrado es demasiada la
deficiencia operativa que se presenta en la microempresa Fungger System, esto
relacionado estrechamente con la poca organizacin de la informacin y el poco
aprovechamiento de toda la data con la que cuentan, es posible que por
desconocimiento, poco asesoramiento con la que cuentan las MYPES o el bajo
financiamiento, pero la cual es necesaria mejorarla, tambin se puede apreciar
que la microempresa no percibe el impacto negativo que esta ocasiona debido a
que convive en el da a da con este aspecto negativo y lo considera parte del
desenvolvimiento operacional.

9
1.2 FORMULACIN DEL PROBLEMA
PROBLEMA GENERAL:
Cul es la influencia del sistema de informacin en la eficiencia operativa de la
microempresa Fungger System?
1.3 OBJETIVOS
OBJETIVO GENERAL:
Evaluar la influencia del sistema de informacin en la eficiencia operativa de la
microempresa Fungger System.
1.4 JUSTIFICACIN
1.4.1 JUSTIFICACIN TERICA
Es de conocimiento que en gran parte del xito que logran las empresas es
debido a las Tecnologas de Informacin y comunicacin (TICs), los cuales
apoyan a tomar decisiones ms acertadas, mayor control en las actividades y as
desenvolverse de mejor manera frente a la competencia. Los Sistemas de
Informacin son de alguna manera una respuesta a todo esto, puesto que la
buena organizacin de la informacin que se tenga en una empresa nos permitir
operar de mejor manera y aprovechar las oportunidades cuando estas se
presenten. Es por tal motivo la aplicacin de Sistema de informacin en este
trabajo de investigacin.
1.4.2 JUSTIFICACIN METODOLGICA
Existe una serie de metodologas para el desarrollo de sistemas de informacin y
en este proyecto en particular se desarrollar basndose en la metodologa RUP,
metodologa que ha sido utilizada en muchos proyectos debido a los estndares
de calidad que se logra, a la eficiencia en la administracin de requerimientos y
debido a que permite medir el nivel de desarrollo y saber el impacto que estas
tienen segn se va avanzado. Es as que surge la inquietud de realizar un estudio
en este campo y basado de en la metodologa RUP y as poder contribuir con la
microempresa Fungger System mediante la implementacin de un sistema de
informacin la cual colaborar en la mejora de la eficiencia operativa.
1.4.3 JUSTIFICACIN PRCTICA
El presente trabajo de investigacin se realiza para permitir que la microempresa
Fungger System trate de tomar las decisiones ms acertadas con respecto a su
desenvolvimiento, es por eso que la microempresa Fungger System en bsqueda
de ese mejoramiento decide apoyarse en los Sistemas de Informacin con la
finalidad de un mejor aprovechamiento de toda la data que registran y disponen.

10
1.5 HIPOTESIS
1.5.1 HIPTESIS GENERAL
El sistema de informacin influye en la mejora de la eficiencia operativa en la
microempresa Fungger System.
1.5.2 OPERACIONALIZACIN DE VARIABLES
A continuacin se identifican las variables dependientes e independientes del
presente estudio y se determinan las caractersticas de la intervencin
metodolgica (implementacin de un sistema de informacin para la
microempresa Fungger System) que afectaran a las variables mencionadas.
Grfico N1.8
Variables de la Hiptesis

VARIABLE
INDEPENDIENTE INDICADORES UNIDADES
Sistema de Escala(Bueno, Regular,
Informacin Nivel de Satisfaccin de Usuario Malo)
VARIABLE
DEPENDIENTE INDICADORES UNIDADES

Tiempo en realizar un inventario Das

Eficiencia Operativa
Perdida de productos Soles

Prdida de clientes Cantidad de Clientes

Fuente: Propia
Elaboracin: Propia.
1.6 DISEO METODOLGICO
1.6.1 TIPO DE INVESTIGACIN
El diseo de la investigacin se ajusta a una investigacin aplicada, ya que
tenemos la posibilidad de implementar y observar los efectos de la aplicacin de
Sistemas de informacin en la microempresa Fungger System.
1.6.2 NIVEL DE LA INVESTIGACIN
El presente trabajo de investigacin rene las caractersticas de una investigacin
explicativa, porque la variable independiente explica la variable dependiente
1.6.3 DISEO DE LA INVESTIGACIN
El diseo de la investigacin es tecnolgico, porque se ha diseado y desarrollado
un software, que se aplicar en la organizacin.
1.6.4 POBLACIN Y MUESTRA
Por la naturaleza de la investigacin la poblacin comprende a las microempresas
dedicadas al rubro de comercializacin de equipos de cmputo, la muestra es
dirigida y enfocada en la empresa Fungger System.
11
En el captulo abordado anteriormente se ha dado a conocer los motivos que dieron origen a
la elaboracin de todo el trabajo de investigacin, para lo cual se present una
contextualizacin de la situacin problemtica, adems de los datos que evidencian la
problemtica y por ltimo se present los alcances que se quiere lograr con la tesis.

12
 CAPTULO II
MARCO DE REFERENCIA
En el presente captulo se har hincapi a los diferentes trabajos de investigacin que nos
sirvieron de referencia y a todo el basamento terico el cual nos servir de soporte a lo
largo del desarrollo del trabajo de investigacin, y para finalizar el captulo se mostrar el
modelo aplicativo lo cual a su vez es producto de una sntesis de todo el fundamento terico.
2.1 ANTECEDENTES
A.1. Agudelo Solano Hernando Andrs (2004). Sistema de Informacin en la parte
operativa (ventas e importaciones), para la empresa importadora Gran Andina
Ltda.
Importadora gran andina ltda (igrandina), es una empresa familiar que se ha
mantenido a travs de 20 aos por los esfuerzos y arriesgadas decisiones tomadas
tanto por sus socios como por los directivos, quienes claramente vieron la
necesidad de incrementar su productividad y eficiencia para as crecer, hacerla ms
slida y lograr los objetivos a corto y largo plazo.
Partiendo del hecho que en la actualidad, la tecnologa y el uso de sistemas de
informacin han sido de gran utilidad para las empresas cuando se trata de
incrementar su productividad y mejorar resultados, lo que pretende esta tesis es
estudiar el sistema de informacin actual utilizado por la empresa, as como
proponer un cambio o mejoramiento del mismo con el fin de optimizar todos los
procesos que se llevan a cabo en la misma.
Con el fin de realizar un estudio ms a fondo y obtener propuestas ms concretas
para el mejoramiento de la misma empresa, este Trabajo de Grado se enfoc
netamente en las reas productivas de la empresa, que son la de Importaciones y
la de Venta de repuestos de maquinaria pesada.
Esta tesis tambin tiene un enfoque de aprendizaje, ya que se pretende que los
socios, los directivos y el jefe de sistemas, comprendan cada uno de los pasos que

13
 se llevaron a cabo durante el trabajo, desde la documentacin de los procesos
hasta los problemas a atacar, siempre buscando la mejor solucin.
La tesis mencionada hace un gran aporte al trabajo de investigacin que se viene
realizando pues trata de mejorar una situacin problemtica en la parte operacional
de una empresa a travs de la implementacin de un sistema de informacin, pero
lo ms resaltante es que la situacin que el trabajo referido aborda tiene muchas
caractersticas similares al problema que en este trabajo de investigacin se
desarrolla, dado que la empresa donde se aplica el trabajo tambin es una empresa
dedicada al rubro de comercializacin.
A.2.Rodrguez Torres, Johanna Elizabeth (2013). Anlisis, Diseo e
Implementacin de un Sistema de Informacin para una Tienda de Ropa con
Enfoque al Segmento Juvenil. Tesis para optar por el Ttulo de Ingeniero
Informtico. Pontificia Universidad Catlica del Per. Per.
En este trabajo de tesis se presenta el desarrollo de un sistema de informacin que
permite gestionar las ventas y el almacn de ventas, de esta manera se ayuda a
organizar, controlar y administrar los productos con los que cuenta la empresa q fue
tomada como modelo, automatizando sus actividades primarias y mejorando la
interaccin con sus clientes. El sistema presenta los siguientes mdulos: El mdulo
de ventas, El mdulo de inventario de ventas y el mdulo de catlogo en lnea.
Para lograr los objetivos del presente proyecto, se propone formalizar las reglas del
negocio, la elaboracin de un prototipo de la posible solucin, la definicin de la
arquitectura y la validacin del sistema.
En la primera seccin se presenta: la identificacin del problema, los objetivos
especficos, los resultados esperados, las metodologas de gestin de proyectos y
de desarrollo de software. Tambin se analizan herramientas similares existentes
en el mercado y se justifica la realizacin del presente proyecto.
En las siguientes secciones se identifican: los requerimientos del sistema, los
actores, mdulos, clases de anlisis, el diseo de la interfaz de usuario, la
arquitectura de la solucin, las principales caractersticas de la construccin y se
describen las pruebas que se realizarn. Finalmente, se presentan las conclusiones
del presente proyecto y las recomendaciones para trabajos futuros.
La referida tesis realiza un aporte significativo en el trabajo que se viene realizando
debido a que cuenta con una metodologa similar a la que se utilizara en el
desarrollo del proyecto pues ambas se tienen como basamento la metodologa
RUP, tambin realiza un gran aporte en la parte del modelado de procesos dado
que la empresa donde se aborda la presente tesis es en el rubro de la
comercializacin.
14
A.3.Trujillo Daz, Marlon David (2013). Anlisis, Diseo e Implementacin de un
Sistema de Planificacin de Procesos Productivos para Pymes de Textiles y
Confecciones. Tesis para optar el Ttulo de Ingeniero Informtico. Pontificia
Universidad Catlica del Per. Per.
El sector textil y de confecciones es una de las industrias ms importantes segn el
INEI (Instituto Nacional de Estadstica e Informtica). Para el primer trimestre del
2012 esta industria represent el 8.8% del PBI (Producto Bruto Interno) global
[CEP2012] lo cual constituye un ingreso substancial para nuestro pas. Uno de los
factores de este desarrollo industrial son las pymes dedicadas a este sector que
debido a esfuerzo, dedicacin y sobretodo loable emprendimiento, han obtenido un
crecimiento sostenido, el cual se ve reflejado en el desarrollo de grandes centros
industriales y comerciales de textiles y confecciones como es el emporio comercial
del distrito de La Victoria conocido como Gamarra.
Las pymes del parque industrial de textiles y confecciones, conocido como
Gamarra, actualmente (2012) concentran ms de 24 mil establecimientos
dedicados a esta industria brindando trabajo a ms de 51 mil personas, albergando
a la clase emprendedora del pas [ECG2012]. Sin embargo, esta clase
emprendedora localizada en este emporio comercial, desde sus inicios, ha
presentado problemas en su produccin, tales como: la sobrecarga de capacidad
de produccin, el escaso control de costos de insumos, el descuido en los tiempos
de entrega de los productos finales [ETC2006]. As pues, estos problemas han
impedido que las empresas puedan aprovechar al mximo oportunidades de
desarrollo como son las exportaciones. Segn el INEI, para el ltimo trimestre del
ao 2011 las exportaciones para el sector textil y prendas de vestir ha aumentado
en un 26.3% [CEP2012] lo cual ha significado una gran oportunidad para las pymes
dedicadas a este sector.
En el presente proyecto se abordar esta problemtica desarrollando un sistema de
informacin que brinde apoyo a las pymes de textiles y confecciones de Gamarra y
as poder realizar una mejora constante y mayor control en sus procesos
productivos de confecciones de prendas de vestir. Se obtendr informacin de un
grupo de empresarios de textiles y confecciones de Gamarra para conocer la forma
de operar de este tipo de empresas, as como, elaborar un perfil de usuario a partir
de los cuales se obtendr los requerimientos necesarios para el desarrollo del
sistema y para los cuales estarn dirigidas las funcionalidades que se
implementaran. Adems, se emplearn metodologas que agilicen el desarrollo y
culminacin del proyecto. As mismo, este sistema de planificacin estar enfocado
a pymes textiles y de confecciones en Gamarra basndose en un algoritmo de
15
 planificacin implementado y aplicado a problemas de este tipo que optimizan el
uso de recursos y los tiempos de entrega de los productos finales. Estas mejoras
ayudaran a la disminucin de problemas en los procesos productivos presentados,
lo cual significar una mejora en el desempeo de estas empresas textiles y de
confecciones.
La referida tesis hace hincapi a lo importante que es tener la informacin de
manera organizada con el fin de darle un valor agregado y que posteriormente
colaborara en procesos no solo operacionales sino en los procesos de toma de
decisin, planificacin, etc. Tambin resalta las deficiencias que se dan dentro de
las MYPES producto de no tener la informacin de manera organizada, para lo cual
se apoya en la implementacin de un sistema de informacin a fin de mejorar esta
situacin, situacin que es muy similar a la que se viene abordando en el trabajo de
investigacin.
A.4.Manottupa Loayza, Roco (2013). Desarrollo de un Sistema de Informacin
para Soporte de Decisiones en el Proceso de Planificacin de Compras en
una Mype Comercial de Productos para Bisutera. Tesis para optar el Ttulo de
Ingeniero Informtico. Pontificia Universidad Catlica del Per. Per.
El presente proyecto de fin de carrera est dirigido a un sector de las Micro y
Pequeas Empresas (MYPEs) comerciales que conforman un considerable
volumen en el mercado peruano, generando empleo y crecimiento en el pas. Las
empresas que venden productos no perecibles, pueden mantener en stock sus
productos con el fin de tenerlos disponibles para cuando se desee colocarlos en
tienda, venta por menor, o venderlos al por mayor desde el almacn.
En el caso de las MYPEs comerciales que venden productos para bisutera se
producen sobrecostos debido a que normalmente tienen stock en exceso. Esto
sucede porque en este tipo de empresas se realizan las compras sin una
planificacin adecuada, sino slo basndose en la percepcin de las ventas
anteriores, lo cual no es suficiente para poder predecir con una mayor exactitud la
cantidad de productos que debe adquirirse. Cuando se realizan las compras de esa
manera, sucede que los productos que son comprados pueden mantenerse por
largos periodos de tiempo en el almacn, y por lo tanto, producir costos de
mantenimiento e impedimento de diversificacin de productos por falta de espacio
en almacn.
Adems, usualmente en este tipo de empresas no se toman un control adecuado
sobre la cantidad de productos que posee la tienda y el almacn, ya que manejan
diferentes unidades para el almacenamiento de productos y para la venta. Es decir,
pueden ser guardados en el almacn en paquetes de un tamao grande o regular,
16
 y vendidas en otra ms pequea. Esto genera que no se pueda tener un
conocimiento exacto sobre el volumen de productos que posee la empresa.
El Sistema de Informacin que se desarroll en el presente proyecto sirve de
soporte para el proceso de toma de decisiones al momento de planificar la cantidad
de productos para bisutera que deben ser adquiridos por la MYPE. Adems, se
manej el uso de las distintas unidades de un mismo producto para poder tener un
mayor control de la cantidad que posee la empresa, as como tambin para la
realizacin de un mejor anlisis en la planificacin de compras.
La presente tesis resalta las deficiencias que tienen la MYPES en el desarrollo de
sus actividades producto de tener un adecuado registro de sus actividades
principales y a su vez esto repercute en la toma de decisiones las cuales no son las
ms apropiadas para su desenvolvimiento, se apoya en las tecnologas de
informacin para mejorar esta situacin y mejorar el rendimiento de la empresa
donde realiza el estudio. Su aporte es de gran importancia pues la problemtica
que se aborda en el presente trabajo tiene caractersticas similares y tambin se
pretende mejorar dicha situacin mediante el apoyo de las tecnologas de
informacin.
A.5 Rodrguez Cabanillas, Keller Gladys (2011). Anlisis Diseo e Implementacin
de una Solucin de Inteligencia de Negocios Para el rea de Compras y
Ventas de una Empresa Comercializadora de Electrodomsticos. Tesis para
optar el Ttulo de Ingeniero Informtico Pontificia Universidad Catlica del
Per. Per.
Las pequeas y medianas empresas comercializadoras de electrodomsticos
crecen en el mercado peruano generando ingresos y empleo. El rpido avance de
la tecnologa permite a ms familias acceder a productos que faciliten su trabajo
diario en el hogar y en el trabajo. Esto obliga a dichas empresas a volverse ms
competitivas en cuanto a precios, promociones, publicidad, tecnologa,
infraestructura y recursos humanos. Las actividades principales de este tipo de
empresas comercializadoras son la compra de electrodomsticos y negociacin con
los proveedores, as como la venta dirigida y el servicio brindado a sus clientes.
Para volverse ms competitivas muchas empresas de este rubro toman decisiones
a base de la experiencia y resultados anteriores.
Debido a que estas decisiones generalmente no se toman de manera estructurada,
se plantea como solucin el uso de una herramienta de inteligencia de negocios
que permita en tiempo real a los gerentes y jefes de producto generar escenarios,
pronsticos y reportes que apoyen a la toma de decisiones en la compra y venta de
electrodomsticos. El uso de esta herramienta se traduce en una ventaja
17
 competitiva y son muchas las empresas que se han beneficiado por la
implementacin de un sistema de inteligencia de negocios, adems se pronostica
que con el tiempo se convertir en una necesidad de toda empresa.
Como solucin de Inteligencia de Negocios se disea un Data Mart de Compras y
un Data Mart de Ventas, luego se realizan los procesos de extraccin,
transformacin y carga de datos, para finalmente explotar los datos mediante
reportes que permitan hacer el anlisis de la informacin.
El proceso de extraccin, transformacin y carga (ETL) permite mover datos de
diferentes fuentes, transformarlos y cargarlos a los Data Marts. El proceso de
Explotacin permite generar los reportes que el usuario final usa para el anlisis de
la informacin y para la toma de decisiones.
Se decide usar software libre para el desarrollo de la solucin y se elige como
herramienta la plataforma de Pentaho, la cual est escrita en Java y presenta una
solucin flexible para cubrir las necesidades de la empresa. Pentaho al ser una
herramienta de software libre es accesible econmicamente a las empresas
comercializadoras de electrodomsticos, brindando as una ventaja diferencial
frente a otras herramientas de inteligencia de negocios de precio elevado.
Pentaho permite la creacin de cubos, la creacin de informes e implementacin de
la plataforma BI (web) lo cual genera un nexo amigable entre la herramienta y los
usuarios finales.
La presente tesis aborda un problemtica similar a la que se tiene en estudio,
adems de hacer uso de las tecnologas de informacin para poder solucionar o
mejorar la problemtica, pero el gran aporte que hace es en el basamento terico
que se tiene, pues se basa en el ciclo de vida que tiene un sistema de informacin y
el cual tambin es soporte para el presente trabajo de investigacin que se viene
desarrollando
2.1 MARCO TERICO
2.2.1 SISTEMAS DE INFORMACIN
Las organizaciones (sistemas sociales) han hecho siempre el uso de la
informacin incluso antes de acuarse el termino sistemas de informacin, es as
que los sistemas de informacin han existido desde tiempos remotos en el que los
seres humanos se reunan para alcanzar un objetivo en comn. Las
organizaciones (sistemas sociales) estn obligadas a tratar con una cantidad
enorme de informacin tanto interna como externa, es as que la informacin le
permite a una organizacin organizarse, reorganizarse continuamente segn su
finalidad y los vnculos, estmulos provenientes de su entorno.

18
Existe una serie de definiciones para definir lo que es sistemas de informacin
pero podemos decir que un sistema de informacin es un conjunto
de componentes que interaccionan entre s para alcanzar un fin determinado, el
cual es satisfacer las necesidades de informacin de dicha organizacin. Estos
componentes pueden ser personas, datos, actividades o recursos materiales en
general, los cuales procesan la informacin y la distribuyen de manera adecuada,
buscando satisfacer las necesidades de la organizacin.
Se puede encontrar distintos enfoques de los sistemas de informacin pero para
esta ocasin consideraremos dos enfoques que son los que tienen ms
importancia para el desarrollo de la tesis.
Transaccional u Operacional: Los sistemas de informacin
transaccionales fueron los primeros en ser incorporados al procesamiento
de un volumen considerable de datos en forma computacional. En el
contexto de transaccionales se debe de establecer que una transaccin es
un intercambio entre el usuario que opera el equipo y el sistema de
procesamiento de datos. Es decir, esto implica la captura y validacin de
los datos ingresados por el usuario, as como la bsqueda y actualizacin
de archivos. Por lo cual podemos establecer que los sistemas de
informacin transaccional estn orientados a satisfacer las necesidades del
nivel operativo de la empresa. Realizando operaciones repetitivas y
sencillas que conllevan a informatizar los procesos que poseen tareas
rutinarias y tediosas, con el fin de minimizar los errores y disminuir la
cantidad de mano de obra.
Decisional: Los sistemas de apoyo a la Toma de Decisiones son aquellos
que tienen por misin ser una herramienta para el apoyo de la funcin
ejecutiva. No hay que dejar de lado que su base como sistema est en
base a los sistemas transaccionales y administrativos, sino este tipo de
sistemas no existira. Estos tipos de sistemas ponen un nfasis en el apoyo
a la toma de decisiones en todas sus fases, aunque hay que establecer
que en definitiva la responsabilidad de tomar la decisin es exclusiva del
responsable. Y la finalidad de estos sistemas es aumentar la eficacia y
disminuir el esfuerzo humano en el proceso de toma de decisiones. Estos
sistemas se orientan a ensamblar la informacin y el juicio humano para
alcanzar mejores resultados en la toma de decisiones.

19
2.2.2 CICLO DE VIDA DE UN SISTEMA DE INFORMACIN
2.2.2.1 DEFINICIN DEL PROBLEMA.
Esta etapa suele ser la primera y la ms difcil de todo el proceso del ciclo
de vida debido a que se encarga del reconocimiento de las fallas o
problemas que una organizacin puede enfrentar.
Tradicionalmente han sido los usuarios y los directivos de las empresas
quienes impulsan la mayora de los proyectos. Por su parte, los analistas
estn encargados de descubrir mejoras dentro de la organizacin; por lo
tanto el analista debe identificar los problemas, las oportunidades y las
normas y objetivos que rigen a la empresa. Problema es una situacin no
deseable que impide que la organizacin pueda alcanzar plenamente sus
propsitos metas y objetivos. Una oportunidad es toda posibilidad de
mejorar el sistema o lograr la ausencia de problemas especficos.
Una norma es todo requisito impuesto por la direccin, las instituciones
gubernamentales o cualquier influencia externa.
Si una oportunidad no es usada en su momento, sta a la larga puede
convertirse en un problema ya que esto pudiera implica el no usar
situaciones favorables tanto para el analista como para la organizacin.
Con relacin a las normas que se aplican en una organizacin, stas
representan problemas, pues implican el cambio de actividades o procesos
internos dentro del tratamiento de informacin.
Los problemas se dan a notar de diversas formas; es decir, stos pueden
estar presentes en la organizacin y tomarse como prcticas normales de
trabajo y depende en gran parte del usuario (directivos) poder descubrir
estos problemas y del analista para determinarlos. La mayora de los
problemas dentro de las organizaciones se refieren al desempeo
(ausentismo, falta de compromiso por parte de los empleados, alta rotacin
de personal).
Sin olvidar a los clientes o proveedores del sistema ya que ellos ejercen el
tipo de retroalimentacin que el sistema est recibiendo. Considere como
retroalimentacin las quejas o sugerencias que se reciben, as como
ventas no consolidadas o canceladas, etc., adems del reflejo al momento
de medir los resultados contra los objetivos planeados. Estos son sntomas
que deben ser tomados en cuenta para iniciar de inmediato el anlisis del
sistema.

20
2.2.2.2 RECOPILACION DE LA INFORMACIN
Esta fase del ciclo de vida del sistema involucra al analista con el sistema,
ya que la tarea principal del analista al finalizar esta etapa es tener una
imagen general del sistema. El analista debe conocer detalladamente las
funciones actuales del sistema para lo cual se considera las siguientes
preguntas:
Quin?: para conocer a la gente involucrada.
Qu?: actividad de la organizacin.
Dnde?: ambiente de trabajo, incluye el lugar.
Cundo?: momento o instante de tiempo en que se realiza la
actividad.
Cmo?: procedimientos o formas para realizar la actividad.
Muchas de estas preguntas sern contestadas si el analista pregunta
sobre el sistema actual que la organizacin est utilizando. Teniendo al
final de esta investigacin una comprensin general del sistema, las
funciones y la informacin sobre personas, datos y procesos que se
realizan.
2.2.2.3 ANALISIS DE LA INFORMACIN
Anlisis se le llama al proceso de identificacin e interpretacin de hechos,
es la fase donde se realiza el diagnstico de problemas empleando
informacin con el fin de recomendar mejoras. Dentro de las actividades
que se realizan en un anlisis se encuentran: examinar, detallar, describir,
descomponer, observar, descubrir, comparar, estudiar, explorar,
cuestionar, diagnosticar y pronosticar. Surge como respuesta a las
necesidades de mejorar el uso de los recursos informticos para satisfacer
los nuevos requisitos del proceso de informacin de las aplicaciones en las
empresas.
Para realizar un anlisis se necesita tomar en cuenta los siguientes puntos:
Se debe tener una situacin.
Se debe conocer la naturaleza del sistema.
Comprender al sistema en su totalidad considerando su actual
funcionamiento.
Considerar si es factible el uso de la computadora para hacer ms
eficiente al sistema.
Marcar un objetivo a lograr
El uso de informacin puede iniciarse por un sin nmero de razones como:

21
 Solicitud de empleados y usuarios del sistema.
Necesidades de informacin de los niveles directivos.
Es as que al considerar estas peticiones es necesario investigar si el
sistema que actualmente funciona en la organizacin cubre las
necesidades y en qu porcentaje, para saber con exactitud lo que el
solicitante desea, por lo que la solicitud del proyecto debe incluir todas y
cada una de las necesidades a cubrir.
Esta actividad permitir al analista determinar si es conveniente redisear
el sistema actual, disear uno nuevo, comprar el sistema de informacin
considerando el costo, los resultados esperados y el perfeccionamiento de
las actividades (aun considerando que algunas de stas sean de forma
manual).Para que esta investigacin se realice se debe elaborar un plan o
programa de trabajo para dar a conocer al cliente cada una de las
actividades que la investigacin involucra y el tiempo que requerirn, as
como los usuarios que debern ser investigados. Antes de implantar el
plan de investigacin es necesario conocer:
Fuentes Internas: son todas las personas contactos en la
investigacin, aquellas de nivel jerrquico de la unidad afectada, as
como los usuarios operativos y administradores.
Fuentes Externas: considerar a todas las dependencias que tienen
relacin al sistema a investigar, sus clientes y personal que se
encuentra involucrado, sin olvidar a la informacin que ellos
generan.
Hay que considerar que el trabajo del anlisis no es una funcin para un
solo analista; este debe crear grupos de trabajo que deben encargarse de
recopilar y analizar datos para saber si existe coincidencia de anomalas
en el sistema.
El anlisis de la informacin es la etapa ms importante del anlisis debido
a que se va a evaluar el sistema que se investig; para ello se integrar la
informacin recopilada durante todo el proceso anterior de investigacin,
obteniendo como resultados la mejora del sistema y la factibilidad de su
mejoramiento si as lo requiere.
Las actividades a realizar dentro de esta etapa son:
Cruce de la informacin: el analista se rene con sus colaboradores
y de los datos recopilados se determinan aquellos lugares crticos o

22
 vulnerables dentro de la organizacin que determinan los
problemas que la empresa est enfrentando.
Anlisis de alternativas: una vez expuestos los problemas de la
organizacin y localizados los procesos a ser mejorados se
debern analizar todas y cada una de las alternativas de solucin
utilizando la informacin recabada. Tales alternativas podran ser:
Aceleracin de procesos
Eliminar procesos innecesarios
Combinacin de procesos (manual y automatizado)
Reduccin de errores
Reduccin de salidas redundantes
Integracin de sistemas
Satisfaccin del trabajador
Mejora en la interaccin cliente- servidor
La alternativa a escoger estar en funcin directa del estudio de
factibilidad correspondiente para respaldar su implementacin. La
factibilidad es valorada en tres formas principales para su posterior
evaluacin:
Factibilidad tcnica.
Factibilidad econmica.
Factibilidad operacional.
Para valorar la factibilidad se hace uso de herramientas como lo es el
anlisis costo / efectividad.
2.2.2.4 DISEO DE EL SISTEMA
Conocidas ya las necesidades de los usuarios, se procede a realizar el
diseo del sistema de informacin. Ahora el trabajo del analista consiste en
disear procedimientos precisos y eficaces para el procesamiento de
datos, a fin de que al ser usados por el sistema sean los correctos; es decir
crear entradas efectivas para que los resultados esperados sean los
correctos, mediante el uso de formas y pantallas, se ocupa de desarrollar
las directrices propuestas durante el anlisis en trminos de aquel la
configuracin que tenga ms posibilidades de satisfacer los objetivos
planteados.
A continuacin en la grfico N2.1, se detallaran los objetivos generales y
especficos los cuales se pretende lograr al realizar el diseo de sistemas.

23
 Grfico N2.1
Objetivos Generales y Especficos del Diseo de Sistemas

Tomado de: Exposicin 2005, Colombia. Dra. Alexandra Aparicio

Como se mencion en el diseo se pueden encontrar una variedad de
posibilidades, es por tal motivo que se muestra la Tabla N2.1 donde se
aprecia los objetivos generales de todo diseo, dentro de los cuales tienen
sus propios objetivos especficos.
2.2.2.5 PROGRAMACIN
Dentro de este aspecto el analista deben considerar si el software a utilizar
ser comprado a terceros o bien disear software de acuerdo a las
necesidades del sistema. La eleccin en cada caso depender del costo
de cada una de las alternativas, el tiempo disponible para el desarrollo y de
la disponibilidad de programadores (accin que puede ejercer el analista
como analista programador).
En caso de seleccionar el desarrollo del software se tendrn que realizar
todas y cada una de las tcnicas que para el desarrollo de software se
conocen y sean adecuadas dependiendo de la pericia del programador.
2.2.2.5.1 Eleccin del Lenguaje de Programacin
El analista junto con el grupo de trabajo deber elegir y aplicar el
lenguaje de programacin ms adecuado para la realizacin del
software para desarrollar el sistema. La eleccin del software
depender en gran parte del conocimiento y experiencia del
analista al usar determinados lenguajes; otro tipo de elemento
que determinar la aplicacin de un lenguaje ser el tipo de

24
 sistema a realizar, ya que dependiendo de lo que se desee en
cuestin del sistema, se seleccionar el lenguaje que facilite su
creacin.
2.2.2.6 PRUEBAS DEL PROGRAMA
El realizar pruebas a cada uno de los elementos que conforman el nuevo
sistema de informacin es una tarea fundamental para garantizar su
adecuado funcionamiento y evitar resultados no favorables al momento de
implantarlo. Por ello, es necesario considerar que los datos contengan la
mayor variedad de condiciones posibles a fin de probar toda la capacidad
de cada programa y que las anomalas detectadas sean corregidas de
forma inmediata, adems de hacer lo mismo con la documentacin. Es
muy importante recordar que el probar un sistema no es prdida de tiempo.
Las fuentes para la obtencin de datos de prueba son los datos reales y
los artificiales, cada uno con sus ventajas e inconvenientes.
Uso de Datos de Prueba Reales
Este tipo de datos son extrados de los archivos de la organizacin;
se usan estos datos para probar parcialmente al sistema.
Uso de Datos de Prueba Artificiales.
Los datos de prueba artificiales se crean slo con fines de prueba, y
son usados para generar todas las combinaciones de formato y de
valores.
La prueba del programa es responsabilidad de quien programa y del
analista, aunque slo es un indicador para conocer el funcionamiento del
sistema y slo se limitan a pruebas en papel.
2.2.2.7 DOCUMENTACIN
Un sistema debe contemplar una documentacin adecuada y completa
para mantenerlo y actualizarlo de manera satisfactoria; sin embargo
muchos analistas hacen caso omiso de este aspecto. La documentacin se
realizar a lo largo de todo del desarrollo del sistema de informacin,
documentando al detalle y cada particularidad.
Al documentar un sistema se debe buscar cubrir los siguientes objetivos:
Estandarizar la documentacin.
Facilitar el desarrollo de la misma.
Ahorrar tiempo.
Facilitar el mantenimiento del sistema
Garantizar un mejor manejo del sistema

25
 Una vez contemplados los puntos anteriores, es necesario aplicar estas
ventajas para realizar la documentacin del sistema, debido a que si se
logra una documentacin eficiente del sistema se tendrn las siguientes
ventajas:
Ser una herramienta didctica para nuevos miembros de la
organizacin y por lo tanto nuevos usuarios.
Es requisito bsico para quien tenga la responsabilidad del
manteamiento del sistema o modificacin del mismo.
Ayuda a los analistas a trabajar en reas relativas, evitando
redundancias y facilitando la integracin de todos los sistemas.
Asegura que el sistema opere correctamente con el mnimo de
errores.
Los recursos se usan de forma ms eficiente.
2.2.2.8 IMPLANTACION
La implantacin involucra a todas las actividades que se dan al pasar de
un sistema viejo a uno nuevo. Se pueden encontrar las siguientes
situaciones al hablar de implantacin:
El sistema es totalmente nuevo y reemplaza al que ya existe, sea
de forma manual o automatizada.
Puede ser una modificacin hacia algunos de los componentes del
sistema que actualmente se usan.
Cualquiera que sea la forma en la que se haya modificado a la
organizacin, la implantacin es un elemento determinante para el buen
funcionamiento del sistema y que permita lograr sus objetivos
2.2.3 METODOLOGA RUP
Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de
Racional) es un producto del proceso de ingeniera de software que proporciona
un enfoque disciplinado para asignar tareas y responsabilidades dentro de una
organizacin del desarrollo. Su meta es asegurar la produccin del software de
alta calidad que resuelve las necesidades de los usuarios dentro de un
presupuesto y tiempo establecidos. Segn Jacaboson, Boochy Rumbaugh J.
(1998) El nombre Proceso Unificado se usa para describir el proceso genrico que
incluye aquellos elementos que son comunes a la mayora de los refinamientos
existentes. Tambin permite evitar problemas legales yaque Proceso Unificado de
Rational o RUP son marcas registradas por IBM (desde su compra de Rational
Software Corporation en 2003). Segn Grady Booch(2000) un reflejo de lo que

26
hemos visto en el trabajo con literalmente decenas de miles de proyectos en los
ltimos 20 aos, la codificacin de lo que funciona en las organizaciones exitosas
y lo que est notablemente ausente en los fallidos.
El RUP tiene dos dimensiones:
El eje horizontal representa tiempo y demuestra los aspectos del ciclo de
vida del proceso.
El eje vertical representa las disciplinas, que agrupan actividades definidas
lgicamente por la naturaleza.
La primera dimensin representa el aspecto dinmico del proceso y se expresa en
trminos de fases, de iteraciones, y la finalizacin de las fases.
La segunda dimensin representa el aspecto esttico del proceso: cmo se
describe en trminos de componentes de proceso, las disciplinas, las actividades,
los flujos de trabajo, los artefactos, y los roles.
A su vez la metodologa RUP plasma el desarrollo de software mediante el uso
de las herramientas del modelado UML (caso de uso diagrama de secuencia y
diagrama de clases), el cual se plasma de manera explcita en el anexo N1.
A continuacin en la grfico N2.2 en el cual se muestra las fases de la
metodologa RUP.
Grfico N2.2
Fases de la metodologa RUP

Tomado de: Proceso Unificado de Desarrollo de Software 2000, New York. Jacaboson.

27
 En la grfico 2.2 se puede observar como vara el nfasis de cada disciplina en un
cierto plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en
iteraciones tempranas, pasamos ms tiempo en requerimientos, y en las ltimas
iteraciones pasamos ms tiempo en poner en prctica la realizacin del proyecto
en sistemas de informacin.
2.2.4 LENGUAJE UNIFICADO DE MODELADO (UML)
UML es una consolidacin de muchas de las notaciones y conceptos ms usados
orientados a objetos. Empez como una consolidacin del trabajo de Grade
Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologas
orientadas a objetos ms populares. En 1996, el Object Management Group
(OMG), un pilar estndar para la comunidad del diseo orientado a objetos,
public una peticin con propsito de un meta modelo orientado a objetos de
semntica y notacin estndares. UML, en su versin 1.0, fue propuesto como
una respuesta a esta peticin en enero de 1997. Hubo otras cinco propuestas
rivales. Durante el transcurso de 1997, los seis promotores de las propuestas,
unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado
UML versin 1.1. este documento fue aprobado por el OMG en Noviembre de
1997.
El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y
diagramas estndar para modelar sistemas orientados a objetos, y describe la
semntica esencial de lo que estos diagramas y smbolos significan. Mientras que
ha habido muchas notaciones y mtodos usados para el diseo orientado a
objetos, ahora los modeladores slo tienen que aprender una nica notacin.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de
software, sistemas de hardware y organizaciones del mundo real. UML ofrece
nueve diagramas en los cuales se pueden modelar sistemas.
2.2.4.1 DIAGRAMAS UML
Los diagramas UML Permiten dividir un modelo y reagrupar y encapsular
los elementos de modelado y se representa con una carpeta con nombre
Cada paquete corresponde a un subconjunto del modelo pudiendo
contener clases, objetos, relaciones, componentes y sus diagramas
asociados.
A. Diagramas de Casos de Uso
Los diagramas de casos de uso documentan el comportamiento de un
sistema desde el punto de vista del usuario. Por lo tanto los casos de
uso determinan los requisitos funcionales del sistema, es decir,

28
representan las funciones que un sistema puede ejecutar. Su ventaja
principal es la facilidad para interpretarlos, lo que hace que sean
especialmente tiles en la comunicacin con el cliente. A continuacin
se presenta algunos elementos bsicos para el modelado de casos de
uso:
Actores: Los actores representan un tipo de usuario del
sistema. Se entiendo como usuario cualquier cosa externa que
interacta con el sistema. No tiene por qu ser un ser humano,
puede ser otro sistema informtico o unidades organizativas o
empresas. En el grfico N 2.3 se muestra la representacin de
un actor en el modelado de caso de uso.
Grfico N 2.3
Representacin Grfica de un Actor

actor

Fuente: UML
Elaboracin: Elaboracin Propia
En el grfico mostrado anteriormente se puede visualizar la
representacin grfica de un actor en el modelado de casos de
uso.
Caso de uso: Es una tarea que debe poder llevarse a cabo
con el apoyo del sistema que se est desarrollando. Se
representan mediante un vulo. Cada caso de uso debe
detallarse, habitualmente mediante una descripcin textual,
seguidamente se presenta el grfico N 2.4 en el cual se
muestra la representacin de un caso de uso.
Grfico N 2.4
Representacin Grfica de Caso de Uso

caso de uso

Fuente: UML
Elaboracin: Elaboracin Propia

Asociaciones: Una asociacin ocurre entre un actor y un caso

de uso cuando el actor interacta con el sistema para llevar a

29
 cabo el caso de uso, para la cual seguidamente se muestra el
grfico N 2.5 en el cual se puede apreciar como representar
una asociacin en el modelado de caso de uso
Grfico N 2.5
Representacin Grfica de una Asociacin

solicitar libro

socio_biblioteca

Fuente: UML
Elaboracin: Elaboracin Propia

Escenario es una interaccin entre el sistema y los actores,

que puede ser descrito mediante una secuencia de mensajes.
Un caso de uso es una generalizacin de un escenario.
Ya explicado los elementos bsicos para el modelado de casos de
uso, en el anexo 1 se muestra un ejemplo de un caso de uso, en el
cual se recurrir a los elementos anteriormente explicados.
B. Diagramas de Secuencia
Los diagramas de Secuencias se podrn representar las interacciones
que van a tener los objetos en un determinado escenario, en un
mucho de los casos son utilizados para poder ampliar la explicacin un
determinado caso de uso, los elementos bsicos en el diagrama de
secuencia son los siguientes:
Lnea de Vida: Una lnea de vida representa un participante
individual en un diagrama de secuencia, usualmente se
representa mediante un rectngulo que contiene el nombre del
objeto, para un mejor panorama se muestra el grfico N 2.6 en
el cual se representa la lnea de vida en un diagrama de
secuencia.
Grfico N 2.6
Lnea de Vida en un diagrama de secuencia

objeto 1 objeto 2 objeto 3

Fuente: UML

30
 Elaboracin: Elaboracin Propia
En el grafico mostrado anteriormente se puede apreciar la
representacin de un diagrama de secuencia el cual como ya
se dijo est representada por un rectngulo, pero algunas
veces un diagrama de secuencia tendr una lnea de vida con
un smbolo del elemento actor en la parte superior, para un
mejor entendimiento de esto se presenta el grfico N 2.7, en el
cual se puede apreciar la lnea de vida relacionado con
diferentes elementos, lo cual es bastante posible en el
desarrollo de un sistema de informacin.

Grfico N 2.7
Lnea de Vida en un diagrama de secuencia

objeto 1 objeto 2

: actor

Fuente: UML
Elaboracin: Elaboracin Propia
En el grafico anterior se puede apreciar que no necesariamente
la lnea de vida est representada por un rectngulo, esto se da
usualmente cuando un diagrama de secuencia es contenido
por un caso de uso. Los elementos entidad, control y lmite de
los diagramas de robustez tambin pueden contener lneas de
vida
Mensajes: Los mensajes se representa como flechas
horizontales, pueden ser completos, perdidos o encontrados,
sncronos o asncronos (llamadas o seales). En el siguiente
grafico N 2.8 se muestra la representacin del envo de
mensajes.
Grfico N 2.8
Representacin Grfica de envo de mensajes
31
 Fuente: UML
Elaboracin: Elaboracin Propia
En el grafico anterior se plasma diferentes tipos de mensajes
en cual el primer mensaje es un mensaje sncrono (denotado
por una punta de flecha oscura), completo con un mensaje de
retorno implcito; el segundo mensaje es asncrono (denotado
por una punta de flecha en lnea) y el tercero es un mensaje de
retorno asncrono (denotado por una lnea punteada).
Inicio y final de lnea de vida: Una lnea de vida en un
diagrama de secuencia tiene un inicio y un final o creacin y
destruccin durante la escala de tiempo y para mejor
comprensin de esto a continuacin en el grfico N 2.9 se
muestra un objeto que fue creado y destruido.
Grfico N 2.9
Creacin y Destruccin de mensajes

Fuente: UML

32
 Elaboracin: Elaboracin Propia
En el grafico mostrado anteriormente se puede apreciar que en
el ltimo caso, la lnea de vida se termina por un smbolo de
detencin o destruccin, representado como una cruz. En el
primer caso, el smbolo al inicio de la lnea de vida se muestra
en un nivel ms bajo de la pgina que el smbolo del objeto que
caus la creacin.
A continuacin en el anexo 2 se presenta un ejemplo de un diagrama
de secuencia, la cual se elabora teniendo en consideracin los
elementos anteriormente explicados.

C. Diagrama de Clases
El Diagrama de Clases es el diagrama principal para el anlisis y
diseo, Un diagrama de clases presenta las clases del sistema con
sus relaciones estructurales y de herencia, La definicin de clase
incluye definiciones para atributos y operaciones, para un mejor
entendimiento a continuacin se explica algunos elementos bsicos
del diagrama de clases.
Clase: Es una tabla en la cual se almacenan datos de los
objetos que tengan los mismos atributos y comportamiento se
agrupan en clases.. La representacin de una clase se muestra
en el grafico N 3.10.
Grfico N 2.10
Representacin de una clase

nombre de clase

+atributo 1
+atributo 2

+operacion 1()
+operacion 2()

Fuente: UML
Elaboracin: Elaboracin Propia
En el grafico anterior se tiene la representacin de una clase,
en la cual se puede apreciar que en la parte superior esta
nombre de la clases, pues esta sirve para identificar a la
clases, tambin se puede ver que estn agrupados una serie

33
 de atributos y operaciones, los cuales son los atributos y
operaciones en comn que va a tener cada objeto que
pertenezca a esta clase, para mejor entendimiento se tiene el
siguiente caso:
Todos los alumnos tienen una serie de atributos comunes:
nombre, apellido Paterno, apellido materno, fecha de
nacimiento y un comportamiento comn: podemos hacer
referencia a un alumno para matricularlo o retirarlo. Los valores
de los atributos podrn ser distintos para cada una de ellos,
pero todos comparten los mismos atributos y comportamiento
(las operaciones que se pueden realizar sobre ellos)
Relaciones entre Clases: Ahora ya definido el concepto de
Clase, es necesario explicar cmo se pueden interrelacionar
dos o ms clases (cada uno con caractersticas y objetivos
diferentes). Para la cual es necesario explicar el concepto de
cardinalidad de relaciones, en UML, la cardinalidad de las
relaciones indica el grado y nivel de dependencia, se anotan en
cada extremo de la relacin y stas pueden ser:
Uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
Nmero fijo: m (m denota el nmero).
Herencia (Especializacin/Generalizacin): Indica que una
subclase hereda los mtodos y atributos especificados por una
Sper Clase, por ende la Subclase adems de poseer sus
propios mtodos y atributos, poseer las caractersticas y
atributos visibles de la Sper Clase (public y protected).
En el grfico N 2.11 se muestra como se representa la
propiedad de herencia en el diagrama de clases.
Grfico N 2.11
Representacin grfica de herencia.

34
 vehiculo

+velocidad
+llantas
+precio

+caracteristicas()

automvovil camioneta

+descapotable +carga
+tara
+subir()
+bajar() +cargar()

Fuente: UML
Elaboracin: Elaboracin Propia
En la figura anterior se puede apreciar que auto y camin
heredan de vehculo, es decir, auto posee las caractersticas de
vehculo (Precio, VelMax, etc.) adems posee algo particular
que es descapotable, en cambio Camin tambin hereda las
caractersticas de Vehiculo (Precio, VelMax, etc) pero posee
como particularidad propia acoplado, tara y carga. Cabe
destacar que fuera de este entorno, lo nico visible es el
mtodo caractersticas aplicable a instancias de vehculo,
auto y camin, pues tiene definicin pblica, en cambio
atributos como descapotable no son visibles por ser privados.
Agregacin: Para modelar objetos complejos, no bastan los
tipos de datos bsicos que proveen los lenguajes: enteros,
reales y secuencias de caracteres. Cuando se requiere
componer objetos que son instancias de clases definidas por el
desarrollador de la aplicacin, tenemos dos posibilidades:
Por Valor: Es un tipo de relacin esttica, en donde el tiempo
de vida del objeto incluido est condicionado por el tiempo de
vida del que lo incluye. Este tipo de relacin es comnmente
llamada composicin (el Objeto base se construye a partir del
objeto incluido, es decir, es "parte/todo").
Por Referencia: Es un tipo de relacin dinmica, en donde el
tiempo de vida del objeto incluido es independiente del que lo
incluye. Este tipo de relacin es comnmente llamada
agregacin (el objeto base utiliza al incluido para su

35
 funcionamiento). A continuacin se presenta el grfico N 2.12
en el cual se representa una agregacin por referencia.
Grfico N 2.12
Agregacin por referencia en el diagrama de clases

almacen

cuentas cliente

Fuente: UML
Elaboracin: Elaboracin Propia

Asociacin: La relacin entre clases conocida como

asociacin, permite asociar objetos que colaboran entre s.
Cabe destacar que no es una relacin fuerte, es decir, el
tiempo de vida de un objeto no depende del otro. En el grfico
N 2.13 se muestra la asociacin en el diagrama de clases.

Grfico N 2.13
Asociacin en el diagrama de clases

cliente orden compra

Fuente: UML
Elaboracin: Elaboracin Propia
En el grfico anterior se muestra que un cliente puede tener
asociadas muchas rdenes de compra, en cambio una orden
de compra solo puede tener asociado un cliente.
Dependencia o Instanciacin (uso): Representa un tipo de
relacin muy particular, en la que una clase es instanciada (su
instanciacin es dependiente de otro objeto/clase). Se denota
por una flecha punteada. El uso ms particular de este tipo de
relacin es para denotar la dependencia que tiene una clase de

36
 otra, como por ejemplo una aplicacin grafica que instancia una
ventana (la creacin del Objeto Ventana est condicionado a la
instanciacin proveniente desde el objeto Aplicacin).
Seguidamente se presenta el grfico N 2.14 en el cual se
podr apreciar la representacin de una dependencia entre
clases.
Grfico N 2.14
Dependencia Entre Clases

aplicacion ventana

Fuente: UML
Elaboracin: Elaboracin Propia
En el grfico mostrado anteriormente cabe destacar que el
objeto creado (en este caso la Ventana grfica) no se
almacena dentro del objeto que lo crea (en este caso la
Aplicacin).
A continuacin en el anexo 3 se presenta un ejemplo de un diagrama de
clases, la cual se elabora teniendo en consideracin los elementos
anteriormente explicados.

2.2.5 MYSQL
MySQL es un sistema de gestin de bases de datos relacional, multihilo y
multiusuario con ms de seis millones de instalaciones.
MYSQL se ofrece bajo la GNU GPL para cualquier uso compatible con esta
licencia, pero para aquellas empresas que quieran incorporarlo en productos
privativos deben comprar a la empresa una licencia especfica que les permita
este uso.
Al contrario de proyectos como Apache, donde el software es desarrollado por
una comunidad pblica y los derechos de autor del cdigo estn en poder del
autor individual, MySQL es patrocinado por una empresa privada, que posee el
copyright de la mayor parte del cdigo. Esto es lo que posibilita el esquema de
licenciamiento anteriormente mencionado. Adems de la venta de licencias
privativas, la compaa ofrece soporte y servicios. Para sus operaciones

37
contratan trabajadores alrededor del mundo que colaboran va Internet. MySQL
AB fue fundado por David Axmark, Allan Larsson y Michael Widenius.
Existen varias interfaces de programacin de aplicaciones que permiten, a
aplicaciones escritas en diversos lenguajes de programacin, acceder a las
bases de datos MySQL, incluyendo C, C++, C#, Pascal, Delphi (via dbExpress),
Eiffel, Smalltalk, Java (con una implementacin nativa del driver de Java), Lisp,
Perl, PHP, Python, Ruby,Gambas, REALbasic (Mac y Linux), (x)Harbour
(Eagle1), FreeBASIC, y Tcl; cada uno de estos utiliza una interfaz de
programacin de aplicaciones especfica. Tambin existe una interfaz ODBC,
llamado MyODBC que permite a cualquier lenguaje de programacin que
soporte ODBC comunicarse con las bases de datos MySQL. Tambin se puede
acceder desde el sistema SAP, lenguaje ABAP.
2.2.5.1 Caractersticas MYSQL
Inicialmente, MySQL careca de elementos considerados esenciales en
las bases de datos relacionales, tales como integridad referencial y
transacciones. A pesar de ello, atrajo a los desarrolladores de pginas
web con contenido dinmico, justamente por su simplicidad.
Poco a poco los elementos de los que careca MySQL estn siendo
incorporados tanto por desarrollos internos, como por desarrolladores de
software libre. Entre las caractersticas disponibles en las ltimas
versiones se puede destacar:
Amplio subconjunto del lenguaje SQL
Disponibilidad en gran cantidad de plataformas y sistemas.
Posibilidad de seleccin de mecanismos de almacenamiento
que ofrecen diferente velocidad de operacin, soporte fsico,
capacidad, distribucin geogrfica, transacciones.
Transacciones y claves forneas.
Conectividad segura.
Replicacin.
Bsqueda e indexacin de campos de texto.
MySQL es un sistema de administracin de bases de datos., una base de
datos es una coleccin estructurada de tablas que contienen datos. Esta
puede ser desde una simple lista de compras a una galera de pinturas o
el vasto volumen de informacin en una red corporativa. Para agregar,
acceder a y procesar datos guardados en un computador, usted necesita
un administrador como MySQL Server. Dado que los computadores son

38
 muy buenos manejando grandes cantidades de informacin, los
administradores de bases de datos juegan un papel central en
computacin, como aplicaciones independientes o como parte de otras
aplicaciones.
MySQL es un sistema de administracin relacional de bases de datos,
una base de datos relacional archiva datos en tablas separadas en vez
de colocar todos los datos en un gran archivo. Esto permite velocidad y
flexibilidad. Las tablas estn conectadas por relaciones definidas que
hacen posible combinar datos de diferentes tablas sobre pedido.
MySQL es software de fuente abierta, fuente abierta significa que es
posible para cualquier persona usarlo y modificarlo. Cualquier persona
puede bajar el cdigo fuente de MySQL y usarlo sin pagar. Cualquier
interesado puede estudiar el cdigo fuente y ajustarlo a sus necesidades.
MySQL usa el GPL (GNU General Public License) para definir qu puede
hacer y qu no puede hacer con el software en diferentes situaciones. Si
usted no se ajusta al GPL o requiere introducir cdigo MySQL en
aplicaciones comerciales, usted puede comprar una versin comercial
licenciada.
2.2.6 LENGUAJE DE PROGRAMACION
Es un idioma formal diseado para expresar procesos que pueden ser llevados a
cabo por computadoras. Pueden ser usados para crear programas que controlen
el comportamiento fsico y lgico de una mquina, para expresar algoritmos con
precisin, o como modo de comunicacin humana. Est formado por un conjunto
de smbolos y reglas sintcticas y semnticas que definen su estructura y el
significado de sus elementos y expresiones. Al proceso por el cual se escribe, se
prueba, se depura, se compila y se mantiene el cdigo fuente de un programa
informtico se le llama programacin.
2.2.6.1 JAVA
Java es un lenguaje de programacin de propsito
general, concurrente, orientado a objetos y basado en clases que fue
diseado especficamente para tener pocas dependencias de
implementacin como fuera posible. Su intencin es permitir que
los desarrolladores de aplicaciones escriban el programa una vez y lo
ejecuten en cualquier dispositivo (conocido en ingls como WORA, o "write
once, run anywhere"), lo que quiere decir que el cdigo que es ejecutado
en una plataforma no tiene que ser recompilado para correr en otra. Java
es, a partir de 2012, uno de los lenguajes de programacin ms populares
39
 en uso, particularmente para aplicaciones de cliente-servidor de web, con
unos 10 millones de usuarios reportados.
El lenguaje de programacin Java fue originalmente desarrollado
por James Gosling de Sun Microsystems (la cual fue adquirida por la
compaa Oracle) y publicado en 1995 como un componente fundamental
de la plataforma Java de Sun Microsystems. Su sintaxis deriva en gran
medida de C y C++, pero tiene menos utilidades de bajo nivel que
cualquiera de ellos. Las aplicaciones de Java son
generalmente compiladas a bytecode (clase Java) que puede ejecutarse
en cualquier mquina virtual Java (JVM) sin importar la arquitectura de la
computadora subyacente.
La compaa Sun desarroll la implementacin de referencia original para
los compiladores de Java, mquinas virtuales, libreras de clases en 1991
y las public por primera vez en 1995. A partir de mayo de 2007 en
cumplimiento con las especificaciones del proceso de la comunidad Java,
Sun volvi a licenciar la mayora de sus tecnologas de Java bajo
la Licencia Pblica General de GNU
2.2 MODELO APLICATIVO
A continuacin en el grfico N 2.15 se muestra el modelo aplicativo de la metodologa
que se aplicar en el desarrollo del trabajo de investigacin, el cual a su vez es una
sntesis de la teora plasmada anteriormente.

Grfico N2.15
Modelo Aplicativo

40
Elaboracin: Propia
Basado en: Kendally Kendall (2005) Anlisis y Diseo de Sistemas. Prentice. Mxico.
2.3.1 CONCEPTUALIZACIN
Esta es la fase de inicio del desarrollo del proyecto de investigacin donde se
realizar una descripcin de la situacin actual, posterior a esto se realizar la
definicin del sistema de referencia esto con la intencin de obtener un panorama
amplio e integral de la situacin bajo estudio, est definicin del sistema es de
mucha importancia debido a que en cierta medida determinar la funcin que
cumplir el sistema de informacin.
2.3.2 ANLISIS
En esta fase de la investigacin se realizar la identificacin y evaluacin de los
procesos que se realiza en la situacin bajo estudio esto con la intencin de
realizar un sistema de informacin en funcin a las actividades que se realizan y
no en funcin a las entidades que operan. La identificacin de procesos nos
ayudar a definir lo que exactamente deber hacer el sistema de informacin,
posterior a esto se analizar la informacin y se determinar los requerimientos en
funcin a los procesos identificados.
2.3.3 DISEO

41
 Conocidas las necesidades y requerimientos de los usuarios, se proceder a
realizar el diseo del sistema de informacin, se disearan los procedimientos
precisos y eficaces para el procesamiento de datos a fin de que al ser usados
sean los correctos, de similar manera se diseara las entradas, salidas, diseo de
archivos, base de datos. En esta fase tambin se analizar el hardware que dar
soporte al sistema de informacin.
2.3.4 IMPLEMENTACIN
En este aspecto se evaluar el software ms apropiado para el desarrollo del
sistema de informacin, esta evaluacin se har en funcin al costo, el diseo de
la base de datos y la disponibilidad de programadores en los diferentes lenguajes
de programacin.
2.3.5 PRUEBAS
En esta etapa del desarrollo se realizar pruebas a cada uno de los elementos
que conforman el nuevo sistema de informacin, est es una tarea fundamental
para garantizar su adecuado funcionamiento y evitar resultados no favorables al
momento de implantarlo, es por eso que al realizar la pruebas se tenga la mayor
variedad de condiciones posibles a fin de probar toda la capacidad de cada
programa para posteriormente corregir las anomalas detectadas adems de
hacer los mismo con la documentacin.
2.3.6 IMPLANTACIN
En esta etapa se realiza todas las actividades necesarias para poner en marcha el
nuevo sistema de informacin.
2.4 MARCO CONCEPTUAL
Data: Es considerada como una porcin de la informacin, para nuestro caso es
equivalente a registrar una compra, venta, cliente, etc. pero de manera bruta.
Diseo: campo de conocimiento multidisciplinario que se caracteriza por su
usabilidad ms no por su originalidad.

42
 Factibilidad econmica: se refiere a valorar si los beneficios obtenidos sern
suficientes para aceptar los costos del nuevo proyecto, o bien el no llevar a cabo
el proyecto.
Factibilidad operacional: Etapa la cual depende de los recursos humanos, ya
que ellos determinarn en gran medida si se desarrolla e implanta el nuevo
sistema.
Factibilidad tcnica: sta se refiere a la valoracin de los recursos tcnicos con
los que cuenta la organizacin, si permiten realizar el proyecto o se necesitan
nuevos recursos (personal, software, material, etc.);
Generacin de conocimiento: Es el valor agregado que se le puede dar a la
informacin que se dispone, principalmente relacionando las diferentes
informaciones que se pueda tener
Informacin: Es el conjunto de data registrada en cierta manera clasificada y
ordenada.
Organizacin Informacin: Es el orden, la clasificacin de acuerdo a las
necesidades y la disponibilidad inmediata que se pueda tener a la informacin.
Sistema: conjunto de elementos interrelacionados los cuales responden de
manera global, a su vez estos elementos comparten un fin comn.
Sistema de Informacin: Es una disposicin de componentes integrados entre s
cuyo objetivo es satisfacer las necesidades de informacin en una organizacin.
Sistemas Referencia: Bosquejo grfico de la situacin bajo estudio en el cual se
aprecia las entradas, salidas, transformacin y el entorno en el cual se da la
situacin bajo estudio.
Sistemas sociales: Hace referencia a las diferentes entidades como: empresas,
instituciones pblicas, en general cualquier institucin donde haya intervencin del
ser humano.
Software: Es el soporte lgico de un sistema informtico y el que hace posible la
realizacin de tareas especficas
Proceso: Conjunto de actividades mutuamente relacionadas o que interactan,
las cuales transforman elementos de entrada en resultados.
Eficiencia: habilidad de contar con algo o alguien para obtener un resultado
Modelo: Es lo que describe completamente aquellos aspectos del sistema que
son relevantes al propsito del modelo, y a un apropiado nivel de detalle.
En este captulo lo que se hizo es exponer todo el fundamento terico en el cual nos
apoyaremos para mejorar la situacin problemtica expuesta en el primer captulo, y en la
cual concluimos con modelo aplicativo que es una sntesis de toda la teora expuesta.

43
 CAPTULO III
INTERVENCION METODOLGICA
En el presente captulo se aplicar la metodologa desarrollada en el captulo II, la cual se
aplicar en funcin al modelo aplicativo propuesto para el desarrollo del trabajo de
investigacin, a travs del cual se buscara mejorar la situacin inicial planteada en el
captulo I y as lograr los objetivos propuestos en el trabajo de investigacin.
3.1 CONCEPTUALIZACIN
Microempresa Fungger System, se dedica a la comercializacin de equipos de cmputo
y afines, adems de brindar servicio de soporte tcnico de los mismos.
Actualmente la microempresa adquiere los productos de los proveedores con los que
cuenta, se puede apreciar que la mayor parte de sus proveedores operan en la ciudad
de lima es por tal motivo que la compra de los diferentes productos lo hace en grandes
cantidades, cuenta con un almacn donde se guarda la mercadera hasta el momento
de efectuar la venta y es que al momento de ingresar la mercadera a almacn se
registra cada producto, el cual actualmente lo hacen en hojas de cuadernos; por otro
lado tambin se aprecia en el rea de ventas cuentan con dos personales quienes son
los encargados de atender a los clientes y efectuar la venta, la misma rea est
encargada de controlar y dirigir el rea de soporte tcnico y en el cual se cuenta con un
personal quien brinda soporte tcnico a los productos que se vendan o que requieran su
servicio, se puede apreciar que tienen clientes que a menudo realizan grandes compras
en tal sentido estos tienen un descuento, descuento que es manejado directamente por
el dueo de la empresa, por otra parte se puede apreciar que la microempresa tiene
prdida un gran nmero de clientes pues cuando los clientes vienen a consultar con
respecto a los productos que se venden los vendedores no cuenta con informacin de
los productos que existen y de la cantidad lo que hace que los clientes esperen hasta
verificar el almacn lo que genera mucha incomodidad en los clientes haciendo que
44
 estos opten por acudir a la competencia, tambin se observa que existe garantas las
cuales requiere almacenar en una cantidad para poder enviar al proveedor respectivo,
esto debido a que gran parte de los proveedores operan en lima y enviar las garantas
por unidad generara un costo elevado. La microempresa no cuenta con un gerente en
consecuencia es el dueo de la organizacin quien coordina controla.
3.2 MODELADO DEL NEGOCIO
3.2.1 IDENTIFICACIN DE PROCESOS
Esta fase de la investigacin es de mucha importancia dado que tiene como
propsito mostrar al detalle cada proceso, las actividades que se realizan en los
mismos y quienes participan en el desarrollo de cada uno de ellos, esto con el fin
de realizar un sistema de informacin apropiado, adecuado y que colabore de la
mejor manera al desempeo de cada una de las actividades que se realiza en
cada proceso.
A continuacin se muestra el grfico N 3.1 donde se puede apreciar a detalle el
proceso de compra.
Grfico N 3.1
Proceso-compra de productos

Elaboracin: Propia
Basado en: procesos operacionales Fungger System.

45
El grfico N 3.1 mostrado anteriormente tiene la finalidad de resaltar las
actividades que se realiza en el mencionado proceso, el resultado, participantes,
entradas que estn en la parte izquierda y la salida en la parte derecha, el objeto
de realizar esto a detalle es que posteriormente los requerimientos que se
determinarn estar en funcin de todo lo mencionado, los cuales reflejarn los
requerimientos del proceso de compra y en funcin a eso realizar un sistema de
informacin que de soporte a las actividades que se realicen en este proceso.
Continuando en esta etapa del anlisis se presenta el grfico N 3.2 en el cual se
presenta el proceso de registro y almacn de productos.
Grfico N 3.2
Proceso-almacenamiento de productos

Elaboracin: Propia
Basado en: procesos operacionales Fungger System.
En el grfico N 3.2 presentado anteriormente se puede apreciar que una de las
actividades principales en este proceso es el registro de los productos, pues en el
planteamiento del problema se pudo apreciar que una de las falencias que tiene la
microempresa es control de productos y en este proceso se muestra que es una
actividad de mucha importancia y en ese sentido se pretende dar soporte a esa
actividad con el desarrollo del sistema de informacin. Por otra parte producto de
este anlisis nos brindar los requerimientos del proceso de registro y almacn de
productos el cual se desarrollar ms adelante pero en funcin a todo lo analizado
en esta parte, para las cuales se considerarn las actividades, los que participen

46
en cada una de ellas a fin de brindar un mejor control a la microempresa esto con
respecto a los productos y a las responsabilidades de sus trabajadores.
Prosiguiendo con esta fase a continuacin se muestra el grfico N 3.3 donde se
pueda apreciar a detalle el proceso de distribucin de productos.
Grfico N 3.3
Proceso-distribucin de productos

Elaboracin: Propia
Basado en: procesos operacionales Fungger System.
El grafico N 3.3 mostrado anteriormente nos muestra que los productos antes de
ser distribuidos a la tienda previamente necesitan un requerimiento por parte del
rea de ventas y es solo despus de este requerimiento que el producto est apto
para la venta como se muestra, la intencin de resaltar esta actividad es debido a
que en algunas ocasiones el personal de ventas desconoce la existencia de
algunos productos y el stock que se tiene en el almacn, lo cual hace que algunas
ventas no se concreten y no se brinde una atencin de calidad pues en algunas
ocasiones hacen esperar a los clientes, se resalta estas actividades a fin de que
con la implementacin del sistema de informacin mejore esta situacin en la
microempresa Fungger System.

47
En el siguiente grafico N 3.4 se presenta el proceso de venta, en el cual se
plasmar las actividades que se realizan en el mencionado proceso, los que
participan de este proceso y el resultado que se obtiene producto de esto.
Grfico N 3.4
Proceso-venta

Elaboracin: Propia
Basado en: procesos operacionales Fungger System.
En el grfico N 3.4 se aprecia que dos actividades importantes en el proceso de
venta son: atender las consultas que realizan los clientes con respecto a los
productos y el emitir los comprobantes de pago, para lo cual al momento de
atender a los clientes se requiere disponer de informacin adecuada con respecto
a los productos y para poder emitir comprobantes de pago se requiere registrar la
informacin de los clientes as como los productos que son adquiridos por este,
ese as que con la implementacin del sistema de informacin se pretende dar
soporte a las actividades mencionadas para que puedan desarrollarse de una
mejor manera.

48
Ya identificado los procesos que tiene en su operatividad la microempresa
Fungger seguidamente en el grafico N3.5 se muestra el diagrama IDEFF de la
microempresa Fungger.
Grfico N 3.5
Diagrama IDEFF-Fungger System

Elaboracin: Propia
Basado en: procesos de la Fungger System.
En el grafico mostrado anteriormente se tiene el diagrama IDEFF de la
microempresa Fungger System, este diagrama permite visualizar de manera
general las entradas, salidas, participantes y controles de la microempresa bajo
estudio.

49
Seguidamente se tiene el grafico N3.6 en el cual se tiene el diagrama IDEFF de
las sub funciones de la microempresa, este diagrama permite visualizar de
manera detallada lo que se present en el grafico anterior
Grfico N 3.6
Diagrama IDEFF-Sub Funciones Fungger System

Elaboracin: Propia
Basado en: procesos de la microempresa Fungger System.

50
 En el grafico mostrado anteriormente se tiene el diagrama IDEFF de las Sub
funciones que se desarrollan en la microempresa Funnger System, el cual tiene
por objetivo mostrar detalladamente las entradas, salidas, participante y
restricciones o controles de cada sub funcin.
De todo lo mostrado anteriormente se concluye que el sistema de informacin
dar soporte a las actividades que se identificaron anteriormente en cada proceso
y de manera especial a las resaltadas en cada explicacin de los grficos, as
mismo se considerar como usuarios a los diferentes intervinientes en cada
proceso.
3.3 DEFINICION DE REQUERIMIENTOS.
Una de las fases ms importantes en la construccin de una solucin informtica es
identificar lo que se pretende satisfacer. En esta seccin se describe los requerimientos
que se buscan satisfacer con la creacin del sistema de Informacin propuesto. Como
cualquier sistema de informacin que se plantea desarrollar debe cumplir con ciertos
requerimientos para ser empleado de manera apropiada por el usuario, siguiendo las
buenas prcticas internacionalmente aceptados dentro de la ingeniera de software.
En esta fase se establece los servicios que el sistema debe proveer y las restricciones
bajo las cuales debe operar, siendo el objetivo establecer las funciones que se quiere
que satisfaga el sistema a construir.
Los principales objetivos de esta fase son:
Definir el mbito del sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y
metas del usuario.
Establecer y mantener un acuerdo entre clientes y otros involucrados sobre lo
que el sistema debera hacer.
Tener un mejor entendimiento de los requerimientos del sistema.
Validar los requerimientos en funcin a las actividades que se realizan
3.3.1. DETERMINACIN DE LOS REQUERIMIENTOS DEL SISTEMA
3.3.1.1. REQUERIMIENTOS FUNCIONALES
Los requerimientos funcionales que seguidamente se presentarn han
sido producto del anlisis de los procesos que se desarrollan en la
microempresa Fungger System (los cuales ya se abordaron
anteriormente), as mismo producto de las reuniones y el levantamiento
de informacin de las personas que son parte de la mencionada
microempresa, a fin de asegurar que el sistema de informacin que se
desarrollar logre satisfacer las necesidades de los que utilizarn el

51
sistema de informacin y as apoyar en las actividades que desarrollan,
para entender de mejor manera en adelante se mostrarn grficos en los
cuales se plasmarn los requerimientos determinados
A continuacin se presenta la grfica N3.7 en la que se tienen los
requerimientos funcionales de la compra de productos.
Grfico N 3.7
Requerimientos Funcionales Compra de Productos

Referencia Requerimiento Prioridad

FR01 lista de productos a comprar MEDIA

bsqueda de datos de los proveedores para

realizar la compra
RF02 ALTA

registro de compra realizada

RF03 ALTA

recepcin de los productos adquiridos

RF04 BAJA

registro de productos nuevos, que no se

encuentran en la lista de productos
RF05 ALTA

registro de cantidad y precio de compra de

productos adquiridos
RF06 ALTA

registro del precio de venta de los productos

RF07 ALTA

registro de descuento de productos adquiridos

RF08 MEDIA

reporte de compras realizadas

RF09 MEDIA

Fuente: Propia
Elaboracin: Propia
En el grafico anterior se tiene la descripcin de los requerimientos
funcionales obtenidos al realizar el anlisis al proceso de compra de
productos de la microempresa Fungger System, as mismo se tiene la
prioridad de los mismos, pues es que en funcin a estos requerimientos y
prioridades se desarrollar el sistema de informacin, a fin de que los
52
requerimientos determinados brinden soporte a las actividades de este
proceso
A continuacin se tiene la grfica N 3.8 en la que se presenta los
requerimientos funcionales de la venta de productos.
Grfico N 3.8
Requerimientos Funcionales Venta de Productos

Referencia Requerimiento Prioridad

RF01 bsqueda de productos ALTA

muestra de caractersticas(stock, precio, etc.)

de los productos
RF02 ALTA

bsqueda o registro de datos de cliente

RF03 ALTA

registro de productos a vender

RF04 ALTA

registro de cantidad de productos a vender

RF05 ALTA

registro de venta
RF06 ALTA

registro de productos con fallas

RF07 MEDIA

modificacin del detalle de venta registrada

RF08 MEDIA

RF09 reporte de ventas realizadas ALTA

Fuente: Propia
Elaboracin: Propia
En el grafico mostrado anteriormente se puede apreciar que se enfatiza
bastante lo que es la disponibilidad de informacin con respecto a los
productos que comercializa la microempresa, as mismo lo importante de
registrar la ventas (registro de datos de los clientes, productos que
adquieren) y los reportes de las ventas realizadas a fin de llevar un mejor
balance de las ventas y quienes lo realizarn.

53
 Seguidamente se presenta el grafico N 3.9 en el cual se tiene los
requerimientos funcionales del control de productos en inventarios.
Grfico N 3.9
Requerimientos Funcionales Control de Productos e Inventarios

Referencia Requerimiento Prioridad

reporte de productos, compras y ventas

RF01 ALTA

verificacin de productos
RF02 BAJA

deteccin de productos no hallados

RF03 BAJA

modificacin en el stock de productos

RF04 ALTA

guardado de los cambios realizados

RF05 ALTA

RF06 actualizacin de precios de los productos ALTA

actualizacin de descuentos en los

RF07 productos ALTA

Fuente: Propia
Elaboracin: Propia
En el grafico anterior se aprecia que tener los reportes con respecto a los
productos que se comercializa es importante ya que darn soporte a lo
que es el adecuado control de los mismos, de similar manera es
necesario que el sistema permita actualizar los precios de los productos y
stock, con el fin de llevar un adecuado control de inventarios.
3.3.1.2. REQUERIMIENTOS NO FUNCIONALES
Una vez determinado los requerimientos funcionales o las actividades a
las cuales se darn soporte con el sistema de informacin tambin es
necesario determinar los requerimientos no funcionales que viene a ser
las restricciones y el entorno en el cual operar el sistema de
informacin.
Seguidamente se presentarn en la grfica N 3.10 determinar el
entorno en el cual operar el sistema que se desarrollar

54
 Grfico N 3.10
Requerimientos No Funcionales

Referencia Requerimiento Prioridad

El sistema deber de operar con el

RF01 sistema operativo Windows XP o Seven ALTA

Mensajes de error concreto y claro

RF02 ALTA

RF03 Interfaz amigable MEDINA

RF04 Gua de usuario MEDINA

Seguridad de la informacin
RF05 ALTA

RF06 Control de acceso a la informacin ALTA

RF07 Integridad de la informacin ALTA

Utilizar como gestor de base de datos a

RF08 Mysql MEDIANA

Se desarrollar en el lenguaje de
RF09 programacin Java. ALTA

Fuente: Propia
Elaboracin: Propia
3.4 ANALISIS Y DISEO
Culminado la fase de definicin de requerimientos en el cual en cierta manera se
plasm como es que opera esta microempresa y como el sistema de informacin se
orientar a dar soporte a todo lo mostrado ahora procederemos a realizar la etapa del
diseo en el cual se har uso de herramientas propias de las tecnologas de informacin
y en forma particular las herramientas de lenguaje de modelado unificado (UML), con el
fin de verificar que los requerimientos determinados sean los ms apropiados y obtener
un bosquejo del proyecto a desarrollar.
3.4.1 MODELO DE CASOS DE USO DEL NEGOCIO
Los siguientes modelos de caso de uso que se presentarn en esta etapa se
realizaron en funcin a los procesos identificados en la etapa anterior.
A continuacin se presenta el grafico N 3.11 el cual se podr apreciar el caso de
uso de compra de productos.

55
 Grfico N 3.11
Caso de uso compra de productos

Elaboracin: Propia
Basado en: procesos de la pyme Fungger System.
Del Grfico N 3.11 presentado anteriormente se resalta dos aspectos
importantes como es el de registrar las compras y los datos del proveedor para
poder tomar de mejor manera nuestras decisiones y tener un mayor control sobre
las compras que se vienen realizando y a que proveedor se le realiza la compra.
En el siguiente grfico N 3.12 se presenta el caso de almacenado y distribucin
de productos en el que se plasma todas las actividades necesarias y quienes
realizan cada actividad.

56
 Grfico N 3.12
Caso de uso almacenamiento y distribucin de productos

Elaboracin: Propia
Basado en: procesos de la pyme Fungger System.
Del grfico N 3.12 mostrado anteriormente se puede observar la actividad de
registro de productos, en el cual se registra detalladamente los productos que se
adquieren para su comercializacin esta actividad es muy importante debido a que
en cierta manera permitir el control de los productos pues es as que esta es una
de las actividades a las que se pretende dar soporte con el sistema de informacin
que se viene desarrollando, dado que ayudar a tener un mayor control sobre los
stocks de productos.

57
Continuado con la presente etapa de investigacin se presenta el grfico N3.13
en el cual se apreciar el caso de uso venta de productos del cual se buscar
resaltar las actividades que sean de importancia para el sistema de informacin.
Grfico N 3.13
Caso de uso venta de productos

Elaboracin: Propia
Basado en: procesos de la pyme Fungger System.
Del grfico anterior en el desarrollo del caso de uso se observa la actividad de
generar un comprobante de pago para lo cual se debe registrar los datos de los
clientes (nombre, apellidos, etc.) adems de los datos del producto, es as que
para un mejor control y acertadas decisiones con respecto al cliente se dar
soporte a estas acciones mediante el sistema de informacin que se viene
realizando.
Para finalizar con los casos de uso a continuacin se presenta el grfico N3.14 el
caso de uso control de compras, ventas e inventario el cual en la etapa de anlisis
no se plasm por considerar que es una actividad complementaria pero

58
importante para los dueos de la microempresa y mediante este caso de uso se
dar a conocer.
Grfico N 3.14
Caso de uso control de compras, ventas e inventario

Elaboracin: Propia
Basado en: procesos de la pyme Fungger System.
En el grfico mostrado anteriormente que el personal genera un informe el cual
contiene una serie de datos en funcin a lo que realiza y este informe es
constatado por el dueo, el sistema de informacin asistir en la realizacin de
estas actividades teniendo en consideracin todos estos aspectos.
3.4.1.1. MATRIZ DE TRAZABILIDAD
Una vez realizado el modelado de los casos de uso, procederemos a
realizar la matriz de trazabilidad en la cual se podr determinar si los
requerimientos determinados son los correctos, dado que estos debern
estar reflejados en los casos de usos determinados.
A continuacin se presenta el grfico N 3.15 en el cual se muestra la
matriz de trazabilidad.
59
 Grfico N 3.15
Matriz de Trazabilidad
CU01 CU02 CU03 CU04
RF01

COMPRA DE PRODUCTOS
RF02
RF03
RF04
RF05
RF06
RF07
RF08
REQUERIMIENTO FUNCIONAL

RF09
RF01
VENTA DE PRODUCTO

RF02
RF03
RF04
RF05
RF06
RF07
RF08
CONTROL DE INVENTARIOS

RF09
RF01
RF02
RF03
RF04
RF05
RF06
RF07
Elaboracin: Propia
Fuente: Propia
En el grafico mostrado anteriormente se tiene la matriz de trazabilidad de
los requerimientos funcionales, los cuales deben estar reflejados en los
casos de uso que anteriormente se han identificado, esto con el fin de ver
si en realidad los requerimientos determinados darn soporte a las
actividades que se realizan en la microempresa.
3.4.2 DIAGRAMAS DE SECUENCIA
Lo que se quiere dar a conocer mediante los diagramas que en adelante se
mostrarn es la secuencia de las actividades de los casos de uso que
anteriormente se present.

60
A continuacin se muestra el grfico N 3.16 el cual reflejar la secuencia de cada
una de las actividades que anteriormente se present en el caso de uso de
compras.
Grfico N 3.16
Diagrama de secuencia compras

Elaboracin: Propia
Basado en: Casos de uso de la pyme Fungger System.
En el grfico presentado tiene la intencin de mostrar cmo se dan las actividades
de manera secuencial desde la parte superior del grafico hacia la parte inferior en
ese orden y que personas interviene en estas actividades. El proceso inicia con la
solicitud de lista de precios a los diferentes proveedores, a su vez este le brinda la
lista solicitada y entonces se genera lo que ser la lista de pedido, luego se enva
esta lista al proveedor y a su vez este genera una orden de pedido con el cual se
realizar la cancelacin del pedido que se est realizando y una vez confirmado el
pago el proveedor enva los productos los cuales finalmente son verificados.

61
Continuando con los diagramas de secuencia a continuacin se presenta el
grfico N 3.17 el cual se podr apreciar todas las actividades que involucra el
proceso de almacenamiento y distribucin de productos.
Grfico N 3.17
Diagrama de secuencia-almacenamiento y distribucin de productos

Elaboracin: Propia
Basado en: Casos de uso de la pyme Fungger System.
En el diagrama de secuencia mostrado anteriormente se plasma lo que la
secuencia de las acciones que se realizan en el proceso de almacenado y
distribucin de productos, el cual inicia con la recepcin de los productos
adquiridos y los que sern almacenados y registrados, tambin en esta parte es
posible detectar algunos productos en mal estado o daados y se devuelven para
su reposicin, una vez almacenado y registrado los productos el personal de
ventas hace los requerimientos de los productos que hacen falta para su venta y
el personal de almacn abastece estos requerimientos en funcin a lo que se
solicite. Por otra parte el personal de almacn es quien va verificando de manera
fsica el stock de los productos y va haciendo requerimientos de los mismos.
Seguidamente se presenta el grafico N 3.18 el cual representa el diagrama de
secuencia de las ventas.

62
 Grfico N 3.18
Diagrama de secuencia ventas

Elaboracin: Propia
Basado en: Casos de uso de la pyme Fungger System.
En el anterior grfico se puede apreciar que existen muchas actividades que se
tienen que realizar este proceso y que no existen actividades que se puedan
realizar paralelamente, la secuencia inicia cuando el cliente se apersona a
consultar con respecto a algn producto y el vendedor atiende todas sus consultas
y le brinda informacin de los productos y servicios para luego generar una orden
de venta y luego concretarla y culmina cuando el cliente realiza el pago y se le
entrega los productos.
A continuacin se tiene el grafico N 3.19 donde se muestra el diagrama de
secuencia del control de ventas, compras e inventarios.

63
 Grfico N 3.19
Diagrama de secuencia- control de ventas, compras e inventariado

Elaboracin: Propia
Basado en: Casos de uso de la pyme Fungger System.
En el grafico anterior se muestra el diagrama de secuencia del control de
productos, compras y ventas, el cual es realizado por el dueo y va solicitando los
informes respectivos a cada responsable y los cuales finalizan con la
corroboracin de los informes brindados.
3.4.3 DISEO DE LA BASE DE DATOS
A continuacin se presenta el grfico N 3.20 en el cual se muestra el diseo de la
base de datos el cual dar soporte a la implementacin del sistema de
informacin, este diagrama permite visualizar las tablas del sistemas de
informacin, la informacin que se registrar en estas tablas, el tipo de variable y
el mbito que tendr la informacin que se registre y como estas tablas y la
informacin est relacionada.

64
 Grfico N 3.20
Diseo de la Base de Datos

Elaboracin: Propia
Basado en: Casos de uso de la pyme Fungger System.

65
 En el grfico presentado se puede observar las tablas de la base de datos sobre
la cual operar el sistema de informacin, as mismo se muestra los datos que se
registrarn esto con respecto a los clientes, productos, proveedores y personal
que labora, por otra parte tambin refleja el tipo de dato que vienen a ser cada
uno de estos y para finalizar muestra algunas operaciones que realizan los
involucrados. Como referencia y para mejor entendimiento en el anexo N 04 se
tiene el cdigo Query en Mysql del diseo de la base de datos.
3.4.4 DIAGRAMAS DE DESPLIEGUE
A continuacin se presenta el grfico N 3.21 el cual representa el diagrama de
despliegue en el cual funcionar el sistema de informacin que se viene
desarrollando.
Grfico N 3.21
Diagrama de despliegue

Elaboracin: Propia
Basado en: Sistema de informacin desarrollado.
El grafico anterior muestra la arquitectura del hardware sobre el cual funcionar el
sistema que se viene desarrollando, se puede apreciar que una de las
computadoras no tiene salida a ninguna impresora eso debido a que ser para
uso exclusivo de consultas de precios y productos para los clientes, pero si en
algn caso se requiera que tenga salida a alguna impresora solo se tendr que
configurar.
3.5 IMPLEMENTACIN
Para la realizacin de esta etapa se mostrarn pantallas de las aplicaciones ms
relevantes del software que se viene desarrollado en las cuales se dar una explicacin
del rol que cumplir y la importancia que tienen en el sistema de informacin.

66
A continuacin se presenta el grfico N 3.22 en cual refleja la interfaz de acceso al
sistema de informacin.
Grfico N 3.22
Interfaz validacin de usuario

Elaboracin: Propia
Basado en: Sistema de informacin desarrollado.
El grfico mostrado anteriormente permite que el usuario se registre con su respectivo
nombre de usuario y contrasea, el cual servir para asignar los privilegios en el
sistema de informacin estos privilegios pueden ser cambiar datos, eliminar entre otros
y para tener un registro de quienes ingresan al sistema de informacin.
A continuacin en el grfico N 3.23 se muestra la interfaz proveedores.
Grfico N 3.23
Interfaz proveedores

67
Elaboracin: Propia.
Basado en: Sistema de informacin desarrollado.
El grafico mostrado anteriormente representa a la interfaz de proveedores en la que se
puede apreciar los datos del proveedor que se requiere almacenar, ademas se tiene la
opcion editar el cual permite modificar los datos del proveedor para lo cual primero
tendra que buscar, seleccionar el proveedor y una vez modificado se procede a
presionar el boton guardar con lo que se guardarn los cambios realizados, tambien se
tiene la opcion de eliminar y nuevo en caso se requiera registrar un nuevo proveedor.
Siguiendo con la etapa de implementacion a continuacin en el grfico N 3.24 se
presenta la interfaz registrar compra.
Grfico N 3.24
Interfaz registrar compra

68
Elaboracin: Propia.
Basado en: Sistema de informacin desarrollado.
La interfaz mostrada anteriormente es la interfaz la cual permitir el registro de
compras, es asi que se puede apreciar tres bloques, primer bloque en la cual se busca
al proveedor del que se adquiro los productos, segundo bloque en la que se busca los
productos del que se requiere almacenar su compra y en caso no se encuentre el
producto previamente tendra que registrar el producto en la opcion agregar producto, el
cual permite agregar productos que no se tengan registrados y por ultimo se aprecia
una tabla el cual permitir visualizar de mejor manera los registro de compra y en la
parte inferior de la tabla el monto total de la compra.
seguidamente se muestra el grfico N 3.25, el cual viene a ser la interfaz de registro
de venta.
Grfico N 3.25
Interfaz registrar venta

69
Elaboracin: Propia.
Basado en: Sistema de informacin desarrollado.
La interfaz anterior es la que permitira registrar las ventas, al igual que la interfaz
registrar compras se distingue de tres bloques, primer bloque en la que se almacenarn
los datos del cliente, en el segundo bloque se buscar el producto a vender y obtener
sus caracteristicas y el ultimo bloque se aprecia una tabla la cual permitir visualizar de
mejor manera los registros de ventas y en la parte inferior de esta tabla se muestra el
valor de total de la venta, y en caso se emita factura mostrar el valor del sub total e igv.
Continuando con muestra de las interfaces se presenta el grfico N 3.26 en el cual se
muestra la interfaz de mantenimineto de producto.
Grfico N 3.26
Interfaz mantenimiento producto

Elaboracin: Propia.
Basado en: Sistema de informacin desarrollado.
El grfico anterior muestra la interfaz que permitir al usuario agregar, eliminar o
modificar algn producto que se tenga registrado en la base de datos, tambin se
70
cuenta con una tabla donde se muestra la lista de productos. Seguidamente se presenta
el grfico N 3.27 el cual representa la interfaz agregar marca.
Grfico N 3.27
Interfaz agregar marca

Elaboracin: Propia.
Basado en: Sistema de informacin desarrollado.
La interfaz anterior es la que permitir agregar las marcas de los diferentes productos a
fin de que se almacenen en una tabla diferente pues si no se almacenaria en otra tabla
habria redundancia en los registros en el campo de marca. A continuacin se presenta
el grfico N 3.28 el cual muestra la interfaz mantenimiento clientes.
Grfico N 3.28
Interfaz Mantenimiento clientes

Elaboracin: Propia.
Basado en: Sistema de informacin desarrollado.
El grfico anterior muestra la interfaz de mantenimineto de clientes, a traves de interfaz
se podra actualizar los datos de los clientes, agregar y eliminar a los clientes; se puede
71
apreciar que cuenta con una tabla en la que nos muestra los datos de algunos clientes
para una mejor administracion.Seguidamente se muestra el grfico N 3.29 el cual
representa la interfaz personal.
Grfico N 3.29
Interfaz personal

Elaboracin: Propia.
Basado en: Sistema de informacin desarrollado.
La interfaz presentada en el grfico anterior permite llevar la administracin del personal
que labora en la microempresa, dado que permite actualizar la informacin del personal,
eliminar y agregar en caso se tenga nuevo personal, tambin cuenta con una tabla
donde se muestra en una lista la informacin del personal.
A continuacin se presenta el grfico N 3.30 en el cual se tiene la interfaz agregar
usuario
Grfico N 3.30
Interfaz agregar usuario

Elaboracin: Propia.
Basado en: Sistema de informacin desarrollado.

72
 La grfica anterior muestra la interfaz usuario, en la que permite habilitar un usuario
para el ingreso al sistema, para lo cual previamente tendrn que estar registrados
correctamente a fin de saber a qu persona se le asign el usuario
Como se mencion a comienzos del desarrollo del trabajo la finalidad de este sistema de
informacin es brindar soporte a las actividades de compra y venta de productos, teniendo
en consideracin esa finalidad es que se desarroll el sistema de informacin para lo cual en
primer momento se procedi a identificar los proceso que estn involucrados, producto de
este anlisis es que se determin los requerimientos y actividades involucradas y as poder
implementar el sistema de informacin.

73
 CAPTULO IV
ANLISIS DE RESULTADOS
En el referido captulo se proceder a realizar el anlisis de resultados considerando los
mismos indicadores que evidenciaron la situacin problemtica reflejada en el captulo I, con
el fin de entender en cuanto fue la mejora despus de haber realizado la intervencin
metodolgica para posteriormente obtener algunas conclusiones y posibles
recomendaciones.
4.1 INDICADORES DE LA SITUACIN MEJORADA Y DE LA HIPOTESIS
En el captulo I se present una serie de indicadores para evidenciar la situacin
problemtica, en tal sentido se har uso de los mismos para expresar las mejoras
despus de la intervencin, para lo cual se har una comparacin entre el antes y el
despus. A continuacin se muestra el grfico N 4.1 en el cual se plasma el tiempo que
le tomaba a la microempresa realizar un proceso de inventariado, antes de la
intervencin metodolgica.
Grfico N4.1
Tiempo en das de realizar un proceso de inventariado antes de la intervencin.

tiempo en dias
5
4
3
2
1
0
jul-12
jul-10

jul-11
ene-10

ene-11

ene-12

ene-13
abr-10

oct-10

abr-11

oct-11

abr-12

oct-12

Fuente: Fungger System

Elaboracin: Propia.

74
Como se puede apreciar en el grfico N4.1 el tiempo promedio que le toma a la
microempresa realizar un proceso de inventariado es de 3.7 das, por el cual se realizan
3 procesos de inventariado al ao permitiendo a la microempresa tener poco control con
respecto a los productos de almacn.
A continuacin se presenta el grfico N4.2 en el cual se muestra el tiempo que la
microempresa Fungger System realiza el control de inventario de sus productos
despus de la implantacin del proyecto.
Grfico N 4.2
Tiempo en das de realizar control de inventarios despus de la intervencin

tiempo en dias
1.6

1.4

1.2

0.8

0.6

0.4

0.2

0
mar-14 abr-14 may-14 jun-14 jul-14 ago-14 sep-14

Fuente: Fungger System

Elaboracin: Propia.
En el grafico anterior se aprecia el tiempo expresado en das que le toma a la
microempresa realizar el control de inventarios, el grfico muestra datos del control de
cada mes lo cual ya es un indicador considerando que anteriormente lo realizaba 3
veces al ao por considerar que era ms el tiempo empleado, tambin del cuadro se
concluye que el promedio en das que toma esta actividad es de 1.1 das lo que en
comparacin con la situacin inicial en el que el promedio era de 3.7 das se aprecia
una mejora en este sentido. En consecuencia se disminuy drsticamente la prdida de
productos dado que el proceso de control de inventarios es ms frecuente lo cual
permite tomar las medidas correctivas ms convenientes a la microempresa.
Seguidamente se presenta el grfico N 4.3 en el cual se muestra las prdidas de
mercadera expresado en soles antes de la intervencin metodolgica.

75
 Grfico N4.3
Monto de prdidas expresado en soles-Antes de la Intervencin

Monto de perdidas en soles

2000

1500

1000

500

0
monto de perdidas expresado en soles

ene-10 may-10 sep-10 ene-11 may-11

sep-11 ene-12 may-12 sep-12 ene-13

Fuente: Fungger System

Elaboracin: Propia.
En el grafico anterior se muestra las prdidas de dinero en la microempresa, debido al
poco control de las ventas, control de los productos e inventariado de los mismos,
teniendo como promedio de prdida de S/1,260 mensuales. A continuacin se presenta
el grafico N 4.4 el cual muestra la perdida de mercadera expresada en soles.
Grfico N4.4
Monto de prdidas expresado en soles-Despus de la Intervencin

200

150

100

50

0
1

mar-14 abr-14 may-14 jun-14 jul-14 ago-14 sep-14

Fuente: Fungger System

Elaboracin: Propia.
El grafico anterior muestra como despus de la intervencin el monto de prdidas ha
disminuido considerablemente, esto debido a que se realizan control de las ventas de
mejor manera y ms cotidianamente el control de inventarios, siendo el promedio de
perdida de S/.113.00 mensuales y en comparacin con el monto de S/1,260 se ve una
gran diferencia.

76
Seguidamente se presenta el grfico N4.5 en el cual se muestra el nmero de clientes
perdidos antes de la intervencin.
Grfico N4.5
Nmero de clientes perdidos

70

60

50

40

30

20

10

0
ago-12 sep-12 oct-12 nov-12 dic-12 ene-13 feb-13

Fuente: Fungger System

Elaboracin: Propia.
El grfico presentado anteriormente se realiz por intervalos de tiempo de mes a mes
por considerar que evidencia de mejor manera la deficiencia operativa debido a que la
microempresa no percibe el impacto de la prdida de clientes en el da a da, del grfico
se tiene que el promedio de clientes perdidos en mes es de 64 y la utilidad que se
podra generar a travs de estos es de bastante consideracin. A continuacin se
muestra el grafico N4.6 en el cual se tiene el nmero de clientes perdidos despus de
la intervencin.
Grfico N 4.6
Nmero de clientes perdidos despus de la intervencin

40
38
36
34
32
Series1
30
mar-14 abr-14 may-14 jun-14 jul-14 ago-14 sep-14

Fuente: Fungger System

Elaboracin: Propia.

77
Del grfico presentado anterior se observa que el promedio de nmero de clientes
perdidos es de 37 lo cual en comparacin con la situacin inicial en el que el promedio
era de 64 es una mejora considerable y en consecuencia genera mayores utilidades
para la microempresa, adems de brindar de la atencin de una manera ms eficiente.
Ya habiendo mostrado la mejora de los indicadores propios de la microempresa,
seguidamente se presenta el grafico N 4.7 el cual muestra la aceptacin del sistema de
informacin por parte de los usuarios.
Grfico N 4.7
Aceptacin del Sistema de Informacin

Como considera al S.I

implementado?
1

2 4

bueno regular malo

Fuente: Propia
Elaboracin: Propia.
En el grafico mostrado anteriormente se puede apreciar que gran parte de los usuarios
considera como bueno al sistema implementado, lo cual es bueno para el proyecto pues
por la naturaleza del proyecto son los usuarios los que determinan la utilidad y en este
caso se tiene una buena aceptacin. Seguidamente se presenta el grafico N 4.8 el cual
refleja la utilidad del sistema de informacin.
Grfico N 4.8
Utilidad del Sistema de Informacin

Considera que el S.I le

apoya en sus actividades?

2 si
no
5

Fuente: Propia
Elaboracin: Propia.
78
 El grafico muestra la utilidad del Sistema de Informacin con respecto al apoyo en las
actividades que realizan los involucrados del microempresa Fungger System, lo cual
segn el grafico se puede apreciar que 5 de 7 personas afirman que el sistema de
informacin es de mucha utilidad en el desarrollo de sus actividades.
En el presente capitulo se realiz una anlisis de los indicadores que se tena antes y
despus de la intervencin a fin de saber que tanto fue la mejora con respecto a la situacin
inicial, as mismo estos indicadores permiten validar la hiptesis y el objetivo planteado
antes de iniciar el proyecto de investigacin.

79
 CONCLUSIONES
1. El sistema de informacin permite mejorar la eficiencia de los procesos
operacionales en la microempresa Fungger System brindando informacin adecuada
y en el momento oportuno.
2. La informacin organizada y el buen aprovechamiento influyen de manera positiva en
los procesos operacionales, lo cual permite tomar decisiones ms acertadas y tener
un mejor control acerca de las actividades que se realizan en los procesos
operacionales y de similar manera un mejor control sobre quienes realizan dichas
actividades.
3. La metodologa RUP es una de las ms adecuadas para realizar proyectos de
sistemas de informacin de envergadura mediana y de plazo mediano y modelado a
travs del lenguaje UML es el bastante apropiado para asistir a esta metodologa.
4. Para desarrollar proyectos en sistemas de informacin es conveniente realizar la
etapa de conceptualizacin, pues permite involucrarnos con la institucin y este nos
brinda un panorama ms amplio a fin de que el sistema de informacin se adecua
de mejor manera a la institucin, tambin permite realizar de manera ms acertada la
etapa de planificacin.
5. Las reuniones con los usuarios finales son sumamente necesarias si se desea
enriquecer el producto, esto en el sentido de levantar informacin de acuerdo a las
necesidades que tengan, y conocer el soporte que debe brindar el sistema de
informacin.

80
 RECOMENDACIONES
1. Se recomienda a las microempresas el uso de sistemas de informacin para mejorar
la eficiencia operativa.
2. Se recomienda a la microempresa Fungger System y al personal que labora en dicha
institucin preservar de manera organizada la informacin a fin de aprovechar de
mejor manera esta informacin, la cual sirve de soporte a la toma de decisiones, al
control y operar de mejor manera.
3. Se recomienda la aplicacin de la metodologa RUP en el desarrollo de sistemas de
informacin
4. Se recomienda el uso de los resultados de este proyecto como base para sucesivos
desarrollos de proyectos similares a mayor escala y bajo contextos pertinentes.
5. Se recomienda tambin enriquecer el mdulo de Seguridad del presente proyecto,
adicionando algn protocolo de encriptacin para brindar confiabilidad en la
transferencia de informacin de los usuarios.

81
 REFERENCIAS
REFERENCIAS BIBLIOGRFICAS:
1. Carrasco Daz Sergio. (2006). Metodologa de la Investigacin Cientfica. 1Edicion.
Editorial San Marcos. Lima. Per.
2. Kendall, K y Kendall, J (2005). Anlisis y Diseo de Sistemas, Sexta Edicin,
Prentice Hall Hispanoamericana S.A. Mxico.
3. Senn A. James. (1992). Anlisis y Diseo de sistemas de Informacin. 2da Edicin.
Editorial McGrawhill. Mxico.
4. Ricardo Rodrguez Ulloa. (1994). La sistmica, los sistemas blandos y los sistemas
de informacin.1ra Edicin. Lima Per.
5. Pressman, R (2005). Ingeniera del Software un Enfoque Prctico, Sexta Edicin,
Editorial McGraw- Hill. Mxico.
REFERENCIAS ELECTRNICAS:
1 Alexandra Aparicio Rodrguez. (2005).Diseo de sistemas. Colombia.
Disponible en:
http://www.elprofesionaldelainformacion.com/contenidos/2001/julio/5.pdf.
Accesado el: [18 mayo 2011]
2 Hernando Andrs Agudelo Solano. (2004).Sistema de Informacin en la parte
operativa para la empresa importadora Gran Andina Ltda. Per.
Disponible en:
http://200.2.13.202/tl_files/escuela_ciencias_sociales/recursos/PlanEstudios/sistema
informacion.pdf.
Accesado el: [18 mayo 2011]
3 Estadsticas de la Micro, Pequea y Mediana Empresa (2012). Ministerio de la
Produccin. Lima. Per.
Disponible en:
http://www.produce.gob.pe/remype/data/mype2012.pdf
Accesado el: [25 agosto 2014]
4 Mirian Milagros Daz Flores. (2009). Metodologa Rational Unified Process. Lima.
Per
Disponible en:
http://www.usmp.edu.pe/publicaciones/boletin/fia/info49/articulos/rup%20vs.%20XP
Accesado el: [27 agosto 2014]
5 Repositorio Digital de Tesis PUCP. Pontificia Universidad Catlica del Per. Lima.
Per
Disponible en:

82
http://tesis.pucp.edu.pe/repositorio/
Accesado el: [05 septiembre 2014]

ANEXOS

83
ANEXO N1: Ejemplo de Caso de Uso

Fuente: UML
Elaboracin: Elaboracin Propia

84
ANEXO N2: Ejemplo de un diagrama de secuencia.

Fuente: UML
Elaboracin: Propia

85
ANEXO 3: Ejemplo de un diagrama de clases

Fuente: UML
Elaboracin: Elaboracin Propia

86
ANEXO 4: Cdigo Query-Mysql
DROP DATABASE IF EXISTS funggerBD;

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;

SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE,
SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';

CREATE SCHEMA IF NOT EXISTS `funggerBD` DEFAULT CHARACTER SET utf8

COLLATE utf8_general_ci ;
USE `funggerBD` ;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblSexo` (

`codSexo` CHAR(1) NOT NULL,
`nomSexo` VARCHAR(20) NULL,
PRIMARY KEY (`codSexo`))
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblCliente` (

`codCliente` CHAR(10) NOT NULL,
`nomCliente` VARCHAR(80) NOT NULL,
`apePatCli` VARCHAR(40) NOT NULL,
`apeMatCli` VARCHAR(40) NOT NULL,
`dniCliente` CHAR(8) NULL,
`codSexo` CHAR(1) NOT NULL,
`telCliente` CHAR(15) NULL,
`dirCliente` VARCHAR(250) NULL,
`corCliente` VARCHAR(60) NULL,
PRIMARY KEY (`codCliente`),
INDEX `fk_tblCliente_tblSexo_idx` (`codSexo` ASC),
CONSTRAINT `fk_tblCliente_tblSexo`
FOREIGN KEY (`codSexo`)
REFERENCES `funggerBD`.`tblSexo` (`codSexo`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblCargo` (

`codCargo` CHAR(3) NOT NULL,
`nomCargo` VARCHAR(150) NULL,
PRIMARY KEY (`codCargo`))
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblEmpleado` (

`codEmpleado` CHAR(10) NOT NULL,
`nomEmpleado` VARCHAR(80) NULL,
`apePatEmpledo` VARCHAR(40) NULL,
`apeMatEmpleado` VARCHAR(40) NULL,
`dniEmpleado` CHAR(8) NULL,
`telEmpleado` CHAR(15) NULL,

87
`sueEmpleado` DECIMAL(6,2) NULL,
`codCargo` CHAR(3) NULL,
`codSexo` CHAR(1) NULL,
`corEmpleado` VARCHAR(65) NULL,
`codRegDom` CHAR(2) NULL,
`codProDom` CHAR(2) NULL,
`codDisDom` CHAR(2) NULL,
PRIMARY KEY (`codEmpleado`),
INDEX `fk_tblEmpleado_tblSexo1_idx` (`codSexo` ASC),
INDEX `fk_tblEmpleado_tblCargo1_idx` (`codCargo` ASC),
CONSTRAINT `fk_tblEmpleado_tblSexo1`
FOREIGN KEY (`codSexo`)
REFERENCES `funggerBD`.`tblSexo` (`codSexo`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_tblEmpleado_tblCargo1`
FOREIGN KEY (`codCargo`)
REFERENCES `funggerBD`.`tblCargo` (`codCargo`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblProveedor` (

`codProvee` CHAR(6) NOT NULL,
`nomProvee` VARCHAR(250) NULL,
`razSocPro` VARCHAR(250) NOT NULL,
`telProvee` CHAR(15) NULL,
`rpmProvee` CHAR(10) NULL,
`dirProvee` VARCHAR(450) NULL,
PRIMARY KEY (`codProvee`))
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblMarca` (

`codMarca` CHAR(3) NOT NULL,
`nomMarca` VARCHAR(250) NULL,
PRIMARY KEY (`codMarca`))
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblProducto` (

`codProduc` CHAR(6) NOT NULL,
`nomProduc` VARCHAR(200) NULL,
`codMarca` CHAR(3) NULL,
`cosProduc` DECIMAL(6,2) NULL,
`numSerie` CHAR(50) NULL,
`modProduc` VARCHAR(100) NULL,
`stock` INT NULL,
PRIMARY KEY (`codProduc`),
INDEX `fk_tblProducto_tblMarca1_idx` (`codMarca` ASC),
CONSTRAINT `fk_tblProducto_tblMarca1`
FOREIGN KEY (`codMarca`)
REFERENCES `funggerBD`.`tblMarca` (`codMarca`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

88
CREATE TABLE IF NOT EXISTS `funggerBD`.`tblUsuario` (
`codUsuario` VARCHAR(15) NOT NULL,
`nomUsuario` VARCHAR(45) NOT NULL,
`pasUsuario` VARCHAR(45) NOT NULL,
`codEmpleado` CHAR(10) NULL,
PRIMARY KEY (`codUsuario`))
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblVariable` (

`nomVariable` VARCHAR(15) NOT NULL,
`valVariable` VARCHAR(250) NULL,
PRIMARY KEY (`nomVariable`))
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblVenta` (

`codVenta` CHAR(8) NOT NULL,
`fecVenta` DATE NULL,
`codCliente` CHAR(10) NULL,
`codEmpleado` CHAR(10) NULL,
`codComprobante` CHAR(6) NULL,
PRIMARY KEY (`codVenta`),
INDEX `fk_tblVenta_tblCliente1_idx` (`codCliente` ASC),
INDEX `fk_tblVenta_tblEmpleado1_idx` (`codEmpleado` ASC),
CONSTRAINT `fk_tblVenta_tblCliente1`
FOREIGN KEY (`codCliente`)
REFERENCES `funggerBD`.`tblCliente` (`codCliente`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_tblVenta_tblEmpleado1`
FOREIGN KEY (`codEmpleado`)
REFERENCES `funggerBD`.`tblEmpleado` (`codEmpleado`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblTipComprobante` (

`codTipComprobante` CHAR(1) NOT NULL,
`nomTipComprobante` VARCHAR(45) NULL,
PRIMARY KEY (`codTipComprobante`))
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblComprobante` (

`codComprobante` CHAR(6),
`numComprobante` CHAR(15) NULL,
`codTipComprobante` CHAR(1) NULL,
PRIMARY KEY (`codComprobante`),
INDEX `fk_tblComprobante_tblTipComprobante1_idx` (`codTipComprobante` ASC),
CONSTRAINT `fk_tblComprobante_tblTipComprobante1`
FOREIGN KEY (`codTipComprobante`)
REFERENCES `funggerBD`.`tblTipComprobante` (`codTipComprobante`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblDetalleVenta` (

89
`codVenta` CHAR(8) NOT NULL,
`codProducto` CHAR(6) NULL,
`cantidad` INT NULL,
`precio` DECIMAL(6,2) NULL,
INDEX `fk_tblDetalleVenta_tblVenta1_idx` (`codVenta` ASC),
INDEX `fk_tblDetalleVenta_tblProducto1_idx` (`codProducto` ASC),
CONSTRAINT `fk_tblDetalleVenta_tblVenta1`
FOREIGN KEY (`codVenta`)
REFERENCES `funggerBD`.`tblVenta` (`codVenta`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_tblDetalleVenta_tblProducto1`
FOREIGN KEY (`codProducto`)
REFERENCES `funggerBD`.`tblProducto` (`codProduc`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblCompra` (

`codCompra` CHAR(8) NOT NULL,
`fecCompra` DATE NULL,
`codEmpleado` CHAR(10) NULL,
`codProvee` CHAR(6) NULL,
`codComprobante` CHAR(6) NULL,
PRIMARY KEY (`codCompra`),
INDEX `fk_tblCompra_tblEmpleado1_idx` (`codEmpleado` ASC),
INDEX `fk_tblCompra_tblProveedor1_idx` (`codProvee` ASC),
CONSTRAINT `fk_tblCompra_tblEmpleado1`
FOREIGN KEY (`codEmpleado`)
REFERENCES `funggerBD`.`tblEmpleado` (`codEmpleado`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_tblCompra_tblProveedor1`
FOREIGN KEY (`codProvee`)
REFERENCES `funggerBD`.`tblProveedor` (`codProvee`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblDetalleCompra` (

`codCompra` CHAR(8) NOT NULL,
`codProducto` CHAR(6) NULL,
`cantidad` INT NULL,
`costo` DECIMAL(6,2) NULL,
INDEX `fk_tblDetalleCompra_tblCompra1_idx` (`codCompra` ASC),
INDEX `fk_tblDetalleCompra_tblProducto1_idx` (`codProducto` ASC),
CONSTRAINT `fk_tblDetalleCompra_tblCompra1`
FOREIGN KEY (`codCompra`)
REFERENCES `funggerBD`.`tblCompra` (`codCompra`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_tblDetalleCompra_tblProducto1`
FOREIGN KEY (`codProducto`)
REFERENCES `funggerBD`.`tblProducto` (`codProduc`)
ON DELETE NO ACTION
90
ON UPDATE NO ACTION)
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblRegion` (

`codRegion` CHAR(2) NOT NULL,
`nomRegion` VARCHAR(250) NULL,
PRIMARY KEY (`codRegion`))
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblProvincia` (

`codRegion` CHAR(2) NOT NULL,
`codProvincia` CHAR(2) NOT NULL,
`nomProvincia` VARCHAR(250) NULL,
PRIMARY KEY (`codRegion`, `codProvincia`))
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `funggerBD`.`tblDistrito` (

`codRegion` CHAR(2) NOT NULL,
`codProvincia` CHAR(2) NOT NULL,
`codDistrito` CHAR(2) NOT NULL,
`nomDistrito` VARCHAR(250) NULL,
PRIMARY KEY (`codRegion`, `codProvincia`, `codDistrito`))
ENGINE = InnoDB;

SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

91