104801340-Proyecto-Final-Ferreteria-Covensy.pdf

Uladech - Practicas Pre Profesionales I – Ferretería “Covensy”
Ferretería_covensy@hotmail.com Página 1
Universidad Católica los Ángeles de
Chimbote
Practicas Pre Profesionales I
2010
FERRETERÍA “COVENSY”
Capillo Velásquez Miguel Ángel
Merino Morillo Vilmer

http://ferreteriacovensy.260mb.com/ Página 2
DEDICATORIA
Dedicado a nuestro Padre
Celestial (Dios), quien
constantemente iluminó nuestras
mentes y fortaleció nuestra
creatividad a fin de cristalizar una
de las metas trazadas en nuestras
vidas.
A nuestros padres, quienes nos
dieron la oportunidad de vivir, y
que con mucho ahínco apoyaron
nuestros ideales y esfuerzos por
llegar a ser un profesional.

AGRADECIMIENTO
En esta página agradecemos a las personas, quienes nos brindaron su apoyo
incondicional en la realización y culminación del presente proyecto.
A nuestro asesor Ing. Heber Gómez por su eficiente orientación profesional en el
asesoramiento del presente proyecto. Asimismo, quien como responsable del curso de
Practicas Pre 01, supo alentar y orientar eficientemente nuestros primeros pasos en
la elaboración del presente trabajo de investigación.
Al dueño y administrador de la ferretería Covensy Sr. Coronado Reyes Joel, a la
Srta. Ventocilla Gonzales, Amandina Rosa, y especialmente a los trabajadores de la
ferretería Covensy por permitirnos y apoyarnos en la ejecución del presente proyecto
en dicha empresa.
A todos los docentes de la facultad de Ingeniería de Sistemas de la Universidad
ULADECH CATÓLICA, quienes se esforzaron por brindarnos conocimientos y una
excelente formación tanto personal como profesional.
Los Autores

INDICE
Título Página
1 Carátula 1
2 Dedicatoria 2
3 Agradecimiento 3
4 Índice 4
5 Resumen 6
6 Abstract 7
7 Introducción 8
8 Generalidades 9
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 procesos 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 de la Ferretería
“Covensy”, en la necesidad de tratar de facilitar y agilizar el proceso de venta en la
ferretería, 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 Ferretería “Covensy” 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 seria una página Web con la cual nos permitiría dar a conocer los
productos con imágenes para que así traten de ver todos los caminos de que la
empresa cumpla con sus objetivos.

RESUMEN
El presente proyecto titulado Implementación de sistema informático Web para
mejorar el proceso de comercialización de la ferretería “Covensy”. Tiene como
objetivo general Implementar un Sistema Web, para la Ferretería “Covensy” basado
en la metodología RUP.
Este Sistema Web 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 Web Extranet e Intranet en la que está desarrollado, lo que permite cubrir
todas las necesidades del negocio y también utilizarla en forma remota.
Este Sistema web, 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.

ABSTRACT
Web System presented in this project is developed in PHP programming language
used as the database engine for MySQL, designed to effectively manage a hardware
company like typical and traditional in our city of Chimbote.
This web-based system that allows us total control of stock, billing, sales and
purchases management, which allows efficient management of business
management.

CAPITULO
GENERALIDADES

1. GENERALIDADES.
1.1. DATOS DEL LOS PRACTICANTES.
Centro Estudios : ULADECH CATÓLICA
Facultad : Ingeniería
Escuela : Ingeniería Sistemas.
Ciclo : IX
 Primer Practicante :
Apellidos : Capillo Velásquez
Nombres : Miguel Ángel
Código Universitario : 0109062044
DN.I. : 45201518
 Segundo Practicante:
Apellidos : Morillo Merino
Nombres : Vilmer
Código Universitario : 0109091039
DN.I. : 42608454
1.2. NOMBRE PROYECTO:
Implementación de sistema informático de web para mejorar el proceso de
comercialización de la ferretería “Covensy”.

1.3. OBJETIVOS DEL PROYECTO.
1.3.1 OBJETIVO GENERAL.
 Implementar un Sistema Web, para la Ferretería “Covensy”.
1.3.2 OBJETIVO ESPECIFICO.
 Definir los objetivos, requisitos y viabilidad del Sistema Web.
 Diseño, Programación e implementación de las definiciones en detalle
de toda la aplicación.
1.3.3 OBJETIVOS DEL SISTEMA
 Brindar un control más exacto y detallado de las ventas y del stock
diario.
 Captar la atención de los clientes o público en general quienes visiten
nuestra página web.
 Proporcionar control absoluto de la cartera de clientes y sus estados de
compras.
 Permitir registrarse al cliente y hacer las consultas del caso vía correo
electrónico.

CAPITULO I
MARCO TEÓRICO
CONCEPTUAL

I. MARCO TEÓRICO CONCEPTUAL:
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:
II.I.III Logotipo:
II.I.IV Áreas que comprende:
 Ventas
 Almacén
Nombre o Razón Social : Ferretería “Covensy”
Ruc : 10152014789
Titular : Ventocilla Gonzales, Amandina Rosa
DNI 15201478
Dirección : Jr. Tumbes s/n Interior Mercado “Ferrocarril”
puesto 347 – Santa – Chimbote – Ancash
Actividad : CIIU 5234 -Venta Mínima Artículos
Ferretería y Cocina.
Teléfono : 358762
Url : http://ferreteriacovensy.260mb.com/

II.I.V Reseña Histórica y Operacional:
La empresa Ferretería “Covensy” fue fundada el 01 de Julio de 2005
llevando el nombre de FERRETERÍA "COVENSY", adecuándose como
Sociedad Anónima el 12 de Julio del 2005 adquiriendo el nombre de
FERRETERÍA "Covensy" S.A.
Desde entonces nos hemos ido posicionando dentro del mercado
Chimbotano, en principal en el mercado Ferrocarril.
Somos Distribuidores Autorizados de las marcas siguientes:
Indeco, Antec, Brennenstuhl,... Todas estas marcas son reconocidas a nivel
mundial. Ferretería “Covensy” es una empresa que se dedica a la venta de
artículos de ferretería, eléctricos y cocinas.
II.I.VI Visión:
Queremos posicionar a nuestra Ferretería Covensy; en el mercado a nivel
nacional siendo reconocidos como comercializadores y distribuidores, de
alto prestigio y confiabilidad, de elementos de ferretería en general y
Cocinas.
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.VIIMisión:
En Ferretería Covensy; es una empresa comercial en el campo de
materiales para la construcción y ferretería en general, que atiende
necesidades de vecinos, contratistas e industriales, generándoles bienestar y
desarrollo y además estamos comprometidos con la distribución y
comercialización de productos nacionales e importados, orientados a las
labores de mantenimiento, montaje y fabricación, en la industria y el
comercio Chimbotano.
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.
o 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.
GERENTE
ADMINISTADOR
EMPLEADO
CONTADOR

 ADMINISTRADOR:
Encargado de administrar el correcto funcionamiento de los procesos
ya demás revisa las ventas hechas en el día.
o 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.
o FUNCIONES:
 Hacer o verificar el correcto corte de caja.
 Realizar los balances.
 Declarar los impuestos.
 EMPLEADO:
Encargado de atender a los clientes.
o 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
3 meses.
Se dará inicio al proyecto en la fecha establecida (desde el 09 de Setiembre
al 16 de Diciembre del 2010).

 Lista de Actividades:
ACTIVIDADES DESCRIPCIÓN FECHA
Definición de
objetivos
Se definirá el resultado del
proyecto y su papel en la
estrategia global.
Del 09 al 16 de
Setiembre
Análisis de los
requisitos y su
viabilidad
Se recopilara, examinara y
formulara los requisitos
del cliente y examinar
cualquier restricción que
se pueda aplicar.
Del 17 al 23 de
Setiembre.
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)
Del 24 al 30 de
Setiembre
Diseño en
detalle
De las definiciones
precisas de cada
subconjunto en detalle de
toda la aplicación (Diseño
de Base de Datos).
Del 01 al 15 de
Octubre
Programación
(programación e
implementación)
Se procederá con el diseño
de las interfaces,
programación e
implementación del
código fuente.
Del 16 de Octubre
al 19 de Noviembre
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.
Del 20 al 23 de
Noviembre

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.
Del 24 de
Noviembre al 26
de Noviembre
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.
Del 27 de
Noviembre al 14 de
Diciembre
Documentación
Se elaborara la
documentación con la
información necesaria
para los usuarios del
software y para
desarrollos futuros.
Del 29 de
Noviembre al 09
de Diciembre
Informes y
Presentación del
Proyecto
Se procederá a elaborar el
informe y la
documentación requerida
para la sustentación del
proyecto de practica I
Del 10 al 17 de
Diciembre
Implementación
Se procederá a ser las
implementaciones
correspondientes, según
los requerimientos
establecidos.
El 20 de Diciembre
Mantenimiento
Se hará mantenimiento
para todos los
procedimientos
correctivos
(mantenimiento
correctivo) y las algunas
actualizaciones
secundarias del software si
así lo requiere el cliente
Del 20 de
Diciembre del 2010
a Diciembre 2011

 Cronograma de Trabajo:
CÓD. ACTIVIDAD PRECEDENCIA
DURACIÓN
(Días)
A
Definición de
objetivos
- 8
B
Análisis de los
requisitos y su
viabilidad
A 7
C Diseño general B 7
D Diseño en detalle C 15
E
Programación
(programación e
implementación)
D 33
F Prueba de unidad E 4
G Integración F 3
H
Prueba beta (o
validación)
G 17
I Documentación H 11
J
Informes y
Presentación del
Proyecto
H 8
K Implementación I y J 1
(mantenimiento continuo),
este mantenimiento serán
cada vez que el cliente lo
solicite, de acuerdo a la
necesidad.

II.V.IIANÁ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
o 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 ferretería.
 Control de los productos ofrecidos y del personal que labora en
la ferretería.
 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
o 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 Centos.
 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 Duo, 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 Centos.
 Estaciones: Procesador Intel® Dual-Core 512Mb, memoria
RAM, Disco duro de 60Gb, unidad lectora de CD. Ubuntu 10.4
 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 Ferretería 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 ferretería 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 ferretería?
____________________________________________________________
 ¿Cómo muestran a los clientes las características y la variedad de productos
que ofrece la ferretería, 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 Ferretería?
____________________________________________________________

II.II.IV Hardware disponible.
o 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.
o 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.
o 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 Ferretería Covensy es una empresa que brinda el servicio de venta
de materiales de cocina, ferretería, electrónica y ferretería en general.
Identificando la problemática dentro de la ferretería es que no se lleva un control
exacto de sus ventas diarias, reportes de ventas, ganancias, productos en stock, ya
que dodos 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 web 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 Web, 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 ferretería Covensy cuenta con un presupuesto establecido,
para mejorar la calidad, si el sistema lo requiere y a la vez
adquirir el software.
Sistema
Venta
Comprobante de Venta
Reporte de Ventas
Liquidación Diaria
Disminución de stock

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.IMetodologí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:
o Desarrollo iterativo del software: Permite comprender los
requerimientos que hacen crecer el sistema.
o Administración de requerimientos: Describe como se obtienen,
organizan, documentan los requerimientos.
o Uso de arquitecturas basadas en componentes: Se basa en diseñar una
arquitectura que sea flexible, fácil de modificar.
o 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
o Ingeniería de Negocios: Entendiendo las necesidades del negocio.
o Requerimientos: Trasladando las necesidades del negocio a un
sistema automatizado.
o Análisis y Diseño: Trasladando los requerimientos dentro de la
arquitectura de software.
o Implementación: Creando software que se ajuste a la arquitectura y
que tenga el comportamiento deseado.
o Pruebas: Asegurándose que el comportamiento requerido es el
correcto y que todo lo solicitado está presente.

 Disciplina de Soporte
