Proyecto Final - Ferreteria Covensy

Uladech - Practicas Pre Profesionales I – Ferretería “Covensy”

Ferreterí[email protected] 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/

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.VII Misió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.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

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

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.III Aná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 PedidoSolcilita 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 OrdenEn stock

. : O: Factura

[Pagado]

: O: Factura

[No Pagado]

: O: Orden

[En Progreso]

Agotado

Fallo

Exito

EMPLEADOCLIENTE



DA – Compra Proveedores

Verifica Ingreso

de Productos

Solicita Pedido

Recepciona y

analiza Cotizacion

¿Es Factib le?

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

PROVEEDORESADMINISTRADOREmpleado



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:

Proyecto Final - Ferreteria Covensy

Documents

Transcript of Proyecto Final - Ferreteria Covensy