UNIVERSIDAD INCA GARCILASO DE LA VEGA

FACULTAD DE INGENIERAS
ESCUELA PROFESIONAL DE INGENIERA DE SISTEMAS E INFORMTICA

INFIORME DE INVESTIGACION

SISTEMA PARA CONTROL DE VENTA DE COMIDA RAPIDA (SCVCR)

INTEGRANTES:

NAVARRO CAMPOS, ALDERSHON

FERNANDEZ GONZALES, KEVIN

VELASQUEZ REBATTA, JHERSON

COMINA CHACALIAZA, ALEJANDRO

ALIAGA PEREZ, CARMEN

DOCENTE

VICTOR ARCE ROJAS

CHINCHA - PER

2017
 INDICE

Ttulo Pgina

1 Cartula

2 Dedicatoria

3 Agradecimiento

4 ndice

5 Resumen

6 Abstract

7 Introduccin

8 Generalidades

8.1 Nombre del Proyecto

8.2 Descripcin del proyecto

8.3 Logotipo de la Organizacin

8.4 Razn Social de la Organizacin: Nombre, Direccin, Fono, Email.

8.5 Descripcin de la organizacin

8.6 Organigrama

8.7 Situacin Problemtica

8.7.1 Descripcin de la organizacin

8.7.2 Seleccin del problema.

8.7.3 Antecedentes del Problema.

8.8 Justificacin del proyecto

8.8.1 Justificacin Tcnica

8.8.2 Justificacin Operativa

8.8.3 Justificacin Econmica

8.9 Objetivos del Proyecto

8.9.1 Objetivo General

8.9.2 Objetivo Especfico

8.10 Limitaciones Proyecto

8.10.1 Limitacin Cronolgica

8.10.2 Limitacin Tecnolgica

8.10.3 Limitacin Tcnica

9 Marco Terico (UML, Metodologa, Cliente/Servidor, Gestor de BD, Lenguaje,

etc.).

10 Aplicacin de la Tecnologa: Proceso Unificado de Rational

10.1 m Modela miento Negocio.

10.1.1 Pictograma, Descripcin del Pictograma

10.1.2 Procesos de Negocio: Nombres, Descripcin

10.1.3 Reglas de Negocio (Por cada proceso de negocio)

10.1.4 Visin del Negocio

10.1.5 Modelado de casos de uso del negocio

10.1.6 Especificacin de Casos de Uso de Negocio

10.1.7 Diagrama de Actividad por cada caso de uso

10.1.8 Modelo de Objetos del Negocio (Por cada caso de uso de negocio.)
10.1.9 Modelo de Dominio. 10.2 Modelo de Requerimientos

10.2.1 Modelo de caso de uso de requerimiento detallado

10.2.2 Diagrama de casos de uso de requerimiento

10.2.3 Matriz de priorizacin de casos de usos

10.2.4 Especificacin de casos de usos de requerimientos

10.3 Anlisis

10.3.1 Diagramas de colaboracin

10.3.2 Diagrama de clases de entidad

10.3.3 Diagramas de clases de anlisis (Boundary + Control+ Entitis)

10.4 Diseo

10.4.1 Interfaces de Usuario

10.4.2 Diagrama de secuencia de diseo

10.4.3 Diagrama de clases de diseo

10.4.4 Diagrama de estado (Por lo menos 3 clases)

10.4.5 Diagrama de paquetes de diseo

10.4.6 Modelo fsico de la base de datos Relacional (Rational)

10.4.7 Script de migracin de la base de datos a SQL Server 2000

10.4.8 Modelo fsico de la base de datos Relacional (SQL Server)

10.4.9 Modelo fsico de la base de datos Relacional (Normalizado)

10.5 Implementacin

10.5.1 Diagrama de componentes (Indicar clases implementadas cada uno)

10.5.2 Diagrama de despliegue

10.6 Prueba

10.6.1 Prueba de la caja Negra

11 Conclusiones

12 Recomendaciones

13 Referencias bibliogrficas y/o enlaces web

14 Bibliografa

15 Apndices

15.1 Formato de historias de usuario

15.2 Formato de tarjeta de tareas

15.3 Formato de especificacin de los casos de uso de requerimientos

15.4 Formato de recopilacin de la informacin (Entrevistas, Cuestionario, etc.)

15.5 Faces de construccin de las interfaces

16 Anexos

16.1 Copias de los documentos fuentes encontrados.

16.2 Fotos.

16.3 Videos.
 INTRODUCCIN

El presente Proyecto es el trabajo de los diferentes actores del Sistema

para Control de Venta de Comida Rpida (SCVCR)

SCVCR, en la necesidad de tratar de facilitar y agilizar el proceso de

venta en la Burger Place, y todo esto tiene que ver con la innovacin y
todo esto sera posible si vamos de la mano con la actualizacin.

La necesidad creciente de comercializar cada da es mayor, y para tratar

de cubrir esta necesidad requiere de tcnicas y elementos que faciliten su
desplazamiento hacia los mercados potenciales de clientes.

Y uno de ellos son las bases de datos que es un instrumento de mucha

utilidad en las empresas, es por ello que en la empresa Burger Place
surge la necesidad de controlar las tareas que son muy rutinarias o sobre
las cuales no se tiene control, como son el orden, la manipulacin de
datos, la seguridad de los datos, etc. Esto lleva a dar soluciones que
faciliten la operacin de tareas mediante la construccin de una base de
datos que pueda satisfacer las necesidades en menor tiempo, brindando as
una mejor calidad en los servicios.

Otro instrumento sera una pgina Sistema de Control con la cual nos
permitira poder registrar pedidos, clientes, rdenes etc.
 RESUMEN

El presente proyecto titulado Sistema para Control de Venta de Comida

Rapida para mejorar el proceso de comercializacin de Burger Place
Tiene como objetivo general Implementar un Sistema de Escritorio , para
Burger Place basado en la metodologa RUP.

Este Sistema de escritorio es una herramienta ideal para administrar esta

empresa o negocio de escala media, permitiendo llevar un completo
control de stock, facturacin, manejo de ventas y compras, clientes.
Adems posee un entorno de fcil manejo, donde podr realizar todas
aquellas operaciones que antes consuman una gran cantidad de tiempo,
en pocos segundos.

Su gran potencial y diferencia del mercado es su plataforma o arquitectura

de servicio en la que est desarrollado, lo que permite cubrir todas las
necesidades del negocio y tambin ser utilizadas en una red local.

Este Sistema, es la mejor solucin ya que controlara todos los procesos de

compra y venta, permitiendo tener un manejo eficiente de la gestin del
negocio, y dar cumplimiento con las disposiciones legales vigentes.
1. GENERALIDADES.

1.1. DATOS DEL LOS INTEGRANTES.

Centro Estudios : Universidad Inca Garcilaso de la Vega

Facultad : Ingeniera de Sistema y Telecomunicaciones

Escuela : Ingeniera Sistemas.

Ciclo : VIII.

Jefe de Proyectos :

Apellidos : Fernndez Gonzales.

Nombres : Kevin.

Cdigo Universitario : 0109062044

DN.I. : 45201518

Analista :

Apellidos : Navarro Campos.

Nombres : Aldershon.

Cdigo Universitario : 0109062044

DN.I. : 45201518

Programador :

Apellidos : Aliaga Prez.

Nombres : Carmen

Cdigo Universitario : 0109062044

DN.I. : 45201518

Programador :

Apellidos : Comina Chacaliaza.

Nombres : Roberto Alejandro.

Cdigo Universitario : 423025480.

DN.I. : 42302548.
1.2. NOMBRE PROYECTO:

Implementacin de sistema informtico para mejorar el proceso de

Comercializacin de Burger Place (Sistema de control de Venta de Comida

Rapida).

1.3. OBJETIVOS DEL PROYECTO.

1.3.1 OBJETIVO GENERAL.

Implementar un Sistema de Control de Ventas, para

la Empresa Burger Place.