o Configuración y administración del cambio: Guardando todas las
versiones del proyecto.
o Administrando el proyecto: Administrando horarios y recursos.
o Ambiente: Administrando el ambiente de desarrollo.
o 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:
o Actividades, Son los procesos que se llegan a determinar en cada
iteración.
o Trabajadores, Vienen hacer las personas o entes involucrados en
cada proceso.
o 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.
o XP surgió como respuesta y posible solución a los problemas derivados
del cambio en los requerimientos.
o XP se plantea como una metodología a emplear en proyectos de riesgo.
o 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?
o Empieza en pequeño y añade funcionalidad con retroalimentación
continua.
o El manejo del cambio se convierte en parte sustantiva del proceso.
o El costo del cambio no depende de la fase o etapa.
o No introduce funcionalidades antes que sean necesarias.
o El cliente o el usuario se convierte en miembro del equipo.
Derechos del Cliente:
o Decidir que se implementa.
o Saber el estado real y el progreso del proyecto.
o Añadir, cambiar o quitar requerimientos en cualquier momento.
o Obtener lo máximo de cada semana de trabajo.
o Obtener un sistema funcionando cada 3 o 4 meses.
Derechos del Desarrollador:
o Decidir cómo se implementan los procesos
o Crear el sistema con la mejor calidad posible
o Pedir al cliente en cualquier momento aclaraciones de los
requerimientos
o Estimar el esfuerzo para implementar el sistema
o 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.
o 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.
o 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.
o 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.
o 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.

o 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.
o 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:
o 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.

o 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.IIIAnálisis:
III.III.I Definición de Requisitos:
III.III.II Casos esenciales de uso:
Modelo del Negocio
MN_Administrador
MN_Cliente
MN_Venta
MN_Pedido
MN_Empleado

III.III.III Diagramas de casos de uso:
Caso de Uso – Facturación
Caso de Uso – Cambio de Producto
Verifica Excistencia
Registro y Verificacion de los datos
del Cliente Ralizacion de la Factura
Descargo de los Productos en el
Inventario
Realiza Pago
CU_Facturacion
CU_Cliente
Entrega del Producto
Toma orden de Pedido
Realiza Pedido
Solcilita Pago
CU_Empleado
Solicita Cambio
CU_Cliente
Recepciona y Verifica Producto
Realiza al cambio
CU_Empleado
Aprueva cambio
CU_Administrador

Caso de Uso - Compra a Proveedores
III.III.IV Crear Modelo Conceptual:
III.III.V Diagramas de Secuencia:
DS - Facturación
Recepcion de la soliciud de compra
Generacionde Factura por Compra
CU_Proveedor
Registro de Stock Registro de Poductos para la
Compra
Ubicar Productos en Almacen
Ingreso de Porductos al Inventario
CU_Empleado
Solicita Registro de Prodcutos
Comprar
Aprovacion del presuspuesto de
Compras
Pago de factura a Proveedores
Recepccion y Verificacion de los
productos comprados
CU_Administrador
: CU_Cliente
: CU_Cliente : CU_Empleado
: CU_Empleado CU_Facturacion :
CU_Cliente
CU_Facturacion :
CU_Cliente
Realiza Pedido
Toma Orden de Pedido
Verifica Exsitencias
Registro y Verificacion de los datos del Cliente
Ralizacion de la Factura
Descargo Porductos en el Inventario
Solicita Pago
Realiza Pago
Entrega del Producto

DS – Cambio de Producto
: CU_Cliente
: CU_Cliente : CU_Empleado
: CU_Empleado : CU_Administrador
: CU_Administrador
Solicita Cambio de Producto
Recepciona y Verifica producto
Aprueva Cambio de Producto
Realiza el cambio

DS – Compra a Proveedores
: CU_Administrador
: CU_Administrador : CU_Empleado
: CU_Empleado : CU_Proveedor
: CU_Proveedor
Registra productos para la compra
Solicita Registro de Productos a comprar
Recepcion de la solicitud de Compra
Reneracion de la factura por compra
Pago de factura a Proveedores
Aprovacion del presupuesto de Compra
Recepcion y Verifiacion de los productos comprados
Registro de Stock
Ingreso de Porductos al inventario
Ubicar productos en almacen

III.III.VI Diagramas de Actividades
DA – Facturación
Pedir Producto
Cancelar Orden
Recibir Orden
Pagar Factura
Recibir Orden
Verificar Pago Comprovar
Stock
Tomar
Materiales
Cerrar Orden
Enviar Orden
Facturar Orden
En stock
. : O: Factura
[Pagado]
: O: Factura
[No Pagado]
: O: Orden
[En Progreso]
Agotado
Fallo
Exito
EMPLEADO
CLIENTE

DA – Compra Proveedores
Verifica Ingreso
de Productos
Solicita Pedido
Recepciona y
analiza Cotizacion
¿Es Factible?
no
Aprueva Presupuesto de
Compras
si
Recibe y
Consolida Factura
Conforme
Cancela
Factura
si
Recibe
Solicitud
Realiza y envia
Cotizacion
Recibe y Confirma
Pedido
Envia Pedido y
Factura
Recibe Error de
Pedido
no
PROVEEDORES
ADMINISTRADOR
Empleado

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 las 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 benlazan 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.
 Tabla Persona:
 Tabla Compra:

 Tabla Detalle Compra:
 Tabla Venta:
 Tabla Producto:

 Tabla Categoría Producto:
 Tabla Sub Categoría Producto:
 Tabla Unidad Medida:
 Tabla Línea Negocio:
 Tabla Marca:

 Tabla Proveedor:
 Tabla Modelo:
 Tabla Privilegio:
 Tabla Tipo Persona:

CAPITULO IV
INTERFACES

IV. INTERFACES:
IV.I Finalidad de las Interfaces de los Sistemas:
IV.I.I Diseño de Interfaces:
PAGINA WEB

INTRANET

INTERFAZ DE CLIENTE

INTERFAZ DE PROVEEDOR

INTERFAZ DE PRODUCTO

INTERFAZ DE VENTA
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:
EQUIPOS
Nº ÁREA EQUIPOS
1 Ventas 2
2 Almacén 1
TOTAL 3
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 Chimbote

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 Ferretería “Covensy” 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
Cant. SOFTWARE P. UNIT. TOTAL
1 Sistema Operativo 230.00 230.00
1 Php 1000.00 1000.00
1 MySQL - Worbench
Total 1230.00
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
Nº DESCRIPCION TOTAL
1 Licenciamiento de Software 1230.00
2 Costo de Desarrollo de Software 600.00
3 Otros Costos 35.00
4 Instalaciones-lugar de trabajo 15.00
5 Costo de Equipos para el Desarrollo 400.00
Total 2270.00
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 Ferretería “Covensy”.
 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 - Ferretería “Covensy”.
 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 Ferretería “Covensy”.
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:

104801340-Proyecto-Final-Ferreteria-Covensy.pdf

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 104801340-Proyecto-Final-Ferreteria-Covensy.pdf

Similar a 104801340-Proyecto-Final-Ferreteria-Covensy.pdf (20)

Más de leidergeiserchacongi1

Más de leidergeiserchacongi1 (10)

Último

Último (20)

104801340-Proyecto-Final-Ferreteria-Covensy.pdf