UNIVERSIDAD INCA GARCILASO DE LA VEGA

FACULTAD DE INGENIERÍAS
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS E INFORMÁTICA

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

Título Página

1 Carátula

2 Dedicatoria

3 Agradecimiento

4 Índice

5 Resumen

6 Abstract

7 Introducción

8 Generalidades

8.1 Nombre del Proyecto

8.2 Descripción del proyecto

8.3 Logotipo de la Organización

8.4 Razón Social de la Organización: Nombre, Dirección, Fono, Email.

8.5 Descripción de la organización

8.6 Organigrama

8.7 Situación Problemática

8.7.1 Descripción de la organización

8.7.2 Selección del problema.

8.7.3 Antecedentes del Problema.

8.8 Justificación del proyecto

8.8.1 Justificación Técnica

8.8.2 Justificación Operativa

8.8.3 Justificación Económica

8.9 Objetivos del Proyecto

8.9.1 Objetivo General

8.9.2 Objetivo Específico
8.10 Limitaciones Proyecto

8.10.1 Limitación Cronológica

8.10.2 Limitación Tecnológica

8.10.3 Limitación Técnica

9 Marco Teórico (UML, Metodología, Cliente/Servidor, Gestor de BD, Lenguaje,
etc.).

10 Aplicación de la Tecnología: Proceso Unificado de Rational

10.1 m Modela miento Negocio.

10.1.1 Pictograma, Descripción del Pictograma

10.1.2 Procesos de Negocio: Nombres, Descripción

10.1.3 Reglas de Negocio (Por cada proceso de negocio)

10.1.4 Visión del Negocio

10.1.5 Modelado de casos de uso del negocio

10.1.6 Especificación 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 priorización de casos de usos

10.2.4 Especificación de casos de usos de requerimientos

10.3 Análisis

10.3.1 Diagramas de colaboración

10.3.2 Diagrama de clases de entidad

10.3.3 Diagramas de clases de análisis (Boundary + Control+ Entitis)

10.4 Diseño

10.4.1 Interfaces de Usuario

10.4.2 Diagrama de secuencia de diseño
10.4.3 Diagrama de clases de diseño

10.4.4 Diagrama de estado (Por lo menos 3 clases)

10.4.5 Diagrama de paquetes de diseño

10.4.6 Modelo físico de la base de datos Relacional (Rational)

10.4.7 Script de migración de la base de datos a SQL Server 2000

10.4.8 Modelo físico de la base de datos Relacional (SQL Server)

10.4.9 Modelo físico de la base de datos Relacional (Normalizado)

10.5 Implementación

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 bibliográficas y/o enlaces web

14 Bibliografía

15 Apéndices

15.1 Formato de historias de usuario

15.2 Formato de tarjeta de tareas

15.3 Formato de especificación de los casos de uso de requerimientos

15.4 Formato de recopilación de la información (Entrevistas, Cuestionario, etc.)
15.5 Faces de construcción de las interfaces

16 Anexos

16.1 Copias de los documentos fuentes encontrados.

16.2 Fotos.

16.3 Videos.
INTRODUCCIÓN

El presente Proyecto es el trabajo de los diferentes actores del Sistema
para Control de Venta de Comida Rápida (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 innovación y
todo esto sería posible si vamos de la mano con la actualización.

La necesidad creciente de comercializar cada día es mayor, y para tratar
de cubrir esta necesidad requiere de técnicas 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 manipulación de
datos, la seguridad de los datos, etc. Esto lleva a dar soluciones que
faciliten la operación de tareas mediante la construcción de una base de
datos que pueda satisfacer las necesidades en menor tiempo, brindando así
una mejor calidad en los servicios.

Otro instrumento sería una página Sistema de Control con la cual nos
permitiría poder registrar pedidos, clientes, órdenes etc.
RESUMEN

El presente proyecto titulado Sistema para Control de Venta de Comida
Rapida para mejorar el proceso de comercialización de Burger Place
Tiene como objetivo general Implementar un Sistema de Escritorio , para
“Burger Place” basado en la metodología 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, facturación, manejo de ventas y compras, clientes.
Además posee un entorno de fácil manejo, donde podrá realizar todas
aquellas operaciones que antes consumían 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 también ser utilizadas en una red local.

Este Sistema, es la mejor solución ya que controlara todos los procesos de
compra y venta, permitiendo tener un manejo eficiente de la gestión 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 : Ingeniería de Sistema y Telecomunicaciones

Escuela : Ingeniería Sistemas.

Ciclo : VIII.


Jefe de Proyectos :

Apellidos : Fernández Gonzales.

Nombres : Kevin.

Código Universitario : 0109062044

DN.I. : 45201518


Analista :

Apellidos : Navarro Campos.

Nombres : Aldershon.

Código Universitario : 0109062044

DN.I. : 45201518


Programador :

Apellidos : Aliaga Pérez.

Nombres : Carmen

Código Universitario : 0109062044

DN.I. : 45201518


Programador :

Apellidos : Comina Chacaliaza.

Nombres : Roberto Alejandro.

Código Universitario : 423025480.

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

Implementación de sistema informático para mejorar el proceso de

Comercialización 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
Diseño, Programación e implementación
en detalle de toda la aplicación.
de las

1.3.3 OBJETIVOS DEL SISTEMA

 Brindar un control más 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 TEÓRICO

CONCEPTUAL
I. MARCO TEÓRICO

CONCEPTUAL:

J. I.I. Datos Generales de La Empresa

II.I.I Ubicación Geográfica.

Jr. Tumbes s/n Interior Mercado “Ferrocarril” puesto 347 – Santa –
Chimbote – Ancash.

II.I.II Base Legal:

Nombre o Razón Social : Burger Place.
Ruc : 10152014789
Titular : Ventocilla Gonzales, Amandina Rosa
DNI 15201478
Dirección : Jr. Tumbes s/n Interior Mercado “Ferrocarril”
puesto 347 – Santa – Chimbote – Ancash

Actividad : Ventas de Comida Rapida.

Teléfono : 056 54 26 58

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

 Ventas
 Almacén
II.I.V Reseña Histórica y Operacional:
La empresa de Comida Rapida “Burger Place” fue fundada el 01 de
Julio de 2005 llevando el nombre de "Burger Place", adecuándose como
Sociedad Anónima 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 Visión:
Consolidarnos como la mejor empresa en nuestra ciudad, en cuanto a la
producción y venta de comidas rápidas, apoyándonos en instalaciones
con la más alta tecnología 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 investigación y el desarrollo de nuevas tecnologías
para colocarlas al servicio del cliente, con oportunidad y economía.

II.I.VII Misión:
Somos una empresa de comida rápida ofreciendo productos de calidad
a un precio accesible para la comodidad y satisfacción de nuestros
clientes

Por otra parte estamos en constantes capacitaciones del factor humano,
actualización tecnológica, inversión de recursos financieros, políticas de
ventas y adquisición de mercancías de excelente calidad y respaldo.
Generará y fortalecerá las relaciones comerciales con sus clientes y
proveedores, a través de una comunicación franca, directa y eficiente,
utilizando todas las herramientas y funciones que los avances
tecnológicos ofrecen cada día.

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.

 Supervisión de inventario.

 Revisión del ingreso de mercadería y su facturación.

 Autorización de movimientos materiales o
financieros.

ADMINISTRADOR:
Encargado de administrar el correcto funcionamiento de los
procesos ya demás revisa las ventas hechas en el día.

FUNCIONES:

 Realizar operaciones bancarias

 Supervisión de inventario

 Revisión del ingreso de mercancía y su facturación

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:

 Autorización de movimientos materiales o
financieros

 Mantenimiento del lugar de trabajo

 Realizar ruta de cobros a clientes

 Compra y recibo de mercancía

 Reparto de mercancía a clientes

 Atención de clientes en mostrador en caso necesario

 Organización de productos en el almacén y en el
mostrador
CAPITULO II
ANÁLISIS DEL SISTEMA

ACTUAL
II. ANÁLISIS DEL SISTEMA ACTUAL:

II.I.ACCIONES PRELIMINARES:

II.V.I CICLO DE VIDA DEL PROYECTO:

Gestión de Tiempo:

A continuación se describirá el desarrollo de software, desde la fase
inicial hasta la fase final. El propósito de este programa es definir las
distintas fases intermedias que se requieren para validar el desarrollo de
la aplicación, es decir, para garantizar que el software cumpla los
requisitos para la aplicación y verificación de los procedimientos de
desarrollo

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 implementación. 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
implementación y en los costos asociados.

El tiempo que se tomara para llevar a cabo el proyecto en su totalidad, es
decir la realización de cada una de las actividades mencionadas a
continuación, desde la Definición de Objetivos hasta implementación
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 DESCRIPCIÓN FECHA
Definición de objetivos Se definirá el resultado del
proyecto y su papel en la
estrategia global.
Análisis de los requisitos y Se recopilara, examinara y
su viabilidad formulara los requisitos
del cliente y examinar
cualquier restricción que
se pueda aplicar.
Diseño general Se hará los Diseños
generales de la
arquitectura de la
aplicación (Diagrama de
Clases, Casos de Uso,
Diagrama de Secuencias,
Diagramas de Actividades)
Diseño en detalle De las definiciones
precisas de cada
subconjunto en detalle de
toda la aplicación (Diseño
de Base de Datos).
Programación Se procederá con el diseño
(programación e de las interfaces,
implementación programación e
implementación del
código fuente.
Prueba de unidad Se llevara a cavo una
prueba individual de cada
subconjunto de la
aplicación para garantizar
que se implementaron de
acuerdo con las
especificaciones.
Integración Se hará para garantizar
que los diferentes módulos
se integren con la
aplicación. Éste es el
propósito de la prueba de
integración.
Prueba beta (o validación) Previo a la entrega del
Web se instalara la prueba
Beta para garantizar que el
software cumple con las
especificaciones
originales.
Documentación Se elaborara la
documentación con la
información necesaria para
los usuarios del software y
para desarrollos futuros.
Informes y Presentación Se procederá a elaborar el
del Proyecto informe y la
documentación requerida
para la sustentación del
proyecto de practica I
Implementación Se procederá a ser las
implementaciones
correspondientes, según
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 serán
cada vez que el cliente lo
solicite, de acuerdo a la
necesidad

 Cronograma de Trabajo:

CÓD. ACTIVIDAD PRECEDENCIA DURACIÓN (Días)

A Definición de - 8
objetivos
B Análisis de los A 7
requisitos y su
viabilidad
C Diseño general B 7

D Diseño en detalle C 15

E Programación D 33
(programación e
implementación
F Prueba de unidad E 4

G Integración F 3

H Prueba beta (o G 17
validación)
I Documentación H 11

J Informes y H 8
Presentación del
Proyecto
K Implementación IYJ 1
II.V.II ANÁLISIS DE AUDIENCIA:

PERIODO NUMERO DE VECES
Ventas Día 95
Devoluciones o cambio Día 3
Registrar Clientes Nuevos Día 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 ANÁLISIS 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,
variación de precios)
 Mostrar reportes de ventas diarias, por productos y
categoría de producto.

 Clientes.
 Control absoluto de la cartera de clientes y sus estados de
compras
 Registrarse al cliente y hacer las consultas del caso vía
correo electrónico.

 Tienda.
 La gestión integral de la empresa.
 Control de los productos ofrecidos y del personal
que labora en la empresa.
 Módulo administrativo contable (Facturación).
 Registro de detalle de comprobante, de lo que el
cliente adquirió,
 Registro de Ventas

II.V.IV Análisis No Funcional

Requerimientos no Funcionales.
 Mínimos.

Servidor: Procesador 2800Mhz., 1Gb memoria RAM, Disco duro
de 180Gb, unidad lectora de CD y sistema de Back-up para copias
periódicas de seguridad, conexión 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® Core™2 Dúo, 2 Gb memoria
RAM, Disco duro de 500 Gb serial ATA, unidad lectora de
CD y sistema de Back-up para copias periódicas de
seguridad, conexión 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. RECOPILACIÓN DE LA INFORMACIÓN

II.II.I Revisión documental:
Actualmente la Empresa lleva sus registros manualmente, es decir cuenta
con:

 Boletas de Venta.
 Facturas de Venta.
 Recibos.
 Guía 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 Diseño de Entrevista:

Entrevista - Preguntas:
 ¿Con cuánto personal cuanta la empresa para atender a los clientes y dar
mantenimiento a su almacén?

____________________________________________________________

 ¿Cómo se lleva actualmente el control de productos en Stock?

____________________________________________________________

 ¿Cómo 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?

____________________________________________________________

 ¿Cómo muestran a los clientes las características y la variedad de productos que
ofrece la empresa, incluyendo precios?

____________________________________________________________

 ¿Cómo se lleva un historial de clientes potencialmente frecuentes?

____________________________________________________________

 ¿De qué manera se emite en los cierres diarios, semanales y mensuales una
información de detallada de los servicios y productos vendidos, detallando bajas
y altas en las ganancias generadas?
____________________________________________________________

 ¿Cómo recibe el dueño un informe minucioso al final del día de sus ingresos?
¿interpreta correctamente el informe?
____________________________________________________________
 ¿El dueño está satisfecho con la gestión 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 Módem
Router TP-Link.
II.II.V Distribución de Equipos.

 En ventas, se tiene las dos PCs Intel Dual Core, estas conectadas ente si,
y a su vez también en red con la impresora.
 En almacén tenemos la PCs Intel Pentium IV, sin conexión a internet y
de los otros dos equipos.

II.III. Formulación del Problema

La empresa de comidas rápidas Burger Place es una empresa que brinda el
servicio de venta de comidas rápidas, en general. Identificando la problemática
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 segmentación las cuales ejercen un
fuerte impacto en los clientes. No cuenta con ningún tipo de tecnología que
nos facilite la administración de los datos del cliente, apoyo a la toma de
decisiones, administración de campañas en el área de ventas

II.IV. Descripción del Sistema Actual.

Actualmente el negocio no cuenta con procesos bien definidos, En relación al
control de inventario, la información se elabora manualmente en archivos de
papeles, y en consecuencia generaba una labor tediosa encontrar información,
ocasionando demoras en los servicios.
El control de registro de clientes realizada a mano en el cual se anotaba el
nombre, teléfono, dirección y pedidos del cliente, con la dificultad de que la
información continuaba dispersa.

II.V. Identificación de los requerimientos

II.V.I Análisis de entradas y Salidas.
II.VI. Alcance del Sistema Propuesto:

II.VI.I Justificación

IV.I.I.I Justificación Técnica.

Para trabajar con la implementación del sistema no se necesita mucho
conocimiento ya que solo se tiene que saber los conocimientos básicos de
funcionamiento de una computadora.

IV.I.I.II Justificación Operativa.

Al implantar el Sistema, sus uso sería muy fácil ya que el entorno es por medio
de formularios amigables es fácil de aprender su funcionamiento y por otra lado
nos generaría los reportes de las ventas diarias de los productos en almacén, 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 aplicación del sistema estas serán más productivas y eficientes.

IV.I.I.III Justificación Económica.

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 ANÁLISIS Y
DISEÑO DEL SISTEMA
PROPUESTO

III. ANÁLISIS Y DISEÑO DEL SISTEMA PROPUESTO:

III.I Descripción de las Metodologías más Usadas:

III.IV.I Metodología RUP:

Es una metodología cuyo fin es entregar un producto de software. Se estructura
todos los procesos y se mide la eficiencia de la organización.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de
modelado UML, constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas orientados a objetos.
Describe cómo aplicar enfoques para el desarrollo del software, llevando a cabo
unos pasos para su realización además se centra en la producción y
mantenimiento de modelos del sistema.

RUP implementa:
 Desarrollo iterativo del software: Permite comprender los
requerimientos que hacen crecer el sistema.
 Administración de requerimientos: Describe como se obtienen,
organizan, documentan los requerimientos.
 Uso de arquitecturas basadas en componentes: Se basa en diseñar una
arquitectura que sea flexible, fácil de modificar.
 Modelo visual de software: Permite analizar la consistencia entre los
componentes, el diseño y su implementación.
Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es
llevada bajo dos disciplinas:

 Disciplina de Desarrollo
 Ingeniería de Negocios: Entendiendo las necesidades del negocio.
 Requerimientos: Trasladando las necesidades del negocio a un sistema
automatizado.
 Análisis y Diseño: Trasladando los requerimientos dentro de la
arquitectura de software.
 Implementación: Creando software que se ajuste a la arquitectura y que
tenga el comportamiento deseado.
 Pruebas: Asegurándose que el comportamiento requerido es el correcto
y que todo lo solicitado está presente.

 Disciplina de Soporte
 Configuración y administración del cambio: Guardando todas las
versiones del proyecto.
 Administrando el proyecto: Administrando horarios y recursos.
 Ambiente: Administrando el ambiente de desarrollo.
 Distribución: Hacer todo lo necesario para la salida del proyecto.
Es recomendable que a cada una de estas iteraciones se les clasifique y ordene
según su prioridad, y que cada una se convierte luego en un entregable al
cliente. Esto trae como beneficio la retroalimentación que se tendría en cada
entregable o en cada iteración.

Los elementos del RUP son:

 Actividades, Son los procesos que se llegan a determinar en cada
iteración.
 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 metodología es que, en cada ciclo de iteración, se
hace exigente el uso de artefactos, siendo por este motivo, una de las
metodologías más importantes para alcanzar un grado de certificación en el
desarrollo del software.

III.IV.II Metodología XP:

La programación extrema o eXtreme Programming (XP) es un enfoque de la
ingeniería de software. Es el más destacado de los procesos ágiles de desarrollo
de software. Al igual que éstos, la programación extrema se diferencia de las
metodologías tradicionales principalmente en que pone más é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
aproximación mejor y más realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos después en controlar los cambios en
los requisitos.
 XP surgió como respuesta y posible solución a los problemas derivados
del cambio en los requerimientos.
 XP se plantea como una metodología a emplear en proyectos de riesgo.
 XP aumenta la productividad

La

metodología XP entre sus fases se tiene a historia de usuarios que tiene el
mismo propósito 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 excepción que no se limitan a la
descripción de la interfaz del usuario.
Las historias de usuarios, solamente proporcionan los detalles sobre la
estimación de riesgo y cuánto tiempo llevará dicha implementación.

¿Qué es lo que propone XP?

 Empieza en pequeño y añade funcionalidad con retroalimentación
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.
 Añadir, cambiar o quitar requerimientos en cualquier momento.
 Obtener lo máximo de cada semana de trabajo.
 Obtener un sistema funcionando cada 3 o 4 meses.
Derechos del Desarrollador:
 Decidir cómo 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 Metodología MSF:

La metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier
tecnología.

Esta es una metodología flexible e interrelacionada con una serie de conceptos, modelos
y prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos
tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un
segundo plano las elecciones tecnológicas.

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 Gestión del Riesgo, Modelo de
Diseño de Proceso y finalmente el modelo de Aplicación.

 Modelo de Arquitectura:
Diseñado para acortar la planificación del ciclo de vida. Este modelo define las
pautas para construir proyectos empresariales a través del lanzamiento de
versiones.

 Modelo del Equipo:

Este modelo ha sido diseñado para mejorar el rendimiento del equipo de
desarrollo. Proporciona una estructura flexible para organizar los equipos de un
proyecto. Puede ser escalado dependiendo del tamaño del proyecto y del equipo
de personas disponibles.

 Modelo de Proceso:

Diseñado 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 liberación de versiones y explicando su relación con el Modelo de
equipo.

 Modelo de Gestión del Riesgo:

Diseñado para ayudar al equipo a identificar las prioridades, tomar las decisiones
estratégicas 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 Diseño del Proceso:

Diseñado para distinguir entre los objetivos empresariales y las necesidades del
usuario. Proporciona un modelo centrado en el usuario para obtener un diseño
eficiente y flexible a través de un enfoque iterativo. Las fases de diseño
conceptual, lógico y físico proveen tres perspectivas diferentes para los tres tipos
de roles: los usuarios, el equipo y los desarrolladores.

 Modelo de Aplicación:

Diseñado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona
un modelo de tres niveles para diseñar 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 Metodológicas:

 XP:

Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras. Pruebas
unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo
pruebas de regresión. Se aconseja escribir el código de la prueba antes de la
codificación. Programación 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 código escrito, de esta manera, el código es revisado y
discutido mientras se escribe. Frecuente integración del equipo de programación
con el cliente o usuario. Se recomienda que un representante del cliente trabaje
junto al equipo de desarrollo. Corrección de todos los errores antes de añadir
nueva funcionalidad. Hacer entregas frecuentes. Refactorización del código, es
decir, reescribir ciertas partes del código para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento. Las pruebas han de
garantizar que en la refactorización no se ha introducido ningún fallo.

RUP:

 Brinda una guía para encontrar, organizar, documentar, y seguir los cambios de
los requisitos funcionales y restricciones. Utiliza una notación 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, según la fase del
proyecto. o La creación de sistemas intensivos en software requiere dividir el
sistema en componentes con interfaces bien definidas, que posteriormente serán
ensamblados para generar el sistema. Esta característica 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 evalúe en varios puntos durante el proceso de desarrollo,
especialmente al final de cada iteración. En esta verificación 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 también deben ser
continuas.

MSF:
 Es una flexible e interrelacionada serie de conceptos, modelos y mejores
prácticas de uso que controlan la planificación, el desarrollo la gestión de
proyectos tecnológicos. MFS se centra en los modelos de procesos y de equipo
dejando en segundo plano las elecciones tecnológicas.
 Concretamente MSF se compone de principios, modelos y disciplinas, además
de ser adaptable a proyectos de cualquier dimensión y de cualquier tecnología.

III.II Fundamentación de la Metodología seleccionada:

Para la realización del proyecto usaremos la Metodología RUP, tal como lo
mencionamos a continuación, ya que se pude considerar como la adopción de las
mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo
con este proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del
software.

Lo más importante de todo esto no es tener que decidir entre la metodología XP
y el RUP, es más bien una recomendación para usar RUP aunque la queremos
decorar como una comparación de equivalencia.

Personalmente creemos que la metodología RUP es adecuada para cualquier tipo
de proyecto y para equipos de cualquier tamaño.

La mayoría de los equipos que utilizan RUP lo han hecho por varios años y
tienen especialistas del proceso que facilitan a los miembros sin experiencia el

Conocimiento de las prácticas y metodologías. Los ciclos de vida de un proyecto
en XP y en RUP no son exactamente iguales, aunque sin duda tienen bastantes
similitudes, ambas son metodologías iterativas con probado éxito en el
desarrollo de software.

En la Transición del RUP o entrega de XP las diferencias pueden ser mayores,
para RUP la entrega final debe ser algo mucho más 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 metodologías contemplan entregas parciales después de cada
iteración para una evaluación y monitoreo continuo.
III.III Análisis:

III.III.I Definición 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 Diseño:

III.IV.I Diagramas de clase:

III.V Implementación 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 información estructurada en registros y almacenada
en un soporte electrónico legible desde un ordenador. Cada registro constituye una
unidad autónoma de información 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 asociación, un registro será la ficha completa de cada
uno de los socios. En cada registro se recogerán determinados datos, como el nombre, la
profesión, la dirección o el teléfono, cada uno de los cuáles 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. Análisis de las necesidades:

En reunión con el cliente se deben documentar los tres grupos de usuarios definidos en
la introducción de la guía, las necesidades de información de cada uno de ellos, así
como los informes que cada uno necesita para su actividad y el contenido de los
mismos. Cuanta más precisión exista en estos requisitos iniciales más preciso será el
desarrollo de la base de datos.
En esta reunión también 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 informáticos del cliente (sistema operativo, tipo de red, servidores, etc.) y
la ubicación 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 información de la base datos
 ¿De qué aplicaciones recibe información?
 ¿Con cuánta frecuencia recibe información?
 ¿Qué hace con esta información?
 ¿Qué precauciones de seguridad debe tomar con respecto a la información?
 ¿Para qué aplicación proporciona datos?
 ¿Están 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 preparación de un informe con las características
siguientes:  Viabilidad tecnológica. ¿Hay tecnología suficiente para el desarrollo? 
Viabilidad operacional. ¿Existen suficientes recursos humanos, presupuesto, experiencia
y formación para el desarrollo?  Viabilidad económica. ¿Se pueden identificar los
beneficios? ¿Los beneficios costearían el desarrollo del sistema? ¿Se pueden medir los
costes y los beneficios?
c. Definición de requisitos

Los requisitos de desarrollo involucran el software y hardware necesario para la
implementación, los recursos humanos necesarios (tanto internos como externos), la
formación 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 señalar 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
implementación está encaminada a subsanar las necesidades del cliente.

d. Diseño

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 implementación. 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 manipulación de
los diferentes grupos de usuarios.

Si parte de la información necesaria para crear algún elemento establecido ya se
encuentra implementado en

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

El diseño consta, como se vio anteriormente, de tres fases: el diseño global o
conceptual, el diseño lógico y el modelo físico.

e. Implementación
Una vez totalmente detallado el modelo conceptual se comienza con la implementación
física del modelo de datos, a medida que se va avanzando en el modelo el administrador
del sistema va asegurando la corrección del modelo y el validador la utilidad del mismo.

La implementación consiste en el desarrollo de las tablas, los índices de los mismos, las
condiciones de validación de los datos, la relación entre las diferentes tablas. Por otro
lado, la definición de las consultas y los parámetros a utilizar por cada una de ellas.

Una vez finalizada la implementación física, se asignan las correspondientes medidas de
seguridad y se ubica la base de datos en el lugar correspondiente.

f. Evaluación 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 disposición cuanta información necesiten. También deberán asegurarse
que el acceso a los datos es cómodo, práctico, 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 implementación.

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

III.V.II Diseño y MODELAMIENTO de base de datos con DBDESIGNER.
III.V.III Transformación del diagrama de Clase a modelo de tabla

Esta sección se centra únicamente en la transformación de diagrama de clase a un
modelo de tablas tipo entidad-relación, donde se aplicará las reglas de correspondencia.
La conversión será la misma para las tablas derivadas de objetos de correspondencia a
las que se derivan de enfoque tradicional.

A continuación 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 más tablas; de igual manera que una clase tiene
atributos, esos atributos pasan a ser atributos de la tabla, añadiendo el ID del objeto y
detalles como partes de la formulación 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 términos generales, una asociación puede o no corresponderse con una tabla ya que
esto depende del tipo y multiplicidad de la asociación y; del criterio de quien diseña 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”. También puede presentarse la
asociación de muchos-a-muchos, extraídas del diagrama de clases.

La asociación 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
asociación.

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 navegación de
superclase a subclases y así acelerar el proceso, manteniendo la tercera forma normal.
III.V.IV Técnicas de Normalización.

La normalización 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 relación, que supone el agrupar en una misma tabla todos los campos de
información relacionados por su significado. Para evitar la inconsistencia y duplicidad
de datos emplearemos la técnica de normalización para organizar los campos de datos
en cada tabla. Sin entrar a desarrollar la teoría que hay detrás de la normalización,
usaremos una serie de reglas que pueden aplicarse para determinar si nuestro diseño
tiene sentido.

Cada campo de una tabla debe contener un único tipo de información. Esto
significa que deberíamos dividir los campos complejos y evitar la repetición de
grupos de información. Ejemplo: Sería conveniente separar en campos
diferentes el nombre y los apellidos de un cliente, o dividir la dirección 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, algún campo o combinación de varios
debe albergar un valor único para cada registro de la tabla. Este identificador es
lo que denominamos clave principal. Como regla general deberíamos usar como
clave principal el campo más corto que identifique a cada registro. No obstante
es recomendable la creación 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 debería 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 información del cliente para cada pedido, los clientes
serían un asunto independiente y tendrían su propia tabla.
 En segundo lugar los datos de la tabla deberían describir completamente
la materia de la que trata la tabla. Por ejemplo, un pedido podría ser
enviado a una dirección diferente a la del cliente, por lo que la adición
de la dirección de envío a la tabla pedido haría que la información fuese
más completa.
Más técnicamente 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 incluyéramos la compañía de envío y su teléfono en la
tabla de pedidos, y la compañía cambia su número de teléfono habría de ser
modificado en muchos registros.

Por otro lado, existen cuatro Formas de Normalización, las mismas que a continuación,
se describen brevemente:

1. Primera Forma de Normalización (1FN):

Un conjunto de relaciones esta en 1FN, si todos los atributos presentes en éstas son
atómicos, 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 Normalización (2FN) :

Se trabaja solo con aquellas relaciones que contienen dependencias funcionales. Por
ejemplo en la relación Usuario, contiene atributos de documentos que pueden o no
presentar un Usuario, por lo tanto la información en estos documentos obliga a la
creación 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
término que describe a aquellos datos que no dependen de la clave de la tabla para
identificarlos.
3. Tercer Forma de Normalización (3FN):

La tercera y última forma de normalización 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 sólo si para cualquier combinación clave –
campo no existen valores duplicados.

III.V.V Modelado Lógico

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 separación entre los
programas de aplicación y los datos, el manejo de múltiples vistas por parte de los
usuarios y el uso de un catálogo para almacenar el esquema de la base de datos. 1.
Nivel interno: Tiene un esquema interno que describe la estructura física de
almacenamiento de base de datos. Emplea un modelo físico de datos y los únicos datos
que existen están 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 físicos de almacenamiento y
trabaja con elementos lógicos como entidades, atributos y relaciones.

3. Nivel externo o de vistas: tiene varios esquemas externos o vistas de usuario. Cada
esquema describe la visión 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 aplicación
de la base de datos física.

III.V.VI Modelado Físico
Una vez que se han definido las entidades, sus relaciones y sus atributos o
características 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 lógico planteado y, sobre todo basándose en las técnicas de normalización
indicadas. Los componentes básicos que se visualizarán en los diagramas o diseños de
estructura de datos son las entidades, atributos, apuntadores atributos y apuntadores
lógicos.

Los apuntadores atributos enlazan dos entidades mediante la información común
usualmente un atributo llave en uno y, un atributo en el otro. Los apuntadores lógicos
identifican las relaciones entre las entidades; sirven para obtener acceso inmediato a la
información en una entidad.

Los atributos llave pueden ser de dos tipos: las llaves primarias o Primary Key (PK) y
las llaves foráneas 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 Diseño de Interfaces:

IV.I.II.II El proceso de diseño:

En el proceso de diseño de una interfaz de usuario se pueden distinguir cuatro fases o
pasos fundamentales:

 Reunir y analizar la información del usuario.

Es decir concretar a través de técnicas de requerimientos, qué tipo de usuarios
van a utilizar el programa, qué tareas van a realizar los usuarios y cómo las van a
realizar, qué exigen los usuarios del programa, en qué entorno se desenvuelven
los usuarios (físico, social, cultural).

 Diseñar la interfaz de usuario.

Es importante dedicar tiempo y recursos a esta fase, antes de entrar en la
codificación. 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 menús 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 versión del programa
que se realice rápidamente 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 diseño
que parta del usuario, y no del sistema. Así mismo, existen 11 pasos en el
proceso de diseño cuando nuestro propósito está centrado en las tareas, es
similar al anterior pero que desglosa algunas actividades implícitas en otras, así
tenemos:

o Entender quien usará el sistema para hacer qué.
o Elegir tareas representativas para el diseño.
o Plagiar o copiar.
o Bosquejar un diseño.
o Pensar acerca del diseño.
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 Diseño de Interfaces Internas y Externas:
CAPITULO V
EVALUACIÓN
ECONÓMICA DE
PROYECTO
V. EVALUACIÓN ECONÓMICA DE PROYECTO

V.I Estudio de Viabilidad:

Todo proyecto debe contar con la posibilidad económica para hacer posible su
ejecución, pero si bien es cierto es un factor importante e imprescindible, existen
también otras dos variables que se deben de tener en cuenta en un proyecto al momento
de observar su viabilidad, estas son el aspecto tecnológico y el aspecto operacional.

V.I.I Viabilidad Tecnológica:

La factibilidad tecnológica va a precisar sí el Sistema de Gestión orientado a la Atención
al Cliente y Control de Ventas para la Ferretería “Covensy” va a ser viable
técnicamente, vale resaltar que, deben existir herramientas tecnológicas y equipos
mínimos requeridos, para ser posible su implementación.
Esta es una evaluación 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 evaluación física de rigor en la Ferretería “Covensy”,
concluyéndose que cuenta con 3 áreas de importancia y que tienen relación directa con
el Sistema de Gestión orientado al Control de ventas, y que a continuación se detalla:

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

En resultado a toda esta evaluación, se puede afirmar que el presente proyecto, SI
TIENE VIABILIDAD TECNOLÓGICA.

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
Gestión orientado al Control de ventas.

En cuanto al personal necesario para poner en funcionamiento el Sistema de Gestión
orientado al control de ventas es suficiente con el actual contratado en su único local de
la ciudad de Chincha.

La infraestructura física 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 Económica:
Debe mostrarse que el proyecto es factible económicamente, lo que significa que la
inversión que se está realizando es justificada por la ganancia que se generará.

La viabilidad económica también considera si la inversión 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 económica se orientará básicamente en realizar una
evaluación y una comparación de dinero de los gastos de implementación, ya que no se
podrá evaluar ni considerar equipamiento, porque el negocio tiene el equipo suficiente.
Esta comparación se realizará luego de unos cálculos del proceso que se denomina
análisis de costes – beneficios.

V.II Análisis de Costos y Beneficios:

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

V.II.I Costos para la implantación:

Es necesario realizar un análisis serio y responsable de los costes de implantación del
Sistema de Gestión orientado al control de ventas, que involucre todo el conjunto
integral de los gastos que su ejecución implica.

Para efectos de la implantación es necesario recordar que este sistema funcionará en 1
equipos por lo tanto algunos de los cálculos a realizar tomaran en cuenta esta cantidad.

Los costes que serán tomados para la implantación del Sistema de Gestión orientado al
control de ventas y se basarán 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.

 Análisis diseño, programación e Implantación (S/. 150.00 soles * 4 meses) S/.
600.00

c. Costo de Equipo para el Desarrollo:

 Computador (S/. 1.0 hora * 8 horas/día * 3 días/semana * 4 semanas/mes * 4
Meses) S/. 350.00.
 Impresora (Pruebas y Reportes) (S/. 0.20 hoja * 100 hojas máximo) 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 valúo S/. 15.00 A continuación se presenta en resumen, el cuadro en costo
de la alternativa expuesta:

 ALTERNATIVA A: SOFTWARE LICENCIADO
V.II.II Beneficios de la implantación:

Terminado el estudio de investigación y determinar que su implementación es
importante para el negocio, podemos mencionar los beneficios más significativos que se
lograrían:

 El sistema de Gestión orientado al control de ventas y Control de Stock a los
clientes que la Ferretería “Covensy”, encuentren una información 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 Ferretería “Covensy”.

 Se automatizará el registro, de las ventas emitidas por el negocio así como la
facturación.

 Ahorrará tiempo para acceder a la información.

 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 atención al público 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 Gestión de Ventas
– “Burger Place”.

 Otros beneficios como: reducción de tasas de error, reducción de pérdidas de
información, reducción de tareas y procesos manuales (menor costo).
V.II.III Determinación de la ejecución del Proyecto:

Luego de haber realizado un exhaustivo análisis de coste – beneficio y que hemos
descrito anteriormente, podemos concluir que los beneficios que se van a obtener versus
la inversión que significa la implantación son muchos mayores y satisfacen las
necesidades de empresa “Burger Place”. Por lo tanto la implantación del Sistema de
Gestión orientado al control de ventas Stock utilizando SOFTWARE LICENCIADO ES
VIABLE ECONÓMICAMENTE.
CAPITULO VI
RESULTADOS

VI. RESULTADOS:

VI.I. CONCLUSIONES:

 El uso del Sistema de Gestión orientado al control de ventas y Stock permitirá
los brindar una adecuada atención al cliente.

 El uso del Sistema de Gestión 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 atención y de esta forma evitando esperas
innecesarias.
 Los que trabajan con el sistema percibirán un rendimiento considerable y
favorable con respecto al sistema manual que actualmente realizan, porque el
Sistema de Gestión 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 atención como para la compra oportuna de los
insumos imprescindibles para la venta.

 El administrador y/o gerente de la empresa podrá tener información 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 Gestión cuenta con opción de reportes.

VI.II. RECOMENDACIONES:

 Desarrollar e implementar una página Web donde se muestren los servicios y
productos que comercializa la empresa, de esta forma captará nuevos clientes y
generará en los actuales identificación y lealtad hacia ella.
 Realizar las transacciones tributarias con la SUNAT y comerciales con los
Bancos a través de Internet, aprovechando las ventajas de ésta tecnología.

 Utilizar software con la licencia respectiva de acuerdo, con la finalidad de
prever cualquier sanción por usar software comercial sin licencia.

VI.III. GLOSARIO DE TÉRMINOS:

 Ámbito: Conjunto de tareas necesarias para conseguir el objetivo del proyecto.
 Ámbito del producto: Conjunto de características, 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: Delimitación económica en la que se basa el desarrollo del
proyecto.
 Incremento de ámbito: Ampliación del ámbito del proyecto que generalmente
repercute en mayor coste y mayor duración.
 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 Gestión de Ventas -
Bodega Feli Página 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 triángulo del proyecto.
Semanas, días, horas y/o minutos necesarios para llevar a cabo las tareas objeto
del proyecto.

VI.IV. ANEXOS: