UNIVERSIDAD

SAN PEDRO

FACULTAD DE INGENIERA
ESCUELA PROFESIONAL DE INGENIERA INFORMTICA Y DE SISTEMAS

DESARROLLO DE UN SISTEMA DE VENTAS PARA EL BAZAR

JOSELYN SPORT EN LA CIUDAD DE HUARAZ - 2015

CURSO

: PRACTICAS PRE PROFESIONALES II

INTEGRANTE

:
ENRIQUEZ MORALES , Luz Marlene

ASESOR

:
MEDINA REGALAGO, Edwin Enrique

FECHA

HUARAZ ANCASH 2015

DEDICATORIA

Dedic

este

principalmente

proyecto

Dios,

por

haberme dado la vida y fortaleza

para terminar este proyecto y
haber llegado hasta este momento
tan importante de mi formacin
profesional.
A mis hijitas Ayshane y Kristen,
por ser el pilar ms importante de
mi vida a quienes amo pues en
ellas descubr el amor y me hace
seguir adelante cada da.
A mis padres Hilda Morales y
Marcos Enrquez, por compartir
momentos significativos conmigo
y por siempre estar dispuestos a
escucharme

ayudarme

en

cualquier momento.

Luz

PRESENTACIN

Seores:
Miembros del Jurado Calificador de la Escuela Acadmico
Profesional de Ingeniera Informtica y de Sistemas.
En cumplimiento con las disposiciones vigentes contenidas en el
Reglamento de Pregrado de la Facultad de Ingeniera de la Universidad San
Pedro, tengo a bien presentar y someter a vuestra consideracin el presente
trabajo de investigacin, titulado:

DESARROLLO DE UN SISTEMA DE VENTAS PARA EL BAZAR

JOSELYN SPORT EN LA CIUDAD DE HUARAZ - 2015
El presente trabajo ha sido realizado en base a nuestros conocimientos
alcanzados en las aulas universitarias durante mi formacin profesional,
adems de las experiencias adquiridas fuera de ella.
Agradeciendo por anticipado su valiosa atencin y decisin, as como el
tiempo y la dedicacin que le estn brindando a la presente.
Atentamente.

__________________________
Luz Enrquez Morales

AGRADECIMIENTO

A Dios por habernos acompaado, guiado

y habernos dado la fortaleza en los
momentos de debilidad y por brindarnos
una

vida

llena

de

aprendizajes,

experiencias que las hemos asumido

responsablemente.
Al Gerente del bazar Joselyn Sport
por haberme acogido para desarrollar mi
prctica pre profesional de este proyecto.
A la Universidad San Pedro, por
seguir brindndonos la oportunidad de
escalar un peldao ms en el campo del
conocimiento.

INDICE GENERAL

INDICES FIGURAS

INDICES TABLAS

RESUMEN

El presente proyecto denominado: Desarrollo de un Sistema de Ventas para el Bazar

Joselyn Sport en la ciudad de Huaraz 2015, pretende orientar sobre la elaboracin
de la documentacin en la automatizacin de los procesos dentro de una empresa, como
es el caso del proceso de ventas.
El objetivo de este proyecto es desarrollar un sistema informtico que permite gestionar
las ventas, de esta manera se ayuda a organizar, controlar y administrar los productos
con los que cuenta la empresa que fue tomada como modelo, automatizando sus
actividades primarias y mejorando la interaccin con sus clientes.
Para el Anlisis y diseo del presente proyecto, se utiliz la metodologa RUP, la cual
permite la utilizacin del Lenguaje UML, como representacin grfica.

Palabras claves: automatizacin, sistema informtico, metodologa.

SUMMARY

This project entitled Development of a System Sales for the Bazaar " Joselyn Sport" in
the city of Huaraz - 2015 , seeks guidance on the preparation of documentation in the
automation of processes within a company , as is the case the sales process .
The objective of this project is to develop a computer system for managing sales, thus
helping to organize, control and manage the products are there in the company that was
taken as a model by automating their primary activities and improving interaction with
their customers.
For the analysis and design of this project, the RUP methodology was used, which
allows the use of UML language as graphical representation.

Keywords : automation, computer system methodology

INTRODUCCIN
El presente proyecto tiene por finalidad, mejorar del control del proceso de ventas, la
cual nos permitir una mejor visin de los problemas que aqueja al bazar Joselyn Sport,
para que en su posterioridad tenga un mejor control en sus ingresos y facilitar las
actividades que realizan en dicha ferretera,
El presente proyecto se encuentra estructurado en 4 captulos, los mismos que se
detallara a continuacin:
En el captulo I, abarca los datos generales de la empresa, as como tambin se
menciona la descripcin de la situacin problemtica, luego de ello se menciona los
objetivos generales y especficos y para concluir se realiza la justificacin econmica,
operativa y tcnica del proyecto.
En el captulo II, se muestra el marco terico, en la cual se tendr toda la informacin
terica que sirve como sustento para la ejecucin del presente proyecto
En el captulo III, se menciona la descripcin de las metodologas que sern aplicadas al
proyecto, la metodologa seleccionada para el desarrollo del presente proyecto es la
RUP con sus respectivas fases de desarrollo y como lenguaje de modelado el UML.
En el captulo IV, se desarrollar las diferentes fases de las metodologas mencionadas,
realizando el diseo de la aplicacin..
En el captulo V, se mencionan las conclusiones y sugerencias de proyecto, dentro de
ello se mencionar las cosas ms relevantes del proyecto y por otra parte se
mencionarn sugerencias para mejorar el trabajo en proyectos futuro.

CAPITULO I

1) DATOS GENERALES DE EMPRESA

Resea Histrica
La Empresa Bazar Joselyn Sport, se inicia el 04 de marzo del ao 1995, por
la seora Elizabeth Achic Gonzales, siendo una mujer emprendedora que inicio a
incursionar en el mundo de las ventas.
Esta empresa ofrece productos de calidad (ropa para bebe, ropa para nio, ropa
para nia, ropa para damas, ropa para caballeros y accesorios entre otros)
Actualmente brinda un servicio de buena calidad al cliente.
2) Visin
Ser la mejor empresa en prendas de vestir a nivel regional y contar con
sucursales alrededor de todo Ancash.
3) Misin
Se vende productos de calidad con los mejores precios y al alcance del pblico
para satisfacer las necesidades de los clientes; donde se comercializa ropas de
marcas reconocidas para aquellos clientes con gustos exigentes.
1.1.1. Organigrama

GERENTE
CONTABILIDA
D
ALMACEN

VENTAS

COMPRAS

1.

Situacin Problemtica
1.1 Descripcin de la problemtica
Las tiendas de ropas constituyen en nuestra ciudad una oportunidad interesante
en donde muchas personas han incursionado y logrado cierto xito, creciendo
en sus operaciones tal como se aprecia en el complejo comercial Gamarra de la
ciudad de Lima. En ese contexto existe una empresa comercializadora de venta
de ropa denominada Bazar JOSELYN SPORT. La Empresa tiene definida una
estrategia de posicionamiento basado en el manejo de productos exclusivos y
variados para sus clientes. Los productos que ofrece son tanto nacionales como
importados teniendo proveedores que adquieren los productos en sus viajes de
compras de manera peridica buscando siempre la novedad y el alineamiento a
la moda internacional.
Bazar JOSELYN SPORT, ha crecido de una manera no formal y en una
revisin de sus operaciones ha podido identificar algunos problemas al
realizar sus ventas y abastecimiento de productos, como por ejemplo:
La administracin de la venta de productos se realiza de forma manual,
al finalizar el da todo lo que se registr en las boletas de venta deben
de ser transcritas a un cuaderno anual; esta labor se vuelve engorrosa
cuando se desea saber cules son los productos que ya no se
encuentran en las tiendas o qu productos son los ms y menos
vendidos, las lneas de productos de mayor y menor venta, entre otros
reportes necesarios de ventas. La bsqueda de potenciales clientes
est limitada a las personas que transitan por el bazar, o por campaas
publicitarias, pero esto no ofrece una forma de interactuar con sus
clientes para lograr una mayor fidelidad y crecimiento en nmero.
Muchos de los productos a medida que cambia la temporada son
guardados en el almacn central, en el cual no se tiene control de
cules son los productos que se encuentran, debido a una falta de
categorizacin o ubicacin, lo que provoca que estn mucho tiempo en
el almacn y no se vendan. Al finalizar el da las vendedoras antes de

retirarse de las tiendas deben de realizar una llamada telefnica

informando la cantidad total que fue vendida, en oportunidades no se
realiza lo mencionado, por olvido o por estar ocupadas y de esta
manera no se puede llevar un clculo de cuanto se va vendiendo hasta
ese momento en el da y la semana. Cuando la gerencia solicita
reportes sobre ventas esto implica un gran esfuerzo pues deben
consolidar todas las operaciones asociadas a ventas y que estn
registradas en su cuaderno. En muchas oportunidades los clientes
hacen saber sus preferencias a las vendedoras de las tiendas y como
no se cuenta con un registro de estas sugerencias no son canalizadas
a los proveedores. De esta manera algunos clientes piensan que no los
toman en cuenta y se pierde la fidelizacin de los mismos, ms an no
se cuenta con un registro de clientes para que se les pueda hacer
llegar la informacin de los productos nuevos y variedades con los que
actualmente cuentan las tiendas.
1.2 Seleccin del Problema
El problema central que pretende resolver la presente investigacin, es la
deficiencias que se presentan en los procesos de ventas, de manera que ayude a
organizar, controlar y administrar los productos con los que cuenta el bazar
JOSELYN SPORT, automatizar sus actividades primarias y mejorar la
interaccin con sus clientes..
1.3 Antecedentes del Problema
La presente investigacin, cuenta con los siguientes antecedentes de estudios:
Segn, Llacchua, M. (2007), en su trabajo de investigacin denominado
Diseo de un Sistema de Comercializacin para el Supermercado Minimarket
Titos, concluye que: El diseo modular que tiene el sistema facilita la
administracin y el entendimiento del mismo haciendo ms la integracin de
otros mdulos o componentes para su crecimiento con ello tambin cabe
recalcar que el diseo multiplataforma hace que se integre fcilmente a
cualquier plataforma de hardware y software. El uso de metodologa de

desarrollo RUP, conjuntamente con el lenguaje UML y el manejo de los

conceptos de la programacin orientada a objetos, propiciaron que el desarrollo
del sistema sea entendible, sostenible, incremental.
Segn, Vsquez, D. (2008), en su tesis titulada Anlisis y Diseo de un
Sistema Informtico para el control de los procesos de comercializacin de la
empresa Grupo Selva SAC de Tarapoto Per., llega a la siguientes
conclusiones: Automatizar el proceso de centralizacin de datos reduce los
gastos administrativos y permite obtener informacin ms confiable y
oportuna, permitiendo que la toma de decisiones sea ms fluida. Los sistemas
de informacin distribuidos reducen la redundancia de tareas durante el control
del proceso de comercializacin estudiado.
Segn, Vilema M. (2007), en su trabajo de investigacin denominada "Diseo
de un Sistema de Informacin Comercial para Distribuidora La Familia, Llego
a las siguientes conclusiones: El diagnstico y levantamiento de informacin,
como primero pasos para el desarrollo de sistema, se constituye en elemento
crticos para el xito de proyecto de software, pues all donde se establecen los
problemas actuales y carencias en el desarrollo del procesos. Es por ello que
debe centrarse gran esfuerzo y tiempo a su realizacin. El uso de entrevistas
personales y /o cuestionarios a los usuario de la empresa es de vital
importancia. Pues termina establecer sus necesidades de informacin e
involucrarlos en el desarrollo del proyecto desde el principio.
Segn, Guzmn S. (2008), en su investigacin titulada, Diseo y
Optimizacin del proceso de gestin y ejecucin de la venta mayorista para una
empresa tipo Home Improvement. Llega a las conclusiones: Lo que ha
permitido entre estas sinergias se encuentra el hecho que el anlisis de Venta
Cruzada sea una extensin de la Minera de Datos, que se realiza con el apoyo
de una empresa de prestigio como lo es Venta. Por otro lado, los Modelos de
Optimizacin demuestran tener, a partir de una muestra pequea pero
representativa de acuerdo a su variedad y niveles de compra, una cercana con
el comportamiento real de los clientes.

1.4 Formulacin del problema

Cmo el desarrollo de un sistema informtico mejorar el proceso de ventas
en el bazar Joselyn Sport en la ciudad de Huaraz - 2015?
1.5 Justificacin del Proyecto:
1.5.1 Justificacin Tcnica
Se mantendr en vanguardia con las dems empresas de la regin y del
pas, porque contar con un sistema informtico que le permitir estar en
las mismas condiciones de progreso y desarrollo.
Permitir elevar el nivel competitivo en poder manejar los procesos de
informacin.
El Sistema simplificara las tareas.
1.5.2 Justificacin Operativa
Mejorar el servicio de la atencin al pblico.
Se contar con personal capacitado para el manejo del nuevo sistema
informtico.
Dar mejor funcionalidad a la toma de decisiones, porque la informacin
que brindara el sistema informtico, ser oportuno, preciso y confiable.

1.5.3 Justificacin Econmica.

El desarrollo del proyecto informtico, permitir reducir costos en el
proceso de compras de productos,ya no se requerir personal de apoyo,
papel y cuadernos. La cual se podr invertir para el benefici de la
empresa.

1.6 Objetivos del Proyecto:

1.6.1 General
Desarrollar un sistema informtico de ventas para el bazar Joselyn

Sport en la ciudad de Huaraz - 2015

1.6.2 Especficos.
Identificar los problemas del bazar.
Identificar los requerimientos del bazar, para el anlisis y diseo del
sistema informtico.
Disear las interfaces y crear la base de datos que permitan la
interaccin del usuario con la aplicacin de la manera ms sencilla
posible
1.7 Limitaciones del Proyecto.
Deficiente acceso a la informacin del proceso de ventas.
El tiempo es muy corto para poder desarrollar el proyecto en forma
adecuada.
Poca disponibilidad de las personas involucradas al sistema de proceso de
ventas.
Falta de experiencia para el desarrollo del sistema informtico por parte de
la autora.
Otro elemento que tampoco debe dejar de ser mencionado, son los
recursos econmicos, siempre escasos e insuficientes tanto para la
recopilacin de informacin a travs de diversos medios (libros, internet,
fotocopias de documentos, etc.) como la elaboracin del material de
recopilacin de datos.

CAPITULO II

2.

MARCO TERICO

2.1.

Sistema De Informacin (S.I.)

Un sistema de informacin es un conjunto de elementos o partes, que interactan
entre s con el fin de apoyar las actividades u operaciones de una empresa o

negocio. El equipo computacional: el hardware necesario para que el sistema de

informacin pueda operar. El recurso humano que interacta con el Sistema de
Informacin, el cual est formado por las personas que utilizan el sistema. Un
sistema

de

informacin

realiza

cuatro

actividades

bsicas:

Entrada,

almacenamiento, procesamiento y salida de informacin.

Tipos:
Entre los tipos de sistemas de acuerdo a la funcin que realizan podemos
citar los siguientes:
Sistemas transaccionales:
Los Sistemas de Informacin que logran la automatizacin de procesos
operativos dentro de una organizacin, son llamados frecuentemente
Sistemas Transaccionales, ya que su funcin primordial consiste en procesar
transacciones; es decir procesos operativos bsicos que tienen que ver con el
que hacer diario o cotidiano de la organizacin.
Caractersticas
- Son los primeros en implementarse dentro de una organizacin
- Necesitan una gran cantidad de entrada y/o salida de datos.
- Permiten lograr ahorros significativos de mano de obra, debido a que
automatizan tareas operativas de la organizacin.
Sistemas de apoyo a la toma de decisiones
Los Sistemas de Informacin que apoyan el proceso de toma de
decisiones son los Sistemas de soporte a la toma de decisiones, Sistemas
para la toma de decisin de grupo, Sistemas expertos de Soporte a la
toma de decisiones y Sistema de informacin para ejecutivos.

Caractersticas
-

Suelen ser Sistemas de Informacin interactivos y amigables, con

altos estndares de diseo grfico y visual, ya que estn dirigidos al
usuario final.

No necesitan mucha entrada y/o salida de datos, pues toman los datos
que han sido ingresados por los sistemas transaccionales.

Son utilizados por lo general por gerentes, administradores,

Jefes de proyectos; es decir por todos aquellos que estn encargados
de tomar decisiones.

Sistemas Estratgicos
El tercer tipo de sistema, de acuerdo con su uso u objetivos que cumplen,
es el de los Sistemas Estratgicos, los cuales se implementan en las
organizaciones con el fin de lograr ventajas competitivas, a travs del uso
de la tecnologa de informacin.
Un ejemplo de estos Sistemas de Informacin dentro de la empresa
puede ser un sistema MRP (Manufacturing Resoure Planning) enfocado a
reducir sustancialmente el desperdicio en el proceso productivo, o bien,
un Centro de Informacin que proporcione todo tipo de informacin;
Como situacin de crditos, embarques, tiempos de entrega, etc.
Caractersticas:
-

Suelen desarrollarse en casa, es decir, dentro de la organizacin, por

lo tanto no pueden adaptarse fcilmente a paquetes disponibles en el
mercado.

Son de corta duracin; es decir cuando la competencia implementa un

sistema similar el sistema caduca.

Elementos:
Los procedimientos y las prcticas habituales de trabajo

Son

aquellos que los directivos suelen hacer para coordinar los distintos
elementos de la empresa para su buen funcionamiento.
La informacin: Este es el elemento fundamental de todo sistema
informtico y su razn de ser, debe adaptarse a las personas que la
manejan y al equipo disponible con el que cuenta la empresa, segn los
procedimientos de trabajo para que las actividades se realicen de forma
eficaz.
Las personas o usuarios: Se trata de los individuos o unidades de la
organizacin que introducen manejan o usan la informacin para realizar

sus actividades y operaciones en funcin de los procedimientos de

trabajo establecidos.
El equipo de soporte: El equipo de soporte se ocupa para la
comunicacin, el procesamiento y el almacenamiento de informacin,
este constituye la parte ms visible del sistema de informacin, su parte
tangible o fsica. Este sistema tangible y fsico puede incluir elementos
de los mas variados niveles tecnolgicos y pueden ser: papel, maquinas
de escribir, archivadores, cintas magnticas, impresoras, computadoras,
etc.

Diferencia entre informacin y datos:

Primero debemos comprender en qu se diferencia el conocimiento de
los datos y de la informacin. De manera informal, los tres trminos
suelen utilizarse indistintamente y esto puede llevar a una interpretacin
libre del concepto de conocimiento. Quizs la forma ms sencilla de
diferenciar los trminos sea pensar que los datos estn localizados en el
mundo y el conocimiento est localizado en agentes de cualquier tipo,
mientras que la informacin adopta un papel mediador entre ambos.
El Dato:
Es un elemento atmico simple o bsico que nos va a servir para la
generacin de algo ms elaborado como es la informacin.
Las organizaciones actuales almacenan datos mediante el uso de
tecnologas computacionales. Desde un punto de vista cuantitativo, las
empresas evalan la gestin de los datos en trminos de coste, velocidad
y capacidad.
Los datos son importantes para las organizaciones, ya que son la base
para la creacin de informacin.

La Informacin:
Como cualquier mensaje, tiene un emisor y un receptor. La informacin
es capaz de cambiar la forma en que el receptor percibe algo. La palabra
informar significa originalmente dar forma a, y la informacin es

capaz de formar a la persona que la consigue, proporcionando ciertas

diferencias en su interior o exterior. Por lo tanto, estrictamente hablando,
es el receptor, y no el emisor, el que decide si el mensaje que ha recibido
es realmente informacin, es decir, si realmente le informa.
Las computadoras nos pueden ayudar a aadir valor y transformar datos
en informacin, pero es muy difcil que nos puedan ayudar a analizar el
contexto de dicha informacin. Un problema muy comn es confundir la
informacin (o el conocimiento) con la tecnologa que la soporta.

Cualidades de la informacin:
La informacin que se maneja dentro de una organizacin debe
responder a ciertas caractersticas para que el anlisis y las medidas que
se tomen correspondan efectivamente a una situacin real previamente
identificada.
Entre estas caractersticas se suele considerara las siguientes:
- Exactitud: La informacin debe reflejar el evento al cual se refiere y
su sistema de medicin expresado con poca variabilidad.
- Objetividad: La informacin debe ser el producto de criterios
establecidos que permitan la interpretacin en forma estandarizada por
diferentes personas en circunstancias diversas de tiempo y lugar.
- Vlida: Se refiere a que la informacin ha de permitir medir en forma
precisa el concepto que se estudia, con criterios uniformes.
- Continuidad: La informacin ha de ser generada en forma
permanente de tal manera que exista la disponibilidad de
los datos a travs del proceso de vigilancia.
- Completa: Debe contener todos los datos y variables previamente
establecidas para cumplir con su finalidad en cada evento
epidemiolgico.
- Oportuna: La informacin debe generarse y notificarse a la par con los
acontecimientos de tal manera que permita la toma de decisiones y la
actuacin inmediata
- Comparable: que permita ser confrontada con datos similares.

2.2.

Programacin Orientada A Objetos (O.O.P.)

La orientacin a objetos otorga mejoras de amplio alcance en la forma de diseo,

desarrollo y mantenimiento del software ofreciendo una solucin a largo plazo a
los problemas y preocupaciones que han existido desde el comienzo en el
desarrollo de software: la falta de portabilidad del cdigo y reusabilidad. Un
lenguaje orientado a objetos ataca estos problemas. Tiene tres caractersticas
bsicas: Debe estar basado en objetos, basado en clases y capaz de tener
herencia de clases. Muchos lenguajes cumplen uno o dos de estos puntos;
muchos menos cumplen los tres. Se basa en la idea natural de la existencia de un
mundo lleno de objetos y que la resolucin del problema se realiza en trminos
de objetos, un lenguaje se dice que est basado en objetos si soporta objetos
como una caracterstica fundamental del mismo. El elemento fundamental de la
OOP es, como su nombre lo indica, el objeto.

Herencia:
Herencia es la propiedad de que los ejemplares de una clase hija extienda
el comportamiento y los datos asociados a las clases paternas. La
herencia es siempre transitiva, es decir que una sub-clase hereda
caractersticas de superclases alejadas muchos niveles. La herencia
tambin se hace presente de las clases a los objetos.
Existe dos tipos de herencia la simple de una clase a otra clase y la
mltiple es cuando una clase hereda de dos o mas clases.
Beneficios De La Herencia
Reusabilidad del software cuando el comportamiento se hereda de otra
clase, no es necesario reescribir el cdigo que lo define. Muchos usuarios
o proyectos distintos pueden usar las mismas clases. Por otro lado, la
herencia reduce el tiempo de escritura y el tamao final del programa.
Consistencia de la interfaz. El comportamiento de una clase madre que
heredan todas sus clases hijas ser el mismo, de esta manera se asegura
que las interfaces para objetos sern similares y no solo un conjunto de
objetos que son parecidos pero que actan e interactan de forma
diferente. Componentes de software. La herencia nos permite escribir
componentes de software reutilizables. Modelado rpido de prototipos
cuando un sistema se construye casi totalmente de componentes

reutilizables, se puede dedicar ms tiempo a la realizacin de aquellas

partes nuevas. Polimorfismo:
Una de las caractersticas fundamentales de la OOP es el polimorfismo,
que no es otra cosa que la posibilidad de construir varios mtodos con el
mismo nombre, pero con relacin a la clase a la que pertenece cada uno,
con comportamientos diferentes. Esto conlleva la habilidad de enviar un
mismo mensaje a objetos de clases diferentes. Estos objetos recibiran el
mismo mensaje global pero responderan a l de formas diferentes; por
ejemplo, un mensaje "+" a un objeto ENTERO significara suma,
mientras que para un objeto STRING significara concatenacin ("pegar"
strings uno seguido al otro); otro ejemplo calcular el rea no es lo
mismo para un cuadrado que para un rectngulo o para un circulo.

Encapsulamiento:
Cada objeto es una estructura compleja en la que internamente hay datos
(atributos) y programas (mtodos), todos ellos relacionados entre s,
como si estuvieran encerrados conjuntamente en una cpsula. Esta
propiedad (encapsulamiento), es una de las caractersticas fundamentales
en la OOP. Los objetos son inaccesibles, e impiden que otros objetos, los
usuarios, o incluso los programadores conozcan cmo est distribuida la
informacin o qu informacin hay disponible. Esta propiedad de los
objetos se denomina ocultacin de la informacin. Esto no quiere decir,
sin embargo, que sea imposible conocer lo necesario respecto a un objeto
y a lo que contiene. Si as fuera no se podra hacer gran cosa con l. Lo
que sucede es que las peticiones de informacin a un objeto. Deben
realizarse a travs de mensajes dirigidos a l, con la orden de realizar la
operacin pertinente. La respuesta a estas rdenes ser la informacin
requerida, siempre que el objeto considere que quien enva el mensaje
est autorizado para obtenerla. El hecho de que cada objeto sea una
cpsula facilita enormemente que un objeto determinado pueda ser
transportado a otro punto de la organizacin, o incluso a otra
organizacin totalmente diferente que precise de l. Si el objeto ha sido
bien construido, sus mtodos seguirn funcionando en el nuevo entorno

sin problemas. Esta cualidad hace que la OOP sea muy apta para la
reutilizacin de programas.

Threads (Hilos)
Un hilo algunas veces llamado contexto de ejecucin o proceso ligero es
un flujo de control secuencial dentro de un programa. Un nico hilo es
similar a un programa secuencial; es decir, tiene un comienzo, una
secuencia y un final, adems en cualquier momento durante la ejecucin
existe un slo punto de ejecucin. Sin embargo, un hilo no es un
programa; no puede correr por s mismo, corre dentro de un programa.
Un hilo por si mismo no nos ofrece nada nuevo. Es la habilidad de
ejecutar varios hilos dentro de un programa lo que ofrece algo nuevo y
til; ya que cada uno de estos hilos puede ejecutar tareas distintas.
El mtodo run:
Antes que nada, necesitamos proveer a cada hilo con un mtodo run para
indicarle qu debe hacer. El cdigo de este mtodo implementa el
comportamiento en ejecucin del hilo y puede hacer, prcticamente
cualquier cosa capaz de ser codificada.

2.3.

Tipos de lenguaje de programacin:

Para que una computadora pueda realizar las funciones y operaciones que
deseamos, es necesario suministrar las instrucciones adecuadas debidamente
agrupadas y ordenadas en un programa o aplicacin.
Para que estas instrucciones sean comprensibles para el computador y debido a
la propia estructura fsica de los mismos, estos programas debern estar
expresados como combinaciones de cero y unos o mejor dicho expresados en
cdigo binario o de lenguaje de maquina.
En lenguajes de maquina existen muchas dificultades para la practica de la
programacin, es por eso que los profesionales del software han desarrollado
lenguajes de programacin mas humanizados que permiten alejar las tareas de
programacin de las maquinas y acercarlas a los problemas.
La clasificacin de los lenguajes de programacin no es fcil debido a que las
categoras no son absolutamente disjuntas.
A) Por Su Estructura Interna:
Bajo nivel:

Se caracterizan por poseer una estructura demasiado compleja, lo cual los hace
difciles de aprender, entender y aplicar. Ello se debe a su relacin directa con
el funcionamiento real de cada uno de los elementos internos del computador:
Microprocesador, RAM, perifricos etc.
Son los lenguajes propios o naturales de las computadoras y por ello los
programas escritos en bajo nivel nos permiten obtener la mxima velocidad de
proceso y un control total de todo el hardware del computador.

Lenguaje de mquina: Cada instruccin esta representada por un valor

numrico, el cual se describe en hexadecimal o en binario. La desventaja
radica en lo difcil de su codificacin, pero a cambio obtenemos alta velocidad
y control. El conjunto de instrucciones que conforman un lenguaje de mquina
es determinado por el microprocesador, ya que cada uno tiene un juego de
instrucciones propio y diferente al resto.

Lenguaje ensamblador (Assembler): Es muy similar al anterior solo que

cada instruccin esta representada por una pequea palabra (nemotcnico),
mucho ms fcil de manejar para los humanos que los cdigos hexadecimales,
por lo que se le considera un lenguaje codificado y a cada palabra le
corresponde una instruccin del microprocesador.
Alto nivel:
Se caracterizan por su similitud con los lenguajes humanos, por lo cual son
ms fciles de aprender, entender y usar. Sus principales objetivos son:
- Humanizar las tareas de programacin, acercando los lenguajes de
programacin al lenguaje coloquial (de conversacin)
- Hacer compatibles los distintos computadores a travs de la programacin:
Un programa escrito en un lenguaje de alto nivel puede ejecutarse en
cualquier computador.
- Como adems estos lenguajes usan nombre simblicos para representar
datos, variables, direcciones de memoria, etc y sus instrucciones tienen la
categora de macro instrucciones con su uso tendremos salvada la totalidad
de las dificultades que presenta la programacin en cdigo o lenguaje de
maquina y lo que es mas importante, nos permite acercar las tareas de
programacin a los problemas alejndolos de los detalles tcnicos
relacionados con el computador.

Ventajas:
- Un programa escrito en un lenguaje de alto nivel puede ser usado, despus
de algunas modificaciones, en distintos equipos.
- El tiempo de formacin de los programadores es relativamente corto, en
comparacin con el necesario para aprender los lenguajes de nivel inferior.
- El tiempo necesario para codificar y poner a punto, es decir los cambios y
correcciones posteriores, de un programa en lenguaje de alto nivel es inferior
al necesario en el caso de los lenguajes menos evolucionados.
- La reduccin del tiempo expresado en el punto anterior reduce tambin el
costo de los programas.
Inconvenientes:
-

Cada vez que se introduce un cambio es necesario compilar el programa

fuente nuevamente.
Nivel medio:
Poseen caractersticas de alto y bajo nivel, por lo que se puede
obtener velocidades de proceso muy similares al bajo nivel, control
total del equipo y adems facilidades de programacin. Ejemplos:
C++ y ADA.

B) Por Su Potencia:
Primera Generacin: Lenguaje de maquina, no requiere traduccin alguna,
el computador es capaz de leerlo directamente.
Segunda Generacin: Lenguaje ensamblador dependiente de la maquina,
que requiere de una traduccin, aunque esta es muy simple porque cada
instruccin corresponde a un cdigo solamente.
Tercera generacin ( lenguajes de alto nivel):
- Estn diseados para ser usados por programadores profesionales.
- Requieren especificaciones de cmo realizar una tarea.
- Se debe especificar todas las posibles opciones.
- Requieren de un nmero grande de instrucciones.
- Cdigos pueden ser difciles de leer, entender, mantener y depurar.
- Originalmente desarrollados para operaciones por lote.

- Orientados hacia archivos

- Requieren de traduccin y cada instruccin es convertida en varias
instrucciones de maquina.
- El programador solo es enfrentado al cdigo fuente que el mismo creo y
nunca al cdigo objeto resultante.
Ejemplo: Fortran, Cobol, Basic, Pascal, C
Cuarta Generacin (4GL): Lenguajes ms avanzados que los de alto nivel.
- Requiere la especificacin de la tarea a realizar (el sistema determina
cmo efectuarla)
- Ofrece opciones pre-determinadas que el usuario no necesita

especificar.

- El programador no es enfrentado a ningn cdigo, siempre usa la interface.

- Requiere traduccin y cada instruccin en convertida en muchas
instrucciones en lenguaje de mquina.
- Errores fciles de localizar.
- Orientados hacia bases de datos, objetos OLE.
2.4.

Compiladores e intrpretes:
Compilador:
Un traductor es cualquier programa que toma como entrada un texto escrito en
un lenguaje, llamado fuente y da como salida otro texto en un lenguaje,
denominado objeto.
Texto Lenguaje
Traductor
Texto Lenguaje
Fuente
Objeto
Se le denomina compilador al traductor en el caso de que el lenguaje fuente
sea un lenguaje de programacin de alto nivel y el objeto sea un lenguaje de
bajo nivel (ensamblador o cdigo de mquina). Un ensamblador es un
compilador cuyo lenguaje fuente es el lenguaje ensamblador. El programa
compilador traduce las instrucciones en un lenguaje de alto nivel a
instrucciones que la computadora puede interpretar y ejecutar. Para cada
lenguaje de programacin se requiere un compilador separado. El compilador
traduce todo el programa antes de ejecutarlo.
Intrprete:

Es

un traductor que realiza la operacin de compilacin paso a paso. Para cada

sentencia que compone el texto de entrada, se realiza una traduccin, ejecuta

dicha sentencia y vuelve a iniciar el proceso con la sentencia siguiente. La
principal ventaja del proceso de compilacin frente al de interpretacin es que
los programas se ejecutan mucho ms rpidamente una vez compilados; por el
contrario, es ms cmodo desarrollar un programa mediante un intrprete que
mediante un compilador puesto que en el intrprete las fases de edicin y
ejecucin estn ms integradas.
Un intrprete no genera un programa equivalente, sino que toma una sentencia
del programa fuente en un lenguaje de alto nivel y la

traduce al cdigo

equivalente y al mismo tiempo lo ejecuta. Histricamente, con la escasez de

memoria de los primeros ordenadores, se puso de moda el uso de intrpretes
frente a los compiladores, pues el programa fuente sin traducir y el intrprete
junto daba una ocupacin de memoria menor que la resultante de los
compiladores. Hoy en da, y con el problema de la memoria prcticamente
resuelto, se puede hablar de un gran predominio de los compiladores frente a los
intrpretes.
2.5

Arquitectura cliente servidor:

Es una arquitectura de procesamientos cooperativos donde uno de los
componentes pide servicios a otro.
El modelo Cliente / servidor, es la tecnologa que proporciona al usuario final el
acceso transparente a las aplicaciones, datos, servicios de cmputo o cualquier
otro recurso del grupo de trabajo y/o, a travs de la organizacin, en mltiples
plataformas. El modelo soporta un medio ambiente distribuido en el cual los
requerimientos de servicio hechos por estaciones de trabajo inteligentes o
"clientes'', resultan en un trabajo realizado por otros computadores llamados
servidores.
El servidor (S) es un proveedor de servicios.
El cliente (C) es un consumidor de servicios.
El cliente y servidor Interactan por un mecanismo de pasaje de mensajes:
Donde intervienen Pedido de servicio y Respuesta.
Elementos principales.

Los elementos principales de la arquitectura cliente servidor son justamente el

elemento llamado cliente y el otro elemento llamado servidor:

Cliente:
Es el que inicia un requerimiento de servicio. El requerimiento inicial puede
convertirse en mltiples requerimientos de trabajo a travs de redes LAN o
WAN. La ubicacin de los datos o de las aplicaciones es totalmente transparente
para el cliente.
Servidor:
Es cualquier recurso de cmputo dedicado a responder a los requerimientos del
cliente. Los servidores pueden estar conectados a los clientes a travs de redes
LANs o WANs, para proveer de mltiples servicios a los clientes y ciudadanos
tales como impresin, acceso a bases de datos, fax, procesamiento de imgenes,
etc.
Tipos de servidor:
Servidores de archivos.
Servidor donde se almacena archivos y aplicaciones de productividad como por
ejemplo procesadores de texto, hojas de clculo, etc.
Servidores de bases de datos
Servidor donde se almacenan las bases de datos, tablas, ndices. Es uno de los
servidores que ms carga tiene.
Servidores de transacciones
Servidor que cumple o procesa todas las transacciones. Valida primero y recin
genera un pedido al servidor de bases de datos.
Servidores de Groupware
Servidor utilizado para el seguimiento de operaciones dentro de la red.
Servidores de objetos

Contienen objetos que deben estar fuera del servidor de base de datos. Estos
objetos pueden ser videos, imgenes, objetos multimedia en general.
Servidores Web
Se usan como una forma inteligente para comunicacin entre empresas a travs
de Internet.
Este servidor permite transacciones con el acondicionamiento de un browser
especfico.
2.6.

Diagrama De Flujo (Contexto, Intermedio, Detalles):

Los diagramas de flujo, son diagramas que emplean smbolos grficos para
representar los pasos o etapas de un proceso. Tambin permiten describir la
secuencia de los distintos pasos o etapas y su interaccin. Las personas que no
estn directamente involucradas en los procesos de realizacin del producto o
servicio, tienen imgenes idealizadas de los mismos, que pocas veces coinciden
con la realidad.
La creacin del diagrama de flujo es una actividad que agrega valor, pues el
proceso que representa est ahora disponible para ser analizado, no slo por
quienes lo llevan a cabo, sino tambin por todas las partes interesadas que
aportarn nuevas ideas para cambiarlo y mejorarlo.
Contexto:
Diagrama de contexto, es el grfico que va a proporcionar el

mbito del

proyecto objeto de estudio.

Intermedio:
Deber haber igual cantidad de archivos. Aunque podr existir mayor cantidad
de almacenamientos en el nivel 2 debido a la explosin de algn proceso.
Detalles:
En el ltimo nivel, cada proceso realizar una funcin especfica y concreta.
En general la expansin de niveles depende de la naturaleza y complejidad del
sistema que se modele; no es posible especificar un nmero de niveles, en
general se debe continuar con el proceso de expansin todo lo que sea necesario
para comprender los detalles del sistema y la forma en que trabaja, teniendo
cuidado de verificar todos los aspectos con usuarios que conocen el sistema, en
general, se debe expandir todo aquel proceso que incluyen varias tareas para las

que es necesario, el flujo de datos entre diferentes personas o localidades. Por

otra parte no requieren expansin aquellas tareas que son realizadas por una
persona o en un escritorio, donde no existe flujo de datos.
2.7.

Diagramas entidad relacin:

Denominado por sus siglas como: E-R; Este modelo representa a la realidad a
travs de un esquema grfico empleando la terminologa de entidades, que son
objetos que existen y son los elementos principales que se identifican en el
problema a resolver con el diagramado y se distinguen de otros por sus
caractersticas particulares denominadas atributos, el enlace que rige la unin de
las entidades esta representada por la relacin del modelo.
Recordemos que un rectngulo nos representa a las entidades; una elipse a los
atributos de las entidades, y una etiqueta dentro de un rombo nos indica la
relacin que existe entre las entidades, destacando con lneas las uniones de
estas y que la llave primaria de una entidad es aquel atributo que se encuentra
subrayado.
Es de gran ayuda por cuanto nos permite tener una representacin grfica del
flujo de datos del sistema en desarrollo, asimismo nos sirve como
documentacin para efectos de validacin y verificacin con el usuario final.

2.8.

Libreras de enlace dinmico (DLLS):

DLL es el acrnimo de Dynamic Linking Library (Bibliotecas de Enlace
Dinmico), trmino con el que se refiere a los archivos con cdigo ejecutable
que se cargan bajo demanda del programa por parte del sistema operativo. Esta
denominacin se refiere a los sistemas operativos Windows siendo la extensin
con la que se identifican los ficheros, aunque el concepto existe en
prcticamente todos los sistemas operativos modernos.
Una Biblioteca de Vnculos Dinmicos (DLL) file es un archivo ejecutable que
permite compartir cdigo y otros recursos para realizar ciertas tareas. Las Dll de
Windows permiten que las aplicaciones puedan operar en el entorno de
Windows.

2.9.

Variables de determinacin de la calidad de un software:

La calidad del software puede medirse despus de elaborado el producto.
Con la nocin de solucin, y ello nos remite a su vez a dos aspectos, por un lado
a la solucin software, al producto y, por otro lado, al uso que se haga del

software. Esto se ha consignado en la literatura especializada como la dualidad

Verificacin y Validacin.
Garanta y control de calidad del software:
La concordancia con los requerimientos funcionales y de rendimiento
explcitamente establecidos, con los estndares de desarrollo explcitamente
documentados y con las caractersticas implcitas que se espera de todo software
se define como:
- Los requerimientos del software son los fundamentos desde los que se mide la
calidad. La falta de concordancia con los requerimientos es una falta de calidad.
- Los estndares especificados definen un conjunto de criterios de desarrollo que
gua la forma en se aplica la ingeniera del software; si no se siguen ciertos
criterios, casi siempre se dar una falta de calidad.
Los Factores Que Afectan La Calidad Del Software:
Correccin: El grado en que un programa satisface sus especificaciones y
consigue los objetivos de la misin encomendada por el cliente.
Fiabilidad: El grado en que se puede esperar que un programa lleve a cabo sus
funciones esperadas con la precisin requerida. Esta puede ser medida o
estimada por datos histricos o estadsticos.
Eficiencia: La cantidad de recursos de computadora y de cdigo requeridos por
un programa para llevar a cabo sus funciones.
Integridad: El grado en que puede controlarse el acceso al software o a los
datos, por personal no autorizado.
Facilidad De Uso: El esfuerzo requerido para aprender un programa, trabajar
con l, preparar su entrada e interpretar su salida.
Facilidad De Mantenimiento: El esfuerzo requerido para localizar y arreglar un
error de un programa.
Flexibilidad: El esfuerzo requerido para modificar un programa operativo.
Facilidad De Prueba: El esfuerzo requerido para probar un programa de
manera que se asegure que realiza su funcin requerida.
PORTABILIDAD: El esfuerzo requerido para transferir el programa desde un
hardware y/o un entorno de sistemas de software a otro.

Reusabilidad: El grado en que un programa (o partes de un programa) se puede

reusar en otras aplicaciones. Esto va relacionado con el empaquetamiento y el
alcance de las funciones que realiza el programa.
Facilidad De Interoperacin: El esfuerzo requerido para acoplar un sistema a
otro.
2.10. Base de datos:
Un conjunto de informacin almacenada en memoria auxiliar que permite
acceso directo y un conjunto de programas que manipulan esos datos.
Base de Datos es un conjunto exhaustivo no redundante de datos estructurados
organizados independientemente de su utilizacin y su implementacin en
mquina accesibles en tiempo real y compatibles con usuarios concurrentes con
necesidad de informacin diferente y no predicable en tiempo.
Tablas: Unidad donde crearemos el conjunto de datos de nuestra base de datos.
Estos datos estarn ordenados en columnas verticales. Aqu definiremos los
campos y sus caractersticas. Tambin conocido como archivo.
Columnas: Las columnas son llamados tambin Campos.
Un campo es cada uno de los tipos de datos que se van a usar
Parte de la estructura de una tabla donde se almacenan datos de un mismo tipo.
Registros: En una Base de Datos un simple archivo es un conjunto de registros;
cada fila de una tabla es un registro y contiene datos de diferentes columnas,
pero relacionada con una persona, un producto o suceso.
Vistas: Una vista de base de datos es un resultado de una consulta SQL de cero,
una o varias tablas.
Las vistas tienen la misma estructura que una tabla: filas y columnas. La nica
diferencia es que slo se almacena de ellas la definicin, no los datos. Los datos
que se recuperan mediante una consulta a una vista se presentarn igual que los
de una tabla. De hecho, si no se sabe que se est trabajando con una vista, nada
hace suponer que es as. Al igual que sucede con una tabla, se pueden insertar,
actualizar, borrar y seleccionar datos en una vista. Aunque siempre es posible
seleccionar datos de una vista, en algunas condiciones existen restricciones para
realizar el resto de las operaciones sobre vistas.
Una vista se especifica a travs de una expresin de consulta (una sentencia
SELECT) que la calcula y que puede realizarse sobre una o ms tablas. Sobre un

conjunto de tablas relacionales se puede trabajar con un nmero cualquiera de

vistas
La mayora de los DBMS soportan la creacin y manipulacin de vistas.
Consultas: Aqu definiremos las preguntas que formularemos a la base de datos
con el fin de extraer y presentar la informacin resultante de diferentes formas
(pantalla, impresora...)
Puede ser una bsqueda simple de un registro especfico o una solicitud para
seleccionar todos los registros que satisfagan un conjunto de criterios.
Constrains o restricciones: Un constrains o restriccin consiste en la definicin
de una caracterstica adicional que tiene una columna o una combinacin de
columnas, suelen ser caractersticas como valores no nulos (campo requerido),
definicin de ndice sin duplicados, definicin de clave principal y definicin de
clave fornea (clave ajena o externa, campo que sirve para relacionar dos tablas
entre s).
Restriccin1: una restriccin de tipo 1 es una restriccin que aparece dentro de
la definicin de la columna despus del tipo de dato y afecta a una columna, la
que se est definiendo.
Restriccin2: una restriccin de tipo 2 es una restriccin que se define despus
de definir todas las columnas de la tabla y afecta a una columna o a una
combinacin de columnas.
Threads: Los threads son similares a los procesos en que ambos representan una
secuencia simple de instrucciones ejecutada en paralelo con otras secuencias.
Los hilos son una forma de dividir un programa en dos o ms tareas que corren
simultneamente.
2.10. Manejadores De Base De Datos(DBMS)
El sistema manejador

de bases de datos (DBMS: Database Management

System) es la porcin ms importante del software de un sistema de base de

datos. Un DBMS es una coleccin de numerosas rutinas de software
interrelacionadas, cada una de las cuales es responsable de alguna tarea
especfica.
El DBMS es conocido tambin como Gestor de Base de datos.

El DBMS interpreta las peticiones de entrada/ salida del usuario y las manda al
sistema operativo para la transferencia de datos entre la unidad de memoria
secundaria y la memoria principal.
En s, un sistema manejador de base de datos es el corazn de la base
de datos ya que se encarga del control total de los posibles aspectos que la
puedan afectar.
Para operar las bases de datos existen los manejadores de bases de datos,

los

cuales agilizan las operaciones en las bases de datos y no son otra cosa que un
conjunto de programas que permiten hacer uso de estos para poder organizar y
manipular la informacin. Son ejemplos de manejadores de bases de datos SQL
-SERVER, ORACLE, PARADOX, SUPERBASE, ACCSES.
Dbase: Fue la primera DBMS (Data Base Mannager Software) para PC. Creada
por Borland. Su nombre original fue Vulcan, dBASE fue creado por Wayne
Ratliff para administrar un equipo de football americano. Fue pulido en el Jet
Propulsion Labs de Los ngeles.
Renombrado dBASE II cuando Hal Lashlee y George Tate formaron AshtonTate para comercializarlo (Ashton-Tate fue adquirido por Borland en 1991),
dBASE fue muy popular por muchos aos, convirtindose en el estndar en PC.
dBASE es un lenguaje de 4ta generacin, con un intrprete, adems de permitir
el uso en forma interactiva.
Fox-Pro: Visual FoxPro sirve para escribir, construir y probar aplicaciones de
Visual FoxPro 8.0, e incluye una mayor compatibilidad con Microsoft SQL
Server T 2000. Proporciona las herramientas necesarias para crear y administrar
aplicaciones y componentes de bases de datos de 32 bits de alto desempeo. Sus
herramientas slidas y su lenguaje centrado en datos y orientado a objetos lo
hacen ideal para construir aplicaciones modernas, escalables y multinivel que
integren la computacin cliente/servidor e Internet.
Visual FoxPro es uno de los gestores de Bases de Datos relacionales ms rpido
y flexible del mercado actual.
Oracle: Es manejador de base de datos relacional que hace uso de los recursos
del sistema informtico en todas las arquitecturas de hardware, para garantizar
su aprovechamiento al mximo en ambientes cargados de informacin. Es el
conjunto de datos que proporciona la capacidad de almacenar y acude a estos de

forma consecuente con un modelo definido como relacional. Adems es una

suite de productos que ofrece una gran variedad de herramientas.
Paradox: Es un motor de base de datos, que viene incluido con la herramienta
RAD Delphi, ambos de la casa Inprise, antes Borland. Para la creacin de tablas
provee la aplicacin DataBase Desktop, la cual permite crear tablas, consultas
QBE (Query By Example) o archivos de scripts SQL.
Sql Server Manager: Es un sistema y herramienta de administracin de bases
de datos para Servidores SQL. Con una interfaz grfica de usuario amigable
sobre Windows, que por medio de iconos se representa a las diferentes tareas
que suele desempear un administrador. Entre estas tareas podemos encontrar la
administracin de uno o ms servidores SQL, de recursos fsicos, de bases de
datos, de objetos en la base de datos.
Superbase: Es una base de datos y una herramienta rpida del desarrollo del uso
(RAD). Cuando est utilizado como base de datos, esencialmente llena el papel
de un gabinete de limadura electrnica. Una funcin ms interesante es su uso
como herramienta de desarrollo rpida del uso, de desarrollar diversos
programas (soluciones) para los campos diversos, de la gerencia de reactores
nucleares, a supervisar procesos de fabricacin, control de calidad, la gerencia
de proyecto, la generacin y el control de la factura, planes contables completos,
el etc.
Inventado por Precisin Software Ltd en Reino Unido, Superbase primero fue
lanzado en 1985 para el Amiga. Entonces en 1989 una versin de Windows fue
lanzada para hacer historia como la primera base de datos de Windows del
mundo. In1991 Superbase tena 86% del mercado mundial de las bases de datos
de Windows.
No teniendo ningn producto similar, Microsoft compr 200.000 licencias que
fueron revendidas bajo el nombre de la base de datos de Microsoft. Esto ayudada
para llenar el boquete hasta que Microsoft desarroll su propia base de datos
llamada Access.
Access: Es un sistema gestor de bases de datos relacionales (SGBD). Una base
de datos suele definirse como un conjunto de informacin organizada
sistemticamente.

CAPITULO III

3 Metodologa de Desarrollo.
3.1

