sistema de ventas en linea subir

SISTEMA DE VENTAS EN LINEA José C. || Brenda S.

ANALISIS Y DISEÑO ORIENTADO A OBJETOS Universidad de Sonsonate

1

ÍNDICE

CONTENIDO PÁGINA No.

Índice ............................................................................................................................ 1

Introducción ................................................................................................................. 5

CAPÍTULO I. PLAN DE DESARROLLO DE SOFTWARE ........................................................ 7

1.1 VISTA GENERAL DEL PROYECTO ....................................................................................... 8

1.1.1 Propósito y alcance ....................................................................................................... 8

1.1.2 Entregables del proyecto ............................................................................................... 9

1.1.2.1 Fases del sistema ........................................................................................... 9

1.1.2.1.1 Requisitos ........................................................................................ 9

1.1.2.1.2 Análisis .......................................................................................... 10

1.1.2.1.3 Diseño ........................................................................................... 10

1.1.2.1.4 Implementación ............................................................................ 10

1.1.2.2 Manuales del sistema .................................................................................. 11

1.1.2.2.1 Manual de instalación ................................................................... 11

1.1.2.2.2 Manual de apoyo al usuario final .................................................. 11

1.1.2.2.3 Manual de contingencias .............................................................. 11

1.1.2.3 Producto ....................................................................................................... 12

1.1.2.3.1 Organización del proyecto ............................................................. 12

1.1.2.3.2 Participantes del proyecto ............................................................. 13

1.1.2.3.3 Entidades externas......................................................................... 13

1.1.2.3.4 Roles y responsabilidades .............................................................. 14

1.1.2.3.5 Gestión del proyecto ...................................................................... 14

1.1.2.3.6 Estimaciones del proyecto ............................................................. 15

1.1.2.3.7 Plan del proyecto ........................................................................... 17

1.1.2.3.8 Calendarización .............................................................................. 18

CAPÍTULO II. MODELADO DEL NEGOCIO ............................................................................ 19



2

2.1 GENERALIDADES DE LA EMPRESA ................................................................................. 20

2.1.1 Descripción de la empresa .......................................................................................... 20

2.1.2 Misión ......................................................................................................................... 20

2.1.3 Visión .......................................................................................................................... 20

2.1.4 Diagramas del subsistema de la empresa .................................................................. 21

2.1.5 Modelado de casos de uso .......................................................................................... 22

2.1.6 Modelado de objetos .................................................................................................. 23

CAPÍTULO III. FASE DE REQUERIMIENTOS DEL SISTEMA .................................................... 24

3.1 OPORTUNIDAD DEL NEGOCIO ........................................................................................ 25

3.2 DEFINICION DEL PROBLEMA ........................................................................................... 25

3.3 FASE DE REQUISITOS ...................................................................................................... 26

3.3.1 Modelado de casos de uso .......................................................................................... 26

3.3.1.1 Actores .......................................................................................................... 26

3.3.1.1.1 Identificación de escenarios ......................................................... 26

3.3.1.2 Diagramas de casos de uso ........................................................................... 28

3.3.1.3 Diagramas de estado .................................................................................... 29

3.1.2 Modelado del dominio del problema .......................................................................... 37

3.3.2.1 Identificación de clases ................................................................................. 37

3.3.3.2 Identificación de asociaciones ...................................................................... 38

3.3.3.3 Identificación de atributos ............................................................................ 39

3.3.3.4 Diagrama de clases con asociaciones ........................................................... 41

3.4 Requerimientos no funcionales ...................................................................................... 42

3.5 Matriz de componentes ................................................................................................. 43

CAPÍTULO IV. FASE DE ANALISIS .......................................................................................... 44

4.1 Objetivos del sistema ..................................................................................................... 45

4.1.1 Objetivo general .............................................................................................. 45

4.1.2 Objetivo específico ......................................................................................... 45

4.2 Análisis ............................................................................................................................ 46



3

4.2.1 Arquitectura de clases ..................................................................................... 46

4.2.1.1 Identificación de clases según estereotipos ..................................... 46

4.2.1.2 Clases según casos de uso ................................................................ 47

4.2.1.3 Diagramas de secuencia ................................................................... 50

4.2.1.4 Diagramas de colaboración .............................................................. 50

4.2.1.5 Identificación de atributos de bases de datos .................................. 50

4.2.1.6 Modelo relacional de bases de datos ............................................... 51

4.2.1.7 Seguridad del sistema a nivel de capas ............................................ 52

4.2.1.8 Matriz PCES ....................................................................................... 53

4.2.2 Diagrama jerárquico del sistema ..................................................................... 54

CAPÍTULO V. FASE DE DISEÑO ..................................................................................... 55

5.1 Especificación de soluciones alternativas ...................................................................... 56

5.2 Análisis de la viabilidad de las soluciones alternativas .................................................. 57

5.3 Determinación de diseños de la propuesta.................................................................... 58

5.4 Justificación técnica de la solución alternativa .............................................................. 58

5.5 Alcances y limitaciones de la aplicación ......................................................................... 66

5.6 Diseño de la arquitectura ............................................................................................... 67

5.6.1 Modelos de casos de uso de diseño ................................................................ 67

5.6.1.1 Identificación de casos de uso de diseño ......................................... 67

5.6.1.2 Diagramas de casos de uso de diseño .............................................. 67

5.6.1.3 Diagramas de secuencia de diseño ................................................... 71

5.6.1.4 Diagrama de clases ........................................................................... 89

5.6.1.4.1 Identificación de clases de diseño ..................................... 89

5.6.1.4.2 Diagramas de clases con asociaciones y atributos ............ 90

5.6.1.5 Interfaz gráfica .................................................................................. 91

5.6.1.5.1 Entrada ............................................................................... 91

5.6.1.5.2 Salida .................................................................................. 93



4

CAPÍTULO VI. FASE DE IMPLEMENTACION ................................................................... 94

6.1 Requisitos de implementación ....................................................................................... 95

6.2 Diagrama de componentes ............................................................................................ 96

6.3 Distribución del sistema ................................................................................................. 97

6.4 Modelo de despliegue .................................................................................................... 97

6.5 Pruebas y corrección de errores ..................................................................................... 97

6.5.1 Pruebas de unidad ........................................................................................... 97

6.5.2 Pruebas de integración .................................................................................... 98

6.5.3 Pruebas del sistema ......................................................................................... 98

6.5.4 Pruebas de stress ............................................................................................. 99

6.6 Plan de implantación .................................................................................................... 100

6.6.1 Capacitación de usuarios ............................................................................... 100

6.7 Plan de mantenimiento ................................................................................................ 101

6.7.1 Preventivo ...................................................................................................... 101

6.7.2 Correctivo ...................................................................................................... 103

6.1 Plan de contingencia..................................................................................................... 104

CAPÍTULO VII. CONCLUSIONES Y RECOMENDACIONES ................................................ 105

7.1 Conclusiones ................................................................................................................. 106

7.2 Recomendaciones ......................................................................................................... 107

7.3 Anexos .......................................................................................................................... 108

7.3.1 Manual de instalación .................................................................................... 109



5

INTRODUCCION

En la actualidad se están generando cambios en el desarrollo de las empresas que les

permiten mejorar sus servicios y tiempos de respuesta a los clientes por medio de los

sistemas informáticos. Tales sistemas deben contar con la adaptación al tipo de empresa

para el cual ha sido creado y llegar de esta manera a ser una herramienta que les permita,

tanto a gerentes como empleados operacionales, agilizar su trabajo de forma eficiente,

reduciendo el tiempo de respuesta o resultados a presentar.

Con el desarrollo de la primera etapa del proyecto realizado en la materia de Análisis y

Diseño Orientado a Objetos de la Universidad de Sonsonate se pretende ayudar a

fortalecer el área de ventas la pequeña empresa OPTICA LA ECONOMICA, mediante

identificación y ejecución de los procesos que se necesitan llevar acabo para implementar

un sistema e-comerce llamado Sistema de Ventas Online que abreviamos como VENTRIX,

este sistema pueda llevar a diario desde el nivel operativo hasta el estratégico de las

operaciones que suscitan en una compra en línea. Por consiguiente el presente

documento contiene inicialmente los antecedentes que muestran las acciones relevantes

anteriores, relacionadas con el desarrollo de la solución, posteriormente se presenta la

definición del problema, donde se realiza el reconocimiento, descubrimiento y

formulación de la problemática planteada para dicha solución.

Se muestran la vista general de la empresa, las pretensiones que se proyectan a alcanzar

con los medios provistos de la tecnología actual y establecer la propuesta del contenido

temático del proyecto y la importancia que la solución a desarrolla.

Se trata además de identificar todos aquellos requerimientos necesarios para el correcto

desarrollo del sistema poniendo en manifiesto por qué y para qué se realizara el proyecto.



6

CAPÍTULO I PLAN DE DESARROLLO DE SOFTWARE

OBJETIVOS DEL CAPÍTULO:

Describir de forma breve lo que será el proyecto a realizar,

definir los tiempos y establecer los recursos a utilizar.