1.3.2 OBJETIVO ESPECIFICO.

Definir los objetivos, requisitos y viabilidad del

Sistema.

definiciones
Diseo, Programacin e implementacin
en detalle de toda la aplicacin.
de las

1.3.3 OBJETIVOS DEL SISTEMA

Brindar un control ms exacto y detallado de las

ventas y del stock diario.

Proporcionar control absoluto de la cartera de clientes y

sus estados de compras.

Permitir
datos.
el registro de los clientes en nuestra base de
CAPITULO I
MARCO TERICO

CONCEPTUAL
I. MARCO TERICO

CONCEPTUAL:

J. I.I. Datos Generales de La Empresa

II.I.I Ubicacin Geogrfica.

Jr. Tumbes s/n Interior Mercado Ferrocarril puesto 347 Santa

Chimbote Ancash.

II.I.II Base Legal:

Nombre o Razn Social : Burger Place.

Ruc : 10152014789
Titular : Ventocilla Gonzales, Amandina Rosa
DNI 15201478
Direccin : Jr. Tumbes s/n Interior Mercado Ferrocarril
puesto 347 Santa Chimbote Ancash

Actividad : Ventas de Comida Rapida.

Telfono : 056 54 26 58

II.I.III Logotipo:
II.I.IV reas que comprende:

Ventas
Almacn
II.I.V Resea Histrica y Operacional:
La empresa de Comida Rapida Burger Place fue fundada el 01 de
Julio de 2005 llevando el nombre de "Burger Place", adecundose como
Sociedad Annima el 12 de Julio del 2016 adquiriendo el nombre de
Ventas de Comida Rapida "Burger Place" S.A.

Desde entonces nos hemos ido posicionando dentro del mercado

Chinchano, en principal en el mercado Central.
II.I.VI Visin:
Consolidarnos como la mejor empresa en nuestra ciudad, en cuanto a la
produccin y venta de comidas rpidas, apoyndonos en instalaciones
con la ms alta tecnologa para el manejo de nuestros productos y
contamos con personal altamente calificado manteniendo nuestro
riguroso y estricto control de calidad.

A la vez obtendr el reconocimiento a nivel nacional de excelencia en

servicio y calidad de los productos que comercializa, e igualmente
estar atenta a la investigacin y el desarrollo de nuevas tecnologas
para colocarlas al servicio del cliente, con oportunidad y economa.

II.I.VII Misin:
 Somos una empresa de comida rpida ofreciendo productos de calidad
a un precio accesible para la comodidad y satisfaccin de nuestros
clientes

Por otra parte estamos en constantes capacitaciones del factor humano,

actualizacin tecnolgica, inversin de recursos financieros, polticas de
ventas y adquisicin de mercancas de excelente calidad y respaldo.
Generar y fortalecer las relaciones comerciales con sus clientes y
proveedores, a travs de una comunicacin franca, directa y eficiente,
utilizando todas las herramientas y funciones que los avances
tecnolgicos ofrecen cada da.

II.I.VIII Organigrama:
La empresa organiza a su personal de la siguiente manera:
GERENTE:
Encargado de dirigir al personal y autorizar todas las operaciones
dentro de la empresa y de administrar los diferentes recursos de la
misma.

FUNCIONES:

Iniciar las Operaciones.

Revisar agenda de cobros y pagos.

Iniciar registro de caja.

Atender a los proveedores.

Hacer o verificar el correcto corte de caja

Elaborar la cartera de clientes.

Realizar operaciones bancarias.

Supervisin de inventario.

Revisin del ingreso de mercadera y su facturacin.

Autorizacin de movimientos materiales o

financieros.

ADMINISTRADOR:
Encargado de administrar el correcto funcionamiento de los
procesos ya dems revisa las ventas hechas en el da.

FUNCIONES:

Realizar operaciones bancarias

Supervisin de inventario

Revisin del ingreso de mercanca y su facturacin

CONTADOR:
 Encargado de contabilizar y de realizar las aperturas de los libros
contables.

FUNCIONES:

Hacer o verificar el correcto corte de caja.

Realizar los balances.

Declarar los impuestos.

EMPLEADO:

Encargado de atender a los

clientes

FUNCIONES:

Autorizacin de movimientos materiales o

financieros

Mantenimiento del lugar de trabajo

Realizar ruta de cobros a clientes

Compra y recibo de mercanca

Reparto de mercanca a clientes

Atencin de clientes en mostrador en caso necesario

Organizacin de productos en el almacn y en el

mostrador
 CAPITULO II
ANLISIS DEL SISTEMA

ACTUAL
 II. ANLISIS DEL SISTEMA ACTUAL:

II.I.ACCIONES PRELIMINARES:

II.V.I CICLO DE VIDA DEL PROYECTO:

Gestin de Tiempo:

A continuacin se describir el desarrollo de software, desde la fase

inicial hasta la fase final. El propsito de este programa es definir las
distintas fases intermedias que se requieren para validar el desarrollo de
la aplicacin, es decir, para garantizar que el software cumpla los
requisitos para la aplicacin y verificacin de los procedimientos de
desarrollo

El Listado de Actividades Y Cronograma de Trabajo se origina en el

hecho de que es muy costoso rectificar los errores que se detectan tarde
dentro de la fase de implementacin. Gestionar el tiempo permite que
los errores se detecten lo antes posible y por lo tanto, permite a los
desarrolladores concentrarse en la calidad del software, en los plazos de
implementacin y en los costos asociados.

El tiempo que se tomara para llevar a cabo el proyecto en su totalidad, es

decir la realizacin de cada una de las actividades mencionadas a
continuacin, desde la Definicin de Objetivos hasta implementacin
ser de 4 meses.

Se dar inicio al proyecto en la fecha establecida (desde el 01 de Marzo

al 16 de junio del 2017).
 Lista de Actividades:

ACTIVIDADES DESCRIPCIN FECHA