Metodologa RUP
El Proceso Unificado Racional, Rational Unified Process en ingls, y sus siglas
RUP, es un proceso de desarrollo de software y junto con el Lenguaje
Unificado de Modelado UML, constituye la metodologa estndar ms
utilizada para el anlisis, implementacin y documentacin de sistemas
orientados a objetos. El RUP no es un sistema con pasos firmemente
establecidos, sino que trata de un conjunto de metodologas adaptables al
contexto y necesidades de cada organizacin, donde el software es organizado
como una coleccin de unidades atmicas llamados objetos, constituidos por
datos y funciones, que interactan entre s.
RUP es un proceso para el desarrollo de un proyecto de un software que define
claramente quien, cmo, cundo y qu debe hacerse en el proyecto

3.2

RUP como proceso de desarrollo

RUP es explcito en la definicin de software y su trazabilidad, es decir,

contempla en relacin causal de los programas creados desde los
requerimientos hasta la implementacin y pruebas.

RUP identifica claramente a los profesionales (actores) involucrados en el

desarrollo del software y sus responsabilidades en cada una de las
actividades.

3.3 Fases de desarrollo del software

a) Fase de inicio
Se hace un plan de fases, donde se identifican los principales casos de uso y
se identifican los riesgos. Se concreta la idea, la visin del producto, como
se enmarca en el negocio, el alcance del proyecto. El objetivo en esta etapa
es determinar la visin del proyecto.

Modelado del negocio

En esta fase el equipo se familiarizar ms al funcionamiento de la empresa,
sobre conocer sus procesos.
Entender la estructura y la dinmica de la organizacin para la cual el
sistema va ser desarrollado.
Entender el problema actual en la organizacin objetivo e identificar
potenciales mejoras.
Asegurar que clientes, usuarios finales y desarrolladores tengan un
entendimiento comn de la organizacin objetivo.

Requisitos
En esta lnea los requisitos son el contrato que se debe cumplir, de modo que
los usuarios finales tienen que comprender y aceptar los requisitos que
especifiquemos.

 Establecer y mantener un acuerdo entre clientes y otros stakeholders

sobre lo que el sistema podra hacer.
Proveer a los desarrolladores un mejor entendimiento de los requisitos
del sistema.
Definir el mbito del sistema.
Proveer una base para estimar costos y tiempo de desarrollo del sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las
necesidades y metas del usuario.

b) Fase de elaboracin
Se realiza el plan de proyecto, donde se completan los casos de uso y se
mitigan los riesgos. Planificar las actividades necesarias y los recursos
requeridos, especificando las caractersticas y el diseo de la arquitectura.
En esta etapa el objetivo es determinar la arquitectura ptima
.

Anlisis y Diseo
En esta actividad se especifican los requerimientos y se describen sobre
cmo se van a implementar en el sistema.
Transformar los requisitos al diseo del sistema.
Desarrollar una arquitectura para el sistema.
Adaptar el diseo para que sea consistente con el entorno de
implementacin.

c) Fase de construccin
Se basa en la elaboracin de un producto totalmente operativo y en la
elaboracin del manual de usuario. Construir el producto, la arquitectura y
los planes, hasta que el producto est listo para ser enviado a la comunidad
de usuarios. En esta etapa el objetivo es llevar a obtener la capacidad
operacional inicial.

Implementacin
Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables
y dems. El resultado final es un sistema ejecutable.
Planificar qu subsistemas deben ser implementados y en qu orden
deben ser integrados, formando el Plan de Integracin.
Cada implementador decide en qu orden implementa los elementos del
subsistema.
Si encuentra errores de diseo, los notifica.
Se integra el sistema siguiendo el plan.

Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que
estamos desarrollando, pero no para aceptar o rechazar el producto al final
del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de
vida.
Encontrar y documentar defectos en la calidad del software.

 Generalmente asesora sobre la calidad del software percibida.

Provee la validacin de los supuestos realizados en el diseo y
especificacin de requisitos por medio de demostraciones concretas.
Verificar las funciones del producto de software segn lo diseado.
Verificar que los requisitos tengan su apropiada implementacin.

d) Fase de transicin
El objetivo es llegar a obtener el proyecto se realiza la instalacin del
producto en el cliente y se procede al entrenamiento de los usuarios.
Realizar la transicin del producto a los usuarios, lo cual incluye:
manufactura, envo, entrenamiento, soporte y mantenimiento del producto,
hasta que el cliente quede satisfecho, por tanto en esta fase suelen ocurrir
cambios.

Despliegue
Esta actividad tiene como objetivo producir con xito distribuciones del
producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:
Probar el producto en su entorno de ejecucin final.
Empaquetar el software para su distribucin.
Distribuir el software.
Instalar el software.
Proveer asistencia y ayuda a los usuarios.

 Formar a los usuarios y al cuerpo de ventas.

Migrar el software existente o convertir bases de datos.

Figura donde se muestra las fases de la metodologa RUP

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual

consiste en reproducir el ciclo de vida en cascada a menor escala. Los objetivos de
una iteracin se establecen en funcin de la evaluacin de las iteraciones
precedentes.

A medida que se avanza en el proyecto, es decir, cuando se va pasando de una fase

a otra, la importancia relativa de cada uno de los Flujos de Trabajo va cambiando.
As, en las iteraciones de la Fase de Inicio el trabajo se centra principalmente en el
Modelamiento del Negocio y en la captura y especificacin de requisitos. Pero en la

fase de Construccin el desarrollo est enfocado en la Implementacin

(codificacin) y, en menor medida, en el Diseo

3.4

Lenguaje Unificado de Modelado UML

El Lenguaje Unificado de Modelado o UML es una tcnica para la
especificacin de sistemas en todas sus fases. Esta ha sido desarrollada por los
ms importantes autores en materia de anlisis y diseo de sistemas, ha sido
usada con xito en sistemas hechos para toda clase de industrias alrededor del
mundo: salud, bancos, comunicaciones, aeronutica, finanzas, etc.
UML no es un lenguaje de programacin. Existen herramientas que pueden
ofrecer generadores de cdigo de UML para una gran variedad de lenguaje de
programacin, as como construir modelos por ingeniera inversa a partir de
programas existentes. Este es pues un lenguaje de propsito general para el
modelado orientado a objetos, UML es tambin un lenguaje de modelamiento
visual que permite una abstraccin del sistema y sus componentes.
5.8.1. Objetivos del lenguaje unificado de modelado.
UML es un lenguaje de modelado que pueden usar todos los modeladores. No
tiene propietario y est basado en el comn acuerdo de gran parte de la
comunidad informtica.
UML no pretende ser un mtodo de desarrollo completo, pues no incluye un
proceso de desarrollo paso a paso, pero puede manejar todos los conceptos que
se consideran necesarios para utilizar un proceso moderno de desarrollo,
basado en construir una slida arquitectura para resolver requisitos dirigidos
por casos de uso, por otro lado busca ser tan simple como sea posible pero
manteniendo la capacidad de modelar toda la gama de sistemas que se
necesiten construir. UML necesita ser lo suficientemente expresivo para
manejar todos los conceptos que se originan en un sistema moderno, tales
como la concurrencia y distribucin, as como tambin los mecanismos de la
ingeniera de software como son la encapsulacin y componentes.

5.8.2. Uso del lenguaje unificado de modelado.

UML sirve para hacer modelos que permitan:

a) Visualizar como es un sistema o como de desea

b) Especificar la estructura y/o comportamiento de un sistema.
c) Hacer una plantilla que gue la construccin de los sistemas
El modelado sirve no solamente para los grandes sistemas; an en aplicaciones
de pequeo tamao se obtienen beneficios de modelar, sin embargo, es un
hecho que entre ms grande y ms complejo es el sistema, el modelado juega
un papel ms importante, esto se debe a una razn simple: se hacen modelos de
sistemas complejos porque no se pueden entender en su totalidad.
El UML es independiente de metodologa, por lo que puede ser usada y lo es
en distintas metodologa como: Fusion, Objectory, RationalUnifiedProcess,
OMT, ECM, Catalysys, etc. La independencia antes mencionada permite que
las organizaciones adapten el uso de UML a la metodologa que consideren
ms apropiada.
5.8.3. Fases del ciclo de desarrollo que soporta UML.
Cada diagrama puede ser usado con nfasis distinto en las fase de desarrollo:
anlisis, diseo e implementacin, un diagrama cualquiera en una fase de
tendr un estudio lgico, cabe aclarar que aunque UML es orientado a objetos
preferentemente, esto es til en cualquier modelo tecnolgico ya que es
independiente de lenguajes de programacin o tecnologa determinada.

5.8.4. Diagramas que ofrece el UML.

El UML tiene una notacin grfica muy expresiva que permite representar en
mayor o menor medida todas las fases de un proyecto informtico pasando por
el anlisis, diseo, implementacin y hasta configuracin. Estos grficos son
un conjunto de elementos con sus relaciones, por otro lado ofrecen una vista
del sistema a modelar. Para poder representar correctamente un sistema UML
ofrece una amplia variedad de diagramas para visualizar el sistema desde
varias perspectivas, entre estos diagramas se tienen los siguientes:

Figura 5Diagramas del UML que expresan grficamente un Modelo.

Fuente: elaboracin propia.
5.8.4.1.

Diagrama de Casos de Usos.

El diagrama de casos de usos representa grficamente los casos de
uso que tiene un sistema (figura6). Se define un caso de uso como
cada interaccin supuesta con el sistema a desarrollar donde se
representan los requisitos funcionales. Es decir se est diciendo lo
que tiene que hacer un sistema.

Figura 6Ejemplo de Modelo de Casos de Uso.

Fuente: http://www.cyta.com.ar/ta0604/v6n4a1.htm

5.8.4.2.

Diagrama de Clase
Un diagrama de clases sirve para visualizar las relaciones entre las
clases que involucran el sistema, las cuales pueden ser asociativas,
de herencia, de uso y de contenido.
Un diagrama de clases est compuesto por los siguientes
elementos:
Clase: atributos, mtodos y visibilidad.
Relaciones: Herencia, Composicin, Agregacin, Asociacin y
Uso.
Clase: Es la unidad bsica que encapsula toda la informacin de un
Objeto (un objeto es una instancia de una clase). A travs de ella
podemos modelar el entorno en estudio (una Casa, un Auto, una
Cuenta Corriente, etc.).

Figura 7Ejemplo de un Diagrama de Clases.

Fuente: http://es.geocities.com/nacarit_espaa/fase2/t1.html, ao:2007
5.8.4.3.

Diagrama de Colaboracin
Un diagrama de colaboracin es una forma alternativa al diagrama
de secuencia para mostrar un escenario. Este tipo de diagrama
muestra las interacciones entre objetos y los enlaces entre ellos.
Los diagramas de secuencia proporcionan una forma de ver el
escenario en un orden temporal - qu pasa primero, qu pasa
despus -, los clientes entienden fcilmente este tipo de diagramas,
por lo que resultan tiles en las primeras fases de anlisis. Por tanto
los diagramas de colaboracin proporcionan la representacin
principal de un escenario, ya que las colaboraciones se organizan
entorno a los

enlaces de unos objetos con otros. Este tipo de diagramas se

utilizan frecuentemente en la fase de diseo, (figura8 ) donde se
muestra un ejemplo.

Figura 8Ejemplo de un Diagrama de Colaboracin.

Fuente: http://rtlabnet.wikidot.com/doc:diseno:rcu:editor, ao:2007.
5.8.4.4.

Diagrama de Secuencia.
Un diagrama de secuencia es una forma de diagrama de interaccin
que muestra los objetos como lneas de vida a lo largo de la pgina
y con sus interacciones en el tiempo representadas como mensajes
dibujados como flechas desde la lnea de vida origen hasta la lnea
de vida destino. Los diagramas de secuencia son buenos para
mostrar qu objetos se comunican con qu otros objetos y qu
mensajes disparan esas comunicaciones. Los diagramas de
secuencia no estn pensados para mostrar lgicas de
procedimientos complejos, (figura 9).

Figura 9Ejemplo de un Diagrama de Secuencia.

Fuente: http://www.chuidiang.com/ood/metodologia/diagrama_secuencia.php,
ao:2007.

CAPITULO IV

4. APLICACIN DE LA METODOLOGIA
4.1.

MODELADO DEL NEGOCIO:

El modelamiento del negocio contempla el flujo de procesos que involucra el
servicio de compras y ventas de productos de una empresa cliente. Estos procesos
permiten la evaluacin detallada de manera que se pueda obtener un resultado que
permita mejorar el negocio de las empresas clientes, mediante la toma de
decisiones.
El modelamiento de estos procesos se visualizar a continuacin.
4.1.1. Visin del Proyecto
El propsito de desarrollar la Visin es mostrar los requerimientos
generales del Sistema de Ventas y servir de base para llevar a cabo un
anlisis ms detallado de los mismos.
4.1.2. Perspectiva Externa: Modelo de Casos de Uso del Negocio (MCUN)
Se describe brevemente, desde el punto de vista externo o del usuario, el
conjunto de acciones que el negocio lleva a cabo y que provee resultados
de valor a quienes interactan en l.
A) Lista de actores del negocio

Cliente

Proveedor

B) Casos de uso del negocio

Gestion Venta

Control Almacen

C) Diagrama de casos de uso de negocio

Gestion Venta

Cliente
(f rom Actores del Negocio)

(from Casos de Uso del Negocio)

Gestion Compra

Proveedor

(from Casos de Uso del Negocio)

(f rom Actores del Negocio)

4.1.3. Perspectiva Interna: Modelo de Anlisis del Negocio

A) Lista de trabajadores de negocio

Vendedor

Almacenero

B) Lista de entidades de negocio

producto

categoria

venta

proveedor

empleado

C) Realizacin de los casos de Uso del Negocio

usuario

cliente

Ges ti on Venta

R_Ges ti on Ventas
(f ro m

Ca sos d e Uso d el

(f ro m

Ca sos d e Uso d el

Ne go ci o)

Control Al m acen

R_Control Alm acen

Ne go ci o)

D) Modelo de Anlisis del Negocio

Ges tion Venta

Vendedor

(from Ca sos de Uso del Negoci o)

Control Alm acen

Alm acenero

(from Ca sos de Uso del Negoci o)

E) Reglas del Negocio

Solo se permiten ventas al contado y en moneda nacional.
La empresa emite boleta o factura
No se admiten descuentos

4.1.4. Diagrama de Objetos del Negocio

Gestin Venta

lee

cliente
(f rom Entidades del Negocio)

lee

Registra
Vendedor

producto
(f rom Entidades del Negocio)

(f rom Trabajadores del N egoc io)

venta
(f rom Entidades del Negocio)

Control Almacn

selecciona

proveedor

lee

lee

categoria

Alm acenero
(f rom Trabajadores del Negoc io)

producto

REQUERIMIENTOS

4.2.
4.2.1. Requerimientos Funcionales
Numero
RF01

Descripcin
El sistema permite el mantenimiento de

Actor
Almacenero

RF02

producto
El sistema permite el mantenimiento de

Vendedor

RF03

Clientes.
El sistema permite el mantenimiento de los

Administrador

RF04

usuarios
El sistema permite el mantenimiento de las

Almacenero

RF05

categora de producto
El sistema permite el mantenimiento de

Administrador

RF06
RF07

proveedores
El sistema permite buscar Cliente
El sistema permite buscar Producto

RF08
RF09

El sistema permite buscar Categora

El sistema permite imprimir el documento la

Vendedor
Vendedor
Almacenero
Almacenero
Vendedor

RF10

venta realizada
El sistema permite generar reportes de los

Vendedor

RF11

productos ms vendidos.
El sistema permite emitir un reporte de los

Vendedor

productos vendidos (diario, semanal, mensual)

4.2.2. Requerimientos No Funcionales

Usabilidad:
El sistema debe presentar mensajes de error que permitan al usuario
identificar el tipo de error.
Fiabilidad:
En el sistema, todo uso requiere la autenticacin de usuarios.
Seguridad:
El acceso al sistema debe ser restringido al uso de claves asignadas a cada
uno de los usuarios y dependiendo su funcin tendr un acceso diferente.
Soportabilidad y Operabilidad:
El sistema debe poder ejecutarse en el Sistema Operativo Linux y/o
Windows.
El sistema debe ser de fcil operacin para el area de ventas
4.2.3. Diagrama de Casos de Uso
Diagrama de Casos de Uso de Ventas

<<include>>
Buscar Producto
(from Casos Uso)

<<include>>

Registrar Venta
(from Casos Uso)

<<extend>>
Vendedor

Buscar Cliente

(f rom Actors)

(from Casos Uso)

Mantenimiento Clientes
(from Casos Uso)

Diagrama de Casos de Uso Control de Almacn

<<extend>>

Mantenimiento Categorias

Buscar Categoria

(from Casos Uso)

(from Casos Uso)

<<extend>>
Almacenero
(f rom Actors)

Mantenimiento Productos

Buscar Producto

(from Casos Uso)

(from Casos Uso)

Diagrama de Casos de Uso Control Seguridad

<<include>>

Asignar Perfil
(from Casos Uso)

Administrador
(f rom Actors)

Mantenimiento Usuario

<<extend>>

(from Casos Uso)

Buscar Usuario
(from Casos Uso)

4.3.

CASOS DE USO DETALLADO

CASO DE USO
ACTOR
PRECONDICION

Mantenimiento Categoras
Almacenero
El usuario ha sido admitido con el rol de

POSCONDICION

almacenero y tiene acceso al sistema

Se ha registrado la categora de los
productos

FLUJO BASICO
1. El caso de uso comienza cuando el almacenero hace clic en el modulo almacn
2. El almacenero hace clic en la opcin Categoras
3. El sistema muestra formulario de ingreso de datos con la relacin de categoras
existentes
4. El almacenero procede a dar clic en el botn nuevo
5. El sistema habilita las cajas de texto para el ingreso de datos
6. El almacenero procede a ingresar los datos de categoras
7. El almacenero indica Registrar
8. El sistema solicita confirmacin
9. El almacenero indica Confirmar
10. El sistema valida y registra datos
11. El sistema muestra Lista de Categoras
12. El caso de uso finaliza
FLUJOS ALTERNATIVOS
En el paso 9 el almacenero indica no registrar
En el paso 10 el sistema no registra los datos, entonces muestra un mensaje de error

CASO DE USO
ACTOR
PRECONDICION
POSCONDICION
FLUJO BASICO

Mantenimiento Productos
Almacenero
El usuario ha sido admitido con el rol de
almacenero y tiene acceso al sistema
Se ha registrado los productos

1. El caso de uso comienza cuando el almacenero hace clic en el modulo Almacen

2. El almacenero hace clic en la opcin Productos

3. El sistema muestra formulario de ingreso de datos con la relacin de productos
existentes
4. El almacenero procede a dar clic en el botn nuevo
5. El sistema habilita las cajas de texto para el ingreso de datos
6. El almacenero procede a ingresar los datos de productos
7. El almacenero indica Registrar
8. El sistema solicita confirmacin
9. El almacenero indica Confirmar
10. El sistema valida y registra datos
11. El sistema muestra Lista de Productos
12. El caso de uso finaliza
FLUJOS ALTERNATIVOS
En el paso 9 el almacenero indica no registrar
En el paso 10 el sistema no registra los datos, entonces muestra un mensaje de error

CASO DE USO
ACTOR
PRECONDICION
POSCONDICION
FLUJO BASICO

Mantenimiento Clientes
Vendedor
El usuario ha sido admitido con el rol de
Vendedor y tiene acceso al sistema
Se ha registrado los clientes

1. El caso de uso comienza cuando el almacenero hace clic en el modulo Ventas

2. El almacenero hace clic en la opcin Clientes
3. El sistema muestra formulario de ingreso de datos con la relacin de clientes
existentes
4. El almacenero procede a dar clic en el botn nuevo
5. El sistema habilita las cajas de texto para el ingreso de datos
6. El almacenero procede a ingresar los datos del cliente
7. El almacenero indica Registrar
8. El sistema solicita confirmacin
9. El almacenero indica Confirmar
10. El sistema valida y registra datos
11. El sistema muestra Lista de Clientes

12. El caso de uso finaliza

FLUJOS ALTERNATIVOS
En el paso 9 el almacenero indica no registrar
En el paso 10 el sistema no registra los datos, entonces muestra un mensaje de error

CASO DE USO
ACTOR
PRECONDICION
POSCONDICION
FLUJO BASICO

Asignar Usuario
Administrador
El usuario ha sido admitido con el rol de
administrador y tiene acceso al sistema
Se ha registrado los Usuarios

1. El caso de uso comienza cuando el almacenero hace clic en el modulo

Administracion
2. El almacenero hace clic en la opcin Usuarios
3. El sistema muestra formulario de ingreso de datos con la relacin de Usuarios
existentes
4. El almacenero procede a dar clic en el botn nuevo
5. El sistema habilita las cajas de texto para el ingreso de datos
6. El almacenero procede a ingresar los datos del Usuario
7. El almacenero indica Registrar
8. El sistema solicita confirmacin
9. El almacenero indica Confirmar
10. El sistema valida y registra datos
11. El sistema muestra Lista de Usuarios
12. El caso de uso finaliza
FLUJOS ALTERNATIVOS
En el paso 9 el almacenero indica no registrar
En el paso 10 el sistema no registra los datos, entonces muestra un mensaje de error

CASO DE USO
ACTOR
PRECONDICION
POSCONDICION
FLUJO BASICO
1.
2.
3.
4.
5.

Buscar Cliente
Vendedor
El usuario ha sido admitido con el rol de
Vendedor y tiene acceso al sistema
Se ha encontrado al cliente

El caso de uso comienza cuando el vendedor hace clic en el modulo Ventas

El vendedor hace clic en la opcin Registrar Venta
El sistema muestra formulario de Registro de Ventas
El almacenero procede a dar clic en el botn buscar cliente
El sistema muestra una ventana para la bsqueda de clientes con los datos de los

mismos
6. El vendedor procede a ingresar el DNI del cliente
7. El vendedor indica buscar
8. El sistema muestra los datos del cliente que se busco
9. El caso de uso finaliza
FLUJOS ALTERNATIVOS
En el paso 8 el sistema no encuentra al cliente

CASO DE USO
ACTOR

Buscar Producto
Vendedor, Almacenero

PRECONDICION

El usuario ha sido admitido con el rol de

Vendedor no almacenero y tiene acceso al

POSCONDICION
FLUJO BASICO

sistema
Se ha encontrado el producto

1. El caso de uso comienza cuando el usuario hace clic en el modulo Ventas o

2.
3.
4.
5.

Almacen
El vendedor hace clic en la opcin Producto o Registrar Venta
El sistema muestra formulario de bsqueda de producto
El almacenero procede a dar clic en el botn buscar producto
El sistema muestra una ventana para la bsqueda de productos con los datos de

los mismos
6. El vendedor procede a ingresar el cdigo del producto
7. El vendedor indica buscar
8. El sistema muestra los datos del producto que se busco
9. El caso de uso finaliza
FLUJOS ALTERNATIVOS
En el paso 8 el sistema no encuentra el producto

CASO DE USO
ACTOR
PRECONDICION
POSCONDICION
FLUJO BASICO

Buscar Categora
Almacenero
El usuario ha sido admitido con el rol de
Almacenero y tiene acceso al sistema
Se ha encontrado la categora

1. El caso de uso comienza cuando el usuario hace clic en el modulo Almacen

2. El vendedor hace clic en la opcin Categoras
3. El sistema muestra formulario de bsqueda de Categora

4. El almacenero procede a dar clic en el botn buscar categora

5. El sistema muestra una ventana para la bsqueda de categoras con los datos de
los mismos
6. El vendedor procede a ingresar el cdigo del categora
7. El vendedor indica buscar
8. El sistema muestra los datos de la categora que se busco
9. El caso de uso finaliza
FLUJOS ALTERNATIVOS
En el paso 8 el sistema no encuentra el producto

CASO DE USO
ACTOR
PRECONDICION
POSCONDICION
FLUJO BASICO

Registrar Venta
Vendedor
El usuario ha sido admitido con el rol de
vendedor y tiene acceso al sistema
Se ha registrado la venta de productos

1. El caso de uso comienza cuando el vendedor hace clic en el Ventas

2. El vendedor hace clic en la opcin generar ventas
3. El sistema muestra formulario de ingreso de datos para realizar ventas
4. El vendedor procede a ingresar o buscar los datos del cliente
5. El vendedor procede a ingresar o buscar los datos del producto
6. El vendedor procede a agregar el producto para la venta respectiva
7. El sistema calcula el subtotal, el igv y el total
8. Se repite el paso 5 y 6 hasta que el cliente no desee comprar ms productos
9. El vendedor indica Generar Venta
10. El sistema solicita confirmacin

11. El vendedor indica Confirmar

12. El sistema valida y registra datos
13. El caso de uso finaliza
FLUJOS ALTERNATIVOS
En el paso 11 el almacenero indica no registrar

4.4.

DIAGRAMA DE CLASES

productos
detall ecompra
iddetal lcom pr
precio
im porte
regi strar()
modificar()
buscar()

proveedor
idproveedor
com pai a
direcci on
tel efono
mostrar()
regi strar()
buscar()

idproduct
nombreprod
marca
tal la
regi strar()
mostrar()
modificar()
eli minar()

categoria
idcategoria
descri pci on
regi strar()
buscar()
modificar()

com pras_producto
idcompras_prod
fechacompras
mostrar()
regi strar()
buscar()
modificar()

detall eventa
iddetal leventa
cantidad
regi strar()
buscar()
eli minar()

usuario
idusuari o
nombres
password
direcci on
cargo
mostrar()
regi strar()
buscar()
documentoventa
iddocum ento
descrpcion
numdoc
regi strar()
buscar()

cl iente
ventas
idventas
num_ruc
seri e
precciounitario
fechaventa
estado
regi strar()
buscar()

idcli ente
razonsocial
nombres
direcci on
ruc
tel efono
regi strar()
mostrar()
buscar()
modificar()

ti pocli ente
idtipocl ient
descrpcion
regi strar()
buscar()
modificar()

4.5.

BASE DE DATOS LOGICO

4.6.

BASE DE DATOS FISICO

4.7.

INTERFACES
Formulario Inicio de Sesin

iv

Formulario Principal

Formulario Ventas

iv

Formulario Registro Clientes

Formulario Producto

iv

Formulario Usuarios

CONCLUSION
iv

 Para culminar el proyecto tengo que identificar los problemas del

Bazar Joselyn Sport para mejorar el proceso de ventas.
Para identificar los requerimientos del bazar, para el anlisis y
diseo del sistema informtico. facilita la administracin
entendimiento del mismo haciendo ms fcil la integracin de
otros mdulos o componentes para su crecimiento con ello
tambin cabe recalcar que el diseo que se integre fcilmente a
cualquier plataforma de hardware y software.

Para disear las interfaces y crear la base de datos que permitan la

interaccin del usuario con la aplicacin de la manera ms
sencilla posible El uso de la metodologa de desarrollo RUP,
conjuntamente con el lenguaje UML y el manejo de los conceptos
de la programacin orientadas a objetos, propiciaron que el
desarrollo del sistema sea entendible, sostenible. Incremental.

iv

RECOMENDACIONES

Se recomienda tener en cuenta el uso del software como alternativa de

desarrollo del sistema, para as beneficiamos de sus ventajas en cuanto a
conceptos de independencia, costo y facilidad de desarrollo, puesto que las
herramientas que provee el software libre estn muy maduras y capaz de
satisfacer las necesidades del desarrollador.

Para que el sistema crezca hasta un nivel gerencial y estratgico, debern

tener en cuenta en proyectos de desarrollos de mdulos, que estos emitan
reportes que sea capaz de hacer ver cmo va el giro del negocio, tenencias
y adems ayude a tomar decisiones.

Los requerimientos de hardware que se pide, segn la seccin tcnica de

anlisis de factibilidad y el diagrama de despliegue, son mnimos; pero se
recomienda que mientras ms capacidad tenga el servidor mejor
performance tendr el funcionamiento del sistema.

Realizar una continua actualizacin de informacin y preparacin en el

manejo del Sistema, por parte de los usuarios pertenecientes del bazar
Joselyn Sport

iv

Anexos
A. ENCUESTA AL GERENTE
1) Qu procesos realiza con mayor frecuencia en el Bazar Joselyn Seleccione
una alternativas?
a) ventas
b) compras
c) reportes
d) kardex
2) sabe que es un sistema informtico?
iv

Si ( )

No ( )

3) Cmo se califica su manejo de la computadora?

a) muy bueno
b) bueno
c) regular
d) psimo
4) Qu tipo de entorno utilizan las maquinas en el Bazar Joselyn?
a) Linux
b) Unix
c) Microsoft windows
5) Qu tipo de equipos posee su Bazar Joselyn?
a) computadora de ltima generacin
b) Pentium IV
c) maquinas antiguas
6) ha utilizado alguna vez un sistema informtico de ventas?
Si (

No (

7) utiliza usted algn sistema informtico para realizar sus ventas diarias en el
Bazar Joselyn?
Si (

No (

8) Cmo realiza actualmente su proceso de ventas?

Hoja de clculo (
manual ( )

sistema informtico ( )

9) Cunto tiempo cree usted que tarda en brindar informacin de sus reportes
de ventas diarias con un sistema manual?
Un minuto ( )

Una hora ( )
iv

Ms de una Hora ( )

10) Cunto tiempo se demora usted en tener un reporte de stocks de sus

productos?
Un minuto ( )

Una hora ( )

Ms de una Hora ( )

11) Con el sistema informtico implantado se mejor tu proceso de ventas?

Si ( )
No ( )
12) Con el sistema informtico instalado mejor sus reportes de ventas
diarias?
Si ( )
No ( )
13) Con el sistema informtico implementado ayudo a mejorar el control de
stocks de productos?
Si ( )
No ( )
14) El sistema informtico es fcil de utilizar y cubre expectativas?
Si ( )
No ( )
BIBLIOGRAFIA

iv

iv