7

1.1 VISTA GENERAL DEL PROYECTO

1.1.1 Propósito y alcance

El propósito principal para realizar el proyecto de un sistema e-comerce Sistema de

Ventas Online que abreviamos como VENTRIX dentro de la empresa “Óptica la

Económica” es de automatizar los procesos de ventas con los clientes por medio de un

sistema web que sea capaz de interactuar con el cliente de tal forma que se le haga fácil la

compra de productos dentro de la línea que maneja la empresa atreves de la red de

internet.

El alcance de este proyecto se orienta a 4 áreas principales:

Usuarios

Permitir el acceso a los empleados que se les ha otorgado permisos de

administración al sitio y por medio de un sistema de acceso identificar a los

usuarios empleados de los clientes.

Permitirle a los clientes acceder a cualquier sección que se relacione con la

presentación de productos.

Permitir a los visitantes acceder a las presentaciones de productos.

Ventas

Registrar clientes y establecer sus datos previamente verificados.

Carro de compras para clientes

Notificación de la compra vía e-mail para clientes

Realizar los pago utilizando la herramientas de pruebas sandbox atreves de

paypall.

Se debe emitir comprobante de envió

Reporte de ventas

Inventarios

Sistema de log para rastrear eventos de compras de clientes y acciones de

empleados



8

Gestionar las categorías de los productos y los productos por parte de los

administradores del sitio

Reportes de productos

Administración del sistema

Restablecer contraseñas perdidas vía email a clientes.

Administración, modificación o eliminación de las noticias de ofertas en las

pantallas principales así como los productos e imágenes de los mismos.

Debe poder enviar e-mails de promociones o como propaganda a nuevos

productos.

Bitácora del sistema

1.1.2 Entregables del proyecto

1.1.2.1 Fases del sistema

Las distintas fases del desarrollo del proyecto tienen un alcance máximo de tiempo de 4

semanas.

1.1.2.1.1 Requisitos

La duración de esta fase será de 1 semana, en esta fase se realizó un estudio previo para

poder establecer los parámetros de limitantes y requerimientos en la realización del

análisis. Para ello se entrevistó continuamente a un representante del negocio en este

caso el dueño ANONIMO el cual proporciono la información de cómo se realizan los

procesos dentro de la empresa. El software utilizado para su primera fase será:

Microsoft Office 2010: Para redactar el documento.

Microsoft Visio 2010: Para realizar los gráficos en realización a la empresa

Start UML: para el modelo de casos de uso.

OpenProj: Como alternativa a Project 2010 para la realización de la

calendarización por medio de un diagrama de Gantt.



9

1.1.2.1.2 Análisis

Esta fase se realizara en un periodo de 1 semanas en el que se deberá hacer el análisis de

todos los datos que se necesiten para poder establecer y preparar la solución precedente

a la etapa de diseño.

Para esta etapa utilizaremos el siguiente software:


Microsoft Visio 2010: Para realizar el modelo relacional y todos los otros

gráficos que no están detallados para esta fase.

Start UML: para el diseño de los diagramas de secuencia, clases de casos de

uso.

1.1.2.1.3 Diseño

La fase de diseño se realizara en un periodo de 1 semana contiguo al análisis del proyecto,

se utilizaran el siguiente software:


Start UML: Para diagramas de casos de uso, el diseño de los diagramas de

secuencia, clases de casos de uso para esta fase.

1.1.2.1.4 Implementación

La fase de implementación no se realizara en su totalidad debido a que hay puntos que no

abarca el análisis y diseño orientado a objetos:

El software a utilizar es:


Microsoft Visio 2010: Para todos los gráficos que se utilizan en esta fase.



10

1.1.2.2 Manuales del sistema

Los manuales del sistema son para la implementación del software por cual se detalla una

pequeña descripción de lo que deberá contener cada uno de ellos.

1.1.2.2.1 Manual de instalación

El manual de instalación de VENTRIX estará dirigido a usuarios administradores de un

servidor web y será la descripción de cómo debe realizarse la instalación y configuración

inicial para VENTRIX; Por tanto se asume que el lector está familiarizado con

conceptos en relación de plataformas web como lo son PHP y MySql además de los

permisos de ejecución del sistema dentro del servidor si fuese necesario.

Dentro del sistema VENTRIX Sistema de Ventas Online abreviado su instalación será

sencilla, se deberá realizar en un servidor que posea las siguientes características:

Apache2 en versiones estables

Sistema operativo recomendado: Linux por los costos que acarrea y la

seguridad nativa.

Soporte para PHP y MySQL en sus versiones más actuales y estables.

Conexión a internet

Configurado para funcionar con Socket Security Layer

1.1.2.2.2 Manual de apoyo al usuario final

Se realizara un documento talque contenga los aspectos más relevantes e importantes

para utilizar VENTRIX.

En este manual describiremos todas las opciones que contiene el sistema tanto para

clientes y empleados, además de la ayuda interna que el sistema VENTRIX tendrá.

1.1.2.2.3 Manual de contingencias



11

El manual de contingencia se realizara en función de la base de datos del sistema y el

servidor web, ya que es un sistema de plataforma web la seguridad de acceso a ella es

muy esencial así como la garantizarían de las credenciales de un usuario y las operaciones

que deben realizarse para poder responder ante sucesos inesperados que puedan ocurrir

para ello se realizara:

Manual de contingencia preventivo: En él se pretenderá preestablecer las

condiciones necesarias para evitar que el sistema falle o la integridad de los

datos se ponga vulnerable.

Manual de contingencia correctivo: En él se describirá los métodos y

procedimientos a realizar ante fallos identificados o suscitados en VENTRIX.

1.1.2.3 Producto

VENTRIX será un Sistema de Ventas Online que poseerá una bitácora de eventos de

administradores, así como de clientes, logs y reportes que permitirán detectar con

facilidad los errores que susciten dentro del sistema, la revisión periódica se hará de

forma automática y es en tiempo real.

1.1.2.3.1 Organización del proyecto

La organización interna se basa en 4 módulos principales:

Administración: Contiene las herramientas administrativas a las que solo un

usuario previamente identificado podrá acceder y estas herramientas estarán

otorgadas por niveles de privilegios.

Ventas: Los módulos de ventas serán las funciones que se encargaran en un

apartado especial de procesar la información e interactuar con la información

del usuario de la base de datos.

Configuración global: Se tendrá una configuración global que contendrá la

configuración del servidor, así como la configuración necesaria para establecer

la conexión a la base de datos, esta configuración será utilizada por los otros



12

módulos para comunicarse con el servidor de la Base de Datos dentro del

Servidor WEB.

Presentación: Es la organización más básica, principal y necesaria para que los

clientes y visitantes puedan visualizar el VENTRIX.

1.1.2.3.2 Participantes del proyecto

a) Para el desarrollo del proyecto se contó con 2 personas:

José C (Analista programador)

Brenda S. (Analista programador y administrador de Bases de Datos)

b) Asesoría técnica:

Ing. Manuel U: Catedrático de la materia Análisis Orientado a Objetos

de la Universidad de Sonsonate, nos orientara en UML así como la

descripción de manera general de los procesos de cómo debe realizarse

las etapas del proyecto.

c) Para la obtención de la información se realizaran las entrevistas que sean

necesarias con empleados de la empresa y gerencia general.

1.1.2.3.3 Entidades externas

Las entidades externas son todas aquellas que se relacionen desde el exterior con la

empresa y se han identificado las siguientes:

Ministerio de trabajo: Es la entidad en la que los empleados pueden presentar

quejas. Además es una guía para la empresa en cumplir las condiciones de trato

que por derecho tiene el trabajador.

Ministerio de Hacienda: Esta es la entidad a quien se le declara la renta atreves de

las planillas y condiciones de formularios para los empleados.

Instituciones de servicios básicos: Entidad que contiene los servicios básicos de la

empresa tales como la energía eléctrica, agua potable, teléfono y que son vitales

para el correcto funcionamiento de la empresa.



13

Entidades financieras: La empresa mantiene una cuenta activa con el Banco

Agrícola.

Policía nacional civil (PNC): La policía nacional civil es la entidad a quien se dirige la

empresa cuando se suscitan eventos relacionados a ella, como lo son: Robos y

asaltos.

1.1.2.3.4 Roles y responsabilidades

ROL Responsabilidad

Asesoría técnica Asesorar de modelado UML, Programación, diseñó y manejo de la DB

Análisis diseño y manejo de la base de datos Capturar la información de los formularios para crear analizar diseñar

Construcción de la aplicación Construcción de un prototipo en colaboración con el asesor técnico

1.1.2.3.5 Gestión del proyecto

GASTOS DE PERSONAL

Cantidad Descripción Cantidad (horas)

P.V. Total

1 Asesoría técnica 80 $10.00 $800.00

1 Analista 75 $10.00 $750.00

1 Diseñador 75 $8.00 $600.00

1 Programador 100 $5.00 $500.00

1 Soporte técnico 20 $15.00 $300.00

OTROS GASTOS

Descripción Cantidad Total

Material de oficina 1 $14.43

Equipo de computo 1 $88.50

SUBTOTAL $3052.93

IMPROVISTO (10%) $305.30

TOTAL $3358.24

1.1.2.3.6 Estimaciones del proyecto



14

GASTOS PERSONAL

Concepto Descripción Costo por unidad Total

ASESORIA

TECNICA

Necesario para la asesoría técnica de

parte del Ing. Manuel U para la

conceptualización del modelado UML

durante todo el proyecto por 80

horas.

La persona encargada de dar la

asesoría será el Ing. Manuel U.

$10.00 $800.00

ANALISTA Es necesario un analista de sistemas

ara el estudio de recopilación

documental vital para la correcta

adaptación del sistema informático

durante todo el proyecto por 75

horas.

La persona encargada en función de

analista será José C.

$10.00 $750.00

DISEÑADO

R

Necesario para hacer el modelado de

los procesos para la implementación

de programación durante todo el

proyecto por 75 horas.


diseñador será Brenda S.

$8.00 $600.00

PROGRAM

ADOR

Se necesitara un programador para la

implementación de producto en

software, durante todo el proyecto

por 100 horas.

$5.00 $500.00

SOPORTE Se necesitara una persona para el $15.00 $300.00



15

TECNICO soporte técnico con un costo

estimado a 20 horas.


analista será José C.

TOTAL DE GASTOS EN PERSONAL $2950.00

OTROS GASTOS

Concepto Descripción Costo por

unidad

Subtot

al

MATERIAL DE OFICINA

1 Resma de papel Servirá para escribir o recopilar toda

aquella información necesaria

concerniente para el desarrollo del

proyecto.

$4.99 $4.99

1 Caja de lápices Servirá para escribir o recopilar toda

aquella información necesaria

concerniente para el desarrollo del

proyecto.

$3.84 $3.84

2 cartapacio Se utilizara para portar las hojas que se

utilizan y que sean necesarias para el

desarrollo del proyecto de desarrollo de

software.

$3.00 $6.00

TOTAL DE MATERIAL DE OFICINA $14.83

EQUIPO DE COMPUTO

Alquiler de 2

computadoras

2 horas diarias de computadora alquilada

con servicio a internet durante 4 semanas.

$1.00 c/u $56.00

2 cartuchos de Para imprimir el proyecto final y la $10.00 $20.00



16

tinta negra para

canon ip2700

información que sea necesaria.

1 cartucho de

tinta de color

Para imprimir gráficos del proyecto final. $12.50 $12.50

TOTAL DE EQUIPO DE COMPUTO $88.50

ESTIMACION GENERAL DEL PROYECTO

GASTOS DE PERSONAL $2950.00

MATERIAL DE OFICINA $14.83

EQUIPO DE COMPUTO $88.50

TOTAL $3358.24

1.1.2.3.7 Plan del proyecto

Modelado del negocio

Modelado de casos de uso del negocio

Modelado de objetos del negocio

Requisitos

Análisis

Diseño

Implementación

Prueba y corrección de errores

Pruebas de unidad

Pruebas de integración

Pruebas del sistema

Pruebas de estress

SISTEMA DE VENTAS EN LINEA José C. || Brenda


17

1.1.2.3.8 Calendarización

Id. Nombre de tarea Comienzo Fin Duraciónmay 2012 jun 2012

18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 2 3 4

1 3d21/05/201218/05/2012FASE I PLAN DE DESARROLLO DE SOFTWARE

2 1d18/05/201218/05/2012Vista general del proyecto

3 1d19/05/201219/05/2012Propósito y alcance

6 1d21/05/201221/05/2012Generalidades de la empresa

12 1d25/05/201225/05/2012Objetivos del sistema

13

4 1d21/05/201221/05/2012 Entregables del proyecto

8 2d23/05/201222/05/2012Oportunidad del negocio

9 1d23/05/201223/05/2012Definición del problema

10 1d24/05/201224/05/2012Requerimientos no funcionales

5 1d21/05/201221/05/2012FASE II MODELADO DEL NEGOCIO

11 4d29/05/201225/05/2012FASE IV ANALISIS

1d26/05/201226/05/2012Análisis

21

14

17

16

15

2d29/05/201228/05/2012Análisis a nivel de capas

4d02/06/201230/05/2012FASE V DISEÑO

2d31/05/201230/05/2012Especificaciones de soluciones alternativas

1d01/06/201201/06/2012Análisis de viabilidad de las soluciones alternativas

18

19

20

1d01/06/201201/06/2012Determinación del diseño de la propuesta

1d01/06/201201/06/2012Justificación técnica de la solución alternativa

1d02/06/201202/06/2012Alcances y limitaciones de la aplicacion

7 3d24/05/201222/05/2012FASE III REQUERIMENTOS DEL SISTEMA

1d04/06/201204/06/2012CONCLUSIONES Y RECOMENDACIONES



18

CAPÍTULO II MODELADO DEL NEGOCIO

Objetivos del capítulo:

Obtener la información referente al negocio así como los procesos

que se realizan actualmente para las ventas de productos.



19

2.1 GENERALIDADES DE LA EMPRESA

2.1.1 Descripción de la empresa

La empresa Óptica la Económica es una pequeña empresa de la ciudad de Sonsonate, se

fundó en el año 2001, lleva más de 10 años trabajando con 3 empleados actuales sus

funciones principales son de vender lentes de todo tipo, posee convenios con varios

laboratorios de procesamiento de lentes en el que ellos se apoyan para hacer la venta de

determinado producto.

Dentro de los objetivos que tienen como empresa están los siguientes:

1. Vender productos de alta calidad dentro de Sonsonate y mantener los ingresos de

le empresa por la calidad de aros, lentes y nuestro servicio

2. Poder aumentar su campo de acción para tener un crecimiento sostenido.

3. Tener una buena administración de recursos económicos y materiales para

garantizar la rentabilidad de la empresa.

4. Invertir en tecnologías nuevas que ayuden a dar un mejor servicio a nuestros

clientes.

5. Optimizar los costes más viables para dar un servicio de excelencia a nuestros

clientes minimizando los costos en cuanto sea posible.

2.1.2 Misión

Vender aros y lentes de alta calidad brindando siempre un servicio de excelencia a cada

uno de nuestros clientes, sustentándonos en recursos humano responsable, por medio de

convenios con otras empresas y utilizando tecnología de punta para convertirse en una

empresa líder a nivel departamental.

2.1.3 Visión

Constituirnos en una empresa innovadora en constante crecimiento, poder expandirnos a

nivel departamental y poder ser reconocidos por la satisfacción de nuestros clientes.



20

2.1.4 Diagramas del subsistema de la empresa

2.1.5 Modelado de casos de uso

Departamento de ventas Gerencia administrativa

Gestion de inventario

Sistema e-comerce VENTRIX

Getion de comprasGestion de cobros

Gestion de ventas

Cliente

Gestionar compra

Ejecutivo de ventas

Gerente administrativo

Facturar

Realizar cobros

Registrar ventas

Realizar pago

Reportes



21

2.1.6 Modelado de objetos

Modelo de objetos de gestionar compra

Modelo de objetos de facturar

Modelo de objetos de realizar pago

Cliente

ControlSolicitarCatalogo

Pedidos del cliente

Cliente

Ejecutivo de venta

Pedidos del cliente

Cliente

Ejecutivo de ventas

Productos facturados



22

Modelo de objetos de realizar cobros

Modelo de objetos de registrar ventas

Modelo de objetos de reportes

Cliente

Ejecutivo de ventas

ClientesDeudores

ClienteEncargado de contabilida

pedidos del cliente

Gerente

SolicitarReporte

productos



23

CAPÍTULO III REQUERIMENTOS DEL SISTEMA


Diseñar el funcionamiento de como operara el sistema e

identificar los requerimientos del sistema.



24

3.1 OPORTUNIDAD DEL NEGOCIO

La unidad de ventas actualmente dentro del negocio es una pequeña unidad controlada

por un solo empleado que atiende a los clientes, despacha órdenes y recibe los pagos.

Actualmente la empresa cuenta con acceso a internet y con equipo de cómputo necesario

para desarrollarse en un entorno e-comerce.

El sistema e-comerce dará la oportunidad de aumentar las ventas por medio de la internet

utilizando una base de datos para almacenar los productos, descripciones y catálogos así

como para los clientes, este sistema facilitara la venta de producto para los clientes ya que

muchos clientes son de otros departamentos o simplemente no tienen tiempo de llegar a

la empresa.

3.2 DEFINICION DEL PROBLEMA

La empresa actualmente no posee un sistema tal que pueda laborar en el mundo virtual y

ser más competitiva, además carece de una base de datos en la cual pueda almacenar

información de sus clientes, productos y ventas, los datos son procesados y almacenados

de forma desordenada en papel y en Excel pero es muy grande y difícil de consultar la

plantilla.

Las ventas solo pueden hacerse con presencia del cliente en el lugar, también puede

hacerse por teléfono si es un cliente registrado pero muchas veces desea información de

nuevos aros o algunos otros estilos de lentes, la empresa no poseen página web y la

competencia actual ya está integrándose al mercado virtual.

Finalmente se posee el equipo y los servicios necesarios para mantener el VENTRIX pero

no se tiene una aplicación e-comerce aun.



25

3.3 FASE DE REQUISITOS

3.3.1 Modelado de casos de uso

3.3.1.1 Actores

Cliente: Realiza compras.

Empleado: Puede acceder a las herramientas básicas para ver las órdenes y

tramitar operaciones de la empresa.

Administrador: Operaciones administrativas.

Figura 3: Actores del sistema

3.3.1.1.1 Identificación de escenarios

Pedido de compra: Un cliente se presenta, consulta los productos y precios, este

cliente tiene acceso al catálogo de productos. Cuando el cliente no desea comprar

o cambia de opinión en cuanto a la compra dentro de la empresa puede descartar

el pedido

Registrar datos del cliente: El empleado comienza el registro de la información del

cliente en fichas y solicita al cliente sus datos.

Registrar compra: El empleado registra la compra del cliente se formula la factura y

esta acción es almacenada en fichas dentro de reportes para el gerente.



26

Pagar productos: El cliente paga la compra realizada y el empleado procede a

entregar los productos y dar la factura



27

3.3.1.2 Diagramas de casos de uso

GestionarCliente

Compras

Gestionar Producto

AdministrarSistema

GestionarCategoria

GestionarUsuario

AccesoSistema

Cliente

Empleado

Gerente General

Administrador1

<<include>>

<<include>><<include>>

<<include>>

<<include>>

<<include>>

<<include>>



28

3.3.1.3 Diagramas de estado

Caso de uso: Compras

Nueva compra

1-Registrar pedido de compra

Datos del producto

2-Solicitar nuevamente

3-Descartar pedido

4-Actualizar base de datos

Información delcliente

Si el producto no exite

Si no desea comprar

Finalizar pedido

Informacióndel producto

Iniciarnuevamente

Descartar pedido

1-Descartar pedido

Datos del pedido

Cancelar operación



29

Registrar compra

1-Seleccionar producto

2-Elaboracion de documentos

3-Actualizar almacén de producto

Información de la compra

Informacion del producto

Información de la venta

Cancelar operación

Facturar

1-Elaborar factura

Procesar factura


Información a facturar

Cancelar operación



30

Entregar producto y factura

Preparar producto

Registrar cobro


Información factura

Cancelar operación

Pagar producto

Solicitar pago

Registra cantidad recivida


Cantidad a pagar

Cancelar operación

Calcular el cambio

Si la cantidad recibida necesita cambio



31

Reportes e inventarios

Procesar venta para reporte

Almacenar reporte



Cancelar operación

Actualizar inventarios


Caso de uso: GestionarCategorias

1-Agregar categoria

Datos deladministrador

2-Modificar categoria

3-Eliminar categoria


Información de la categoria

Si no desea agregar una categoría

Si no desea modificarUna categoría

Si desea modificar otra categoria

Informaciónde la categoría



32

Caso de uso: GestionarCliente

Registrar cliente

1-Registrar datos del cliente

2-Solicitar informacion del cliente

3-Almacenar datos del cliente

Información de pedido

Ficha de registro

Informacion del cliente

Cancelar operación

Pedir datos del cliente

1-Solicitud de datos del cliente

Datos del pedido

Cancelar operación

2-Verificacion de cliente3-Registrar nuevo cliente

Nombre del cliente

Informacion de registro de cliente



33

Caso de uso: GestionarProducto

1-Agregar producto

Datos deladministrador

2-Modificar producto

3-Eliminar producto


Información delproducto

Si no desea agregar un producto

Si no desea modificarun producto

Si el producto no se encuentra

Informacióndel producto

Caso de uso: AdministrarSistema

Administración de las áreas

1-Seleccionar la seccion a administrar

2-Aplicar acciones

3-Actualizar registros

Datos del administrador

Campo a administrar

Acciones

Cancelar operación



34

Reportes

1-Seleccionar categorías de productos

2-Generar reportes administrativos


Acción de generar reportes

Cancelaroperación

Caso de uso: GestionarUsuario

Registrar Usuario

1-Registrar usuario

2-Completar los datos

3-Almacenar usuario

Pedido de registro

Datos verificados

Cancelar operación



35

Gestionar Usuario

1-Buscar usuario a actualizar


2-Buscar usuario a elminar

4-Actualizar o eliminar usuario

Informacion de usuario

Si no actualiza

Inoformacion de usuario

Iniciarnuevamente

Cancelar operacion

Caso de uso: AccesoSistema

1-Capturar los datos

2-Verificar los datos

3-Asignar menu de privilegios

4-Rechazar el acceso al sistema

Datos capturados

Datos válidosCancelar

operaciónDatos no válidos

Datos usuario

5-Entrar al sistema

Perfil de usuario



36

3.1.2 Modelado del dominio del problema

3.3.2.1 Identificación de clases

Usuario: La clase usuario contendrá 4 tipos de usuario:

o _Administrador

o _Empleado

o _Cliente

o _GerenteGeneral

Descuento: Encargada de generar los descuentos de ofertas que pueden ser

aplicados.

Categoria: Las categorías deben estar definidas para los productos.

Producto: El producto para realizar ventas.

DetalleCompra: Los detalles de las compras con funciones de agregar,

modificar y cancelar producto.

CabeceraVenta: La suma de los detalles de las compras, es el carrito de

compra.

Noticias: Registro de noticias, anuncios.

Página: Clase necesaria para crear artículos de productos y contenido de los

mismos dentro del sistema VENTRIX.



37

3.3.3.2 Identificación de asociaciones

Un usuario _Administrador puede crear de cero a muchas promociones para las ventas.

Un usuario _Administrador puede crear muchas noticias de compras para las ventas

Un usuario _Administrador puede crear varias páginas de productos dentro del sistema.

Un usuario _Administrado, _Empleado y _Cliente puede contener muchas CabeceraVenta

Un usuario _Cliente puede aplicar a muchos descuentos

Un una CabeceraVenta puede contener muchos detalle compra

Un DetalleCompra puede contener muchos productos

M 1

1 M

Usuario:

_Administrador

Noticia

Usuario:

_Administrador

Pagina

Usuario: _Administrador,

_Empleado _Cliente

CabeceraVenta

Usuario:

_Cliente

Descuento

CabeceraVenta DetalleCompra

Producto DetalleCompra

1 0..M

1 M

1 M

1 M

Usuario:

_Administrador

Promociones 1 0..M



38

Una clase categoría puede contener muchos productos.

3.3.3.3 Identificación de atributos

Categoria Producto 1 M



39



40

3.3.3.4 Diagrama de clases con asociaciones



41

3.4 REQUERIMENTOS NO FUNCIONALES

Sistema: VENTRIX Página: 1 de: 3

Analistas: Brenda S, Jose C Fecha: Fecha: 26 de mayo de 2012

Requisito de Usuario

Especificación Proceso: Entorno del sistema

1.1 Función: El sistema debe de funcionar sobre un servidor web dado que es un sistema en línea




Especificación Proceso: Funcionamiento del sistema

2.1 Función:

El administrador es el único que puede acceder a todas las secciones del sistema

Es necesario agregar esta medida de seguridad para evitar alguna clase de negligencia.




Especificación Proceso: Funcionamiento del sistema

3.1 Función:

El gerente es el único que puede ver los reportes gerenciales

Es necesario agregar esta medida de seguridad para que analice y decida si es necesaria una acción concreta sobre el sistema o la empresa.



42

3.5 MATRIZ DE COMPONENTES

Actividades

Recursos de Hardware y Redes Recursos Software Recursos de

Datos

Productos de

Información Equipos Medios Programas Procedimiento

Entrada Terminales de usuario

LAN/INTERNET Teclado. Ratón.


Informes de pedidos de

compras

Fichas de Información de productos

y cliente dentro de la

empresa

Reportes de compras y productos

Procedimientos/procesamiento Servidor Web

LAN CPU


Formularios de compras

Base de datos del sistema.

-

Salida Terminales

de usuario e impresor

Pantallas e informes impresos

en papel


Generación de informes de compras y reportes.


Reportes de compras y productos

Almacenamiento

Servidor Web,

unidades de disco

Disco duro del servidor

USB MySQL 5.4 -


Base de datos y respaldo de

base de datos.

Control

Servidor Web y

terminales de usuario

LAN, Formulario de ingresos de

usuario al sistema


Solicitud de claves para

ingresar


Control de actividades

realizadas por los usuarios



43

CAPÍTULO IV ANALISIS


Realizar el análisis correspondiente para determinar la

solución.



44

4.1 OBJETIVOS DEL SISTEMA

4.1.1 Objetivo general

Utilizar la información generada por los procesos que sean de interés para

la venta de productos en línea y así poder desarrollar una aproximación para desarrollar

un prototipo como propuesta de un sistema llamado VENTRIX e-comerse que en su

versión final se pretende que realice las gestiones necesarias para que un clienta pueda

comprar en línea productos sin necesidad de estar presente físicamente en el

establecimiento, el sistema permitirá registrar el flujo de datos creado a partir del

procesamiento de compras online por parte del cliente para utilizarlos en el registro de

pedidos, actualización de inventarios y reportes administrativos para gerencia entre

otros.

4.1.2 Objetivo específico

1. Hacer un análisis de los procesos actuales que se llevan a cabo dentro de la

empresa para conocer su funcionamiento, detalles, requerimientos y registros

que sean necesarios para la creación de un sistema informático.

2. Determinar cuáles son las necesidades técnicas, tecnologías de documentos y

restricciones para el desarrollo del sistema.

3. Crear una base de datos como resultado de la aplicación del proceso de

normalización que contenga los campos necesarios que sean requeridos por el

sistema en donde se almacenara toda la información introducida o generada

por el sistema.



45

4.2 ANALISIS

4.2.1 Arquitectura de clases

4.2.1.1 Identificación de clases según estereotipos

Bordes/fronteras Entidad Control

Interfaz de acceso

Ficha usuarios

Gestor de acceso

4.2.1.2 Clases según casos de uso

Caso de uso: AccesoSistema

Ficha de usuarios

Interfaz de acceso Validar usuario

Interfaz principal

Bordes/Frontera ControlEntidad

Otorgar permisos



46

Caso de uso: Registro de usuarios del sistema

Bordes/Frontera Control

Ficha de usuario

Interfaz de registro de usuario Consultar

producto

Ficha de empleado

Ficha de cliente

Interfaz de asignaciones de cliente

Interfaz de administración de usuario

Entidad

Interfaz de asignaciones para usuario



47

Caso de uso: Administrar el sistema


Ficha administrativa general

Interfaz de administracion Gestor de Administración

del sistema

Ficha administrativa de usuario

Ficha administrativa de datos de publicidad

Ficha administrativa de datos De noticias

Interfaz de administración de usuario

Interfaz de administración de publicidad

Interfaz de administración de noticias

Entidad

Caso de uso: Ventas


Ficha de cliente

Interfaz de perfil de cliente Gestor de Ficha de

venta

Ficha De datos de compra

Ficha de datos de producto

Ficha de datos de pago

Interfaz de compra

Interfaz de pago de compra

Entidad



48

Caso de uso: Gestión de inventarios


Ficha de productos

Interfaz administrativa de productos Gestor de ficha de

inventario

Ficha de categorias

Ficha de descuentos

Interfaz administrativa de categorias

Entidad

Interfaz administrativa de descuentos

Caso de uso: Generación de reportes


Ficha administrativa de gestión de reportes

Interfaz administrativa de reportes Gestor de ficha de

gestión de reportes

Ficha administrativa de reportes

Ficha administrativa de generación de reportes

Interfaz administrativa de consulta de reportes

Entidad

Interfaz administrativa de generación de reportes



49

4.2.1.4 Diagramas de secuencia.

Los diagramas de secuencia de diseño fueron quitados en la instructora no obstante el

grupo ya los tenía hecho, pero no así los diagramas del análisis por tanto decidimos

mostrar los diagramas de diseño y no los de análisis.

4.2.1.4 Diagramas de colaboración

Los diagramas de colaboración no se realizaron debido a que alcanzamos el límite de

tiempo para el análisis del desarrollo del sistema.

4.2.1.5 Identificación de atributos de bases de datos



50

4.2.1.6 Modelo relacional de bases de datos



51

4.2.1.7 Seguridad del sistema a nivel de capas

Las capas estarán virtual izadas en un mismo servidor pero en máquinas virtuales distintas

para mayor seguridad.

CAPAS DESCRIPCION LOCALIZACION

CAPA INTERFAZ

Interfaz de acceso

Esta interfaz permitirá el ingreso del usuario al sistema

Capa disponible a nivel de usuario del sistema , usaremos un Servidor compartido Apache2

CAPA DE DATOS

Gestor de base de datos

Es el administrador de la base de datos quien devolverá respuestas respecto a las peticiones solicitadas por un usuario

Se usara un Servidor compartido MySQL

clsGestorBD

Es una clase que gestionara la conexión a la base de datos, y verificara los datos ingresados

CAPA DE PROCESOS

clsAcceso

Es una clase que verifica si los datos ingresados son los necesarios para poder ingresar al sistema

Estara compartida con el servidor mysql y Apache2



52

4.2.1.8 Matriz PCES

PROBLEMA/

OPORTUNIDAD CAUSA EFECTO SOLUCION

Los clientes no conocen los descuentos ni ofertas nuevas

Falta de información.

El cliente puede no comprar.

Implementar un sistema de noticias para anuncios de publicidad.

No hay información específica acerca de los clientes.

No existe una base de datos.

Se desconoce muchos detalles de su información.

Crear una base de datos dentro del sistema.

El control actual de compras es poco detallado

Se lleva el control en Excel.

La búsqueda de información es poco eficiente.

Implementar un control especializado dentro del sistema.

No hay información acerca de reportes de productos.

No existe un control

No se puede consultar esa información.

Implementar un módulo que realice la generación de reportes.



53

4.2.2 Diagrama jerárquico del sistema

Sistema de Ventas online VENTRIX (Menú Principal)

Mantenimientos (Catálogos)

Procesos (Operación)

Reportes (Consultas)

Usuarios

Ventas

Perfiles

Productos

Categorias

Descuentos

Noticias

Ficha clientes

Carrito de compras

Publicidad

Productos

Acceso al sistema

Salir

Cerrar sesión

Ventas



54

CAPÍTULO V FASE DE DISEÑO


Obtener la información referente al negocio así como los procesos

que se realizan actualmente para las ventas de productos.



55

5.1 ESPECIFICACION DE LAS SOLUCIONES ALTERNATIVAS

CARACTERISTICA

S CANDIDATA 1 CANDIDATA 2 CANDIDATA 3

Sistema informático (Prototipo no funcional)

- El prototipo no funcional solo serán las vistas de las pantallas.

- El lenguaje de programación será php y java.


- El lenguaje de programación será asp y html.


- El lenguaje de programación será php, html y python.

Ventajas

- Sistema operativo libre o

gratuito. - Fácil acceso a la información. - Programación sencilla y liviana. - Licencias completamente gratis.

- Programación sencilla pero

requiere más recursos que la candidata uno para programación.

- Licencia de desarrollo no gratuita.

- Sistema operativo libre o

gratuito. - Fácil acceso a la

información. - Programación sencilla y

liviana. - Licencias completamente

gratis.

Herramientas de aplicaciones de software necesario

- PHP - MySQL 5.1 - JAVA (IDE Netbeans 5.5.1)

- Visual ASP (Visual studio 2011) - SQL Server 2008

- PHP - Python - MySQL 5.1

Métodos de proceso de datos

- Servidor Web. - Terminales de usuario



Dispositivos de salida

- Pantalla. - Impresiones. - Archivos .Pdf, .Xls,

- Pantalla. - Impresiones. - Archivos .Pdf, .Xls, .Doc.

- Pantalla. - Impresiones. - Archivos .Pdf

Dispositivos de - Teclado. - Teclado. - Teclado.



56

entrada - Ratón. - Ratón. - Ratón.

Dispositivos de almacenamiento

- Disco duro. - CD. - DVD.

- Disco duro. - CD. - DVD.

- -Disco duro. - -CD - -DV.

5.2 ANALISIS DE LA VIABILIDAD DE LAS SOLUCIONES ALTERNATIVAS

CRITERIOS DE

VIABILIDAD PESO ALTERNATIVA 1 ALTERNATIVA 2 ALTERNATIVA 3

Viabilidad Operativa 40% Puntaje = 40 Puntaje = 30 Puntaje = 35

Viabilidad Técnica 25% Puntaje = 25 Puntaje = 25 Puntaje = 25

Viabilidad Económica 25% Puntaje = 25 Puntaje = 10 Puntaje = 25

Viabilidad Calendario 10% Puntaje = 10 Puntaje = 6 Puntaje = 8

Totales 100% Puntaje = 100 Puntaje = 71 Puntaje = 93



57

5.3 DETERMINACION DE DISEÑO DE LA PROPUESTA

A partir de las alternativas que proponemos y su análisis de viabilidad la solución

seleccionada es la candidata 1, debido a que cumple con las siguientes condiciones:

Los servicios contratados para el almacenamiento de los datos es gratuito y

puede funcionar sin licencia.

La inversión de equipos y licencias es mínima.

Menor tiempo para su desarrollo e implantación.

La calendarización se aria más rápida por dominar los lenguajes a utilizar y su

complejidad.

5.4 JUSTIFICACION TECNICA DE LA SOLUCION

ESTUDIO DE LA VIABILIDAD TÉCNICA:

HARDWARE.

El equipo con el que cuenta la empresa OPTICA LA ECONOMICA, se describe a

continuación:

NOMBRE PC

MARCA,

MODELO

CARACTERÍSTICAS

(PROCESADOR/

DISCO/MEMORIA)

TIPO MARCA UPS Y

MODELO

BLANCA

MEJIA

CLON PIV 3.2 GHz /80 GB /1.5 GB DESKTOP TRIPPLITE/550U

SOFTWARE.

Poseen licencias tanto de Sistema Operativos de Windows XP, Office 2003 y 2007. Estos

datos fueron obtenidos del estudio realizado dentro de la empresa y entre las



58

herramientas disponibles con las que cuentan para el desarrollo de nuestro sistema se

encuentran:

Sistema Operativo de las PC de Producción: Windows XP Profesional.

Software de Ofimática: Office 2007 y Acrobat Reader.

Antivirus: Avast 4.8 Profesional edition.

Gestor de Bases de Datos: MySQL.

RECURSO HUMANO.

CANTIDAD DE PERSONAS CARGO

1 Empleado técnico de mantenimiento y soporte

externo.

TÉCNICAS Y HERRAMIENTAS.

Para el desarrollo del proyecto de “VENTRIX” se tienen las siguientes técnicas y

herramientas:

Ciclo de Vida del Desarrollo de Sistemas.

Enfoque de Sistemas.

Técnicas de modelado de objetos y casos de uso

Técnicas de análisis y diseño orientado a objetos.

Técnica de recolección de datos Entrevista y Cuestionarios.

ESTUDIO DE LA VIABILIDAD ECONOMICA:



59

RECURSOS TECNOLÓGICOS.

INVERSIÓN EN EQUIPO EXISTENTE

EQUIPO CARACTERÍSTICAS (PROCESADOR/

DISCO/MEMORIA)

COSTO

($)

PC1 DE RESPALDO Pentium IV 1.5 GHz / 40 GB / 1 GBRAM 300.00

PC2 DE SERVIDOR Intel core2 e8500,3200 MHz / 160 GB / 2 GB 320.00

PC3 DE CLIENTE Intel 2,400 MHz. / 40 GB / 512 MB 300.00

Epson LX300-2II. Matricial.

Velocidad de impresión: 3 páginas por minuto

B/N. 254.00

TOTAL ($): 1174.00

DEPRECIACIÓN DE EQUIPO.

Para la determinación de la depreciación de equipo se hará uso del método de la línea

recta, obteniéndose mediante la fórmula:

Depreciación= Inversión / Vida útil fiscal.

Dónde:

Inversión = Costo total del equipo.

Vida útil fiscal = 3 años para equipo existente y 5 años para equipo nuevo.

Inversión (equipo existente) = $ 1,174.00

Depreciación (equipo existente) = $1,174 / 3 años = $ 391.33 anual

$391.33 / 12 meses= $ 32.61 mensual.

Mensual Inversión (equipo nuevo) = $ 24.00

Depreciación (equipo nuevo) = $ 24 / 5 años = $ 4.80 anual



60

4.80 / 12 = $ 0.40 mensual.

COSTOS DE INVERSION

INVERSIÓN EN EQUIPO QUE SE VA ADQUIRIR PERIFÉRICOS

NOMBRE CANTIDAD PRECIO UNITARIO

($)

TOTAL ($)

Memoria Flash 2 12 24

TOTAL ($): 24

COSTOS DE RECURSO TECNOLÓGICO

RUBRO COSTO

MENSUAL ($)

CANTIDAD

DE MESES

TOTAL

($)

Depreciación del equipo existente. 32.61 2 65.22

Inversión en equipo nuevo. 24 - 24

Depreciación de equipo nuevo. 0.40 2 0.80

TOTAL ($): 90.02

COSTOS DE OPERACION ANUALES

Computadora (Energía eléctrica) $ 360.00

Hojas de Papel $ 3.12

Tinta para impresora matricial $ 4.99

TOTAL ($): $ 367.92

USO INFORMATICO

Horas de Trabajo $ 716.00 c/u

SUMINISTROS Y GASTOS

Personal de Capacitación (1 semana x 2 personas) $ 235 .00

Transporte y alimento $ 40.00



61

Computadora $ 74.00

TOTAL ($): $ 3216.20

COSTOS DE DESARROLLO

PERSONAL

2 Analistas $ 1433.60

2 Programadores $ 1433.60

BENEFICIOS DE INVERSION

OPERACIONALES

Individual Beneficio anual

Hacer las planillas por el contador (el sistema

realizara las planillas, el contador solo deberá

firmarlas) x 12 meses

$ 185 $ 2220.00

TOTAL ($): $ 2220.00

NOMBRE AÑO 0 AÑO 1 AÑO 2 AÑO 3 AÑO 4 AÑO 5

Costo de Análisis -3216.20

Costo de

Operación

-367.92 -367.92 -367.92 -367.92 -367.92

Factor de

Descuento 12%

1 0.893 0.797 0.712 0.636 0.567

Costo de Tiempo

Ajustado

-328.55 -293.23 -261.96 -234.00 -208.61

Costos

Acumulados

-3216.20 -3544.75 -3837.98 - 4099.94 -4333.94 -4542.58



62

Beneficios

Obtenidos

2220.00 2220.00 2220.00 2220.00 2220.00

Factor de

Descuento 12%

1 0.893 0.797 0.712 0.636 0.567

Beneficio de

Tiempo Ajustado

1982.46 1769.34 1580.64 1411.92 1258.79

Beneficios

Acumulados

0.00 1982.46 3751.80 5332.44 6744.36 8003.10

Beneficio - Costo -3216.20 -1562.29 - 86.18 1232.10 2410.42 3460.42

ESTUDIO DE LA VIABILIDAD OPERATIVA:

De acuerdo a los resultados obtenidos en las entrevistas con el dueño de la óptica se

puede evidenciar la necesidad y el interés por parte de los usuarios para mantener la

competencia con las demás empresas y llevar a cabo el desarrollo e implementación del

sistema.

Volúmenes de Datos

Ya que el sistema nuevo será desarrollado en un ambiente cliente-servidor se pretende

que la base de datos y el programa este instalado en el servidor de operación con el

tamaño del disco duro es de 160 GB en su totalidad, 2 GB de Memoria RAM además se

posee 2 servidores y se espera usar el otro como respaldo del primero para cumplir las 3

capas. A continuación se detalla los programas a ser instalados al servidor con su

respectivo tamaño de almacenamiento en el disco

PROGRAMAS NECESARIOS EN DISCO

Sistema Operativo: Linux Debian 20GB



63

Base de Datos: MySQL 3 GB

Lenguaje de Programación: Php, Java 5 GB

Offimática: Libreoffice 1 GB

Gestor de Base de Datos: MySQL 1 GB

TOTAL 30 GB

El espacio que ocupara la Nueva aplicación no se coloca porque se estima que no

superara los 100 MB por lo cual se considera depreciable.

En Base al tamaño de archivos que se almacena en el servidor se detallan a

continuación:

Archivos Maestros (45 registros)X mes X 43 Bytes

Planillas de empleados(100 registros) X mes X44 bytes

Reportes de empleados (50 registros) X mes X 25 bytes

Registros Mes Bytes Total en MB

100 20 44 88,000

50 20 25 25,000

45 20 43 38,700

Total Espacio Necesario 151,700

Con esto determinamos el tamaño de los archivos a almacenar mensualmente por la

base de datos es:



64

151,700 bytes equivalente a MB en: 162 MB por mes esto en años seria 1.94 GB que

equivale a 2 GB por año

Por lo tanto:

Si el tamaño del disco duro es de 160 GB y restamos el almacenamiento de software al

servidor y los registros de la base de datos tenemos que:

Disco de 160 GB – (21 GB de software necesarios + 2 GB de almacenamiento por

año)

160 – 23 = 137 GB de espacio disponible

Quedando en espacio de almacenamiento de 137 GB donde dispone de un 85 % libre de

espacio en el servidor.

Tiempo de Repuesta del Nuevo Sistema.

El tiempo de repuesta de los proveedores es en promedio de 3 horas. En el sistema se

espera que se implemente un módulo agregado para su versión final que envía un

correo a todos los proveedores el tiempo de respuesta sea menor ya que por

competencia los proveedores trataran de ser los primeros en enviar su cotización del

producto teniendo una disminución en el tiempo de repuesta de aproximadamente una

hora por petición.

Haciendo los cálculos de 100 peticiones mes nos deja los resultados que se ahorran 100

horas al mes dando un total de 1,200 horas al año equivaliendo esto 50 días al año.

Este ahorro generado en días no se verá reflejado en términos monetarios en efectivo,

sino que este tiempo podrá ser redistribuido para apoyar otras actividades que

beneficien el desarrollo del trabajo del departamento.



65

Resistencia al Cambio

Se espera que el Nuevo Sistema no tenga resistencia al cambio. Por ser un sistema que

es de bajo impacto para los empleados, solo se les dará una pequeña.

5.5 ALCANCES Y LIMITACIONES DE LA APLICACION

El sistema VENTRIX se desarrollara en Zend Studio utilizando esta herramienta bajo LINUX.

El sistema VENTRIX incluirá una página principal con información relacionada a productos

de la empresa, banners, imágenes, etc. y varias páginas más como enlaces dentro del

servidor conteniendo información relacionada a la empresa, inicio de sesión de usuario,

página de ventas, productos por categorías, carrito de compra para que el usuario pueda

comprar y una página de contáctenos.

Los módulos que se implementaran en el sistema son 4:

Módulo de Usuarios: Controlara quien puede ingresar al sistema y los permisos

que este usuario posee.

Módulo de Ventas: Podrá gestionar las tareas de compra respecto a los clientes.

Módulo de Inventarios: Podrá mostrar y gestionar el almacén de la óptica.

Módulo de Administración del Sistema: Se podrán administrar usuarios, generar

reportes, notificarles ofertas vía email, de nuevos productos y promociones.

El sistema está dirigido a usuarios externos (Clientes) e internos (Empleados y

administradores) para el cual el administrador puede gestionar los módulos del sistema y

administrar las opciones del sistema.



66

5.6 Diseño de la arquitectura

5.6.1 Modelos de casos de uso de diseño

5.6.1.1 Identificación de casos de uso de diseño

Acceso al sistema

Administrar el sistema

Ventas

Gestión de inventarios

Generación de reportes

5.6.1.1 Diagramas de casos de uso de diseño

Caso de uso: Acceso al sistema

Diagrama: Acceso al sistema

System

Administrador

Cliente

Empleado

Gerente General

ValidarUsuario

CargarPermiso

AutentificarAdministrador

<<include>>

<<include>>



67

Caso de uso: Registro de usuarios del sistema

Diagrama: Registro de usuarios del sistema

Caso de uso: Administrar el sistema

Diagrama: Administrador del sitio

System

RegistroUsuario

Gerente General

Cliente

Empleado

Administrador

RegistroCliente

DefinirPerfil

AdministrarUsuarios

System

Administrador

Administrar noticias

Enviar E-mails de publicidad

Generar / Bitacora

Reiniciar contraseñas



68

Caso de uso: Ventas

Diagrama: Venta

System

RegistrarCliente

GenerarReporteVentas

ActualizaCliente

ConsultarCliente

ConsultarCompra

ManejarDescuentos

Cliente

Empleado

Gerente General

Administrador

ConsultarProducto

RealizarPago

Actualizar base de datos

RegistrarCompra

NotificarCompraEmitirComprobanteEnvio

<<include>>



69

Caso de uso: Gestión de inventarios

Diagrama: Administración de inventarios

Caso de uso: Generación de reportes

Diagrama: Caso de uso para la generación de reportes

System

Administrador

AccesoSistema

ActualizaCliente

ConsultarCliente

ConsultarProducto

ConsultarCompra

ManejarDescuentos

ConsultaCategorias

RegistrarCategoriasProductos

System

Gerente General

Administrador

AccesoSistema

GenerarReporteVentas

ConsultarReportesAdministrativos



70

5.6.1.3 Diagramas de secuencia de diseño

Acceso administrador



71

Registrar cliente



72

Actualizar cliente

Consultar cliente



73

Registrar categoría

Actualizar categoría



74

Consultar categoría

Eliminar categoría



75

Registrar producto



76

Actualizar producto

Consultar producto



77

Eliminar producto

Generar reportes



78

Registrar descuento y tipo de cliente



79

Registrar compra



80

Consultar compra



81

Pagar con paypall



82

Detalle de pagar con paypall



83

Notificar compra via e-mail al cliente y a la tienda

Emitir comprobante de envió



84

Actualizar almacen



85

Registrar noticias

Consultar noticias



86

Modificar noticias

Eliminar noticia



87

Reiniciar contraseñas



88

5.6.1.4 Diagrama de clases

5.6.1.4.1 Identificación de clases de diseño



89

5.6.1.4.2 Diagramas de clases con asociaciones y atributos



90

5.6.1.5 Interfaz gráfica

5.6.1.5.1 Entrada

Pantalla de inicio de sesión y portada principal:

El inicio de sesión se realiza en el panel izquierdo del sistema:



91

Formulario de contacto:

Formulario administrativo agregar producto:



92

5.6.1.5.2 Salida

Formulario pago de producto:

Formulario catálogos de lentes:



93

CAPÍTULO VI FASE DE IMPLEMENTACION


Realizar el análisis correspondiente para determinar la solución.



94

6.1 REQUERIMENTOS DE IMPLEMENTACION

Hardware a utilizar

Optimo:

Procesador a 2.4Ghz

1Gb en RAM

Disco duro de 10Gb o superior

monitor SVGA

Teclado y mouse

Estabilizador o UPS

Mínimo:

Procesador a 1.6Ghz

256Mb en RAM

Disco duro de 5Gb

Monitor SVGA

Teclado

Estabilizador o UPS

Software a utilizar

Sistema Operativo: LINUX

Lenguaje de Programación: PHP

Gestor de Base de Datos: MYSQL



95

6.2 DIAGRAMA DE COMPONENTES

Paginas PHP

CAPA DE PRESENTACIÓN

clsBDManager

Invent

CAPA DE DATOS

Clases en php

CAPA LÓGICA



96

6.3 DISTRIBUCION DEL SISTEMA

:Terminal:Servidor

:Consola

Velocidad de los procesadores = 3.2 GHz (2)

Memoria= 2 Gb.

Paginas PHP

Base de Datos:

clsBDManager

Páginas PHP

ClsAdministrarPermisos

ClsEmitirFactura

ClsGenerarReportes

ClsManttAcceso

ClsManttProductos

ClsMaestroDetalleCliente

dbVENTRIX

6.5 PRUEBAS DE ERRORES

6.5.1 Pruebas de unidad

Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada

componente individualmente una vez que ha sido codificado.

Las pruebas de unidad es un proceso para probar los subprogramas, las subrutinas, los

procedimientos individuales o las clases en un programa. Es decir, es mejor probar

primero los bloques desarrollados más pequeños del programa, que inicialmente probar el

software en su totalidad. Las motivaciones para hacer esto son tres. Primera, las pruebas

de unidad son una manera de manejar los elementos de prueba combinados, puesto que

se centra la atención inicialmente en unidades más pequeñas del programa. En segundo

lugar, la prueba de una unidad facilita la tarea de eliminar errores (el proceso de

establecer claramente y de corregir un error descubierto), puesto que, cuando se

encuentra un error, se sabe que existe en un módulo particular. Finalmente, las pruebas

de unidad introducen paralelismo en el proceso de pruebas del software presentándose la

oportunidad de probar los múltiples módulos simultáneamente.



97

Se necesita dos tipos de información al diseñar los casos de prueba para una prueba de

unidad: la especificación para el módulo y el código fuente del módulo. La especificación

define típicamente los parámetros de entrada y de salida del módulo y su función.

Dentro del sistema pretendemos desarrollar las pruebas de unidad en base a la teoría

documental anteriormente mencionada.

6.5.2 Pruebas de integración

El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los

distintos componentes una vez que han sido probados unitariamente con el fin de

comprobar que interactúan correctamente a través de sus interfaces, tanto internas como

externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales

especificados en las verificaciones correspondientes.

Los tipos fundamentales de integración son los siguientes:

Integración incremental: se combina el siguiente componente que se debe probar

con el conjunto de componentes que ya están probados y se va incrementando

progresivamente el número de componentes a probar.

Integración no incremental: se prueba cada componente por separado y

posteriormente se integran todos de una vez realizando las pruebas pertinentes.

Dentro del sistema pretendemos desarrollar las pruebas de integración en base a la teoría


6.5.3 Pruebas del sistema

Las pruebas de sistema buscan discrepancias entre el programa y sus objetivos o

requerimientos, enfocándose en los errores hechos durante la transición del proceso al

diseñar la especificación funcional. Esto hace a las pruebas de sistema un proceso vital de

pruebas, ya que en términos del producto, número de errores hechos, y severidad de esos



98

errores, es un paso en el ciclo de desarrollo generalmente propenso a la mayoría de los

errores.

Las pruebas de sistema no son procesos para probar las funciones del sistema o del

programa completo, porque ésta sería redundante con el proceso de las pruebas

funcionales. Las pruebas del sistema tienen un propósito particular: para comparar el

sistema o el programa con sus objetivos originales (Requerimientos funcionales y no

funcionales). Dado este propósito, se presentan dos implicaciones

Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la

prueba del sistema es el proceso de procurar demostrar cómo el programa, en su

totalidad, no resuelve sus objetivos o requerimientos.

Las pruebas de sistema, por definición, son imposibles si no están los requerimientos por

escrito, mensurables para el producto.

Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema

comprobando la integración del sistema de información globalmente, verificando el

funcionamiento correcto de las interfaces entre los distintos subsistemas que lo

componen y con el resto de sistemas de información con los que se comunica.

Son pruebas de integración del sistema de información completo, y permiten probar el

sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las

especificaciones funcionales y técnicas se cumplen. Dan una visión muy similar a su

comportamiento en el entorno de producción.

Dentro del sistema pretendemos realizar las pruebas del sistema en base a la teoría




99

6.5.4 Pruebas de stress

Una prueba de stress es aquella que forsa al sistema al máximo punto para poder medir

sus capacidades y las condiciones en las cuales trabaja realizando una cantidad definida

de peticiones y procesos.

La prueba de stress para este sistema se realizó utilizando el software JMeter

mencionado anteriormente, configurándolo adecuadamente utilizando el árbol de

configuración de la Figura 5.1, para que se llevaran a cabo 6 peticiones por usuario, las

cuales estaban dadas en el siguiente orden:

Logeo en el sistema, que consta de ingresar el ID y el NIP y desplegar la página de

bienvenida con los estrenos, artículos más populares, entre otros.

Desplegar el catálogo de películas

Ver la información detallada de una película

Desplegar el catálogo de libros

Ver la información detallada de un libro

Salir del sistema

Dentro del sistema pretendemos realizar las pruebas del stress en base a la teoría


6.6 PLAN DE IMPLANTACION

6.6.1 Capacitación de usuarios

La capacitación a usuarios se realizara por un periodo de tres días, durante el almuerzo de

doce del mediodía a una de la tarde, en ellos se orientara la forma de utilizar el sistema en

cuanto a administración, cliente y otros tópicos.



100

6.7 PLAN DE MANTENIMIENTO

6.7.1 Preventivo

Para iniciar el mantenimiento de este software se le preguntara al usuario lo siguiente:

1. ¿Ha ocurrido un error en el momento de carga?

2. ¿Los datos del software no cargaron normalmente?

3. ¿Existió algún problema en el hardware o algún dispositivo del sistema en el

momento del error?

4. ¿Existió un error al momento de cargar una ventana del software?

5. ¿Existía algún programa externo abierto a la hora que ocurrió el error?

6. ¿El programa no dio los datos esperados?

7. Otros.

De acuerdo al problema ocurrido se realizara un mantenimiento correctivo programado o

no programado.

Error 1. Ha ocurrido un error en el momento de carga.

En caso de haber ocurrido un error en el momento de carga se acudirá a realizar un

mantenimiento correctivo no programado (Se reparara la falla inmediatamente) a la base

de Datos del software ya que el problema principal detectado al momento de cargar el

software son errores ocurridos en las bases de datos.

Para hacer una revisión exhaustiva de la base de datos se realizaran los siguientes pasos.

Paso 1. Se creara dos archivos de recuperación, uno del software con el error y

otro archivo anterior donde el software trabajaba normalmente.

Paso 2. Revisión de la Base de datos y del Servidor del software, en caso de que

existió un error en algún proceso anterior que imposibilitó el trabajo de este

posteriormente.

Paso 3. Se revisara la integridad y seguridad de la base de datos en caso de haber

existido algún problema de robo o hurto de datos.



101

Paso 4. Se reparara la base de datos del software.

En caso de ser un problema de integridad y seguridad de la base de datos se realizara un

mantenimiento evolutivo al software para eliminar los bugs que dañaron la integridad y

seguridad de la base de datos.

Paso 5. Se realizaran las pruebas necesarias de mantenimiento para asegurar que

el software está libre de ese error.

Paso 6. Se recuperara la información de la base de datos, si es posible se

recuperara los datos donde existió el error y será reparado.

Paso 7. Se dará asistencia a los usuarios.

Error 2. Los datos del software no cargaron normalmente.

En caso de haber ocurrido este error se tomara el mismo procedimiento que el del

“ERROR 1.” Ya que estos errores suelen ocurrir en la propia base de datos.

En todo caso de no ser un error en la base de datos sino en la aplicación en si se realizará

un mantenimiento evolutivo al software para eliminar los bugs que están causando dicho

problema

Error 3. Existió algún problema de hardware en el momento que se generó un problema.

Este error muy a menudo ocurre por incompatibilidad de hardware con el sistema y para

detectar y reparar el problema se realizaran los siguientes pasos.

Paso 1. Se creara dos archivos de recuperación, uno del software con el error y

otro archivo anterior donde el software trabajaba normalmente.

Paso 2. Se hará una revisión de compactibilidad del hardware con respecto al

sistema, para detectar el dispositivo que está generando problemas.

Paso 3. Se le informara al usuario, que hardware está dando problemas con el

software, para que este consulte con su distribuidor de hardware, para su pronta

reparación o cambio, del hardware.



102

Paso 4. Se realizaran las pruebas necesarias de mantenimiento para asegurar que

el software está libre de ese error.

Paso 5. Se recuperara la información de la base de datos, si es posible se

recuperara los datos donde existió el error y será reparado.

Paso 6. Se dará asistencia a los usuarios.

Error 4. Existió un error al momento de cargar una pagina

En caso de haber ocurrido este error se tomara el mismo procedimiento que el del

“ERROR 1.” Ya que estos errores suelen ocurrir en la propia base de datos.

En todo caso, de no ser un error en la base de datos sino en la aplicación en si se realizara

un mantenimiento evolutivo al software para eliminar los bugs que está causando dicho

problema.

Error 5. El software no dio los datos esperados

La mayoría de veces que ocurre este problema suele ser un error al momento de digitar la

información al software pero en caso de no ser un error así se recurrirá a un

mantenimiento evolutivo del software para reparar los bugs que están generando dicho

problema.

Error 6. Otros.

En caso de existir un error que no se encuentre en la lista de errores que comúnmente

ocurren se hará una investigación exhaustiva del error para luego repararse y se

actualizara la documentación de mantenimiento para futuros soportes que se realicen.

6.7.2 Correctivo

El mantenimiento correctivo se realizara en caso de ocurrir un percance dentro del

sistema y su continuidad laboral en el periodo ordinario que se necesite realizar.



103

6.7.3 Plan de contingencia

El plan de contingencia aún no se ha elaborado, se espera elaborar en la etapa de

implementación del sistema ya que debemos realizar una visita más a las instalaciones

porque este no se había tomado en cuenta y tratamos de realizarlo en base a la

infraestructura y su ambiente que influyan directamente en el sistema e indirectamente

con él.



104

CAPÍTULO VII CONCLUSIONES Y RECOMENDACIONES


Realizar el análisis correspondiente para determinar la solución.



105

7.1 CONCLUSIONES

La planificación para la creación de nuestro sistema de información nos brindó las pautas

necesarias sobre las cuales empezar el desarrollo del proyecto que dio como resultado a

"VENTRIX" (Sistema de Ventas Online).

En la primera etapa es donde definimos los problemas, y las actividades a las que

"VENTRIX" debería darles apoyo. También determinamos los requerimientos de

información que serían necesarios para el funcionamiento del sistema.

Después de evaluar algunas alternativas para el desarrollo del sistema elegimos la

candidata uno ya que era la más adecuada según los estudios que hicimos, en el diseño

del sistema definimos de forma concreta lo que es en sí nuestro sistema definiendo todos

los diagramas de flujo de datos

De nuestro sistema. También se hace una definición concreta de lo que es la base de datos

de "VENTRIX" esto con referencia a las tablas donde se almacenara la información

recolectada en cada interfaz de usuario.

En la parte del soporte del sistema hacemos una declaración de las formas en la que

deberíamos dar soporte a los posibles problemas que puedan ocurrir durante el uso de

“VENTRIX” pero de manera teórica utilizando información documental.



106

7.2 RECOMENDACIONES

Es necesario realizar un verdadero diagnóstico de los conocimientos que el cliente

tiene sobre lo deseado al final del proyecto, ya que es en esta etapa donde se definen

los requerimientos, los cuales si han sido correctamente diagnosticados

proporcionarán seguramente un proyecto exitoso y que ayude en gran medida al

cliente.

Se considera que para la administración de nuestro proyecto la mejor herramienta de

software de planificación es Microsoft Project, ya que cuenta con todas las

características que ayudan a desarrollar una mejor planeación, además de ser la

herramienta que mejor se maneja por el grupo de Ingenieros, proporciona mayor

satisfacción de requerimientos para esta planificación y está disponible dentro del

paquete de Microsoft Office ya requerido durante el desarrollo del proyecto.

Se recomienda hacer uso de las técnicas y herramientas asociadas a la administración

de proyectos a fin de reducir la incertidumbre y asegurar el éxito y satisfacción al

término de todo el proyecto y esto a su vez proporcionará ventaja competitiva en la

organización.

Es necesario para todo proyecto hacer las estimaciones pertinentes a fin de finalizarlo

a tiempo y con los recursos necesarios que han sido asignados por el cliente.



107

7.3 ANEXOS

Manual de instalación

Esta instalación será realizada por un técnico de nuestro equipo para ello es necesario

instalar los siguientes programas:

Apche2

MySQL

Sistema operativo

Es indispensable contar con una conexión a internet.

La manera de instalar el programa será configurar el archivo setting.php de la carpeta del

sistema:

Abrirlo y configurar los siguientes parámetros con la información de su conexión al

servidor de la base de datos:

Una vez configurado VENTRIX puede ver su portal accediendo de manera local como

http://localhost

http://SuIPPublica

http://localhost/

http://suippublica/



108

Gracias por usar VENTRIX.

sistema de ventas en linea subir

Documents