Definicin de objetivos Se definir el resultado del
proyecto y su papel en la
estrategia global.
Anlisis de los requisitos y Se recopilara, examinara y
su viabilidad formulara los requisitos
del cliente y examinar
cualquier restriccin que
se pueda aplicar.
Diseo general Se har los Diseos
generales de la
arquitectura de la
aplicacin (Diagrama de
Clases, Casos de Uso,
Diagrama de Secuencias,
Diagramas de Actividades)
Diseo en detalle De las definiciones
precisas de cada
subconjunto en detalle de
toda la aplicacin (Diseo
de Base de Datos).
Programacin Se proceder con el diseo
(programacin e de las interfaces,
implementacin programacin e
implementacin del
cdigo fuente.
Prueba de unidad Se llevara a cavo una
prueba individual de cada
subconjunto de la
aplicacin para garantizar
que se implementaron de
acuerdo con las
especificaciones.
Integracin Se har para garantizar
que los diferentes mdulos
se integren con la
aplicacin. ste es el
propsito de la prueba de
integracin.
Prueba beta (o validacin) Previo a la entrega del
Web se instalara la prueba
Beta para garantizar que el
software cumple con las
especificaciones
originales.
Documentacin Se elaborara la
documentacin con la
informacin necesaria para
los usuarios del software y
para desarrollos futuros.
Informes y Presentacin Se proceder a elaborar el
del Proyecto informe y la
documentacin requerida
para la sustentacin del
proyecto de practica I
Implementacin Se proceder a ser las
implementaciones
correspondientes, segn
los requerimientos
establecidos.
Mantenimiento Se har mantenimiento
para todos los
procedimientos correctivos
(mantenimiento
correctivo) y las algunas
actualizaciones
secundarias del software si
as lo requiere el cliente
(mantenimiento continuo),
este mantenimiento sern
cada vez que el cliente lo
solicite, de acuerdo a la
necesidad

Cronograma de Trabajo:

CD. ACTIVIDAD PRECEDENCIA DURACIN (Das)

A Definicin de - 8
objetivos
B Anlisis de los A 7
requisitos y su
viabilidad
C Diseo general B 7

D Diseo en detalle C 15

E Programacin D 33
(programacin e
implementacin
F Prueba de unidad E 4

G Integracin F 3

H Prueba beta (o G 17
validacin)
I Documentacin H 11

J Informes y H 8
Presentacin del
Proyecto
K Implementacin IYJ 1
 II.V.II ANLISIS DE AUDIENCIA:

PERIODO NUMERO DE VECES

Ventas Da 95
Devoluciones o cambio Da 3
Registrar Clientes Nuevos Da 42
Altas de un producto 6 Meses 3
Bajas de un producto 6 Meses 1
Compra de Productos Mes 4
Inventarios Mes 2

II.V.III ANLISIS FUNCIONAL

Requerimientos Funcionales. El sistema debe permitir:

Ventas.
 Gestionar toda la gama de productos (Ver las los
productos stock, los productos por agotarse y los
agotados)
Mantenimiento a los productos en stock (bajas y altas,
variacin de precios)
Mostrar reportes de ventas diarias, por productos y
categora de producto.

Clientes.
Control absoluto de la cartera de clientes y sus estados de
compras
Registrarse al cliente y hacer las consultas del caso va
correo electrnico.

Tienda.
La gestin integral de la empresa.
Control de los productos ofrecidos y del personal
que labora en la empresa.
Mdulo administrativo contable (Facturacin).
Registro de detalle de comprobante, de lo que el
cliente adquiri,
Registro de Ventas

II.V.IV Anlisis No Funcional

Requerimientos no Funcionales.
 Mnimos.

Servidor: Procesador 2800Mhz., 1Gb memoria RAM, Disco duro

de 180Gb, unidad lectora de CD y sistema de Back-up para copias
peridicas de seguridad, conexin a Internet. Sistema operativo
Windows.

Estaciones: Procesador 800Mhz., 1 Gb memoria RAM, Disco

duro de 120Gb, unidad lectora de CD. Sistema Ubuntu 10.4

Red local: Ethernet 100 Mbps con protocolo TCP/IP

Recomendados.
Servidor: Procesador Intel Core2 Do, 2 Gb memoria
RAM, Disco duro de 500 Gb serial ATA, unidad lectora de
CD y sistema de Back-up para copias peridicas de
seguridad, conexin a internet, Sistema operativo
Windows.
Estaciones: Procesador Intel Dual-Core 512Mb,
memoria RAM, Disco duro de 60Gb, unidad lectora de
CD.
Red local Ethernet 100 Mbps con protocolo TCP/IP.

II.II. RECOPILACIN DE LA INFORMACIN

II.II.I Revisin documental:

 Actualmente la Empresa lleva sus registros manualmente, es decir cuenta
con:

Boletas de Venta.
Facturas de Venta.
Recibos.
Gua de Proforma.
Documentos Excel donde almacena el stock de sus
productos.

II.II.II Entrevistas Para Obtener Requerimiento:

Aplicado la entrevista para obtener requerimientos,

II.II.III Diseo de Entrevista:

Entrevista - Preguntas:
 Con cunto personal cuanta la empresa para atender a los clientes y dar
mantenimiento a su almacn?

____________________________________________________________

Cmo se lleva actualmente el control de productos en Stock?

____________________________________________________________

Cmo se lleve el control de entradas de productos?

____________________________________________________________

Se hacen inventarios?

____________________________________________________________

Con que frecuencia?, En qu formatos?

____________________________________________________________

Qu medios han utilizado o utilizan para hacer propaganda empresa?

____________________________________________________________

Cmo muestran a los clientes las caractersticas y la variedad de productos que

ofrece la empresa, incluyendo precios?

____________________________________________________________

Cmo se lleva un historial de clientes potencialmente frecuentes?

____________________________________________________________

De qu manera se emite en los cierres diarios, semanales y mensuales una

informacin de detallada de los servicios y productos vendidos, detallando bajas
y altas en las ganancias generadas?
____________________________________________________________

Cmo recibe el dueo un informe minucioso al final del da de sus ingresos?

interpreta correctamente el informe?
____________________________________________________________
El dueo est satisfecho con la gestin integral de su empresa?

II.II.IV Hardware disponible.

1 Computadora Intel Pentium IV 3.0 Mhz. o 2 Computadoras Intel

Pentium Dual Core E5200 o 1 Impresora HP LaserJet 5200. o 1 Mdem
Router TP-Link.
II.II.V Distribucin de Equipos.

En ventas, se tiene las dos PCs Intel Dual Core, estas conectadas ente si,
y a su vez tambin en red con la impresora.
En almacn tenemos la PCs Intel Pentium IV, sin conexin a internet y
de los otros dos equipos.

II.III. Formulacin del Problema

La empresa de comidas rpidas Burger Place es una empresa que brinda el

servicio de venta de comidas rpidas, en general. Identificando la problemtica
dentro de la empresa es que no se lleva un control exacto de sus ventas diarias,
reportes de ventas, ganancias, productos en stock, ya que todos los registros son
manuales. La empresa no cuenta con estrategias precios, de canal, de
mercadotecnia de marca, de publicidad, de segmentacin las cuales ejercen un
fuerte impacto en los clientes. No cuenta con ningn tipo de tecnologa que
nos facilite la administracin de los datos del cliente, apoyo a la toma de
decisiones, administracin de campaas en el rea de ventas

II.IV. Descripcin del Sistema Actual.

Actualmente el negocio no cuenta con procesos bien definidos, En relacin al

control de inventario, la informacin se elabora manualmente en archivos de
papeles, y en consecuencia generaba una labor tediosa encontrar informacin,
ocasionando demoras en los servicios.
El control de registro de clientes realizada a mano en el cual se anotaba el
nombre, telfono, direccin y pedidos del cliente, con la dificultad de que la
informacin continuaba dispersa.

II.V. Identificacin de los requerimientos

II.V.I Anlisis de entradas y Salidas.

II.VI. Alcance del Sistema Propuesto:

II.VI.I Justificacin

IV.I.I.I Justificacin Tcnica.

Para trabajar con la implementacin del sistema no se necesita mucho

conocimiento ya que solo se tiene que saber los conocimientos bsicos de
funcionamiento de una computadora.

IV.I.I.II Justificacin Operativa.

Al implantar el Sistema, sus uso sera muy fcil ya que el entorno es por medio
de formularios amigables es fcil de aprender su funcionamiento y por otra lado
nos generara los reportes de las ventas diarias de los productos en almacn, etc.
Y por otra parte el Sistema nos ayudara toma decisiones que con lleva a lograr
las metas y objetivos definidos. Todas las operaciones se realizan manualmente,
pero con la aplicacin del sistema estas sern ms productivas y eficientes.

IV.I.I.III Justificacin Econmica.

La empresa Burger Place cuenta con un presupuesto establecido, para mejorar

la calidad, si el sistema lo requiere y a la vez adquirir el software.
 CAPITULO III ANLISIS Y
DISEO DEL SISTEMA
PROPUESTO

III. ANLISIS Y DISEO DEL SISTEMA PROPUESTO:

III.I Descripcin de las Metodologas ms Usadas:

III.IV.I Metodologa RUP:

Es una metodologa cuyo fin es entregar un producto de software. Se estructura

todos los procesos y se mide la eficiencia de la organizacin.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de
modelado UML, constituye la metodologa estndar ms utilizada para el
anlisis, implementacin y documentacin de sistemas orientados a objetos.
 Describe cmo aplicar enfoques para el desarrollo del software, llevando a cabo
unos pasos para su realizacin adems se centra en la produccin y
mantenimiento de modelos del sistema.

RUP implementa:
Desarrollo iterativo del software: Permite comprender los
requerimientos que hacen crecer el sistema.
Administracin de requerimientos: Describe como se obtienen,
organizan, documentan los requerimientos.
Uso de arquitecturas basadas en componentes: Se basa en disear una
arquitectura que sea flexible, fcil de modificar.
Modelo visual de software: Permite analizar la consistencia entre los
componentes, el diseo y su implementacin.
Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es
llevada bajo dos disciplinas:

Disciplina de Desarrollo
Ingeniera de Negocios: Entendiendo las necesidades del negocio.
Requerimientos: Trasladando las necesidades del negocio a un sistema
automatizado.
Anlisis y Diseo: Trasladando los requerimientos dentro de la
arquitectura de software.
Implementacin: Creando software que se ajuste a la arquitectura y que
tenga el comportamiento deseado.
Pruebas: Asegurndose que el comportamiento requerido es el correcto
y que todo lo solicitado est presente.

Disciplina de Soporte
Configuracin y administracin del cambio: Guardando todas las
versiones del proyecto.
Administrando el proyecto: Administrando horarios y recursos.
Ambiente: Administrando el ambiente de desarrollo.
Distribucin: Hacer todo lo necesario para la salida del proyecto.
Es recomendable que a cada una de estas iteraciones se les clasifique y ordene
segn su prioridad, y que cada una se convierte luego en un entregable al
cliente. Esto trae como beneficio la retroalimentacin que se tendra en cada
entregable o en cada iteracin.

Los elementos del RUP son:

Actividades, Son los procesos que se llegan a determinar en cada

iteracin.
Trabajadores, Vienen hacer las personas o entes involucrados en cada
proceso.
Artefactos, Un artefacto puede ser un documento, un modelo, o un
elemento de modelo.
Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se
hace exigente el uso de artefactos, siendo por este motivo, una de las
metodologas ms importantes para alcanzar un grado de certificacin en el
desarrollo del software.

III.IV.II Metodologa XP:

La programacin extrema o eXtreme Programming (XP) es un enfoque de la

ingeniera de software. Es el ms destacado de los procesos giles de desarrollo
de software. Al igual que stos, la programacin extrema se diferencia de las
metodologas tradicionales principalmente en que pone ms nfasis en la
adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los
cambios de requisitos sobre la marcha son un aspecto natural, inevitable e
incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a
los cambios de requisitos en cualquier punto de la vida del proyecto es una
aproximacin mejor y ms realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en
los requisitos.
XP surgi como respuesta y posible solucin a los problemas derivados
del cambio en los requerimientos.
XP se plantea como una metodologa a emplear en proyectos de riesgo.
XP aumenta la productividad

La

metodologa XP entre sus fases se tiene a historia de usuarios que tiene el

mismo propsito que casos de usos, es decir, lo realizan los mismo clientes tal y
como ellos ven las necesidades del sistema.
Son similares al empleo de escenarios con la excepcin que no se limitan a la
descripcin de la interfaz del usuario.
Las historias de usuarios, solamente proporcionan los detalles sobre la
estimacin de riesgo y cunto tiempo llevar dicha implementacin.

Qu es lo que propone XP?

Empieza en pequeo y aade funcionalidad con retroalimentacin

continua.
El manejo del cambio se convierte en parte sustantiva del proceso.
El costo del cambio no depende de la fase o etapa.
 No introduce funcionalidades antes que sean necesarias.
El cliente o el usuario se convierte en miembro del equipo.
Derechos del Cliente:
Decidir que se implementa.
Saber el estado real y el progreso del proyecto.
Aadir, cambiar o quitar requerimientos en cualquier momento.
Obtener lo mximo de cada semana de trabajo.
Obtener un sistema funcionando cada 3 o 4 meses.
Derechos del Desarrollador:
Decidir cmo se implementan los procesos
Crear el sistema con la mejor calidad posible
Pedir al cliente en cualquier momento aclaraciones de los
requerimientos
Estimar el esfuerzo para implementar el sistema
Cambiar los requerimientos en base a nuevos descubrimiento

III.IV.III Metodologa MSF:

La metodologa MSF se adapta a proyectos de cualquier dimensin y de cualquier

tecnologa.

Esta es una metodologa flexible e interrelacionada con una serie de conceptos, modelos
y prcticas de uso, que controlan la planificacin, el desarrollo y la gestin de proyectos
tecnolgicos. MSF se centra en los modelos de proceso y de equipo dejando en un
segundo plano las elecciones tecnolgicas.

MSF se compone de varios modelos encargados de planificar las diferentes partes

implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto,
Modelo de Equipo, Modelo de Proceso, Modelo de Gestin del Riesgo, Modelo de
Diseo de Proceso y finalmente el modelo de Aplicacin.

Modelo de Arquitectura:
 Diseado para acortar la planificacin del ciclo de vida. Este modelo define las
pautas para construir proyectos empresariales a travs del lanzamiento de
versiones.

Modelo del Equipo:

Este modelo ha sido diseado para mejorar el rendimiento del equipo de

desarrollo. Proporciona una estructura flexible para organizar los equipos de un
proyecto. Puede ser escalado dependiendo del tamao del proyecto y del equipo
de personas disponibles.

Modelo de Proceso:

Diseado para mejorar el control del proyecto, minimizando el riesgo, y

aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura
de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las
actividades, la liberacin de versiones y explicando su relacin con el Modelo de
equipo.

Modelo de Gestin del Riesgo:

Diseado para ayudar al equipo a identificar las prioridades, tomar las decisiones
estratgicas correctas y controlar las emergencias que puedan surgir. Este
modelo proporciona un entorno estructurado para la toma de decisiones y
acciones valorando los riesgos que puedan provocar.

Modelo del Diseo del Proceso:

Diseado para distinguir entre los objetivos empresariales y las necesidades del
usuario. Proporciona un modelo centrado en el usuario para obtener un diseo
eficiente y flexible a travs de un enfoque iterativo. Las fases de diseo
conceptual, lgico y fsico proveen tres perspectivas diferentes para los tres tipos
de roles: los usuarios, el equipo y los desarrolladores.

Modelo de Aplicacin:

Diseado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona

un modelo de tres niveles para disear y desarrollar aplicaciones software. Los
servicios utilizados en este modelo son escalables, y pueden ser usados en un
solo ordenador o incluso en varios servidores.
III.IV.IV Conclusiones Metodolgicas:

XP:

Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras. Pruebas

unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo
pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la
codificacin. Programacin en parejas: se recomienda que las tareas de
desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone la
mayor calidad en el cdigo escrito, de esta manera, el cdigo es revisado y
discutido mientras se escribe. Frecuente integracin del equipo de programacin
con el cliente o usuario. Se recomienda que un representante del cliente trabaje
junto al equipo de desarrollo. Correccin de todos los errores antes de aadir
nueva funcionalidad. Hacer entregas frecuentes. Refactorizacin del cdigo, es
decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento. Las pruebas han de
garantizar que en la refactorizacin no se ha introducido ningn fallo.

RUP:

Brinda una gua para encontrar, organizar, documentar, y seguir los cambios de
los requisitos funcionales y restricciones. Utiliza una notacin de Caso de Uso y
escenarios para representar los requisitos.
Desarrollo del producto mediante iteraciones con hitos bien definidos, en las
cuales se repiten las actividades pero con distinto nfasis, segn la fase del
proyecto. o La creacin de sistemas intensivos en software requiere dividir el
sistema en componentes con interfaces bien definidas, que posteriormente sern
ensamblados para generar el sistema. Esta caracterstica en un proceso de
desarrollo permite que el sistema se vaya creando a medida que se
obtienen o se desarrollan sus componentes. o Es importante que la calidad de
todos los artefactos se evale en varios puntos durante el proceso de desarrollo,
especialmente al final de cada iteracin. En esta verificacin las pruebas juegan
un papel fundamental y se integran a lo largo de todo el proceso. Para todos los
 artefactos no ejecutables las revisiones e inspecciones tambin deben ser
continuas.

MSF:
Es una flexible e interrelacionada serie de conceptos, modelos y mejores
prcticas de uso que controlan la planificacin, el desarrollo la gestin de
proyectos tecnolgicos. MFS se centra en los modelos de procesos y de equipo
dejando en segundo plano las elecciones tecnolgicas.
Concretamente MSF se compone de principios, modelos y disciplinas, adems
de ser adaptable a proyectos de cualquier dimensin y de cualquier tecnologa.

III.II Fundamentacin de la Metodologa seleccionada:

Para la realizacin del proyecto usaremos la Metodologa RUP, tal como lo

mencionamos a continuacin, ya que se pude considerar como la adopcin de las
mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo
con este proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del
software.

Lo ms importante de todo esto no es tener que decidir entre la metodologa XP

y el RUP, es ms bien una recomendacin para usar RUP aunque la queremos
decorar como una comparacin de equivalencia.

Personalmente creemos que la metodologa RUP es adecuada para cualquier tipo

de proyecto y para equipos de cualquier tamao.

La mayora de los equipos que utilizan RUP lo han hecho por varios aos y
tienen especialistas del proceso que facilitan a los miembros sin experiencia el

Conocimiento de las prcticas y metodologas. Los ciclos de vida de un proyecto

en XP y en RUP no son exactamente iguales, aunque sin duda tienen bastantes
similitudes, ambas son metodologas iterativas con probado xito en el
desarrollo de software.

En la Transicin del RUP o entrega de XP las diferencias pueden ser mayores,

para RUP la entrega final debe ser algo mucho ms definido, mientras que en XP
se realizan entregas continuas y discretas que permiten evaluar el sistema
conforme se colocan las versiones finales. Sin embargo, por el esquema iterativo
de ambas, las dos metodologas contemplan entregas parciales despus de cada
iteracin para una evaluacin y monitoreo continuo.
III.III Anlisis:

III.III.I Definicin de Requisitos:

III.III.II Casos esenciales de uso:

III.III.IV Crear Modelo Conceptual:

III.III.V Diagramas de Secuencia:

ACTORES:
 Recepcionar insumos Solicitar Insumos

Entrega insumos
Jefe de Almacen Determinar insumos de Producto
Proveedor

Comprar insumos
Entregar Insumos Solicitado
Administrador

Informar Pedido Informar ventas diarias

Concinero Cajero

Controlar Ingresos mensuales

Anular pedido

Solicitar pedido Registrar ventas

Realizar pago
Entrega producto

Preparar Pedido

Entregar pedido Generar voucher

Empleado Cliente
 ACTORES EXTERNOS.

Cliente Proveedor

ACTORES INTERNOS.

Administrador Cajero Concinero

Jefe de Almacen Empleado

 CASO DE USO DE NEGOCIO ENCONTRADOS

Entrega insumos Recepcionar insumos Registrar ventas Comprar insumos

Informar Pedido Entregar Insumos Solicitado Informar ventas diarias Solicitar Insumos

Entrega producto Realizar pago Controlar Ingresos mensuales Determinar insumos de Producto

Generar voucher Preparar Pedido Anular pedido Solicitar pedido

Entregar pedido
 Entrega insumos R_Entrega insumos Registrar ventas R_Registrar ventas

Informar Pedido R_Informar Pedido Informar ventas diarias R_Informar ventas diarias

Entrega producto R_Entrega producto Controlar Ingresos mensuales R_Controlar Ingresos mensuales

Generar voucher R_Generar voucher Anular pedido R_Anular pedido

Recepcionar insumos R_Recepcionar insumos Comprar insumos R_Comprar insumos

Entregar Insumos Solicitado R_Entregar Insumos Solicitado Solicitar Insumos R_Solicitar Insumos

Determinar insumos de Producto R_Determinar insumos de Producto

Realizar pago R_Realizar pago

Preparar Pedido R_Preparar Pedido Solicitar pedido R_Solicitar pedido

Entregar pedido R_Entregar pedido

 REALIZACIONES DE CASO DE USO DE NEGOCIO

DIAGRAMA DE ENTIDADES

Cargo
Cod_Cargo
Descip_Cargo

Stock
Nota_de_Salida Cod_Stock
Trabajador Cod_Insumo
Cod_Salida
Stock_Actual
Cod_Trabajador Cant_Salida
Stock_Min
DNI Fecha_Salida
Stock_Max
Ap_Paterno Cod_Usuario
Sexo Cod_Entrada
Ap_Materno
Cod_Salida
Cod_Sexo Nom_Trabajador
Descrip_Sexo Direcc_Trabajador
Telf _Trabajador Nota_de_Entrada
Correo_Trabajador Cod_Entrada
Cod_Cargo Cant_Entrada Calif_Prov eedor
Cod_Sexo Fecha_Entrada Cod_Calif
Cod_Usuario Descripcion_Calif _Prov ee
Producto +1
Cod_Pro
Descrip_Pro
Recepcion_Insumos
+1 Proveedor
Cod_Recep Insumo
Usuario Cod_Prov eedor
Fecha_Recep Cod_Insumo
+1 Cod_Usuario +1 ++ +1 +* +1 +* Fecha_Aceptacion_Prov eedor
N_Guia_Recep Nom_Insumo
Id_Usuario Razon_Social_Prov eedor
Cod_Usuario Precio_Insumo
Catalogo_Producto Clav e_Usuario Cod_Insumo
Cod_Insumo Cod_Lote
Cod_Catalogo Cod_Calif
Cod_Cond_Recep
Descrip_Catalogo
Precio_Producto +*
Cod_Pro
+1
+* Condicion_Recepcion Lote
Cod_Cond_Recep Cod_Lote
Venta +1
Descrip_Cond_Recep Fecha_Lote
Cod_Pedido Orden_Compra Cantidad_Lote
Descrip_Pedido Numero_Compra
Fecha_Pedido Fecha_Compra
Cod_Catalogo +* Cantidad
Cod_Insumo
+* Cod_proveedor
Cod_Usuario

+1
Cliente
Cod_Cliente Comprobante_Pago
Nombre_Cliente Cod_Comprobante
Apellido_Cliente +1 +1 Descrip_Comprobante
Telf _Cliente
III.IV Diseo:

III.IV.I Diagramas de clase:

III.V Implementacin de la Bases de Datos:

III.V.I Modelado Conceptual:

V.II.I Concepto de la Base de Datos:

Una base de datos es un conjunto de informacin estructurada en registros y almacenada

en un soporte electrnico legible desde un ordenador. Cada registro constituye una
unidad autnoma de informacin que puede estar a su vez estructurada en diferentes
campos o tipos de datos que se recogen en dicha base de datos. Por ejemplo, en un
directorio de miembros de una asociacin, un registro ser la ficha completa de cada
uno de los socios. En cada registro se recogern determinados datos, como el nombre, la
profesin, la direccin o el telfono, cada uno de los cules constituye un campo.

V.II.II Ciclo de Vida de la Base de Datos:

El ciclo de vida de un desarrollo de una base de datos consta de seis pasos:

a. Anlisis de las necesidades:

En reunin con el cliente se deben documentar los tres grupos de usuarios definidos en
la introduccin de la gua, las necesidades de informacin de cada uno de ellos, as
como los informes que cada uno necesita para su actividad y el contenido de los
mismos. Cuanta ms precisin exista en estos requisitos iniciales ms preciso ser el
desarrollo de la base de datos.
En esta reunin tambin deben quedar documentados los niveles de seguridad de los
grupos de usuarios, los derechos de cada uno de ellos sobre los datos, los requisitos de
los sistemas informticos del cliente (sistema operativo, tipo de red, servidores, etc.) y
la ubicacin de los usuarios.

No hay que olvidar que normalmente en las empresas existen ya sistemas de

almacenamiento de datos, por tanto es conveniente analizar los datos ya existentes y
analizar las posibles relaciones con la base de datos a desarrollar.

Un cuestionario muy sencillo pero muy til para el administrador es el siguiente (a

rellenar por todos los usuarios):

CUESTIONARIO

Nombre,
Cargo,
rea de Responsabilidad,
Obligaciones principales que requieren informacin de la base datos
De qu aplicaciones recibe informacin?
Con cunta frecuencia recibe informacin?
Qu hace con esta informacin?
Qu precauciones de seguridad debe tomar con respecto a la informacin?
Para qu aplicacin proporciona datos?
Estn contemplados cambios para alguna de sus actividades actuales que
involucren alguna de las informaciones anteriores?

b. Estudio de viabilidad

Un estudio de viabilidad implica la preparacin de un informe con las caractersticas

siguientes: Viabilidad tecnolgica. Hay tecnologa suficiente para el desarrollo?
Viabilidad operacional. Existen suficientes recursos humanos, presupuesto, experiencia
y formacin para el desarrollo? Viabilidad econmica. Se pueden identificar los
beneficios? Los beneficios costearan el desarrollo del sistema? Se pueden medir los
costes y los beneficios?
c. Definicin de requisitos

Los requisitos de desarrollo involucran el software y hardware necesario para la

implementacin, los recursos humanos necesarios (tanto internos como externos), la
formacin al personal.

Aunque un poco al margen del tema es conveniente parar en este momento y planificar
las acciones a realizar elaborando un cronograma del proyecto y un organigrama con las
responsabilidades de cada miembro del equipo. Conviene sealar quienes van a ser los
interlocutores y fijar un calendario de reuniones de seguimiento del proyecto.

Hay que definir la figura del validador, esta persona ser la encargada de velar en cada
momento que no se est rebasando el alcance del proyecto, as como asegurar que la
implementacin est encaminada a subsanar las necesidades del cliente.

d. Diseo

En esta etapa se crea un esquema conceptual de la base de datos. Se desarrollan las

especificaciones hasta el punto en que puede comenzar la implementacin. Durante esta
etapa se crean modelos detallados de las vistas de usuario y sobre todo las relaciones
entre cada elemento del sistema, documentando los derechos de uso y manipulacin de
los diferentes grupos de usuarios.

Si parte de la informacin necesaria para crear algn elemento establecido ya se

encuentra implementado en

Otro sistema de almacenamiento hay que documentar que relacin existir entre uno y
otro y detallar los sistemas que eviten la duplicidad o incoherencia de los datos.

El diseo consta, como se vio anteriormente, de tres fases: el diseo global o

conceptual, el diseo lgico y el modelo fsico.

e. Implementacin
Una vez totalmente detallado el modelo conceptual se comienza con la implementacin
fsica del modelo de datos, a medida que se va avanzando en el modelo el administrador
del sistema va asegurando la correccin del modelo y el validador la utilidad del mismo.

La implementacin consiste en el desarrollo de las tablas, los ndices de los mismos, las
condiciones de validacin de los datos, la relacin entre las diferentes tablas. Por otro
lado, la definicin de las consultas y los parmetros a utilizar por cada una de ellas.

Una vez finalizada la implementacin fsica, se asignan las correspondientes medidas de

seguridad y se ubica la base de datos en el lugar correspondiente.

f. Evaluacin y Perfeccionamiento

En esta ltima etapa todos los usuarios del sistema acceden a la base de datos y deben
asegurarse el correcto funcionamiento de la misma, que sus derechos son los adecuados,
teniendo a su disposicin cuanta informacin necesiten. Tambin debern asegurarse
que el acceso a los datos es cmodo, prctico, seguro y que se han eliminado, en la
medida de lo posible, las posibilidades de error.

El administrador se asegura que todos los derechos y todas las restricciones han sido
implementados correctamente y que se ha seguido en manual de estilo en la totalidad de
la implementacin.

El validador se asegurar que todas las necesidades del cliente han sido satisfechas.

III.V.II Diseo y MODELAMIENTO de base de datos con DBDESIGNER.

III.V.III Transformacin del diagrama de Clase a modelo de tabla

Esta seccin se centra nicamente en la transformacin de diagrama de clase a un

modelo de tablas tipo entidad-relacin, donde se aplicar las reglas de correspondencia.
La conversin ser la misma para las tablas derivadas de objetos de correspondencia a
las que se derivan de enfoque tradicional.

A continuacin se har una breve referencia para mostrar las reglas de correspondencia
que se ha basado para las relaciones:

Correspondencia entre clases y tablas:

Toda clase se corresponde con una o ms tablas; de igual manera que una clase tiene
atributos, esos atributos pasan a ser atributos de la tabla, aadiendo el ID del objeto y
detalles como partes de la formulacin del modelo de tablas, especificando que atributos
pueden o no ser nulos y asignando un dominio a cada atributo.

Correspondencia entre Asociaciones y Tablas

En trminos generales, una asociacin puede o no corresponderse con una tabla ya que
esto depende del tipo y multiplicidad de la asociacin y; del criterio de quien disea la
base de datos. Puede presentarse el caso de asociaciones de Uno-a-muchos con una
clave externa en la tabla para la clase muchos. Tambin puede presentarse la
asociacin de muchos-a-muchos, extradas del diagrama de clases.

La asociacin muchos-a-muchos siempre se corresponde con una tabla concreta,

satisfaciendo as la tercera forma normal. Las claves primarias tanto la para las clases
relacionadas como para los atributos de enlace pasan a ser atributos de la tabla de
asociacin.

Correspondencia de las generalizaciones a Tablas

Esta correspondencia se basa en las clases con herencia simple, sin embargo la
correspondencia consiste en eliminar la tabla de superclase y los atributos de la
superclase se duplican para cada subclase, esto le permite eliminar la navegacin de
superclase a subclases y as acelerar el proceso, manteniendo la tercera forma normal.
III.V.IV Tcnicas de Normalizacin.

La normalizacin es el proceso que permite distribuir todos los campos de la base de

datos en tablas relacionadas entre s, de forma que cumplan con el funcionamiento
esperado de la base de datos. Como premisa fundamental partiremos del propio
significado de relacin, que supone el agrupar en una misma tabla todos los campos de
informacin relacionados por su significado. Para evitar la inconsistencia y duplicidad
de datos emplearemos la tcnica de normalizacin para organizar los campos de datos
en cada tabla. Sin entrar a desarrollar la teora que hay detrs de la normalizacin,
usaremos una serie de reglas que pueden aplicarse para determinar si nuestro diseo
tiene sentido.

Cada campo de una tabla debe contener un nico tipo de informacin. Esto
significa que deberamos dividir los campos complejos y evitar la repeticin de
grupos de informacin. Ejemplo: Sera conveniente separar en campos
diferentes el nombre y los apellidos de un cliente, o dividir la direccin del
mismo en los campos necesarios.

Claves principales. Cada tabla debe tener un nico identificador o clave

principal, que debe estar formado por uno o varios campos de la tabla. En una
base de datos relacional, cada uno de los registros de cualquier tabla debe ser
identificado de forma nica. Es decir, algn campo o combinacin de varios
debe albergar un valor nico para cada registro de la tabla. Este identificador es
lo que denominamos clave principal. Como regla general deberamos usar como
clave principal el campo ms corto que identifique a cada registro. No obstante
es recomendable la creacin de campos artificiales para ser usados como clave
principal.

Dependencia funcional. Para cada valor nico de la clave principal, los valores
de las columnas de datos deben estar relacionados y deben describir
completamente el contenido de la tabla. Esta regla opera de dos formas:

En primer lugar no debera haber en una tabla un dato que no sea

relevante del asunto o materia del que trata la tabla. Por ejemplo, aunque
es necesaria la informacin del cliente para cada pedido, los clientes
seran un asunto independiente y tendran su propia tabla.
 En segundo lugar los datos de la tabla deberan describir completamente
la materia de la que trata la tabla. Por ejemplo, un pedido podra ser
enviado a una direccin diferente a la del cliente, por lo que la adicin
de la direccin de envo a la tabla pedido hara que la informacin fuese
ms completa.
Ms tcnicamente decimos que dados dos campos, A y B, se dice que B
es funcionalmente dependiente de A si para cada valor de A existe un
valor de B, y solo uno, asociado con l. A y B pueden ser compuestos, es
decir pueden ser conjuntos de campos en lugar de campos simples.

Independencia de los campos. Debe ser posible realizar cambios en cualquier

campo que no forme parte de la clave principal sin que para ello se vea afectado
cualquier otro campo. Si incluyramos la compaa de envo y su telfono en la
tabla de pedidos, y la compaa cambia su nmero de telfono habra de ser
modificado en muchos registros.

Por otro lado, existen cuatro Formas de Normalizacin, las mismas que a continuacin,
se describen brevemente:

1. Primera Forma de Normalizacin (1FN):

Un conjunto de relaciones esta en 1FN, si todos los atributos presentes en stas son
atmicos, es decir que cada campo debe de tener un nico valor indivisible. Las
relaciones de las entidades principales presentadas se encuentran en primera forma
normal. En consecuencia establece que las columnas repetidas deben eliminarse y
colocarse en tablas separadas.

2. Segunda Forma de Normalizacin (2FN) :

Se trabaja solo con aquellas relaciones que contienen dependencias funcionales. Por
ejemplo en la relacin Usuario, contiene atributos de documentos que pueden o no
presentar un Usuario, por lo tanto la informacin en estos documentos obliga a la
creacin de una tabla. En consecuencia, establece que todas las dependencias parciales
se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un
trmino que describe a aquellos datos que no dependen de la clave de la tabla para
identificarlos.
3. Tercer Forma de Normalizacin (3FN):

La tercera y ltima forma de normalizacin establece que hay que eliminar y separar
cualquier dato que no sea clave. Es decir el valor de esta columna debe depender de la
clave. Todos los valores deben identificarse nicamente por la clave.

4. Cuarta Forma Normal:

Una tabla est en cuarta forma normal si y slo si para cualquier combinacin clave
campo no existen valores duplicados.

III.V.V Modelado Lgico

La arquitectura de sistemas de bases de datos de tres esquemas fue aprobado por la

ANSI-SPARC (American National Standard Institute - Standards Planning and
Requirements Committee) en 1975 como ayuda para conseguir la separacin entre los
programas de aplicacin y los datos, el manejo de mltiples vistas por parte de los
usuarios y el uso de un catlogo para almacenar el esquema de la base de datos. 1.
Nivel interno: Tiene un esquema interno que describe la estructura fsica de
almacenamiento de base de datos. Emplea un modelo fsico de datos y los nicos datos
que existen estn realmente en este nivel.

2. Nivel conceptual: tiene esquema conceptual. Describe la estructura de toda la base de

datos para una comunidad de usuarios. Oculta los detalles fsicos de almacenamiento y
trabaja con elementos lgicos como entidades, atributos y relaciones.

3. Nivel externo o de vistas: tiene varios esquemas externos o vistas de usuario. Cada
esquema describe la visin que tiene de la base de datos a un grupo de usuarios,
ocultando el resto.

El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicacin

de la base de datos fsica.

III.V.VI Modelado Fsico

Una vez que se han definido las entidades, sus relaciones y sus atributos o
caractersticas podemos centrarnos en los requerimientos de datos para cada entidad. Se
desarrollar un diagrama de estructura de datos a partir del modelo conceptual y del
modelo lgico planteado y, sobre todo basndose en las tcnicas de normalizacin
indicadas. Los componentes bsicos que se visualizarn en los diagramas o diseos de
estructura de datos son las entidades, atributos, apuntadores atributos y apuntadores
lgicos.

Los apuntadores atributos enlazan dos entidades mediante la informacin comn

usualmente un atributo llave en uno y, un atributo en el otro. Los apuntadores lgicos
identifican las relaciones entre las entidades; sirven para obtener acceso inmediato a la
informacin en una entidad.

Los atributos llave pueden ser de dos tipos: las llaves primarias o Primary Key (PK) y
las llaves forneas o Foreig Key (FK).

Con el software que se ha utilizado para el presente proyecto se podr observar las
entidades, los campos o atributos junto con el tipo de dato as mismo los atributos llave.

Pegar las tablas imagenes:

 CAPITULO IV
INTERFACES

IV.I.II Proceso de desarrollo de Interfaces:

IV.I.II.I Diseo de Interfaces:

IV.I.II.II El proceso de diseo:

En el proceso de diseo de una interfaz de usuario se pueden distinguir cuatro fases o

pasos fundamentales:

Reunir y analizar la informacin del usuario.

Es decir concretar a travs de tcnicas de requerimientos, qu tipo de usuarios

van a utilizar el programa, qu tareas van a realizar los usuarios y cmo las van a
realizar, qu exigen los usuarios del programa, en qu entorno se desenvuelven
los usuarios (fsico, social, cultural).

Disear la interfaz de usuario.

Es importante dedicar tiempo y recursos a esta fase, antes de entrar en la

codificacin. En esta fase se definen los objetivos de usabilidad del programa,
las tareas del usuario, los objetos y acciones de la interfaz, los iconos, vistas y
representaciones visuales de los objetos, los mens de los objetos y ventanas.

Todos los elementos visuales se pueden hacer primero a mano y luego refinar con las
herramientas adecuadas.

Construir la interfaz de usuario.

Es interesante realizar un prototipo previo, una primera versin del programa

que se realice rpidamente y permita visualizar el producto para poderlo probar
antes de codificarlo definitivamente

Validar la interfaz de usuario.

 Se deben realizar pruebas de usabilidad del producto, a ser posible con los
propios usuarios finales del mismo. Es importante, en suma, realizar un diseo
que parta del usuario, y no del sistema. As mismo, existen 11 pasos en el
proceso de diseo cuando nuestro propsito est centrado en las tareas, es
similar al anterior pero que desglosa algunas actividades implcitas en otras, as
tenemos:

o Entender quien usar el sistema para hacer qu.

o Elegir tareas representativas para el diseo.
o Plagiar o copiar.
o Bosquejar un diseo.
o Pensar acerca del diseo.
o Crear un prototipo.
o Evaluarla con los usuarios.
o Repetir.
o Construirla.
o Rastrearla.
o Cambiarla.

IV.II Interfaces de los principales proceso:

LOGIN

INTERFAZ DE VENTA

IV.III Diseo de Interfaces Internas y Externas:

 CAPITULO V
EVALUACIN
ECONMICA DE
PROYECTO
V. EVALUACIN ECONMICA DE PROYECTO

V.I Estudio de Viabilidad:

Todo proyecto debe contar con la posibilidad econmica para hacer posible su
ejecucin, pero si bien es cierto es un factor importante e imprescindible, existen
tambin otras dos variables que se deben de tener en cuenta en un proyecto al momento
de observar su viabilidad, estas son el aspecto tecnolgico y el aspecto operacional.

V.I.I Viabilidad Tecnolgica:

La factibilidad tecnolgica va a precisar s el Sistema de Gestin orientado a la Atencin

al Cliente y Control de Ventas para la Ferretera Covensy va a ser viable
tcnicamente, vale resaltar que, deben existir herramientas tecnolgicas y equipos
mnimos requeridos, para ser posible su implementacin.
Esta es una evaluacin que demuestra que el negocio puede ponerse en marcha y
mantenerse, mostrando evidencias de que se ha planeado cuidadosamente, contemplado
los problemas que involucra y mantenerlo en funcionamiento. Por este motivo, se
efectu en su debido momento, la evaluacin fsica de rigor en la Ferretera Covensy,
concluyndose que cuenta con 3 reas de importancia y que tienen relacin directa con
el Sistema de Gestin orientado al Control de ventas, y que a continuacin se detalla:

Como se puede observar, no todas las reas cuentan con respectivos equipos para poder
implementar el sistema.

En resultado a toda esta evaluacin, se puede afirmar que el presente proyecto, SI

TIENE VIABILIDAD TECNOLGICA.

V.I.II Viabilidad Operacional:

La factibilidad operacional consiste en analizar si se cuenta o no con el personal y las

instalaciones que permitan el buen funcionamiento y operatividad del Sistema de
Gestin orientado al Control de ventas.

En cuanto al personal necesario para poner en funcionamiento el Sistema de Gestin

orientado al control de ventas es suficiente con el actual contratado en su nico local de
la ciudad de Chincha.

La infraestructura fsica o instalaciones con las que se cuenta actualmente son

suficientes, debido a que la bodega no es de gran envergadura. En consecuencia se
puede afirmar que el proyecto SI TIENE VIABILIDAD OPERACIONAL.

V.I.III Viabilidad Econmica:

Debe mostrarse que el proyecto es factible econmicamente, lo que significa que la
inversin que se est realizando es justificada por la ganancia que se generar.

La viabilidad econmica tambin considera si la inversin necesaria puede ser asumida

por la empresa Burger Place para contribuir en el logro de sus metas y objetivos.

La pregunta a responder es si vale la pena invertir el dinero en el proyecto propuesto y

si la utilidad o el beneficio a obtener es considerable.

Este estudio de viabilidad econmica se orientar bsicamente en realizar una

evaluacin y una comparacin de dinero de los gastos de implementacin, ya que no se
podr evaluar ni considerar equipamiento, porque el negocio tiene el equipo suficiente.
Esta comparacin se realizar luego de unos clculos del proceso que se denomina
anlisis de costes beneficios.

V.II Anlisis de Costos y Beneficios:

El objetivo en este punto es conseguir una lista de todo los elementos necesarios que se
requieren para la implementacin del Sistema de Gestin orientado al control de ventas
y Stock y una lista de Beneficios.

V.II.I Costos para la implantacin:

Es necesario realizar un anlisis serio y responsable de los costes de implantacin del

Sistema de Gestin orientado al control de ventas, que involucre todo el conjunto
integral de los gastos que su ejecucin implica.

Para efectos de la implantacin es necesario recordar que este sistema funcionar en 1

equipos por lo tanto algunos de los clculos a realizar tomaran en cuenta esta cantidad.

Los costes que sern tomados para la implantacin del Sistema de Gestin orientado al
control de ventas y se basarn en dos alternativas:
a. Costos de Licenciamiento

ALTERNATIVA A: SOFTWARE LICENCIADO

b. Costo de Desarrollo del Software:

Este monto lo constituye el monto fijado por el personal especialista en el desarrollo de

sistemas.

Anlisis diseo, programacin e Implantacin (S/. 150.00 soles * 4 meses) S/.

600.00

c. Costo de Equipo para el Desarrollo:

Computador (S/. 1.0 hora * 8 horas/da * 3 das/semana * 4 semanas/mes * 4

Meses) S/. 350.00.
Impresora (Pruebas y Reportes) (S/. 0.20 hoja * 100 hojas mximo) S/. 20.00
Total S/. 400.00.

d. Otros Costos

Estos son los costos que son ocasionados por materiales de oficina y algunos
imprevistos:

Materiales de Oficina S/. 30.00

Imprevistos S/. 15.00
Total S/. 35.00

e. Instalaciones-lugar de trabajo

Auto valo S/. 15.00 A continuacin se presenta en resumen, el cuadro en costo

de la alternativa expuesta:

ALTERNATIVA A: SOFTWARE LICENCIADO

V.II.II Beneficios de la implantacin:

Terminado el estudio de investigacin y determinar que su implementacin es

importante para el negocio, podemos mencionar los beneficios ms significativos que se
lograran:

El sistema de Gestin orientado al control de ventas y Control de Stock a los

clientes que la Ferretera Covensy, encuentren una informacin segura y
confiable acerca de los productos que pretende adquirir.

Contribuir a la eficiencia y eficacia en el proceso de ventas y control de stock de

la Ferretera Covensy.

Se automatizar el registro, de las ventas emitidas por el negocio as como la

facturacin.

Ahorrar tiempo para acceder a la informacin.

Contar con un historial de ventas, usuarios y/o productos que hayan sido
gestionados por fecha al momento de su venta.

Se mejorar notablemente la atencin al pblico concurrente y por ende

mejorar la imagen de la empresa Burger Place.

Se tendr en tiempo real la cantidad exacta de existencias de productos

existentes en forma detallada. Modelamiento de un sistema de Gestin de Ventas
Burger Place.

Otros beneficios como: reduccin de tasas de error, reduccin de prdidas de

informacin, reduccin de tareas y procesos manuales (menor costo).
V.II.III Determinacin de la ejecucin del Proyecto:

Luego de haber realizado un exhaustivo anlisis de coste beneficio y que hemos

descrito anteriormente, podemos concluir que los beneficios que se van a obtener versus
la inversin que significa la implantacin son muchos mayores y satisfacen las
necesidades de empresa Burger Place. Por lo tanto la implantacin del Sistema de
Gestin orientado al control de ventas Stock utilizando SOFTWARE LICENCIADO ES
VIABLE ECONMICAMENTE.
 CAPITULO VI
RESULTADOS

VI. RESULTADOS:

VI.I. CONCLUSIONES:

El uso del Sistema de Gestin orientado al control de ventas y Stock permitir

los brindar una adecuada atencin al cliente.

El uso del Sistema de Gestin orientado al control de ventas y Stock permitir a

los que laboran obtener una ayuda visualmente al momento de la venta a los
 clientes, reduciendo los tiempos en la atencin y de esta forma evitando esperas
innecesarias.
Los que trabajan con el sistema percibirn un rendimiento considerable y
favorable con respecto al sistema manual que actualmente realizan, porque el
Sistema de Gestin orientado al control de ventas y Stock le permitir tener un
control sobre las existencias de cada uno de los productos en stock lo que
resulta favorable tanto en la atencin como para la compra oportuna de los
insumos imprescindibles para la venta.

El administrador y/o gerente de la empresa podr tener informacin detallada de

las compras facturadas, ventas realizada, registro de clientes, productos
gestionados, etc. en cualquier momento que l lo requiere, por lo mismo que el
Sistema de Gestin cuenta con opcin de reportes.

VI.II. RECOMENDACIONES:

Desarrollar e implementar una pgina Web donde se muestren los servicios y

productos que comercializa la empresa, de esta forma captar nuevos clientes y
generar en los actuales identificacin y lealtad hacia ella.
Realizar las transacciones tributarias con la SUNAT y comerciales con los
Bancos a travs de Internet, aprovechando las ventajas de sta tecnologa.

Utilizar software con la licencia respectiva de acuerdo, con la finalidad de

prever cualquier sancin por usar software comercial sin licencia.

VI.III. GLOSARIO DE TRMINOS:

mbito: Conjunto de tareas necesarias para conseguir el objetivo del proyecto.

mbito del producto: Conjunto de caractersticas, funciones, especificaciones y
calidad final que tiene dicho producto una vez terminado.
mbito del proyecto: Trabajo requerido para realizar el proyecto y conseguir el
objetivo, el producto final.
Coste Costo: Delimitacin econmica en la que se basa el desarrollo del
proyecto.
Incremento de mbito: Ampliacin del mbito del proyecto que generalmente
repercute en mayor coste y mayor duracin.
Objetivo: Meta final objeto del proyecto. Resultado que debe obtenerse. Puede
ser un producto o un servicio.
 Producto o servicio: Objetivo final de todo proyecto. Ser nico y deber
satisfacer a un mercado. Modelamiento de un sistema de Gestin de Ventas -
Bodega Feli Pgina 72
Proyecto: Secuencia de tareas programadas y planificadas con un fin: Obtener
un producto nico.
Recurso: Elemento necesario para llevar a cabo una tarea.
Tiempo: Una de los tres componentes fundamentales del tringulo del proyecto.
Semanas, das, horas y/o minutos necesarios para llevar a cabo las tareas objeto
del proyecto.

VI.IV. ANEXOS: