UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

PROYECTO DE GRADO
“SISTEMA WEB DE CONTROL DE PEDIDOS Y VENTAS
CASO: EMPRESA ITSEVEN SOLUCIONES
INFORMÁTICAS INTEGRALES”
PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA
MENCIÓN: INGENIERÍA DE SISTEMAS INFORMÁTICOS

POSTULANTE: GLAUCIA MARIEL ATAHUICHI MAMANI

TUTOR METODOLÓGICO: M.SC. ALDO RAMIRO VALDEZ ALVARADO

ASESOR: LIC. JAVIER HUGO REYES PACHECO

LA PAZ – BOLIVIA
2014
 UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.

LICENCIA DE USO

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
El presente proyecto va dedicado con mucho cariño a mis queridos

padres Edwin Javier y Ana María, que siempre me dieron todo su

apoyo y colaboración incondicional.

 AGRADECIMIENTOS

Agradezco a Dios por la fuerza y salud que me da para seguir

adelante, agradezco a toda mi familia, por el apoyo que me brindo
a lo largo de toda mi vida, e impulsarme a seguir y no rendirme.

A mi Tutor M. Sc. Aldo Ramiro Valdez por la enseñanza y

colaboración brindada en Taller I y Taller II, las cuales me
ayudaron a la conclusión de este proyecto.

A mi Asesor Lic. Javier Hugo Reyes Pacheco, por brindarme su

tiempo, y por guiarme paso a paso durante todo el proceso de Taller
I y Taller II.

Al Gerente Freddy Ramos por otorgarme la oportunidad de

desarrollar el sistema en la empresa ITSeven.

A todos mis amigos y amigas por brindarme la ayuda y apoyarme

en los momentos más difíciles.

Muchas Gracias a todos!!

 RESUMEN

El proyecto “SISTEMA WEB DE CONTROL DE PEDIDOS Y VENTAS”, fue creado

para la empresa ITSeven Soluciones Informáticas Integrales, dicha empresa tiene la

función de realizar venta, mantenimiento y reparación de equipos electrónicos en general.

EL presente proyecto de grado se pretende automatizar los procesos que la empresa realiza

como las ventas y pedidos de productos, la centralización de la información en una base

de datos que permite acceder de manera inmediata a la información de las ventas y pedidos

de productos, ya que estos proceso son de vital importancia para la empresa.

La metodología empleada en el presente proyecto es OpenUP, que brinda un desarrollo

ágil de software orientado a la web dividido en cuatro etapas: Inicio, Elaboración,

Construcción y Transición, cabe desatacar que para un mejor trabajo se fusiona con el uso

de ingeniería web UML-UWE, que es una herramienta comprensible y entendible.

Para el desarrollo del sistema se utilizaron lenguajes como PHP y JavaScript, para la

administración e base de datos es bajo el entorno MySQL, utilizando el servidor Apache

XAMPP.

La medición de calidad del sistema se realizó mediante a la técnica WEBSITE basada en

la NORMAS ISO 9126, que maneja los parámetros de usabilidad, funcionalidad,

confiabilidad, mantenibilidad, portabilidad.

i
 ÍNDICE
CAPÍTULO I
MARCO INTRODUCTORIO

1.1. INTRODUCCIÓN ................................................................................................. 1

1.2. ANTECEDENTES ................................................................................................. 2
1.2.1. ANTECEDENTES DE LA INSTITUCIÓN .......................................................... 2
1.2.2. ANTECEDENTES DE PROYECTOS SIMILARES .................................... 3
1.3. PLANTEAMIENTO DEL PROBLEMA .............................................................. 4
1.3.1. PROBLEMA CENTRAL ...................................................................................... 4
1.3.2. PROBLEMAS SECUNDARIOS ................................................................... 5
1.4. DEFINICIÓN DEL OBJETIVO ............................................................................ 6
1.4.1. OBJETIVO GENERAL ......................................................................................... 6
1.4.2. OBJETIVOS ESPECÍFICOS ......................................................................... 6
1.5. JUSTIFICACIÓN .................................................................................................. 6
1.5.1. JUSTIFICACIÓN ECONÓMICA ......................................................................... 6
1.5.2. JUSTIFICACIÓN SOCIAL ............................................................................ 7
1.5.3. JUSTIFICACIÓN TECNOLÓGICA .............................................................. 8
1.6. ALCANCES Y LIMITES ...................................................................................... 8
1.6.1. ALCANCES ........................................................................................................... 8
1.6.2. LIMITES ......................................................................................................... 9
1.7. APORTES ............................................................................................................ 10
1.7.1. APORTE PRÁCTICO .................................................................................. 10
1.7.2. APORTE TEÓRICO..................................................................................... 10
CAPÍTULO II
MARCO TEÓRICO

1.8. METODOLOGÍA ................................................................................................ 11

2.1. INGENIERÍA DE SOFTWARE .......................................................................... 12
2.1.1. ¿QUÉ ES INGENIERÍA DE SOFTWARE? ....................................................... 12

ii
2.1.2. CICLO DE VIDA DEL SOFTWARE ................................................................. 12
2.1.3. MODELOS DE PROCESO DE SOFTWARE .................................................... 13
2.2. MODELOS DE DESARROLLO DE SOFTWARE ............................................ 14
2.3. MÉTODOS DE DESARROLLO ÁGIL .............................................................. 15
2.4. METODOLOGÍA OPENUP................................................................................ 16
2.4.1. OBJETIVO DE OPENUP .................................................................................... 16
2.4.2. CARACTERÍSTICAS DE OPENUP .................................................................. 17
2.4.3. ELEMENTOS DE OPENUP ............................................................................... 18
2.4.4. ESTRUCTURA DE OPENUP............................................................................. 18
2.4.5. DISCIPLINA DE OPENUP ................................................................................. 19
2.4.6. TAREAS DE OPENUP ....................................................................................... 21
2.4.7. CICLO DE VIDA DE OPENUP ......................................................................... 22
2.4.7.1. INICIO .......................................................................................................... 22
2.4.7.2. ELABORACIÓN .......................................................................................... 23
2.4.7.3. CONSTRUCCIÓN ....................................................................................... 24
2.4.7.4. TRANSICIÓN .............................................................................................. 25
2.4.8. CARACTERÍSTICAS DE UNA APLICACIÓN WEB ...................................... 26
2.5. UWE (UML- Based Web Engineering) ............................................................... 26
2.5.1. CARACTERÍSTICAS UWE ............................................................................... 27
2.5.2. FASES DE UWE ................................................................................................. 27
2.5.2.1. FASE DE ANÁLISIS DE REQUISITOS .................................................... 28
2.5.2.2. FASE DE CONCEPTUAL ........................................................................... 29
2.5.2.3. FASE DE NAVEGACIÓN ........................................................................... 29
2.5.2.4. FASE DE DISEÑO DE PRESENTACIÓN ................................................. 31
2.5.2.5. MODELO DE PROCESO ............................................................................ 33
2.5.3. VENTAJAS UWE ............................................................................................... 33
2.6. CRM (Customer Relationship Management)....................................................... 33
2.6.1. OBJETIVO DE LA CRM .................................................................................... 34
2.6.2. TIPOS DE TECNOLOGÍA CRM ........................................................................ 34
2.6.2.1. INTERACCIÓN CON EL CLIENTE O CRM OPERACIONAL ............... 34
2.6.2.2. CONOCIMIENTO DEL CLIENTE O CRM ANALÍTICO ........................ 35
2.6.2.3. DIFUSIÓN DEL CONOCIMIENTO O CRM COLABORATIVO ............. 35

iii
2.6.3. ARQUITECTURA DE LOS SISTEMAS CRM ................................................. 35
2.6.3.1. CRM ENGINE .............................................................................................. 36
2.6.3.2. SOLUCIONES FRONT - OFFICE .............................................................. 37
2.6.3.3. CRM EN EL BACK OFFICE ...................................................................... 37
2.6.3.4. APLICACIONES DE INTEGRACIÓN EMPRESARIAL PARA CRM .... 37
2.7. ADMINISTRACIÓN DE VENTAS .................................................................... 38
2.7.1. ORIGEN DE LA ADMINISTRACIÓN DE VENTAS ....................................... 38
2.7.2. FASES DEL PROCESO DE VENTA ................................................................. 38
2.8. HERRAMIENTAS DE DESARROLLO DE SOFTWARE ................................ 39
2.8.1. SISTEMA DE GESTOR DE BASE DE DATOS SGBD .................................... 39
2.8.1.1. CLASIFICACIÓN DE LOS SGBD ............................................................. 40
2.8.1.2. BASE DE DATOS “MYSQL” ..................................................................... 40
2.8.2. LENGUAJE DE PROGRAMACIÓN “PHP” ...................................................... 41
2.8.3. JAVASCRIPT ...................................................................................................... 41
2.8.4. AJAX (Asynchronous JavaScript And XML) ..................................................... 42
CAPÍTULO III
MARCO APLICATIVO

3.1. INTRODUCCIÓN ............................................................................................... 43

3.2. INICIO ................................................................................................................. 44
3.2.1. DESCRIPCIÓN DE LOS INTERESADOS DEL SISTEMA ............................. 45
3.2.2. ENTORNO DE USUARIO ................................................................................. 46
3.2.3. DESCRIPCIÓN DEL PRODUCTO .................................................................... 46
3.2.4. REQUISITOS ESPECÍFICOS ............................................................................. 47
3.2.4.1. INTERFAZ DE USUARIO .......................................................................... 47
3.2.4.2. INTERFAZ DE HARDWARE..................................................................... 47
3.3. ELABORACIÓN ................................................................................................. 48
3.3.1. CAPTURA DE REQUERIMIENTOS ................................................................. 48
3.3.2. CASOS DE USO ................................................................................................. 49
3.3.2.1. DESCRIPCIÓN DE ACTORES ................................................................... 49
3.3.2.2. CASO DE USO GENERAL ......................................................................... 50

iv
3.3.2.3. ESPECIFICACIÓN DE CASOS DE USO ................................................... 52
d) GESTIÓN PARA REALIZAR UNA VENTA .................................................... 62
3.3.3. DISEÑO CONCEPTUAL.................................................................................... 71
3.3.3.1. MODELO CONCEPTUAL .......................................................................... 71
3.3.3.2. MODELO FÍSICO ........................................................................................ 72
3.3.4. DISEÑO DE NAVEGACIÓN ............................................................................. 72
3.3.4.1. GESTIÓN DE USUARIO ........................................................................... 73
3.3.4.2. GESTIÓN DE PRODUCTOS ...................................................................... 74
3.3.4.3. GESTIÓN DE PEDIDOS ............................................................................. 74
3.3.4.4. REALIZAR VENTA DE PRODUCTO ....................................................... 75
3.3.4.5. GESTIÓN DEL CLIENTE ........................................................................... 75
3.3.4.6. DIFUSIÓN DE SERVICIOS ........................................................................ 76
3.3.5. DIAGRAMA DE PRESENTACIÓN .................................................................. 76
3.3.5.1. GESTIÓN DE USUARIO ............................................................................ 77
3.3.5.2. GESTIÓN DE PRODUCTOS ...................................................................... 78
3.3.5.3. GESTIÓN DE PEDIDOS ............................................................................. 80
3.3.5.4. REALIZAR VENTA DE PRODUCTO ....................................................... 81
3.3.5.5. GESTIÓN DE CLIENTE ............................................................................. 82
3.3.5.6. DIFUSIÓN DE SERVICIOS OFRECIDOS POR LA EMPRESA .............. 83
3.4. FASE DE CONSTRUCCIÓN.............................................................................. 84
3.4.1. PANTALLAS DE SISTEMA .............................................................................. 84
3.4.2. PRUEBA FUNCIONALES DE SISTEMA ......................................................... 90
3.5. FASE DE TRANSICIÓN .................................................................................... 98
3.5.1. PRUEBAS DE STRESS ...................................................................................... 98
3.5.1.1. LOAD IMPACT ........................................................................................... 99
3.5.2. INSTALACIÓN DEL SISTEMA ...................................................................... 100
3.5.3. CAPACITACIÓN DE USUARIO ..................................................................... 100
CAPÍTULO IV
CALIDAD Y SEGURIDAD

4.1. CALIDAD .......................................................................................................... 101

v
4.1.1. TÉCNICA WEBSITE ISO 9126 ................................................................ 101
4.1.1.1. USABILIDAD ............................................................................................ 101
4.1.1.2. FUNCIONALIDAD ................................................................................... 103
4.1.1.3. CONFIABILIDAD ..................................................................................... 107
4.1.1.4. MANTENIBILIDAD.................................................................................. 108
4.1.1.5. PORTABILIDAD ....................................................................................... 109
4.1.1.6. RESULTADOS .......................................................................................... 109
4.2. SEGURIDAD ..................................................................................................... 110
4.2.1. SEGURIDAD DE BASE DE DATOS .............................................................. 110
CAPÍTULO V
COSTO BENEFICIO

5.1. ESTIMACIÓN DE COSTO BENEFICIO ........................................................ 112

5.2. CALCULO DE COSTO DEL SISTEMA.......................................................... 112
5.2.1. ANÁLISIS DE COSTO ..................................................................................... 113
5.2.2. BENEFICIO ....................................................................................................... 117
5.2.2.1. VALOR ACTUAL NETO (VAN) ............................................................. 117
5.2.2.2. LA TASA INTERNA DE RETORNO TIR ............................................... 119
5.2.2.3. ANÁLISIS DE BENEFICIO/ COSTO ....................................................... 119
6.1. CONCLUSIONES ................................................................................................. 121
6.2. RECOMENDACIONES ........................................................................................ 122

ÍNDICE DE FIGURAS

Figura 2. 1 Áreas de Contenido de OpenUP .................................................................... 16

Figura 2. 2 Organización de los componentes de OpenUP .............................................. 19
Figura 2. 3 Iteraciones del ciclo de vida de OpenUP ....................................................... 20
Figura 2. 4 Ciclo de vida de OpenUP .............................................................................. 22
Figura 2. 5 Vista General de Modelos UWE ................................................................... 28
Figura 2. 6 Modelo de caso de Uso .................................................................................. 28
Figura 2. 7 Diagrama de Contenido ................................................................................. 29
Figura 2. 8 Diagrama de navegación UML...................................................................... 30
Figura 2. 9 Nombre y símbolo de esteriotipos – Modeo de Navegación ........................ 31

vi
Figura 2. 10 Nombre y símbolo de estereotipos – Modelo de Presentación .................... 32
Figura 2. 11 Diseño de Presentación UWE ...................................................................... 32
Figura 2. 12 Arquitectura de las soluciones CRM. .......................................................... 36

Figura 3.1. Diagrama de Caso de Uso General ................................................................ 51

Figura 3.2. Diagrama de Caso de Uso – Gestión de Usuario ........................................... 52
Figura 3. 3. Diagrama de caso de uso – Gestión de Productos ........................................ 55
Figura 3. 4. Diagrama de caso de uso – Gestión de pedidos............................................ 59
Figura 3. 5. Diagrama de caso de uso – Realizar venta ................................................... 62
Figura 3. 6. Diagrama de caso de uso – Gestión de Cliente ............................................ 64
Figura 3. 7. Diagrama de caso de uso – Difusión de servicios ........................................ 68
Figura 3.8. Diseño de clases ....................................................................................... 71
Figura 3.9. Diseño Físico ................................................................................................. 72
Figura 3. 10. Diagrama de Navegación general ............................................................... 73
Figura 3.11. Diagrama de Navegación – Gestión de Usuario .......................................... 73
Figura 3. 12. Diagrama de Navegación – Gestión de Producto ....................................... 74
Figura 3. 13. Diagrama de Navegación – Gestión de Pedidos ......................................... 74
Figura 3. 14. Diagrama de Navegación – Realizar Venta de producto ............................ 75
Figura 3.15. Diagrama de Navegación – Gestión de Cliente ........................................... 75
Figura 3.16. Diagrama de Navegación – Difusión de servicio ........................................ 76
Figura 3.17. Diagrama de Presentación – Inicio .............................................................. 77
Figura 3.18. Diagrama de Presentación – Gestión de Usuario – Lista de Empleados ..... 77
Figura 3.19. Diagrama de Presentación – Gestión de Usuario – Nuevo Empleado......... 78
Figura 3.20. Diagrama de Presentación – Gestión de Producto – Lista de producto ....... 79
Figura 3.21. Diagrama de Presentación – Gestión de Producto – Nuevo Producto......... 79
Figura 3.22. Diagrama de Presentación – Gestión de Pedidos – Lista de Pedidos .......... 80
Figura 3.23. Diagrama de Presentación – Gestión de Pedidos – Realizar un pedido ...... 80
Figura 3.24. Diagrama de Presentación – Realizar Venta – Ingresa datos de cliente ...... 81
Figura 3.25. Diagrama de Presentación – Realizar Venta – selección de producto......... 81
Figura 3.26. Diagrama de Presentación – Realizar Venta – Lista de Ventas................... 82
Figura 3.27. Diagrama de Presentación – Gestión de Cliente – Lista de Clientes ........... 82
Figura 3.28. Diagrama de Presentación – Gestión de Cliente – Modificar datos ............ 83
Figura 3.29. Diagrama de Presentación – Difusión de servicio - Lista............................ 83
Figura 3.30. Diseño de Construcción – Ventana Inicio de Sesión .................................. 84
Figura 3.31. Diseño de Construcción – Pantalla Principal.............................................. 85
Figura 3.32. Diseño de Construcción – Gestión de Usuario ........................................... 85
Figura 3.33. Diseño de Construcción – Registro de nuevo usuario de Usuario.............. 86

vii
Figura 3.34. Diseño de Construcción
Figura 3.35. Diseño de Construcción
Figura 3.36. Diseño de Construcción
Figura 3.37. Diseño de Construcción
Figura 3.38. Diseño de Construcción
Figura 3.39. Diseño de Construcción
Figura 3.40. Diseño de Construcción
Figura 3.41. Diseño de Construcción
– Reporte de usuario ............................................ 86
– Gestión de Productos- Lista de productos ........ 87
– Gestión de Productos- Detalle de Producto...... 88
– Realiza Venta- ingresa datos de cliente ........... 88
– Realiza Venta ................................................... 89
– Realiza Venta ................................................... 89
– Realiza Venta ................................................... 90
– Prueba de stress ................................................ 99

ÍNDICE DE TABLAS
Tabla 3.1 Actividades por Fase de OpenUP .................................................................... 44
Tabla 3.2 Interesados del Sistema ................................................................................ 46
Tabla 3.3 Descripción del Producto ................................................................................. 47
Tabla 3.4 Requerimientos del Sistema ............................................................................. 49
Tabla 3.5 Descripción del Actores del Sistema ............................................................... 50
Tabla 3.6 Autenticación de Usuario ................................................................................. 53
Tabla 3.7 Gestionar cuenta de usuario ............................................................................. 55
Tabla 3.8 Adición de Productos al sistema ...................................................................... 57
Tabla 3.9 Modificar datos de productos ........................................................................... 58
Tabla 3.10 Ver de detalle de productos ............................................................................ 59
Tabla 3.11 Realizar pedido .............................................................................................. 61
Tabla 3.12 Consultar los registros de pedidos ................................................................. 62
Tabla 3.13 Realizar venta de productos .......................................................................... 63
Tabla 3.14 Ingresar nuevo cliente .................................................................................... 65
Tabla 3.15 Actualizar datos de cliente ............................................................................. 66
Tabla 3.16 Generar reportes estadísticos ......................................................................... 67
Tabla 3.17. Ingreso de nuevo servicio que ofrece la empresa ......................................... 69
Tabla 3.18 Modificar Servicio que ofrece la empresa ..................................................... 70
Tabla 3.19 Caso de prueba – Gestión de Usuario ............................................................ 92
Tabla 3.20 Caso de prueba - Gestión de Productos ......................................................... 94
Tabla 3.21 Caso de prueba - Gestión de pedidos ............................................................. 95
Tabla 3.22 Caso de prueba - Realizar venta ..................................................................... 96
Tabla 3.23 Caso de prueba - Gestión de Cliente .............................................................. 98

Tabla 4. 1 Tabla de Usabilidad del sistema.................................................................... 102

Tabla 4. 2 Calculo de funcionalidad según el punto función ......................................... 104
Tabla 4. 3 Tabla de Ajuste de complejidad .................................................................... 106
Tabla 4. 4 Resultados ..................................................................................................... 110

viii
 CAPÍTULO I

MARCO INTRODUCTORIO

1.1. INTRODUCCIÓN

Actualmente la accesible disponibilidad de tecnología de información, ha creado un cambio

en la sociedad, cabe destacar que con mayor énfasis en los negocios. La manipulación de
datos por computadora es muy diferente de la manipulación de información manualmente.

En la actualidad la implementación de Sistemas de Información en una empresa cualquiera

sea esta, ha logrado mejorar la forma en la que realizan sus operaciones, la cantidad de
información que es necesario procesar, hace que el tratamiento automático sea realmente
necesario.

También se observa que internet en las últimas décadas va siendo parte de nuestras vidas, la
vida en línea es ahora un hábito de comunicación.

Las empresas que desean sobresalir deben usar las herramientas que beneficien a la misma.
Muchas de las empresas que se dedican en vender productos y ofrecer servicios requieren un
control de las ventas efectuadas y los servicios prestados para que la empresa esté al tanto de
sus transacciones.

Con esta finalidad el proyecto que se propone efectuará la implementación de un sistema de

información vía web, para una adecuado control de pedidos, venta de productos y servicios
que ofrece la empresa ITSEVEN Soluciones Informáticas Integrales, dicha empresa tiene la
función de realizar venta, mantenimiento y reparación de equipos electrónicos en general.

La empresa ITSEVEN con bastante información a ser procesada, tiene la necesidad de

agilizar los procesos así como también mejorar la eficiencia. Para esto y gracias al sistema
propuesto lograremos el almacenamiento adecuado de los datos obtenidos de las actividades

1
habituales como pedidos y venta de productos así también los servicios que ofrecen, entre
otros, para poder realizar consultas y reportes. La metodología adoptada para el desarrollo
del software es OpenUP, y como metodología de modelado de datos UWE basado en UML.

Las Herramientas utilizadas son el lenguaje de programación PHP, el gestor de base de datos
MySQL, bajo la plataforma Windows.

1.2. ANTECEDENTES

1.2.1. ANTECEDENTES DE LA INSTITUCIÓN

La empresa ITSEVEN Soluciones Informáticas Integrales, ubicada en la calle Batallón

Colorados Edif. El Cóndor Of.808. Se encuentra en sujeción al decreto ley de su creación de
2011. Es una empresa que está dedicada a realizar Ventas, Mantenimiento y reparación de
quipos electrónicos en general. Tiene como misión el ofrecer productos garantizados al
público, los clientes pueden realizan pedidos o servicios que la empresa analizara y enviara
una cotización de los mismos, si son clientes antiguos el precio de los productos deberán ser
el mismo a una anterior compra. La empresa ITESEVEN Soluciones Informáticas Integrales,
en cuanto a sistema de información se refiere aún no cuenta con un sistema de pedidos y
ventas en línea, que facilite procesos y brinde beneficios a la misma.

Se observó que los procesos registro de productos, registro de pedidos, registro de clientes,
registro de servicios de mantenimiento y reparación, también el registro de ventas se realiza
de manera manual a través de hojas Excel, causando perdida de valioso tiempo dentro de la
empresa; a la vez el proceso de cotizaciones de pedidos es retardado por procesos manuales
con el que se desarrolla.

Los clientes de esta empresa son de variadas necesidades, desde personas singulares hasta
organizaciones enteras, teniendo así diversos pedidos que deben ser cotizados para
posteriormente llegar a concretar ventas, además cuenta con el área de servicios y
mantenimiento, tanto de los productos que fueron vendidos por la empresa así como también

2
a personas que lo requieran. El registro de las actividades de pedidos con su respectiva
cotización de productos, la venta de los mismos, así como también los servicios que ofrecen
como mantenimiento y reparación de material electrónico. Habiendo observado esta
situación se vio necesario que exista un control automatizado que brinde claridad, rapidez y
precisión.

1.2.2. ANTECEDENTES DE PROYECTOS SIMILARES

 “SISTEMA WEB PARA EL CONTROL DE VENTAS Y FACTURACIÓN

USANDO AGENTES INTELIGENTES”, IMPORTADORA DE FÁRMACOS
“IMESMAT”
AUTOR: Patricia Evelyn Matta Catacora
Mayor De San Andrés
GESTIÓN: 2011
Desarrollar un sistema web para el control de ventas y facturación usando agentes
inteligentes que permita la agilización en el proceso de facturación, registro,
cotizaciones de los productos y genere reportes actualizados de ventas, basado en
metodología de Diseño XP (Programación Extrema).

 “SISTEMA DE CONTROL DE VENTAS E INVENTARIOS”, ILLIMANI

NATURAL CONFORT
AUTOR: Luis Omar Quisbert Lima
Mayor De San Andrés
Herramienta de software de apoyo, en la administración, seguimiento y control de
ventas e inventarios de sus productos. Coadyuvando de forma eficiente y transparente
a la elaboración y obtención de información organizada, confiable, inmediata y
oportuna, el método a utilizar será el RUP (Proceso Unificado Rational).
GESTIÓN: 2011

3
  “SISTEMA INFORMÁTICO COMERCIAL PARA LA GESTIÓN DE
ALMACENES Y VENTAS DE FÁRMACOS UTILIZANDO UN CMS”, RED DE
FARMACIAS NIÑO DE JESÚS
AUTOR: María Rosario Ochoa Choque
Mayor De San Andrés
GESTIÓN: 2011
Diseñar e implementación de un sistema de información destinado a gestionar y
procesar los datos de medicamentos en la res de farmacias “NIÑO JESÚS”, para
facilitar los procesos comerciales y optimizar el proceso de la administración de la
información dentro de la organización, utilizando las metodologías de procesos
proporcionada por ICONIX.

1.3. PLANTEAMIENTO DEL PROBLEMA

1.3.1. PROBLEMA CENTRAL

La empresa ITSEVEN Soluciones Informáticas Integrales, ubicada en la Ciudad de La Paz,

realiza actividades y procesos a través de registros en libros y hojas Excel, los cuales
disminuyen la rapidez en el manejo de información, no se conoce con certeza que producto
se encuentran disponibles para su venta, existe una actualización deficiente de esta
información. Existe un registro de manera manual de los servicios que brinda la empresa, ya
sea de mantenimiento o de reparación de material electrónico, la actualización de
disponibilidad de empleados para tal trabajo es poco eficiente.

En la empresa ya existen clientes continuos, de los cuales solo existe un registro manual para
una próxima atención se busca en libro Excel las compras que realizaron. Los registros de
clientes nuevos son de manera manual.

El registro de pedidos y la emisión de su respectiva cotización se las realiza en base a hojas

Excel, lo cual ocasiona demoras en la entrega al cliente de los mismos.

4
Todos los aspectos mencionados nos llevan a decir que la información no se maneja de
manera automatiza en la empresa, tampoco presenta información en línea sobre los productos
y servicios que ofrece al público, lo cual genera problemas en la administración, toma de
decisiones y planificación. De lo expuesto anteriormente surge la interrogante:

¿Cómo se puede mejorar el manejo del control de

pedidos y ventas de productos así como los
servicios que se ofrecen en la empresa ITSEVEN?

1.3.2. PROBLEMAS SECUNDARIOS

 El registro de ventas se las realiza de forma manual, lo cual ocasiona que el estimado
de tiempo en el proceso es mayor.
 Las cotizaciones de los pedidos que tiene la empresa se realiza de también de manera
manual, esto ocasiona demora en el tiempo de entrega a los clientes, así también no
es completamente fiable.
 La actualización de la información sobre los productos no es de manera automatizada,
esto en ocasiones produce perdida de ventas, también retraso en las entregas de
productos.
 Existe falencias en la información de productos, esto afecta al cliente que demora más
tiempo en los trámites de compra.
 Los reportes de pedidos, ventas realizadas así como los datos de clientes no están
accesibles en tiempo real, esto ocasiona demora en la toma de decisiones.
 Carencia de información oportuna.
 Existe un control manual de información, por lo cual la información que se llega a
extraer no es fiable.

5
1.4. DEFINICIÓN DEL OBJETIVO

1.4.1. OBJETIVO GENERAL

Desarrollar un sistema web que mejore el control de pedidos y ventas de productos que se
ofrece la empresa ITSEVEN, en base a criterios y tecnología de información adecuados a la
necesidad de la institución.

1.4.2. OBJETIVOS ESPECÍFICOS

 Mejorar el tiempo de ventas para los clientes y así poder evitar deserciones y mejorar
las ventas.
 Organizar la información para saber qué productos están disponibles y que productos
no lo están, evitando tardanza en las entregas.
 Control de existencia de productos para venta y crear mecanismos de alerta cuando
no hay stock..
 Obtener información oportuna y en tiempo real.
 Generar reportes de clientes y ventas.
 Mejorar la organización de la información.

1.5. JUSTIFICACIÓN

1.5.1. JUSTIFICACIÓN ECONÓMICA

Los problemas mencionados anteriormente hacen que en la empresa ITESEVEN exista

inestabilidad en el manejo de información, esta situación llega ser un gasto de recursos
económicos para la empresa.

Este proyecto se justifica económicamente ya que permite que la empresa reduzca el tiempo
de elaboración de reportes e informes de las actividades de ventas y servicios que se realiza

6
lo cual optimizara el uso de recursos humanos como también de materiales esto reducirá
costos.

El sistema brindara a la empresa ITSEVEN una información útil, organizada, manejable,

confiable de los pedidos, las ventas, servicios así como también y de los clientes, que ayude
a las decisiones que se toma en la empresa.

El sistema nos permitirá hacer valoraciones si las estrategias empresariales son adecuadas e
introducir los cambios necesarios de los resultados, ya que se podrá disponer de información
fiable que permite dar una respuesta rápida y altamente competitiva, logrando el ahorro de
tiempo y costos.

Por tanto el sistema reducirá los errores más comunes tanto de registro de productos, ventas
y servicios, así también la elaboración de informes, de esta manera se disminuye los gastos
en materiales de escritorio asé también el tiempo que se emplea para su realización.

Para la implementación del presente sistema de control de pedidos y ventas, no se requiere

presupuesto ya que la empresa ITSEVEN cuenta con el equipo tecnológico necesario.

1.5.2. JUSTIFICACIÓN SOCIAL

El proyecto beneficia de manera directa a los empleados de la empresa ITSEVEN ya que

podrán tener información precisa, confiable y en tiempo corto de las actividades de pedidos,
ventas y servicios que se registran, así como también beneficia a los clientes, estos beneficios
se detallan a continuación. Este proyecto pondrá a disposición de los gerentes y del personal
del área de ventas, la información necesaria con los informes requeridos, con la facilidad de
un acceso directo cada vez que lo requieran.

También se mejorara la atención al cliente al agilizar el proceso de venta de cada producto,

evitando la deserción de clientes y al contrario aumentar la lista de nuestros clientes.

7
Por un lado los clientes podrán tener acceso directo a la lista de productos actualizado, podrán
realizar pedidos y recibir cotizaciones de sus pedidos, podrán solicitar servicios de
mantenimiento o reparación que ofrece la empresa.

El sistema brindara información sistematizada vía web, que será de gran apoyo para la toma
de decisiones y planificación mejorando así la administración empresarial, además se
brindara información necesaria para sus clientes.

1.5.3. JUSTIFICACIÓN TECNOLÓGICA

Este proyecto se justifica tecnológicamente por el uso de alta tecnología de comunicación,

como internet, lenguaje de programación así también un gestor de base de datos.

Cabe destacar que la empresa ITESEVEN cuenta con la tecnología necesaria para
implementar el sistema en sus ambientes, es decir equipos de computación que se encuentran
en perfecto funcionamiento, para poder desarrollar nuestro sistema, también la empresa
ITSEVEN cuenta con repositorio de datos en planillas de Excel, dado que nos enfocaremos
principalmente en el diseño de la base de datos que almacenará la información para el control
de ventas.

1.6. ALCANCES Y LIMITES

1.6.1. ALCANCES

El presente sistema web de control de pedidos y ventas para la empresa ITESEVEN

Soluciones Informáticas Integrales, mejora y facilita las actividades que desempeñan los
empleados, aumentando la eficiencia en las actividades que se desarrolla en el área de ventas
y servicios, incrementando sustantivamente la automatización, transparencia y garantizando
la calidad de en el desarrollo de procesos. Involucrando las actividades que a continuación
se detallan:

8
  Módulo de registros de productos, pedidos, ventas y servicios que el almacenamiento
se realizara en una base de datos mediante formulario.
 Módulo que permite almacenar el registro de todos los pedidos y los servicios
registrados en línea.
 Módulo de visualización cuadros estadísticos respecto a las ventas, clientes,
productos y servicios facilitado el análisis de las mismas.
 Módulo de reportes, de ventas, de pedidos y servicios realizados en el área de venta,
emisión de históricos de productos disponibles. Se podrá obtener reportes
actualizados en cualquier momento.
 Módulo de administración de usuarios, donde podrá realizar gestión de su cuenta,
registrar nuevos usuario, generar lista de usuarios.

1.6.2. LIMITES

El presente sistema web de control de pedidos y ventas para la empresa ITESEVEN

Soluciones Informáticas Integrales propuesto se limitara a solo:

 Automatizar el almacenamiento de datos existentes en la empresa ITSEVEN, se

aclara que solo será respecto al área de ventas donde se registran; los pedidos, las
ventas y servicios.
 Las consultas sobre los pedidos, las ventas y también los servicios que están
registrados, serán solo para el área de ventas y la gerencia.
 Se tomara en cuenta la información del departamento de ventas, conjuntamente la
demás información de la empresa respecto a las ventas.

9
1.7. APORTES

1.7.1. APORTE PRÁCTICO

El aporte del presente proyecto es la implementación de un sistema web que brindara un

óptimo control y manejo de la información de pedidos, ventas, clientes, logrando colaborar
a la empresa ITSEVEN, en términos de:

 Mayor difusión de los servicios como también de productos a través del sistema Web.
 Agilización de obtención de reportes en cuanto a los pedidos, ventas y servicios que
se registraron en el sistema Web.
 Incorporar la generación de gráficos para entender de una mejor y fácil manera las
ventas realizadas, efectuando el desarrollo mediante la aplicación de métodos y
utilización de tecnologías.

1.7.2. APORTE TEÓRICO

La implementación del modelo de gestión: Será CRM (Customer Relationship Management)

gestión de la relación con los clientes, La administración de la relación con los clientes, se
caracteriza por realizar servicios al cliente o gestión de los mismos.

Para el desarrollo del sistema web se utilizara la metodología ágil OpenUP, basada en las
características más sobresalientes de metodología RUP. Dentro de la ingeniería web se hallan
varias metodologías de desarrollo de aplicaciones Web, el presente proyecto hace énfasis a
la metodología de Ingeniería Web basada en UML (UML Based Web Engineering “UWE”),
esta metodología de ingeniería Web, proporcionara los elementos y diagramas necesarios
para el desarrollo óptimo del modelo del sistema.

10
1.8. METODOLOGÍA

El método de investigación empleado en este proyecto será, el método científico que nos
ayudara a descubrir propiedades del objeto de estudio. El tipo de investigación empleados en
este proyecto será la investigación descriptiva, que ayudara a obtener información relevante
y de resultados claros, precisos.

La metodología de ingeniería de software, a partir de la cual se desarrollara el presente

proyecto será OpenUp, es una metodología de desarrollo basada en la metodología RUP
(Raional Unified Process). OpenUp, una de sus grandes características es el alto grado de
adaptabilidad a las necesidades de un proyecto en particular. Las fases son:

 Fase de Inicio, donde se define el propósito, objetivos del proyecto.

 Fase de Elaboración, dentro de esta fase se halla el análisis y diseño del sistema.
 Fase de Construcción, especifica únicamente el proceso de desarrollo o codificación
del sistema.
 Fase de Transición, la entrega del producto a los usuarios, y evalúa la funcionalidad
y performance del último entregable de la fase de construcción.

La herramienta de modelado de datos Web basada en UML (UWE), consiste en aplicar la

metodología de análisis y diseño orientado a objetos al desarrollo de aplicaciones Web,
usando UML podemos ver una página como un objeto, esto nos permitirá poder establecer
los métodos y atributos de una página web.

Las tecnologías que se utilizaran: El servidor Apache; PHP es un lenguaje de programación,

diseñado originalmente para la creación de páginas Web dinámicas; para la construcción de
la base de datos se usara MySQL que nos permitirá, crear y administrar la base de datos, los
usuarios y los permisos también el diseñar y ejecutar las instrucciones SQL.

11
 CAPÍTULO II

MARCO TEÓRICO

2.1. INGENIERÍA DE SOFTWARE

2.1.1. ¿QUÉ ES INGENIERÍA DE SOFTWARE?

Según El IEEE ingeniería de software se define como, Ingeniería es la aplicación de un

método sistemático, estructurado y cuantificable a estructuras, máquinas, productos, sistemas
o procesos. Ingeniería del software es la aplicación de un método sistemático, estructurado
y cuantificable al desarrollo, operación y mantenimiento de software.

Según Bauer, 1972 define ingeniería de software como, la ingeniería de software es el

establecimiento y uso de sólidos principios de ingeniería y buenas prácticas de gestión, así
como la evolución de herramientas y métodos aplicables y su uso cuando sea apropiado para
obtener, dentro de las limitaciones de recursos existentes, software que sea de alta calidad en
un sentido explícitamente definido.

Para su mayor comprensión, la ingeniera de software es una disciplina de la ingeniera que

comprende todos aspectos de la producción de software desde las etapas iniciales de la
especificación del sistema, hasta el mantenimiento, en los productos se aplican teorías,
métodos y herramientas donde sean convenientes, pero las utilizan de forma selectica y
siempre tratando de descubrir soluciones a los problemas, aun cuando no existan teorías y
métodos aplicables para resolver.

2.1.2. CICLO DE VIDA DEL SOFTWARE

El software no solo comprende los procesos técnicos de desarrollo de software, sino también
con actividades tales como la gestión de proyectos de software y el desarrollo de

12
herramientas, métodos y teorías de apoyo a la producción de software, con estas característica
es una forma de producir software de alta calidad.

Para producir un software de alta calidad el desarrollo exige un enfoque secuencial a lo largo
de su vida. Abarca las siguientes actividades:

 Análisis del Sistema: El Software es siempre parte de un sistema mayor, por tanto se
comienza estableciendo las entidades, roles, funciones etc. de los que intervienen en
el sistema, se identifican los requisitos del sistema.
 Análisis de Requisitos: Proceso de recopilación de los requisitos específicamente del
software. El analista debe comprender el ámbito de la información, la función, el
rendimiento y las interfaces del software.
 Diseño: Traduce los requisitos en una representación de software que pueda ser
codificada.
 Codificación: Traducción del diseño en código fuente escrito en un lenguaje de
programación.
 Prueba: Verificación de que las funciones del software producen los resultados que
realmente se requieren.
 Mantenimiento: El mantenimiento aplica cada uno de los pasos precedentes para
implementar los cambios que con el tiempo indudablemente sufrirá el software.

2.1.3. MODELOS DE PROCESO DE SOFTWARE

Los Modelos de Proceso de Software se los puede definir como una descripción simplificada
de un proceso del software que presenta una visión de ese proceso. Los modelos de proceso
de software, pueden incluir actividades que son parte de los procesos, productos de software
y el papel de las personas involucradas en la ingeniería de del software.

La mayor parte de los modelos de procesos de software se basa en uno de los tres modelos
generales o paradigmas de desarrollo de software:

13
  Enfoque en cascada: Considera las actividades anteriores y las representa con fases
de procesos separados, tales como la especificación de requerimientos, el diseño de
software, la implementación, las pruebas etc.
 Desarrollo iterativo: Este enfoque entrelaza las actividades de especificación,
desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de
especificaciones muy abstractas.
 Modelo Prototipado: Un modelo sirve de prototipo para la construcción del sistema
final.
 Transformación Formal: Un modelo matemático del sistema se transforma
formalmente en la implementación.
 Desarrollo basado en Reutilización: El sistema es ensamblado a partir de
componentes existentes.

2.2. MODELOS DE DESARROLLO DE SOFTWARE

Una parte importante de la ingeniería de software es el desarrollo de metodologías.

Donde se mencionan: Metodologías Estructurada, Metodologías Orientada a Objetos,

Metodologías Tradicionales y Metodología Agiles.

 Metodología Estructurada: Las metodologías estructuradas se basan en la

estructuración y descomposición funcional de problemas en unidades más pequeñas
interrelacionadas entre sí. Representan los procesos, flujos y estructuras de datos, de
una manera jerárquica y ven el sistema como entradas-proceso-salidas.
 Metodología Orientada a Objetos: Las metodologías orientadas a objetos modelan
el sistema examinando el dominio del problema como un conjunto de objetos que
interactúan entre sí.
 Metodología Tradicional: La metodologías tradicionales imponen una disciplina de
trabajo sobre el proceso de desarrollo del software. Se centran especialmente en el
control del proceso, con definición de roles, actividades, artefactos, herramientas y

14
 notaciones para el modelado y documentación detallada. Las metodologías
tradicionales no se adaptan adecuadamente a los cambios.
 Metodología Ágil: Los procesos ágiles trabajan con requisitos desconocidos o
variables. Si no existen requisitos estables, no existe una gran posibilidad de tener un
diseño estable y de seguir un proceso totalmente planificado, que no vaya a variar ni
en tiempo ni en dinero.

2.3. MÉTODOS DE DESARROLLO ÁGIL

Los métodos de desarrollo ágil trabajan con requisitos desconocidos o variables. Por tanto,
el objetivo de los equipos desarrollar software deberán responder rápidamente a los cambios
que puedan surgir a lo largo del proyecto.

Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales,

caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de
las actividades desarrolladas.

A continuación se describe algunos de los métodos de desarrollo ágil:

 XP, Programación Extrema: Es una metodología ágil centrada en potenciar las

relaciones interpersonales como clave para el éxito en desarrollo de software,
promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo.
 SCRUM: es una metodología ágil que consiste en asignación de tareas diarias basado
en reuniones rápidas y control de la evolución de los procesos. Se puede llevar un
seguimiento de las tareas y saber en qué puntos existe debilidad.
 OpenUP: Es un proceso unificado ligero, iterativo, incremental, extensible y ágil.
Tiene como objetivo disminuir los riesgos con una identificación temprana; y es
aplicable a un conjunto amplio de plataformas y aplicaciones de desarrollo. Este
proceso de desarrollo unificado está basado en Rational Unified Process (RUP).

15
2.4. METODOLOGÍA OPENUP

OpenUP es un proceso de desarrollo iterativo del software que es mínimo, completo, y

extensible, también OpenUP como metodología de desarrollo es conducida por el principio
de colaboración para alinear intereses y para compartir su comprensión.

OpenUP tiene la característica de ser extensible, porque puede ser utilizada como base para
agregar o adaptar según las necesidades, apoya el desarrollo iterativo, ágil, e incremental y
es aplicable a un amplio sistema de plataformas y de usos del desarrollo.

Esta organizada dentro de cuatro áreas principales de contenido: Comunicación y

Colaboración, intensión, solución y administración.

Figura 2. Áreas de Contenido de OpenUP

Fuente: OpenUP Eclipse, 2011

2.4.1. OBJETIVO DE OPENUP

Los objetivos principales que presenta la Metodología de desarrollo de software OpenUP se

describen a continuación:

16
  Colaboración: Para sincronizar intereses y compartir conocimiento. Este principio
promueve prácticas que impulsan un ambiente de equipo saludable, facilitan la
colaboración y desarrollan un conocimiento compartido del proyecto.
 Equilibrar: Las prioridades para maximizar el beneficio obtenido por los interesados
en el proyecto. Este principio promueve prácticas que permiten a los participantes de
los proyectos desarrollar una solución que maximice los beneficios obtenidos por los
participantes y que cumple con los requisitos y restricciones del proyecto.
 Enfoque: Articular la arquitectura para facilitar la colaboración técnica, reducir los
riesgos, minimizar excesos y trabajo extra. Enunciar las decisiones técnicas
esenciales a través de una arquitectura creciente.
 Desarrollo evolutivo: Para obtener retroalimentación y mejoramiento continuo. Este
principio promueve prácticas que permiten a los equipos de desarrollo obtener
retroalimentación temprana y continua de los participantes del proyecto, permitiendo
demostrarles incrementos progresivos en la funcionalidad.

2.4.2. CARACTERÍSTICAS DE OPENUP

OpenUP presenta cuatro caracteriza principalmente que se soportan mutuamente:

 Balance: para confrontar las prioridades (necesidades y costos técnicos) para

maximizar el valor para los stakeholders.

 Colaboración: para alinear los intereses y un entendimiento compartido.

 Enfoque: en articular la arquitectura para facilitar la colaboración técnica, reducir los

riesgos y minimizar excesos y trabajo extra.

 Evolución: continúa para reducir riesgos, demostrar resultados y obtener

retroalimentación de los clientes.

Se puede decir que OpenUP tiene como características generales los siguientes aspectos:

17
  Preserva la esencia del Unified Process:
 Desarrollo iterativo e incremental.
 Desarrollo dirigido por Casos de Uso.
 Centrado en la Arquitectura.
 Sólo lo fundamental está incluido, sin dejar de ser completo y extensible.
 Ya que es apropiado para proyectos pequeños y de bajos recursos permite. disminuir
las probabilidades de fracaso en los proyectos pequeños e incrementar las
probabilidades de éxito.
 Permite detectar errores tempranos a través de un ciclo iterativo.
 Evita la elaboración de documentación, diagramas e iteraciones innecesarios.
requeridos en la metodología RUP.
 Por ser una metodología ágil tiene un enfoque centrado al cliente y con iteraciones
cortas.

2.4.3. ELEMENTOS DE OPENUP

La Metodología de desarrollo de software OpenUP está compuesto por dos elementos

esenciales y diferentes pero completamente interrelacionados entre sí, que describiremos a
continuación:

 Método: EL contenido del método es donde los roles, tareas, artefactos y

lineamientos son definidos, sin tener en cuenta como son utilizados en el ciclo de vida
del proyecto.
 Proceso: El proceso es donde los elementos del método son aplicados de forma
ordenada en el tiempo. Muchos ciclos de vida para diferentes proyectos pueden ser
creados a partir del mismo conjunto de elementos del método.

2.4.4. ESTRUCTURA DE OPENUP

La Estructura de la Metodología de Software OpenUP, hace énfasis en cuatro fases

principales que se desglosaran a lo largo del proyecto que son:

18
Inicio, elaboración, construcción y transición; en el presente proyecto está desarrollado
basado en estas cuatro fases de la metodología OpenUP.

También cabe mencionar que mediante las iteraciones, el ciclo de vida del proyecto brinda
supervisión continua a lo largo del proyecto, así también una dirección para minimizar su
exposición a riesgos que se pueden presentar y de esta manera lograr los alcances
establecidos.

Figura 2. Organización de los componentes de OpenUP

Fuente: OpenUP Eclipse, 2011

2.4.5. DISCIPLINA DE OPENUP

En OpenUP se plantea 6 disciplinas para ordenar los flujos de trabajo y el agrupamiento de

tareas del desarrollo, las disciplinas son: Requerimiento, Arquitectura, Desarrollo, Prueba,
Administración de Configuraciones y Cambio y Administración de Proyectos.

19
 Figura 2. Iteraciones del ciclo de vida de OpenUP
Fuente: Metodología Ágil Basado en Conocimiento, [Gimson, 2012]

 Requerimientos: Explica como analizar, validar y manejar los requerimientos para

el sistema a desarrollar. Es importante entender la definición y alcance del problema
que se intenta resolver. Identificar los stakeholders y definir el problema resolver.
Durante el ciclo de vida se administran los cambios de los requerimientos.
 Arquitectura: El propósito es lograr evolucionar a una arquitectura robusta para el
sistema. Explica cómo crear una arquitectura a partir de requerimientos
estructuralmente importante. Es en la disciplina de desarrollo donde se construye la
arquitectura.
 Desarrollo: Explica como diseñar e implementar una solución técnica que este
conforme a la arquitectura y sustente los requerimientos.
 Prueba: Explica como proveer retroalimentación sobre la madurez del sistema
diseñando, implementando, ejecutando y evaluando pruebas. Es iterativa e
incremental. Aplica la estructura de “La prueba lo antes posible y con la mayor
frecuencia posible” para la eliminación de riesgos tan pronto como sea posible.
 Administración de configuración y cambios: Denominado también gestión de
proyecto, explica cómo controlar los cambios de los artefactos, asegurando una

20
 evolución sincronizada del conjunto de productos que compone un sistema de
software. Esta desaplica se expande durante todo el ciclo de vida.
 Administración de Proyecto: Explica como entrenar, ayudar y apoyar al equipo,
ayudándolo a mejorar los riesgos y obstáculos que se encuentren al construir el
software.

En OpenUP se pasa por alto algunas disciplinas de proyectos ya que está orientada a
proyectos no muy amplios [Gimson, 2012].

2.4.6. TAREAS DE OPENUP

Una tarea es una unidad de trabajo realizada por un rol, son 19 tareas en OpenUP:

 Arquitectura
o Refinar la arquitectura.
o Definir la arquitectura.
 Desarrollo
o Implementar pruebas para desarrolladores.
o Implementar la solución
o Ejecutar las pruebas de desarrollo.
o Integración y construcción.
o Diseño de la solución.
 Administración de proyecto
o Evaluar los resultados.
o Administrar las iteraciones.
o Planificar las iteraciones.
o Planear el proyecto.
o Solicitar cambios.
 Requerimientos.
o Identificar los requisitos.

21
 o Detallar casos de uso.
o Detallar los requerimientos del sistema.
o Desarrollar la visión técnica.
 Prueba.
o Crear casos de prueba.
o Implementar pruebas.
o Ejecutar pruebas.

2.4.7. CICLO DE VIDA DE OPENUP

OpenUP desarrolla un ciclo de vida interactivo que elimina el riesgo a tiempo y ofrece
demostrar resultados al cliente del proyecto, tiene un desarrollo evolutivo para obtener
retroalimentación y mejoramiento continuo.

Figura 2. Ciclo de vida de OpenUP

Fuente: OpenUP Eclipse, 2012

2.4.7.1. INICIO

En esta primera fase del proyecto del ciclo de vida de OpenUP, Se analiza el propósito,
objetivos y la recopilación de suficiente información para el desarrollo del proyecto. Por

22
tanto, toda la información recopilada por este primer análisis, se define para el desarrollo del
proyecto; ámbito, límite, criterio. Los aspectos que se hallara en la fase de inicio son:

 Entender qué construir. Determine la Visión, el alcance del sistema y sus límites.
Identifique quién está interesado en este sistema y por qué.

 Identificar funcionalidad clave del sistema. Decida que requerimientos son los
críticos.

 Determinar al menos una posible solución. Identificar al menos una arquitectura

candidata y su viabilidad.

Los proyectos pueden tener una o más iteraciones en la fase inicial. Estas son algunas de las
razones por las múltiples iteraciones:

 Proyecto es grande, y es difícil de definir su ámbito de aplicación sistema sin

precedentes.
 Demasiados actores que compiten con las necesidades y relaciones complejas.
 Los principales riesgos técnicos demandan la creación de un prototipo o prueba de
concepto.

2.4.7.2. ELABORACIÓN

En esta segunda fase del ciclo de vida de OpenUP, donde se trata los riesgos significativos
para la arquitectura, es decir, el propósito de esta fase es establecer la arquitectura del sistema.

Los siguientes aspectos son los que se define en la fase de elaboración:

 Obtener un entendimiento con mayor nivel de detalle de los requerimientos. Tener un

buen entendimiento de la mayoría de requisitos que le permitan crear un plan más
detallado. Asegurar de ganar profundidad en el entendimiento de los requisitos más
críticos a ser validados.

23
  Diseñar, implementar y validar la línea base arquitectónica. Diseñe, implemente y
pruebe un esqueleto estructural del sistema. Aunque la funcionalidad no sea completa
aún, muchas de las interfaces entre los bloques de construcción son implementadas y
probadas.
 Disminuir los riesgos posibles y de esta manera lograr estimaciones de costos y
calendarios más precisos. Muchos riesgos técnicos son dirigidos como un resultado
de detallar los requisitos y de diseñar, implementar y probar la arquitectura. Refine y
detalle el plan de proyecto de alto nivel.

El número de iteraciones en la fase de elaboración es dependiente, pero no se limitan, por lo

general, en la primera iteración, es mejor para diseñar, implementar y probar un pequeño
número de escenarios críticos para identificar qué tipo de mecanismos de la arquitectura y la
arquitectura que usted necesita, por lo que puede mitigar los riesgos más importantes.

También los detalles de alto riesgo, se deben abordarse al comienzo del proyecto.

2.4.7.3. CONSTRUCCIÓN

En esta tercera fase del ciclo de vida de OpenUP, es la fase más larga del proyecto,
comprende el diseño, implementación y prueba de las funcionalidades para desarrollar un
sistema completo. El sistema es construido en base a lo desarrollado en la fase de elaboración.
Los siguientes aspectos son elaborados en la presente fase de construcción:

 Iteración de administración y planeación.

 Requerimientos administrativos.
 Desarrollar una solución por requerimientos dentro del contexto.
 Validar construcción.

Por lo general, la fase de construcción tiene más iteraciones (dos a cuatro) que en las otras
fases, en función de los tipos de proyectos.

24
2.4.7.4. TRANSICIÓN

En esta cuarta fase y la última del ciclo de vida de OpenUP, tiene como propósito es asegurar
que el sistema es entregado a los usuarios, y evalúa la funcionalidad y performance del último
entregable de la fase de construcción.

La retroalimentación incorporada al sistema en las iteraciones.

 Iteración de administración y planeación, la prueba beta presentada entra a

evaluación para ver si satisface las expectativas del usuario.
 Desarrollar una solución por requerimientos dentro del contexto.
 Documentar las lecciones aprendidas y mejorar el ambiente de los procesos y las
herramientas para el proyecto.

La fase de transición puede incluir la ejecución de los sistemas antiguos y nuevos en paralelo,
la migración de datos, los usuarios de formación, y el ajuste de los procesos de negocio. El
número de iteraciones en la fase de transición varía de una iteración de un sistema simple
que requiere la corrección de errores sobre todo menor de edad, de muchas iteraciones de un
sistema complejo, que incluye además de las funciones y la realización de actividades para
hacer la transición del negocio de usar el viejo sistema de utilizar el nuevo sistema.

Cuando los objetivos de la fase de transición que se cumplan, el proyecto se puede cerrar.

Para algunos productos, al final del ciclo de vida del proyecto actual puede coincidir con el
comienzo del ciclo de vida siguiente, lo que lleva a la siguiente generación WEB

Hoy en día el avance en las nuevas Tecnologías de la Información y Comunicación (TIC),

abren grandes oportunidades. Esta red universal abrió las puertas a la difusión de la
información siendo uno de los servicios más importantes para tal acontecimiento la World
Wide Web (WWW) y las aplicaciones asociadas a esta. Por tal razón cobre auge la Ingeniería
Web.

25
La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y
cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad.
Desde que esto empezó a suceder el internet se volvió más que una diversión y empezó a ser
tomado más en serio, ya que el aumento de publicaciones y de informaciones hizo que la
Web se volviera como un desafío para los ingenieros del software, a raíz de esto se crearon
enfoques disciplinados, sistemáticos y metodologías donde tuvieron en cuenta aspectos
específicos de este nuevo medio.

2.4.8. CARACTERÍSTICAS DE UNA APLICACIÓN WEB

Las Aplicaciones Web tienen una serie de rasgos comunes que diferencia a unos de otras:

 Desde el punto de vista del usuario, se ha universalizado su accesibilidad:

Actualmente un usuario experto y un usuario con habilidad limitada en el uso de
aplicaciones informáticas acceden al mismo tipo de aplicación. Aún más, el número
y tipo de usuario de las Aplicaciones Web no siempre es predecible, lo que obliga a
tener el concepto de facilidad de uso aún más presente que en otros tipos de
aplicaciones.
 Desde el punto de vista de la plataforma se realiza un uso intensivo de la red y la
conexión se establece desde distintos tipos de dispositivo de acceso.
 Desde el punto de vista de la información, asistimos en la actualidad a una
disponibilidad global de fuentes heterogéneas de información, estructurada y no
estructurada, pertenecientes a distintos dominios y que colaboran en el cumplimiento
de los objetivos de la aplicación.

2.5. UWE (UML- Based Web Engineering)

UML-Based Web Engineering (UWE) es una metodología de desarrollo de aplicaciones web,

utilizada en la ingeniería web, dedicado a la sistematización y personalización, es decir
realizar sistemas adaptativos.

26
Debemos también destacar las características relevantes del proceso UWE como la
utilización del paradigma orientado a objetos, su orientación al usuario.

UWE es un proceso, iterativo e incremental, incluye flujos de trabajo y puntos de control, las
fases coinciden con las propuestas en el Proceso Unificado de Modelado y UML pero
adaptada a la web.

El lenguaje UWE posee definiciones que representan características específicas y necesarias

para el diseño de modelos en el dominio Web y el hecho de ser una ramificación del lenguaje
UML le provee de la flexibilidad necesaria para la definición en este dominio. Como el
lenguaje UML es un lenguaje de amplio uso en la mayoría de las herramientas CASE y en la
ingeniería de software en general, la aplicación de UWE es de fácil entendimiento y de simple
utilización.

2.5.1. CARACTERÍSTICAS UWE

Las principales características en los que se fundamenta UWE son los siguientes:

 Una de las características de UWE es el uso de una notación estándar, para todos los
modelos Lenguaje de modelado unificado UML.
 Definición de métodos: UWE presenta una definición de los pasos para la
construcción de los diferentes modelos.
 Especificación de Restricciones: en la metodología UWE, se recomienda el uso de
restricciones en su desarrollo.

2.5.2. FASES DE UWE

UWE es una metodología dirigida o enfocada al modelado de aplicaciones Web, ya que está
basada estrictamente en UML, esta metodología nos garantiza que sus modelos sean fáciles
de entender para los que manejan UML.

En la siguiente figura podemos ver una vista general de UWE, con las fases que tiene como.

27
 Figura 2. Vista General de Modelos UWE
Fuente: Nolivos y Coronel, [T-ESPE, 2013]

2.5.2.1. FASE DE ANÁLISIS DE REQUISITOS

La Fase de Análisis de Requerimientos realiza la captura de los mismos mediante diagramas

de casos de uso acompañado de documentación que detallada.

Figura 2. Modelo de caso de Uso

Fuente: Ludwig-Maximilians-Universität München [UWE,2014]

28
2.5.2.2. FASE DE CONCEPTUAL

Caracterizado por un modelo de dominio, que utiliza los requisitos que se detallan en los
casos de uso. En esta etapa se representa el dominio del problema con un diagrama de clases
de UML, que permiten determinar, métodos y atributos.

El propósito de este diagrama es construir un modelo del dominio que intenta no considerar
el paseo de la navegación, la presentación y los aspectos de interacción. Aspectos que se
analizarán en los pasos respectivos de navegación y presentación de la planificación.

Figura 2. Diagrama de Contenido

Fuente: Fuente: Ludwig-Maximilians-Universität München [UWE, 2014].

2.5.2.3. FASE DE NAVEGACIÓN

Basado en el diagrama de la fase conceptual, donde se especifica los objetos que serán
visitados dentro de la aplicación web y la relación entre los mismos.

29
Su objetivo principal es representar el diseño y estructura de las rutas de navegación al
usuario para evitar la desorientación en el proceso de navegación.

Este modelo se destaca en el marco de UWE como el más importante, ya que representa
elementos estáticos, a la vez que se pueden incorporar lineamiento semántico de referencia
para las funcionalidades dinámicas de una aplicación Web.

Figura 2. Diagrama de navegación UML

Fuente: Ludwig-Maximilians-Universität München [UWE, 2014].

La fase de navegación a su vez podemos dividirlo en dos áreas:

 Modelo del espacio de navegación: basada en lo estructurado en la fase de

conceptualización, es decir en los diagramas de clases.

30
  Modelo de la estructura de navegación: Muestra la forma de navegar ante el
espacio de navegación. Están constituidas por menús, índices, visitas guiadas, y
formularios.
o Los índices es la colección de objetos permitiendo una navegación directa.
o Las visitas guiadas compuesta por grupo de referencias, permitiendo una
navegación secuencial.
o Un menú es un elemento parte de la navegación con un número específico de
conexiones a otros objetos.
o Un formulario facilita al usuario ingresar información para completar las
condiciones de selección de objetos pertenecientes a las colecciones de
índices y visitas guiadas.

Figura 2. Nombre y símbolo de esteriotipos – Modeo de Navegación

Fuente: Nolivos y Coronel, [T-ESPE, 2013]

2.5.2.4. FASE DE DISEÑO DE PRESENTACIÓN

La fase de diseño de presentación tiene como objetivo la representación de las vistas del
interfaz del usuario final, la representación gráfica de esta fase se encuentra basada en los
diagramas realizados en las fases anteriores.

Las clases del modelo de presentación representan páginas Web o parte de ellas, organizando
la composición de los elementos de la interfaz de usuario y las jerarquías del modelo de
presentación.

31
 Figura 2. Nombre y símbolo de estereotipos – Modelo de Presentación
Fuente: Nolivos y Coronel, [T-ESPE, 2013]

El diagrama de esta fase representa los objetos de navegación y elementos de acceso, por
ejemplo en que marco o ventana se encuentra el contenido y que será remplazado cuando se
accione un enlace. En la siguiente imagen podremos observar un ejemplo de un diagrama de
presentación mediante UWE.

Figura 2. Diseño de Presentación UWE

Fuente: Ludwig-Maximilians-Universidad München [UWE, 2014].

32
2.5.2.5. MODELO DE PROCESO

Le modelo de proceso o tareas integra los proceso de negocios al modelo de UWE,

especificando los comportamientos de cada proceso y delas interfaces que permiten manejar
a cada uno de ellos.

Representa la parte dinámica de la aplicación Web, especificando la funcionalidad de las

transiciones y de los flujos de trabajo complejos de las actividades, contrario al modelo
navegación, que representa la parte estática de la información [T-ESPE, 2013].

2.5.3. VENTAJAS UWE

La especificación de UWE par a la especificación de aplicaciones adaptativas provee al

usuario páginas más apropiadas ya que estas están descritas en función de las preferencias
del usuario o de las características de contexto y se basan en técnicas orientadas a los
aspectos.

UWE permite un modelado de aplicaciones Web basado en las demandas de cada usuario en
particular, separando requerimientos, enfoques, interfaces, adaptabilidad, aspectos y
componentes para mayor flexibilidad, definiendo un conjunto de procesos adecuados durante
todas las etapas del desarrollo, cual permite mantener la integridad del diseño y la
funcionalidad del sistema.

2.6.CRM (Customer Relationship Management)

CRM Gestión de Relaciones con los Clientes, es una especialidad de la tecnología de la

información enfocada a la relación entre las empresas y sus clientes. Esta especialidad CRM
empleada para aprender más acerca de las necesidades y comportamiento de los clientes con
el fin de afianzar la relación con los mismos. Debemos tomar en cuenta que el CRM nos
permitirá integrar grandes cantidades de información de los clientes, las ventas, eficacia de
la comercialización, índices de respuesta y tendencias del mercado.

33
2.6.1. OBJETIVO DE LA CRM

La Gestión de Relación con el cliente o CRM, tiene el objetivo de brindar soluciones

tecnológicas que permitan fortalecer la comunicación empresa y cliente mediante la
automatización de los siguientes componentes:

 La preventa: está relacionada con el marketing y consiste en estudiar el mercado, es

decir las necesidades de los clientes, así también la identificación de clientes
potenciales. La información obtenida sobre los clientes permite a la empresa revisar
su selección de productos con el fin de satisfacer mejor las expectativas del cliente y
tener una atención personalizada.

 Las ventas: El proceso de ventas comprende el ciclo comercial de la empresa, desde

la planificación y previsión, hasta la gestión de incentivos, pasando por el cálculo de
ofertas personalizadas y la gestión de los contratos.

 Gestión de servicio al cliente: a los clientes les gusta sentirse conocidos y

reconocidos por la empresa.

 La posventa: En esta etapa se provee asistencia al cliente, en especial a través de la

implementación de centros de llamada y del suministro en línea de información de
soporte técnico.

2.6.2. TIPOS DE TECNOLOGÍA CRM

2.6.2.1. INTERACCIÓN CON EL CLIENTE O CRM OPERACIONAL

Sistema que facilita el registro de los pedidos y de todas las actividades subsiguientes hasta
que se produce la entrega del producto al cliente final.

 Business Intelligence.
o DataWarehouse es almacén central de los datos de la empresa.

34
 o DataMining, analiza información para descubrir tendencias, escenarios, etc.
Es decir una detección de patrones de comportamiento, así también, permite
diseñar acciones comerciales diferenciadas.

2.6.2.2. CONOCIMIENTO DEL CLIENTE O CRM ANALÍTICO

Herramientas que facilitan el análisis de los datos acumulados por la empresa sobre el
comportamiento de compra de sus clientes. Toma datos del CRM operacional.

El CRM Analítico hace uso de un repositorio de datos, el mismo que se alimenta de

información general sobre los clientes y las transacciones que realizan.

El CRM Operacional colabora con el CRM Analítico en la captura de información adicional

que se requiere, en especial en cuanto a conocer mejor al cliente. Igualmente se utilizan
herramientas de mineo de datos que permiten identificar patrones ocultos en la relación entre
los clientes y los productos y /o servicios que adquieren a la organización.

2.6.2.3. DIFUSIÓN DEL CONOCIMIENTO O CRM COLABORATIVO

Diseñados para dar soporte a la interacción entre el cliente y los distintos puntos de
información y servicios de post-venta. Es decir la gestión de comunicación con los clientes
por los diferentes canales de relación como FRONT OFFICE, Web, E-mail, Fax, Teléfono,
Interacción directa.

2.6.3. ARQUITECTURA DE LOS SISTEMAS CRM

La arquitectura básica de un CRM está cubierta por el módulo de atención al cliente,

denominado front-office, generalmente constituido por los submódulos de marketing, ventas
y de servicio al cliente. Las tecnologías de soporte al contacto con el cliente son inherentes a
los puntos de interacción con el mismo. El back-office está constituido por el conjunto de
sistemas internos de la empresa.

35
 Figura 2. Arquitectura de las soluciones CRM.
FUENTE: Lagos Cesar, 2008

Entre los componentes deben constar de CRM

 Un motor de base de datos eficiente que pueda manejar y procesar grandes volúmenes
de información. La base de datos del CRM debe centralizar la información de los
clientes y proporcionar una visión única del cliente para cada uno de los
departamentos de la empresa.
 Un conjunto de herramientas y procesos que permitan explotar adecuadamente estos
datos así como su distribución e integración con todos los procesos del negocio.
 Un conjunto de aplicativos que permitan entregar, visualizar y analizar la información
que necesita el usuario del CRM.

2.6.3.1. CRM ENGINE

Contiene el depósito de datos de los clientes. Puede ser definido como el depósito central de
los datos de clientes (Customer Data Warehouse CDW), donde toda la información de los

36
clientes es capturada y almacenada. El propósito final de este componente es el de
proporcionar un único punto para individualizar la información de los clientes de manera que
se unifique la perspectiva del cliente para todos los departamentos de la compañía que
necesiten acceder a los datos de un cliente o segmento de clientes de una manera consistente
y lógica.

2.6.3.2. SOLUCIONES FRONT - OFFICE

Front-Office es un componente que provee una interface hacia los clientes y usuarios del
sistema. Pueden ser una parte esencial y automática para las ventas, así además del servicio,
soporte y aplicación de interacción de los clientes.

Una de las ventajas que presenta esta aplicación es que pueden analizar, y reportar de manera
casi instantánea todo cuanto sucede en la interacción con el cliente, y el hecho de que
proporcionan un fácil acceso a la información que generan se convierte en un elemento
bastante importe en las aplicaciones que la apliquen.

2.6.3.3. CRM EN EL BACK OFFICE

Conjunto de herramientas para análisis y extracción de datos. Las herramientas analíticas son
las aplicaciones de back-office para CRM. Sencillamente son “back office” porque operan
detrás de la escena y son utilidades completamente transparentes al cliente y el usuario.

2.6.3.4. APLICACIONES DE INTEGRACIÓN EMPRESARIAL PARA CRM

Proveen la interface entre el Back Office y el Front Office a más de posibilitar la

comunicación con sistemas externos. Esta es el componente de aplicaciones CRM que se
ubican entre el “back office” y “front office”. Una aplicación EAIs debe proveer el servicio
de mensajería y mapeo de datos que permitan disparar comunicaciones hacia otros sistemas
considerando el menor formateo posible de los datos que se intercambian.

37
2.7. ADMINISTRACIÓN DE VENTAS

La administración de ventas es la disciplina encargada de facilitar estos procesos y mantiene

al día a clientes, operaciones y proveedores. En el día actual, se lleva a cabo principal mente
gracias a los programas de CRM que, además permiten realizar estadísticas de ventas por
cliente, por vendedor y por equipo, detectando los puntos débiles de manera temprana y
facilitando su corrección a tiempo.

2.7.1. ORIGEN DE LA ADMINISTRACIÓN DE VENTAS

Las ventas ya existían 4,000 A.C., cuando los árabes viajaban en caravana para comercializar
sus productos en la mesopotámica y Egipto. La gente consideraba que era incorrecto obtener
ganancias por el intercambio de mercancías y servicios y quienes se dedicaban a esas
transacciones eran menospreciados en esa época.

2.7.2. FASES DEL PROCESO DE VENTA

 Proceso y Calificación: En esta fase se realiza la búsqueda de futuros clientes, una

vez ubicados se califican determinando fundamentalmente su capacidad de compra y
su capacidad financiera.
Para la captura de clientes que es importante se toma en cuenta tres etapas:
o Identificar a los clientes.
o Calificar a los candidatos en función a su potencial de compra.
o Elaborar una lista de clientes.
 Contactos y principios de venta: Luego de elaborada la lista de clientes, en esta fase
de contactos y principios de venta se ingresa al principio de venta que consiste en la
obtención de información más detallada de cada cliente en perspectiva y la
preparación de la presentación de ventas adaptada a las particularidades de cada
cliente.
Esta fase involucra el siguiente proceso:

38
 o Investigación de las particularidades de cada cliente en perspectiva.
o Preparación de la presentación de ventas enfocada en el posible cliente.
o Obtención de la cita o planificación de las visitas en frio.
 La presentación: todo objetivo de toda presentación de venta es llegar al cierre, sin
embargo, para productos más complicados se requiere de varias visitas para hacer la
presentación completa.
La presentación de ventas se basa en una estructura basada en 3 pilares:
o Las características del producto: Lo que es el producto en sí, sus atributos
o Las ventajas: Aquello que lo hace superior a los productos de la competencia
o Los beneficios que obtiene el cliente: Aquello que busca el cliente de forma
consciente o inconsciente
 Manejo de las objeciones y de la resistencia a la venta: Las objeciones, por lo
general, indican cierto interés inicial y ofrecen la oportunidad de presentar puntos de
venta adicionales en el proceso de responderlas.
 Cierre de la venta: Es la culminación del proceso de la venta, donde el vendedor
solicita el pedido al cliente.
 Seguimiento: En esta etapa es importante que el vendedor no se conforme con el
cierre de la venta, debe manejar el pedido y la entrega del producto lo más eficiente
que sea posible, comprobando que el producto o servicio haya sido prestado en forma
satisfactoria.

2.8. HERRAMIENTAS DE DESARROLLO DE SOFTWARE

2.8.1. SISTEMA DE GESTOR DE BASE DE DATOS SGBD

Los Sistemas de Gestión de Base de Datos son un tipo de software muy específico que
realiza agrupación de programas que sirven para definir, construir y manipular una base de
datos. Los SGBD deben incluir un control de concurrencia, o sea, deben permitir a varios
usuarios tener acceso "simultáneo" a la base de datos. Controlar la concurrencia implica que

39
si varios usuarios acceden a la base de datos, la actualización de los datos se haga de forma
controlada para que no haya problemas.

2.8.1.1. CLASIFICACIÓN DE LOS SGBD

Esta clasificación está basada en el modelo de datos en que está basado el SGBD. Los
modelos de datos más habituales son:

 Relacional (SGBDR): representa a la base de datos como una colección de tablas.

Estas bases de datos suelen utilizar SQL como lenguaje de consultas de alto nivel.
 Orientado a objetos: define a la base de datos en términos de objetos, sus
propiedades y sus operaciones. Todos los objetos que tienen la misma estructura y
comportamiento pertenecen a una clase y las clases de organizan en jerarquías.
 Objeto-relacional o relacional extendido: son los sistemas relacionales con
características de los orientados a objetos.
 Jerárquico: representa los datos como estructuras jerárquicas de árbol.

Un SGBD también puede clasificarse por el número de usuario a los que da servicio:

a) Monousuario
b) Multiusuario

También puede clasificarse según el número de sitios de la base de datos:

c) Centralizado: la base de datos y el software SGBD están almacenados en un solo sitio.

d) Distribuido (SGBDD): la base de datos y el software SGBD pueden estar distribuidos
en múltiples sitios conectados por una red.

2.8.1.2. BASE DE DATOS “MYSQL”

MySQL es un sistema de administración de base de datos relacional (RBDMS) se trata de un

programa capaz de almacenar una enorme cantidad de datos de gran variedad y de

40
distribuirlos para cubrir la necesidad de cualquier tipo de organización, desde pequeños
establecimientos comerciales a grandes empresas y organismos administrativos.

MySQL incluye todos los elementos necesarios para instalar el programa, prepara diferentes
niveles de acceso de usuario, administrar el sistema, protege y hacer volcado de datos. Puede
desarrollar sus propias aplicaciones de base de datos y ejecutarlos en casi todos los sistemas
operativos, incluyendo algunos de los que probablemente no ha oído hablar nunca.

2.8.2. LENGUAJE DE PROGRAMACIÓN “PHP”

PHP es un lenguaje de programación de uso general de código del lado del servidor
originalmente diseñado para el desarrollo web de contenido dinámico.

PHP fue uno de los primeros lenguajes de programación del lado del servidor que se podían
incorporar directamente en el documento HTML en lugar de llamar a un archivo externo que
procese los datos. El código es interpretado por un servidor web con un módulo de procesador
de PHP que genera la página Web resultante.

2.8.3. JAVASCRIPT

JavaScript es un lenguaje interpretado que permite incluir macros en páginas Web.

Estas macros se ejecutan en el ordenador del visitante de nuestras páginas, y no en el servidor.

JavaScript proporciona los medios para:

 Controlar las ventanas del navegador y el contenido que muestran.

 Programar páginas dinámicas simples sin tener que matar moscas a cañonazos de
Java.

 Evitar depender del servidor Web para cálculos sencillos.

 Capturar los eventos generados por el usuario y responder a ellos sin salir a Internet.

41
  Comprobar los datos que el usuario introduce en un formulario antes de enviarlos.

 Comunicarse con el usuario mediante diversos métodos.

La característica de JavaScript que más simplifica la programación es que, aunque el lenguaje

soporta cuatro tipos de datos, no es necesario declarar el tipo de las variables, argumentos de
funciones ni valores de retorno de las funciones.

2.8.4. AJAX (Asynchronous JavaScript And XML)

AJAX JavaScript asíncrono y XML, es una técnica de desarrollo web para crear aplicaciones
interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los
usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano.
De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas,
mejorando la interactividad, velocidad y usabilidad en las aplicaciones.

42
 CAPÍTULO III

MARCO APLICATIVO
3.1. INTRODUCCIÓN
Este capítulo constituye el elemento central para la solución al problema expuesto en el
capítulo de Marco Introductorio, también se considera lo expuesto en el capítulo del Marco
Teórico, ya que se desarrollara en base a las fases del ciclo de vida de la metodología
OpenUP, con el fin de describir el desarrollo del sistema web de control de pedidos y ventas
para la empresa ITSEVEN. Basando el desarrollo del sistema en la arquitectura de CRM,
usando como Ingeniería Web a UWE.

El uso de la metodología OpenUP implica la realización de actividades por cada una de sus
fases, presentando entregables en cada una de ellas, a continuación se describe por cada fase
de la metodología, las actividades que se realizaran a lo largo de todo el desarrollo de este
capítulo:

FASES ACTIVIDADES

Inicio Delimitación del Descripción de interesados.

proyecto, mediante Entorno de usuario.
criterios CRM.
Descripción de la posible solución.
Planeación del proyecto.
Requerimientos específicos
Definición de la posible
solución.

Elaboración Requerimientos. Captura de requerimientos.

43
 Definir los Casos de Uso Descripción de actores.
- UWE, Descripción de cada caso de uso
general,

Descripción de caso de uso general.

Especificación de caso de uso.

Diseño Conceptual - Diseño físico.

UWE, Diseño conceptual.

Diseño de navegación - Diseño de navegación para todas las

UWE, especificaciones.

Diseño de presentación. - Diseño de presentación por las

UWE, especificaciones.

Construcción Implementar la solución. Descripción de pantallas.

Realizar pruebas de Pruebas funcionales del sistema.

desarrollo.

Transición Realizar pruebas de Pruebas de estrés.

solución.

Tabla 3. Actividades por Fase de OpenUP

Fuente: Elaboración Propia

3.2. INICIO

En esta fase de inicio de la metodología OpenUP, tiene como base fundamental los conceptos
del criterio CRM. Realizando una descripción de los requisitos específicos que presentaron

44
los interesados del sistema. A continuación se desglosa los puntos esenciales en el desarrollo
de la fase de inicio del proyecto.

3.2.1. DESCRIPCIÓN DE LOS INTERESADOS DEL SISTEMA

Para que el producto sea adaptable a las necesidades de la empresa, es necesario identificar
a los participantes también denominados actores que de una u otra forma se verán
beneficiados por el sistema a desarrollar.

DESCRIPCIÓN RESPONSABILIDADES

Gerente de la Empresa  Dirigir la Institución.

ITSEVEN  Cumplir los objetivos y misión de la
institución.
 Seguimientos del desarrollo del
proyecto, y pruebas del cumplimiento de
requisitos.

Secretaria  Encargada de recibir todos los pedidos

y registrar las ventas hasta ahora de
manera manual.

Encargados de Ventas  Representa encargado de la primera fase

de aprobación de los pedidos y ventas de
productos.

Técnicos de la empresa  Representa al Usuario técnico de la

empresa.

45
 Clientes  Representa a todos los clientes que
puede tener la empresa.

Tabla 3. Interesados del Sistema

Fuente: Elaboración Propia

3.2.2. ENTORNO DE USUARIO

Para el acceso al sistema se debe identificar con un usuario y contraseña dentro del sistema
web, de esta forma ingresara al sistema de acuerdo al perfil que tenga el usuario con las
opciones adecuadas habilitadas.

Los clientes podrán realizar pedidos y recibir su cotización instantáneamente, encargados de

la empresa recibirán la notificación de nuevos pedidos.

3.2.3. DESCRIPCIÓN DEL PRODUCTO

La descripción del producto muestra las características del sistema en una perspectiva
general, señalando las necesidades de la empresa y las propuestas de solución planteadas, por
el presente proyecto.

NECESIDADES CARACTERÍSTICAS

Registro automatizado de Registrar las ventas de manera Alta

ventas de productos. automatizada, y luego tendrá reportes
de manera instantánea y precisa.

Gestionar Información del Registra datos de clientes, para su Alta

cliente. posterior tratamiento.

Gestionar información de Registra datos de productos, para su Alta

Productos. posterior tratamiento.

46
 Registro automatizado de La aplicación ofrecerá una interfaz Alta
pedidos por cliente. Web la cual permitirá que el usuario
cliente realice pedidos de productos o
productos en línea.

Control de la frecuencia de La aplicación deberá ofrecer Alta

pedidos de un producto. información del nivel de frecuencias
de productos que se piden, con
cuadros estadísticos.

Administración de interfaz Posibilidad de editar los contenidos Alta

segura y confiable.
del sistema, de manera segura con el
uso de niveles de usuario que cada
usuario registrado tiene, también debe
registrar las actividades realizadas en
el sistema de cada usuario.

Tabla 3. Descripción del Producto

Fuente: Elaboración Propia

3.2.4. REQUISITOS ESPECÍFICOS

3.2.4.1. INTERFAZ DE USUARIO

La interfaz de usuario será creada utilizando como base PHP5, HTML5, java script y como
base de datos MySQL.

3.2.4.2. INTERFAZ DE HARDWARE

Características mínimas necesarias en cuanto a hardware para montar la aplicación, se

describen a continuación.

 Memoria RAM 512 MB o superior.

47
  Disco Duro 20 GB.
 Servidor Web.
 Motor de Base de datos MYSQL.
 Conexión a internet 512Kb.
 Tarjeta gráfica de 512 Mb o superior.

3.3. ELABORACIÓN

3.3.1. CAPTURA DE REQUERIMIENTOS

La captura de requerimientos se realizó de acurdo al análisis realizado en la empresa

específicamente en el área de ventas, que será organizada por los siguientes módulos:

COD. REQUERIMIENTOS PRIORIDAD

R1 Base de datos para el registro de pedidos, y Alta

productos de almacén

R2 Diseño de la interfaz de registros de pedidos. Alta

R3 Automatizar el proceso de pedidos y ventas Alta

R4 El sistema debe permitir registrar los servicios Alta

que ofrece la empresa.

R5 Búsquedas de ventas y pedidos mediante filtros. Media

R6 Proporcionar Informes de manera rápida y Alta

eficiente de cada uno de los productos.

48
 R7 Desarrollar una interfaz para obtener Media
información de cada pedido o venta.

R8 Seguimiento de información de ventas Media

realizadas por cada uno de los empleados.

R9 Reporte de datos de los productos Media

R10 Reportes que generen informes de los pedidos Alta

R11 Control de acceso seguro para los usuarios. Media

R12 Interfaz amigable Media

R13 Registro de datos de cliente Media

R14 Reportes estadísticos de frecuencia de pedidos Media

de productos

R15 Reportes estadísticos de frecuencia de pedidos Media

que realizan los clientes.

Tabla 3. Requerimientos del Sistema

Fuente: Elaboración Propia

3.3.2. CASOS DE USO

3.3.2.1. DESCRIPCIÓN DE ACTORES

Los actores representan a los usuarios que presenta el sistema. Se comprende como usuario
cualquier persona que llegue a interactuar con el sistema.

49
A continuación se describe a los actores que interactúan con el sistema que se desarrolla.

ACTOR DESCRIPCIÓN

Administrador En este caso es el Gerente de ITSEVEN, es el actor

con mayor privilegio; Es el usuario que autoriza las
ventas, y aprobación de los pedidos para su posterior
paso a la venta del producto.

Encargado de Ventas Responsable de la gestión, control de almacén de los

productos, y emisión de la información referente a
cada pedido y venta de los mismos realizados en la
empresa, dando informes al administrador.

Secretaria Encargada de la elaboración de informes de ventas,

pedidos y los servicios que presta la empresa, estas
actividades son realizadas conjuntamente con el
administrador de ventas para su supervisión.

Cliente Es la persona singular o jurídica que realiza los

pedidos de productos, también realiza compras a la
empresa ITSEVEN, la empresa tiene registrado los
datos de los clientes para poder tener un control
individual y de esta forma mejorar las relaciones con
los mismos.

Tabla 3. Descripción del Actores del Sistema

Fuente: Elaboración Propia

3.3.2.2. CASO DE USO GENERAL

El siguiente diagrama de caso de uso general describe las actividades que realizan.

50
También muestra a los actores que pertenecientes a la empresa en cada venta o pedido de un
producto, los clientes también forman parte de esta descripción.

Figura 3.. Diagrama de Caso de Uso General

Fuente: Elaboración Propia

51
3.3.2.3. ESPECIFICACIÓN DE CASOS DE USO

a) GESTIÓN DE USUARIO

Las actividades que se realiza en la gestión de los usuarios se describen en forma de caso de
uso a continuación:

Figura 3.. Diagrama de Caso de Uso – Gestión de Usuario

Fuente: Elaboración Propia

En la siguiente tabla se describirá el caso de uso gestión de usuario del sistema, que se refiere
a la autenticación de usuario.

Nombre Autenticación de Usuario

Descripción Este caso de uso el usuario se autentifica con un nombre y

contraseña, estos datos son asignados por el administrador, para que

52
 de esta forma los usuarios autentificados realizasen sus respectivas
actividades en el sistema.

Actores Gerente, Administrador de Ventas, Secretaria

Precondición Los actores deben estar registrados previamente en la base de datos

del sistema.

Postcondición Se autentica al usuario, reconociendo sus datos y el nivel de acceso

que este tiene.

Flujo de Básico
Eventos 1.- El usuario Ingresa al sistema

2.- El sistema solicita nombre de usuario y contraseña.

3.- El sistema valida los datos y verifica el nivel de acceso que tiene
el usuario.

Alternativo

1.- Si el sistema encuentra datos que no concuerdan con los

requeridos, el sistema no permite el ingreso al sistema de manera
autentificada.

Tabla 3. Autenticación de Usuario

Fuente: Elaboración Propia

En la siguiente tabla se describe la gestión de usuario, que se refiere a la creación y

modificación de un usuario del sistema, tomando en cuenta que primero que un usuario
primero debe ser registrado como empleado, para poder de esta manera poder tener una
cuenta de usuario en el sistema.

53
Nombre Gestionar cuenta de usuario

Descripción Este caso de uso permite el control de las cuentas de usuario,

es decir, el registro de nuevo usuario, la modificación, y la
desactivación de una cuenta de usuario.

Actores Gerente ITESEVEN

Precondición El usuario se autentifica en el sistema.

Postcondición El usuario asigna una contraseña y un nombre de usuario al

nuevo registro, los datos son almacenados.

Flujo de Básico
Eventos 1.- El usuario ingresa al sistema.

2.- El usuario ingresa a la pestaña de registro de empleado.

3.- El usuario llena los datos de nuevo empleado, asignando

también los privilegios que tendrá en el sistema.

4.- El usuario asigna contraseña y un nombre al nuevo registro.

5.- El sistema valida los datos.

6.- El sistema guarda los datos en la base de datos

Alternativo

1.- Si el sistema encuentra datos que no concuerdan con los

requeridos, el sistema despliega una alerta de informe que no
se introdujo los datos.

54
 2.- el usuario ingresa al link modificar datos de empleado, se
desplegá los datos de empleado, el usuario modifica los datos
y tiene la opción de guardar los cambios.

Tabla 3. Gestionar cuenta de usuario

Fuente: Elaboración Propia

b) GESTIÓN DE PRODUCTOS

La gestión de los productos, se describe en forma de caso de uso a continuación, donde se

observa las actividades que realizan los usuarios involucrados en el caso de uso:

Figura 3. . Diagrama de caso de uso – Gestión de Productos

Fuente: Elaboración Propia

En la siguiente tabla se describe el caso de uso que permite adicionar productos al sistema.

55
Nombre Adicionar producto al sistema

Descripción En este caso de uso permite que el encargado del área de

ventas registre los datos de los nuevos productos.

Actores Encargado de Ventas

Precondición El usuario debe estar autentificado.

El producto no debe existir en la base de datos.

Postcondición Los datos del producto que se registró, serán almacenados

en la base de datos.

Básico
Flujo de
Eventos 1.- El usuario ingresa al interfaz pulsando opción de nuevo
producto

2.- El usuario registra los datos del nuevo producto que está
disponible para la venta.

3.- Los datos son validados e ingresados en el sistema

inmediatamente luego de presionar el botón “Guardar”.

Alternativo

1.- Si el usuario visualiza en la interfaz que el nuevo

producto ya fue registrado con todas las características
iguales, se anula la actividad.

56
 2.- Si el sistema encuentra datos que no concuerdan con los
requeridos, el sistema despliega una alerta de informe que
no se introdujo los datos.

Tabla 3. Adición de Productos al sistema

Fuente: Elaboración Propia

La siguiente tabla se describe el caso de uso que se refiera a la modificación de datos de un

producto en el sistema.

Nombre Modificar datos de producto

Descripción En este caso de uso permite la modificación de datos de un

producto, esto es realizado por el Encargado de ventas.

Actores Encargado de ventas.

Precondición El usuario debe estar autentificado, debe tener privilegio de

gerente.

Deben existir datos registrados previamente del producto.

Postcondición Los datos del producto que ser registro deben estar
almacenados en la base de datos.

Flujo de Básico
Eventos 1.- El usuario ingresa al interfaz pulsando opción de
modificar producto, para poder acceder al formulario de que
permite modificar datos de los productos.

57
 2.- Se despliega el formulario donde se ve los datos
existentes del producto.

3.- El usuario modifica los datos del producto que sean

necesarios.

4.- Los datos son validados e ingresados en el sistema

inmediatamente luego de presionar el botón “Guardar”.

Alternativo

1.- Si el sistema encuentra datos que no concuerdan con los

requeridos, el sistema despliega una alerta de informe que no
se introdujo los datos.

Tabla 3. Modificar datos de productos

Fuente: Elaboración Propia

La siguiente tabla describe el caso de uso de los reportes de datos de productos registrados
en el sistema.

Nombre Ver detalle de productos

Descripción En este caso de uso permite al usuario ver los detalles de

productos, es decir, una descripción general de sus
características.

Actores Encargado de venta, administrador.

Precondición El usuario debe estar autentificado.

Debe existir registro de productos en la base de datos.

58
 Postcondición Los reportes son almacenados en la computadora.

Flujo de Básico
Eventos
1.- El usuario ingresa al interfaz pulsando opción Reporte
producto, ya sea de reporte individual de producto, como
también, el reporte general de todos los productos
registrados.

Tabla 3. Ver de detalle de productos

Fuente: Elaboración Propia

c) GESTIÓN DE PEDIDOS

La gestión de pedidos, se describe en forma de caso de uso a continuación, donde se observa

las actividades que realizan los usuarios involucrados en el caso de uso:

Figura 3. . Diagrama de caso de uso – Gestión de pedidos

Fuente: Elaboración Propia

59
La siguiente tabla describe el caso de uso donde los usuarios pueden realizar pedidos de
productos en el sistema.

Nombre Realizar pedido

Descripción En este caso de uso se permite al usuario realizar pedidos de

uno o varios productos y en cantidades diferentes si se
prefiere.

Actores Cliente

Precondición EL o los productos deben estar registrado en la base de datos.

Postcondición Los registro de pedidos se almacenan en la bases de datos.

Flujo de Eventos Básico

1.- El usuario ingresa al portal de sistema.

2.- El sistema le muestra los productos disponibles.

3.- El usuario elige los productos y la cantidad que desea

pedir.

4.- El usuario registra sus datos en el sistema.

5.- El usuario acepta lo seleccionado.

6.- El sistema le informa del moto de pago, la cantidad de

productos pedidos y el nombre de los mismo.

7.- El sistema despliega el mensaje de confirmación.

8.- Los datos son registrados en la base de datos.

60
 Alternativo

1.- si el usuario no está conforme con lo pedido puede

cancelar el presente pedido.

Tabla 3. Realizar pedido

Fuente: Elaboración Propia

La siguiente tabla describe el caso de uso donde los usuarios pueden realizar pedidos de
productos en el sistema.

Nombre Consultar los registros de pedidos

Descripción En este caso de uso el encargado de ventas como la secretaria,

también el administrador, pueden ver los pedidos que se
realizaron en un determinado tiempo.

Actores Encargado de ventas, secretaria, Administrador

Precondición El usuario debe estar autentificado.

Existe registro de pedidos.

Postcondición El pedido es enviado para su revisión y aprobación.

Básico
Flujo de
1.- El usuario ingresa al sistema.
Eventos
2.- El usuario revisa si existen pedidos recientes.

3.- El sistema despliega los datos que existen en el nuevo pedido

registrado.

61
 4.- El usuario puede solicitar reportes del mismo.

Tabla 3. Consultar los registros de pedidos

Fuente: Elaboración Propia

d) GESTIÓN PARA REALIZAR UNA VENTA

La gestión de realizar una venta, se describe en forma de caso de uso a continuación, donde
se observa las actividades que realizan los usuarios involucrados:

Figura 3. . Diagrama de caso de uso – Realizar venta

Fuente: Elaboración Propia

La siguiente tabla describe el caso de uso de registro de una venta de uno o varios productos.

Nombre Realizar venta de productos

Descripción En este caso de uso permite el control del registro de las ventas
realizadas.

62
 Actores Encargado de ventas

Precondición El usuario debe estar autentificado.

El producto está registrado y almacenado.

Postcondición Los datos de la venta se registran y son almacenados en la base

de datos.

Flujo de Básico
Eventos
1.- El encargado de ventas entra al sistema.

2.- El usuario registra los datos necesarios de la venta,

seleccionando producto o productos y cantidades que se
venderán.

3.- El usuario Finaliza la venta.

Alternativo

1.- Si el sistema encuentra datos que no concuerdan con los

requeridos, el sistema despliega una alerta de informe que no
se introdujo los datos.

Tabla 3. Realizar venta de productos

Fuente: Elaboración Propia

e) GESTIÓN DE CLIENTE

La gestión de clientes, se describe en forma de caso de uso donde se observa las actividades
que realizan los usuarios involucrados en el caso de uso en el sistema, en el registro y
nidificación de datos de usuario.

63
 Figura 3. . Diagrama de caso de uso – Gestión de Cliente
Fuente: Elaboración Propia

La siguiente tabla describe el caso de uso de registro de un nuevo cliente el sistema, para
poder tener acceso a sus datos y poder mejorar la atención a los mismos, con una atención
más personalizada.

Nombre Ingresar nuevo cliente

Descripción En este caso de uso el usuario ingresa un nuevo cliente al

sistema, para que posteriormente se realice in trato más
personalizado.

64
 Actores Encargado de ventas, administrador.

Precondición El usuario debe estar autentificado.

Postcondición Si el usuario ha realizado el ingreso de un nuevo cliente

correctamente, esta queda almacenada en el sistema y
muestra un mensaje de confirmación.

Flujo de Básico
Eventos
1. El usuario accede a la pantalla de nuevo cliente.
2. El usuario selecciona el nuevo cliente, para registrar
datos de un cliente nuevo.
3. El usuario registra datos de necesarios del cliente.
4. Los datos son validados y guardados.

Alternativo

1.- Si el sistema encuentra datos que no concuerdan con los

requeridos, el sistema despliega una alerta de informe que
no se introdujo los datos.

Tabla 3. Ingresar nuevo cliente

Fuente: Elaboración Propia

La siguiente tabla describe el caso de uso donde los usuarios pueden realizar cambios a los
datos ya existentes.

Nombre Actualizar datos de cliente

65
Descripción En este caso de uso, el usuario puede modificar los datos
de clientes según sea necesario.

Actores Administrador, encargado de ventas.

Precondición El usuario debe estar autentificado.

El usuario debe realizar la búsqueda del cliente para

proceder a modificarla.

Postcondición Si el usuario ha realizado la modificación de cliente

correctamente, esta queda almacenada en el sistema y
muestra un mensaje de confirmación.

Flujo de Básico
Eventos 1.- El usuario accede a la pantalla web de modifica datos
de cliente.

2.- El usuario registra las modificaciones de datos

necesarios del cliente.

3.- Los datos son validados y guardados.

Alternativo

1.- Si el sistema encuentra datos que no concuerdan con

los requeridos, el sistema despliega una alerta de informe
que no se introdujo los datos.

Tabla 3. Actualizar datos de cliente

Fuente: Elaboración Propia

66
La siguiente tabla describe el caso de uso donde los usuarios pueden obtener un cuadro
estadístico, que indica que usuario es el más asiduo a la empresa, de esta forma poder
contribuir a la toma de daciones.

Nombre Generar estadísticas

Descripción En este caso de uso en usuario podrá ver cuán asiduos son
los clientes con la empresa, con la presentación de cuadros
estadísticos.

Actores Administrador, encargado de Ventas, secretaria

Precondición El usuario debe estar autentificado.

Deben existir datos almacenados de clientes.

Postcondición Si existen datos registrados de cliente y sus compras en la

empresa, el sistema mostrara el cuadro estadístico.

Básico
Flujo de
Eventos 1.- El usuario accede a la pantalla de estadísticas.

2.- El sistema muestra los nombres de clientes y quienes

son más asiduos de la empresa.

Tabla 3. Generar reportes estadísticos

Fuente: Elaboración Propia

f) DIFUSIÓN DE SERVICIOS OFRECIDOS POR LA EMPRESA

En el siguiente diagrama se describe como el usuario añade datos al sistema sobre los
servicios que ofrecen.

67
 Figura 3. . Diagrama de caso de uso – Difusión de servicios
Fuente: Elaboración Propia

La siguiente tabla describe el caso de uso de registro de un nuevo servicio ofrecido por la
empresa.

Nombre Ingresar Servicio

Descripción En este caso de uso el usuario podrá registrar los servicios que
la empresa brinda a sus clientes.

Actores Administrador.

Precondición El usuario debe estar autentificado.

68
 Postcondición Si el usuario ha realizado el ingreso de un nuevo servicio
correctamente, este queda almacenada en el sistema y muestra
un mensaje de confirmación

Flujo de Básico
Eventos
1.- El usuario ingresa la opción de servicios.

2.- el usuario registra los datos de un nuevo servicio que ofrece

la empresa.

3.- Los datos son validados e ingresados en los sistemas.

Alternativo

1.- Si los datos requeridos, al ingresar el nuevo servicio no han

sido los correctos o existe duplicidad de información, se
muestra una notación de aviso y se solicita el ingreso
nuevamente.

Tabla 3.. Ingreso de nuevo servicio que ofrece la empresa

Fuente: Elaboración Propia

La siguiente tabla describe el caso de uso de modificación de los datos de un servicio ofrecido
por la empresa.

Nombre Modificar servicios que ofrece la empresa

Descripción En este caso de uso los usuarios

Actores Encargado de Ventas

69
Precondición El usuario debe estar autentificado.

Postcondición Al realizar la modificación de información del servicio

seleccionado, se muestra un mensaje de datos guardados
correctamente.

La información editada queda almacenada en el sistema.

Flujo de Básico
Eventos
1.- El usuario accede a la pantalla de administración de
servicio.

2.- El usuario selecciona la opción de modificar algún

servicio.

3.- Se despliega el detalle total del servicio y el usuario

edita los campos necesarios.

4.- Al modificar los campos, se procede a guardar la nueva

información en el sistema.

5.- Los datos son validados y guardados.

Alternativo

1.- Si los datos requeridos, al ingresar el nuevo servicio no

han sido los correctos o existe duplicidad de información,
se muestra una notación de aviso y se solicita el ingreso
nuevamente.

Tabla 3. Modificar Servicio que ofrece la empresa

Fuente: Elaboración Propia

70
3.3.3. DISEÑO CONCEPTUAL

3.3.3.1. MODELO CONCEPTUAL

El diagrama de diseño conceptual, describe cada una de las clases de dominio del sistema
web y la relación con cada una de las clases, se presenta el a siguiente figura

Figura 3.. Diseño de clases

Fuente: Elaboración Propia

71
3.3.3.2. MODELO FÍSICO

En la siguiente figura se muestra el diagrama físico del sistema web, donde se observa las
tablas representativas del sistema.

Figura 3.. Diseño Físico

Fuente: Elaboración Propia

3.3.4. DISEÑO DE NAVEGACIÓN

En el diagrama navegación general. Se describe la función de cada actividad del sistema en

forma general y como el usuario final podría navegar.

72
 Figura 3. . Diagrama de Navegación general

3.3.4.1. GESTIÓN DE USUARIO

El diseño de navegación de la administración de usuario, muestra las opciones de navegación,

partiendo del registro de usuario.

Figura 3.. Diagrama de Navegación – Gestión de Usuario

73
3.3.4.2. GESTIÓN DE PRODUCTOS

El diseño de navegación de la administración de producto, muestra las opciones de

navegación, partiendo del registro de producto.

Figura 3. . Diagrama de Navegación – Gestión de Producto

3.3.4.3. GESTIÓN DE PEDIDOS

El diseño de navegación de la gestión de pedido, muestra las opciones de navegación.

Figura 3. . Diagrama de Navegación – Gestión de Pedidos

74
3.3.4.4. REALIZAR VENTA DE PRODUCTO

El diseño de navegación de la realizar una venta, muestra las opciones de navegación que se
realizan al registrar una venta.

Figura 3. . Diagrama de Navegación – Realizar Venta de producto

3.3.4.5. GESTIÓN DEL CLIENTE

El diseño de navegación de seguimiento del cliente, muestra las opciones de navegación que
se realizan desde el registro de cliente, hasta poder ver cuán asiduo es cada cliente de la
empresa.

Figura 3.. Diagrama de Navegación – Gestión de Cliente

75
3.3.4.6. DIFUSIÓN DE SERVICIOS

El diseño de navegación de difusión de servicios, muestra las opciones de navegación que se

realizan al registrar un servicio y la manipulación de los mismos como altas bajas y
modificaciones.

Figura 3.. Diagrama de Navegación – Difusión de servicio

Fuente: Elaboración Propia

3.3.5. DIAGRAMA DE PRESENTACIÓN

Los diagramas de presentación, que se describen a continuación muestran como están

estructuradas las páginas del sistema web. A continuación de observa el diagrama de inicio
de sistema.

76
 Figura 3.. Diagrama de Presentación – Inicio

3.3.5.1. GESTIÓN DE USUARIO

El diagrama de presentación de la administración del usuario, permite visualizar las interfaces

que implica el registro de empleado así como sus modificaciones.

Figura 3.. Diagrama de Presentación – Gestión de Usuario – Lista de Empleados

77
La siguiente imagen describe el diagrama de presentación de la pantalla de registro de nuevo
empleado.

Figura 3.. Diagrama de Presentación – Gestión de Usuario – Nuevo Empleado

3.3.5.2. GESTIÓN DE PRODUCTOS

El diagrama de presentación de la administración de productos, permite visualizar las

interfaces que implica el registro de productos así como sus modificaciones.

78
 Figura 3.. Diagrama de Presentación – Gestión de Producto – Lista de producto

La siguiente imagen describe la pantalla de registro de nuevo producto.

Figura 3.. Diagrama de Presentación – Gestión de Producto – Nuevo Producto

79
3.3.5.3. GESTIÓN DE PEDIDOS

El diagrama de presentación de la administración de productos, permite visualizar las

interfaces que implica el registro de productos así como sus modificaciones.

Figura 3.. Diagrama de Presentación – Gestión de Pedidos – Lista de Pedidos

La siguiente imagen describe la pantalla de registro de un pedido.

Figura 3.. Diagrama de Presentación – Gestión de Pedidos – Realizar un pedido

80
3.3.5.4. REALIZAR VENTA DE PRODUCTO

El diagrama de presentación de realizar venta, permite visualizar las interfaces que se

presenta al registro de una venta.

Figura 3.. Diagrama de Presentación – Realizar Venta – Ingresa datos de cliente

La siguiente imagen describe la pantalla de realizar una venta.

Figura 3.. Diagrama de Presentación – Realizar Venta – selección de producto

81
 La siguiente imagen describe la pantalla donde se observa el listado de ventas.

Figura 3.. Diagrama de Presentación – Realizar Venta – Lista de Ventas

3.3.5.5. GESTIÓN DE CLIENTE

El diagrama de presentación de seguimiento de cliente, permite visualizar las interfaces que

se presenta en la web.

Figura 3.. Diagrama de Presentación – Gestión de Cliente – Lista de Clientes

82
La siguiente imagen muestra la pantalla de modificar datos de cliente.

Figura 3.. Diagrama de Presentación – Gestión de Cliente – Modificar datos

3.3.5.6. DIFUSIÓN DE SERVICIOS OFRECIDOS POR LA EMPRESA

El diagrama de presentación de difusión de servicios, permite visualizar las interfaces que se

presenta en la web.

Figura 3.. Diagrama de Presentación – Difusión de servicio - Lista

83
3.4. FASE DE CONSTRUCCIÓN

3.4.1. PANTALLAS DE SISTEMA

A continuación se muestra las pantallas del sistema web, y las pantallas de operaciones
esenciales que se realiza.

 Ventana Principal: Un usuario al ingresar ala link de la página tiene esta pantalla,
donde si tiene un nombre de usuario podrá ingresar al sistema.

Figura 3.. Diseño de Construcción – Ventana Inicio de Sesión

Fuente: Elaboración Propia

 Pantalla de inicio: Posteriormente del ingreso al sistema, de acuerdo al acceso que

tiene cada usuario, se muestra la pantalla principal que le corresponde, donde puede
elegir la actividad que desea realizar.

84
 Figura 3.. Diseño de Construcción – Pantalla Principal
Fuente: Elaboración Propia
 Ventana de control de usuario

En la siguiente imagen se puede observar la lista de empleados registrados en el sistema,

donde podrá modificar datos de usuario o deshabilitar el mismo, para poder realizar estas
acciones debe tener los permisos necesarios.

Figura 3.. Diseño de Construcción – Gestión de Usuario

Fuente: Elaboración Propia

La siguiente imagen se observa el registro de un nuevo usuario al sistema, donde el usuario

puede elegir el empleado registrado y la categoría de usuario, también su nombre de usuario
y su contraseña.

85
 Figura 3.. Diseño de Construcción – Registro de nuevo usuario de Usuario
Fuente: Elaboración Propia

En la siguiente pantalla se observa todas las modificaciones que han existido de la cuenta de
un respectivo usuario, con la fecha respectiva de cada modificación

Figura 3.. Diseño de Construcción – Reporte de usuario

Fuente: Elaboración Propia

86
  Ventanas Gestión de Productos

Se puede observar la lista de productos, con el nombre de cada uno, y su precio e imagen
respectiva para su mejor elección, también existe la posibilidad de editar o ingresar un nuevo
producto.

Figura 3.. Diseño de Construcción – Gestión de Productos- Lista de productos

Fuente: Elaboración Propia

La siguiente imagen muestra el formulario de modificación de un determinado producto,

debe llenar todos los campos necesariamente.

87
 Figura 3.. Diseño de Construcción – Gestión de Productos- Detalle de Producto
Fuente: Elaboración Propia
 Realizar Venta

En el formulario de realizar una venta de debe llenar los datos de cliente, debe llenar todos
los campos

Figura 3.. Diseño de Construcción – Realiza Venta- ingresa datos de cliente

Fuente: Elaboración Propia

88
Con el boton siguiente, los usuarios podran ver la lista de productos y podran elegir la
cantidad y los productos que desean adquirir, el sistema al finalizar las elecciones de
productos y llenado de datos.

Figura 3.. Diseño de Construcción – Realiza Venta

Fuente: Elaboración Propia

El sistema manda una alerta con todo el detalla de la acción realizada. Luego de esta pantalla
pasa al reporte y posterior cancelación de la venta.

Figura 3.. Diseño de Construcción – Realiza Venta

Fuente: Elaboración Propia

89
Podrá imprimir el reporte de la venta realiza, se muestra todo el detalle en formato pdf.

Figura 3.. Diseño de Construcción – Realiza Venta

Fuente: Elaboración Propia

3.4.2. PRUEBA FUNCIONALES DE SISTEMA

Una vez finalizado el desarrollo de las primeras cuatro etapas de OpenUP, se realiza las
pruebas necesarias para garantizar el funcionamiento del sistema, tomando en cuenta los caso
de uso representativos del mismo. El uso de las pruebas funcionales es para asegurar correcto
trabajo de entrada de datos, la navegación en el sistema, procedimientos y obtención de
resultados.

PROCEDIMIENTO DESCRIPCIÓN VALOR

Prueba previa requerida Registro de usuario Si

90
Usuario Administrador,
Secretaria,
Encargado de
Ventas

SECUENCIA DE PRUEBA

PROCEDIMIENTOS RESULTADOS CALIFICACIÓN DE

ESPERADOS FUNCIONALIDAD

Ingresa al sistema con el nombre de Valida el sistema el SI

usuario y contraseña ingreso

FALLAS ENCONTRADAS DESCRIPCIÓN GRAVEDAD

Ninguna Ninguna -

Pasos de Prueba Resultados esperados Pos. Neg.

1 Desde la pantalla de login se El usuario ingresara al sistema X

ingresa al sistema con un usuario si los datos son correctos, y
y contraseña. según el grado de privilegios
que tenga.

2 Una vez que se ingresa de forma El usuario debe tener acceso a X

autentificada se comprueba que cada uno de las áreas según su
tenga acceso a todas las áreas que privilegio.

91
 puede realizar según sus
privilegios.

3 Los usuarios ingresan a la gestión En la gestión de cuenta pueden X

de cuenta. cambiar si contraseña y login.

4 El administrador puede registrar a El usuario debe tener acceso a X

un nuevo empleado y también la modificación de datos de
nuevo usuario. empleado y de usuario del
sistema.

COMENTARIO DE LA PRUEBA REALIZADA

Las pruebas de ingreso al sistema y de gestión de usuario se efectuaron con absoluta

normalidad. Se obtuvo el resultado esperado en cuanto a validación de usuario y clave,
se mostraron alertas respuestas al ingresar con un nombre o cable no registrados.

Tabla 3. Caso de prueba – Gestión de Usuario

Fuente: Elaboración Propia

PROCEDIMIENTO DESCRIPCIÓN VALOR

Prueba previa requerida Autentificado y con Si

privilegios para el área

Usuario Administrador, Encargado de

Ventas

92
SECUENCIA DE PRUEBA

PROCEDIMIENTOS RESULTADOS CALIFICACIÓN

ESPERADOS

Registrar datos de nuevo El sistema registre los datos SI

producto y/o modificar datos añadidos o modificados
de producto.

FALLAS ENCONTRADAS DESCRIPCIÓN GRAVEDAD

Ninguna Ninguna -

Pasos de Prueba Resultados esperados Pos. Neg.

1 Se prueba el registro de un Se debe registrar un nuevo cliente y el X

nuevo empleado informe de que la operación se realizó
con éxito.

2 Se elige un producto Posteriormente al cambio los valores X

existente y se procede a son cambiado, y un mensaje de
editar los valores de su confirmación.
registro.

3 Eliminación de un Posteriormente a la eliminación los X

producto valores son cambiados y un mensaje de
confirmación.

93
COMENTARIO DE LA PRUEBA REALIZADA

Las pruebas de gestión de productos se efectuaron con absoluta normalidad. Se obtuvo

el resultado esperado en cuanto al registro y modificación de usuario, se mostraron
alertas de respuestas al modificar o agregar un muevo producto.

Tabla 3. Caso de prueba - Gestión de Productos

Fuente: Elaboración Propia

PROCEDIMIENTO DESCRIPCIÓN VALOR

Prueba previa requerida Autentificado y con Si

privilegios para el área

Usuario Cliente, encargado de ventas.

SECUENCIA DE PRUEBA

PROCEDIMIENTOS RESULTADOS CALIFICACIÓN DE

ESPERADOS FUNCIONALIDAD

Gestión de pedidos y Sistema debe registrar los SI

emisión de reportes de datos de nuevos pedidos y
pedidos. poder realizar emisión de
reportes.

FALLAS DESCRIPCIÓN GRAVEDAD

ENCONTRADAS

94
Ninguna Ninguna -

Pasos de Prueba Resultados esperados Pos. Neg.

1 Se prueba el registro de Se debe registrar un nuevo pedido y el X

un nuevo pedido. informe de que la operación se realizó con
éxito.

2 Reporte de pedidos Se muestra el reporte de los pedidos en X

formato pdf.

COMENTARIO DE LA PRUEBA REALIZADA

Las pruebas de registro de nuevos pedidos que realiza el cliente y la gestión de los
pedidos en cuando a la emisión de reportes para la posterior entrega del producto por
el encargado de ventas se efectuaron con absoluta normalidad obteniendo el resultado
esperado mostraron alertas de las acciones registradas.

Tabla 3. Caso de prueba - Gestión de pedidos

Fuente: Elaboración Propia

PROCEDIMIENTO DESCRIPCIÓN VALOR

Prueba previa requerida Autentificado y con Si

privilegios para el área

Usuario Encargado de ventas.

95
SECUENCIA DE PRUEBA

PROCEDIMIENTOS RESULTADOS CALIFICACIÓN DE

ESPERADOS FUNCIONALIDAD

Gestión de ventas y emisión SI

de reportes de ventas.

FALLAS ENCONTRADAS DESCRIPCIÓN GRAVEDAD

Ninguna Ninguna -

Pasos de Prueba Resultados esperados Pos. Neg.

1 Se prueba el registro de un Se debe registrar nuevos datos y el X

nuevo. informe de que la operación se realizó.

2 Se elige la lista para Se muestra el reporte de los pedidos en X

obtener su reporte formato pdf.

COMENTARIO DE LA PRUEBA REALIZADA

Las pruebas de registro de nueva ventas y la gestión de venta en cuando a la emisión

de reportes por el encargado de ventas se efectuaron con absoluta normalidad
obteniendo el resultado esperado mostraron alertas de las acciones registradas.

Tabla 3. Caso de prueba - Realizar venta

Fuente: Elaboración Propia

96
PROCEDIMIENTO DESCRIPCIÓN VALOR

Prueba previa Autentificado y con privilegios para Si

requerida el área

Usuario Administrador, Encargado de Ventas,

secretaria

SECUENCIA DE PRUEBA

PROCEDIMIENTO RESULTADOS ESPERADOS CALIFICACIÓN

S

Registrar datos de El sistema registre los datos añadidos SI

nuevo cliente y/o o modificados
modificar datos de
producto.

FALLAS DESCRIPCIÓN GRAVEDAD

ENCONTRADAS

Ninguna Ninguna -

Pasos de Prueba Resultados esperados Pos. Neg.

1 Se prueba el Se debe registrar un nuevo cliente y el informe X

registro de un de que la operación se realizó con éxito.
nuevo cliente

97
 2 Se elige un registro Posteriormente al cambio los valores son X
de cliente existente cambiado, y un mensaje de confirmación.
y se procede a
editar los valores
de su registro.

3 Reporte de datos Lista de cliente o clientes completa y oportuna. X

de clientes.

COMENTARIO DE LA PRUEBA REALIZADA

Las pruebas de gestión de cliente se efectuaron con absoluta normalidad. Se obtuvo el

resultado esperado en cuanto al registro y modificación de clientes, se mostraron alertas
de respuestas al modificar o agregar un muevo cliente.

Tabla 3. Caso de prueba - Gestión de Cliente

Fuente: Elaboración Propia

3.5. FASE DE TRANSICIÓN

3.5.1. PRUEBAS DE STRESS

Dentro de la pruebas de rendimiento de software se realizan o se encuentran las pruebas de

estrés son las que evalúan y ponen aprueba la robustez y la confiabilidad del software
sometiéndolo a condiciones de uso extremas. Entre estas condiciones se incluyen el envió
excesivo de peticiones y la ejecución en condiciones de hardware limitadas. Para aplicaciones
web, una posible condición extrema puede ser el acceso de un enorme número de usuarios
en poco tiempo.

El objetivo de las pruebas de estrés es saturar el programa hasta un punto de quiebre donde
aparezcan defectos potencialmente peligrosos, no para decir que el sistema no funciona, lo

98
que se intenta es mejorar el sistema reduciendo riesgos que puedan dar origen a una caída del
sistema.

3.5.1.1. LOAD IMPACT

Impacto de carga ofrece pruebas y presentación de informes de carga como un servicio en

línea para el comercio electrónico y de negocio a negocio (B2B) sitios en todo el mundo.

¿Qué es Load Impact?

Impacto de carga ofrece una solución simple pero esencial para startups y empresas que
buscan a escala. Impacto de carga proporciona servicios de pruebas de carga en-demanda que
se puede acceder desde el navegador.

Impacto de carga es uno de esos servicios que permite al usuario generar carga de diversas
partes del mundo para llevar a cabo una prueba de esfuerzo en su sitio web.

El proyecto fue sometido a pruebas de estrés con la pagina Load Impact y los resultados de
muestran en la siguiente imagen.

Figura 3.. Diseño de Construcción – Prueba de stress

En la imagen anterior se muestra los resultados que Load Impact emite en cuanto al sistema.
Se observa que indican el rendimiento del mismo en un instante donde existen más de 50

99
usuarios conectados, los resultados indican que el sistema funciona y responde bastante bien
cuando existe esta saturación de usuarios conectados, este resultado servirá para mejorar el
sistema, de esta forma cumplir con las expectativas del usuario en su totalidad.

3.5.2. INSTALACIÓN DEL SISTEMA

Las actividades para la implementación del sistema.

 Instalar y/o configurar el sistema operativo.

 Instalar y configurar los servidores que requiere nuestro sistema (Apache).
 Instalar y configurar el gestor de base de datos (MySQL).
 Cargar el sistema para la empresa.
 Se establecen el usuario y las contraseñas en el gestor de base de datos.
 Se realiza la capacitación a los usuarios.

3.5.3. CAPACITACIÓN DE USUARIO

La capacitación del personal que maneja el sistema de información, se realizara de los

siguientes puntos al usuario de la empresa.

 Ingreso al sistema: Para que puedan realizar sus distintas actividades en el mismo.
 Gestión de usuario: El usuario con más privilegios puede realizar la gestión de
usuarios, donde podrá añadir modificar datos de usuario como de empleados.
 Registro de Pedido y ventas: El usuario que realiza ventas será capacitado para el
registro de una venta. Los pedidos son realizados por los clientes en línea.
 Gestión de producto: registro y modificación de características de los productos que
están disponibles para la venta.
 Emisión de reportes: los usuarios que requieran la emisión de reportes.

La capacitación y el manual de usuario serán de gran ayuda para poder manejar de manera
óptima el sistema.

100
 CAPITULO IV

CALIDAD Y SEGURIDAD

4.1. CALIDAD

El desarrollar un software de calidad es el objetivo de todo desarrollador, por tanto se le

dedica muchos esfuerzos, pero también cabe mencionar que no se logra la perfección en el
producto de software, pero se debe tomar en cuenta que todo software debe cumplir y/o
superar las expectativas del cliente. Si cumple esta característica tendrá la dominación de un
software de alta calidad.

En la actualidad existen diversas opciones, los estándares y modelos de evaluación y mejora

de los procesos de software que están relacionados con la calidad, el presente proyecto usara
la técnica WEBSITE ISO 9126.

4.1.1. TÉCNICA WEBSITE ISO 9126

El objetivo de esta técnica es alcanzar la calidad necesaria para satisfacer las necesidades del
cliente. Esta técnica tiene la característica de evaluar dos ámbitos; el producto final y los
procesos.

Los criterios de evaluación de calidad que tiene esta norma WEBSITE ISO 9126 son:
Usabilidad, funcionalidad, confiabilidad, Matenibilidad, portabilidad.

En base a estos criterios se desarrollara la evaluación de calidad del presente proyecto, para
brindarle al usuario, facilidad, ahorro económico y dar al cliente seguridad en su información.

4.1.1.1. USABILIDAD

La usabilidad consiste de un conjunto de atributos que permite evaluar el esfuerzo necesario

que deberá invertir el usuario para utilizar el sistema, es decir realizar una serie de preguntas

101
que permiten ver cuán sencillo, fácil de aprender y manejar es para los usuarios. En la
siguiente tabla se observa estos criterios en niveles de porcentajes a los que llego el sistema
en cuanto a su comprensibilidad, para el usuario, y posteriormente se da el porcentaje final
de usabilidad del sistema.

En La siguiente tabla se halla el nivel de usabilidad del sistema:

NRO PREGUNTA RESPUESTAS PORCENTAJE

SI NO

1. ¿El sistema es comprensible? 8 0 1.00

2. ¿El sistema es agradable a la vista? 7 1 0.88

3. ¿El sistema hace lo que dice que hace? 8 0 1.000

4. ¿Las Respuestas del sistema son 7 1 0.88

satisfactorias?

5. ¿Es fácil aprender a manejar el sistema? 7 1 0.88

6. ¿El sistema satisface las necesidades que 7 1 0.88

usted requiere?

Tabla 4. Tabla de Usabilidad del sistema

Fuente: Elaboración Propia

USABILIDAD = 92%
De acuerdo a los datos obtenidos en la tabla de usabilidad, se concluye que el sistema tiene
una usabilidad del 0.92, es decir del 92%. Que de cada 100 personas que lleguen a usar el
sistema 92 personas indican que el sistema es fácil de manejar y comprensible.

102
4.1.1.2. FUNCIONALIDAD

La funcionalidad examina si el sistema satisface los requisitos funcionales esperados. El

objetivo es revelar problemas y errores en lo que concierne a la funcionalidad del sistema y
su conformidad al comportamiento, expresado o deseado por el usuario.

En la siguiente tabla se calcula el punto función, los cuales miden el software desde una
perspectiva del usuario, dejando de lado los detalles de codificación.

a) Técnica Punto función: Esta técnica permite cuantificar el tamaño de un sistema en

unidades independientes del lenguaje de programación y la metodología utilizada.

Para el cálculo de Punto Función se toma en cuenta 5 características de dominio de

información.

 Número de entras de usuario: Se refiere a cada entrada que proporciona datos al

sistema.
 Número de salidas de usuario: Se refiere a cada salida que proporciona el sistema
al usuario, entre estos están: informes, pantallas, mensajes de errores, etc.
 Número de peticiones de usuario: Una petición se define como una entrada
interactiva que produce la generación de alguna respuesta de software en forma de
salidas interactivas.
 Número de Archivos: Se cuenta archivos maestro lógico, estos pueden ser: grupo
lógico de datos, o un archivo independiente.
 Número de interfaces externas: se cuenta las interfaces legibles por la máquina que
se utilizan para transmitir información a otro sistema.

En la siguiente tabla se realiza el cálculo punto función hallando la suma de estas

características y el factor de complejidad, el resultado es el punto función no ajustado.

103
 PARÁMETROS DE CUENTA FACTOR DE TOTALES
ENTRADA COMPLEJIDAD

Número de entradas de usuario 18 * 3 54

Número de salidas de usuario 20 * 4 89

Número de peticiones de usuario 21 * 3 63

Número de archivos 18 * 7 126

Número de interfaces externas 0 * 5 0

Cuenta Total 332

Tabla 4. Calculo de funcionalidad según el punto función

Fuente: Elaboración Propia

Calculo del punto función ajustada. Los valores de Fi, se obtiene de los resultados de la
siguiente tabla, bajo las ponderaciones descritos en la escala.

IMPORTANCIA 0 1 2 3 4 5

ESCALAS
Significativo
importancia
Incremental
Moderado

Esencial
Medio
Sin

104
1.- ¿Requiere el sistema copias de seguridad y de X
recuperación fiable?

2.- ¿Se requiere comunicación de datos? X

3. ¿Existe funciones de procesos distribuidos? X

4. ¿Es critico el rendimiento? X

5.- ¿El sistema web será ejecutado el SO. Actual? X

6.- ¿Se requiere una entrada interactiva para el X

sistema?

7.- ¿Se requiere que el sistema tenga entradas a X

datos con múltiples ventanas?

8.- ¿Se actualiza los archivos de forma X

interactiva?

9.- ¿Son complejas las entradas, salidas, os X

archivos o las peticiones?

10.- ¿Es complejo el procesamiento interno del X

sistema?

11.- ¿se ha diseñado el código para ser X

reutilizado?

12.- ¿Se ha diseñado el sistema para facilitar al X

usuario el trabajo y ayudarlos a encontrar la
información?

105
 Cuenta total ∑(fi) = 51

Tabla 4. Tabla de Ajuste de complejidad

Fuente: Elaboración Propia

 Para el ajuste se utiliza la ecuación:

PF= cuenta total * (grado de confiabilidad + Tasas de Error * ∑(fi) )

PF= 332 *(0.65+ 0.01 * 51)

PFobtenida=385.12

 Para el ajuste se utiliza la ecuación para hallar el punto función ideal al 100% de los
factores que seria 60:

PF= 332 *(0.65+ 0.01 * 60)

PFideal=415

 Calculando del % de funcionalidad real:

PFreal =PFobtenida/PFideal

𝟑𝟖𝟓.𝟏𝟐
FUNCIONALIDAD = ∗ 𝟏𝟎𝟎
𝟒𝟏𝟓

FUNCIONALIDAD= 93%

Interpretando, el sistema tiene una funcionalidad o utilidad del 93% para la empresa, lo que
indica que él es sistema cumple con los requisitos funcionales de forma satisfactoria.

106
4.1.1.3. CONFIABILIDAD

La confiabilidad permite evaluar la relación entre el nivel de funcionalidad y la cantidad de

recursos usados, es decir, representa el tiempo que el software está disponible para su uso, la
misma se calcula utilizando la privacidad de que un sistema presente fallas:

 Comportamiento con respecto al tiempo: Atributos del software relativos a los

tiempos de respuesta y de procesamiento de los datos.
 Comportamiento con respecto a Recursos: Atributos software relativo a la cantidad
de recursos usados y la duración de su uso en la realización de funciones.

La función a continuación muestra el nivel de confiabilidad del sistema:

𝑭(𝒕) = (𝑭𝒖𝒏𝒄𝒊𝒐𝒏𝒂𝒍𝒊𝒅𝒂𝒅) ∗ 𝒆−𝛌𝐭

Se observa el trabajo hasta que se observa un fallo en un instante t, la función es la siguiente.

Probabilidad de hallar una falla: P(T<=t)=F(t)

Probabilidad de hallar una falla : P(T>t)=1-F(t)

Funcionalidad = 93 %

λ = 0.01 (es decir 1 error en cada 6 ejecuciones)

t=12 meses.

Hallamos la confiabilidad del sistema

1
𝐹(12) = 0.93 ∗ 𝑒 −6∗12
𝑭(𝟏𝟐) = 𝟎. 𝟏𝟐𝟒
Con este resultado podemos decir que la probabilidad que el sistema no presente fallas es de
0.88.

107
 𝑪𝑶𝑵𝑭𝑰𝑨𝑩𝑰𝑳𝑰𝑫𝑨𝑫 = 𝟖𝟖%

Para concluir decimos que el sistema tiene un grado de confiabilidad del 88% durante los
próximos 12 meses, es decir, que de cada 100 ejecuciones existen 13 fallas de elección del
sistema.

4.1.1.4. MANTENIBILIDAD

La Mantenibildiad se refiere a los atributos que permiten medir el esfuerzo necesario para
realizar modificaciones al software, ya sea por la corrección de errores o por el incremento
de funcionalidad.

Para hallar mantenibilidad del sistema se utiliza el índice de madurez de software (IMS), que
proporciona una indicación de la estabilidad de un producto de software.

Se determina la siguiente función (IMS):

𝑀𝑡 − (𝐹𝑐 + 𝐹𝑎 + 𝐹𝐸)
𝐼𝑀𝑆 =
𝑀𝑡

Mt: Numero de módulos total de la versión actual

Fc: Numero de módulos de la versión actual que se cambiaron.

Fa: Numero de módulos de la versión actual que se añadieron.

FE: Numero de módulos de la versión anterior que se eliminaron en la versión actual.

11 − (1 + 0 + 0)
𝐼𝑀𝑆 = = 0.91
11

La interpretación a este resultado establece un 91%, lo que indica que no requiere de

mantenimiento inmediatamente.

108
4.1.1.5. PORTABILIDAD

En este caso, se refiere a la habilidad del software de ser transferido de un ambiente a otro, y
considera los siguientes aspectos:

 Adaptabilidad: Evalúa la oportunidad para adaptar el software a diferentes

ambientes sin necesidad de aplicarle modificaciones.
 Facilidad de Instalación: Es el esfuerzo necesario para instalar el software en un
ambiente determinado.
 Conformidad: Permite evaluar si el software se adhiere a estándares o convenciones
relativas a portabilidad.
 Capacidad de reemplazo: Se refiere a la oportunidad y el esfuerzo usado en sustituir
el software por otro producto con funciones similares.

El sistema fue desarrollado en PHP y sistemas operativos, y de la base de datos MySQL, se

ejecuta en todos los servidores web. También se comprobó que en los distintos navegadores
más usados en nuestra área, se le da una calificación del 95% de portabilidad.

El resultado del 95% indica que el desenvolvimiento del sistema es correctos en los distintos
navegadores.

4.1.1.6. RESULTADOS

El factor de calidad total está directamente relacionada con el grado de satisfacción con el
usuario que ingresa al sistema.

CARACTERÍSTICAS RESULTADO

Usabilidad 92%

Funcionalidad 93%

109
 Mantenibilidad 91%

Portabilidad 95%

Confiabilidad 88%

Evaluación de calidad total 92%

Tabla 4. Resultados
Fuente: Elaboración Propia

El nivel de aceptación satisfactorio, indica que los valores de preferencia se encuentran en el

rango de 60-100.

La calidad del sistema corresponde al 92%, lo que se interpreta como la satisfacción que tiene
un usuario al interactuar con el sistema.

4.2. SEGURIDAD

4.2.1. SEGURIDAD DE BASE DE DATOS

Se usó como base de datos MySQL. En cuanto a la forma de resguardo se realiza:

 Cuando una acción del usuario en el sistema requiere o solicita algunos registros de
la base datos, existe una conexión segura para esta acción.
 Para la seguridad de datos del sistema se tienen registrado de nombre de usuario y
contraseña de acceso, según su nivel de acceso pueda realizar actividades en el
sistema.

La información en una empresa es muy valiosa, por tanto su resguardo es fundamental, la

conexión a la base de datos y el cierre de la conexión es de forma automática.

110
En cuanto a las amenazas de SQL Injection que es una de las más comunes amenazas,
implemento medidas como la restricción de caracteres especiales en los campos de ingresos
de texto.

4.2.2. SEGURIDAD CON AUTENTIFICACIÓN

Este control se refiere al control de sesión o verificación de la autentificación de un usuario

con nombre de usuario y una contraseña, que ya anteriormente asignados.

Mientras el usuario ingresa la contraseña, esta no se puede mostrar en pantalla, también cabe
resaltar que la contraseña de cada usuario esta encriptado por el algoritmo md5.

En la siguiente imagen observamos la pantalla de autentificación de la empresa.

Figura 4.. Autentificación de usuario

Elaboración propia

4.2.3. SEGURIDAD DE LA APLICACIÓN

Se desarrolla un módulo de control de acceso al sistema para la restricción del acceso a

usuario no autorizado. Este módulo verifica y autoriza a los usuarios por medio de permisos
que son otorgados por el adiestrador del sistema, haciendo uso de las sesiones de PHP. Se
realiza el registro del usuario que modifica la información la base de datos, para esto se
registra en cada tabla el identificar del usuario que modifica la información.

111
 CAPITULO V

ANÁLISIS COSTO Y BENEFICIO

5.1. ESTIMACIÓN DE COSTO BENEFICIO

La estimación de costo y beneficio son requeridos para el desarrollo de software. Se han

producido varios modelos algorítmicos como base para estimar el esfuerzo, agenda y costes
de un proyecto software.

La técnica de Análisis de Costo/Beneficio, tiene como objetivo fundamental proporcionar

una medida de la rentabilidad de un proyecto, mediante la comparación de los costos
previstos con los beneficios esperados en la realización del mismo. Esta técnica se debe
utilizar al comparar proyectos para la toma de decisiones. El análisis Costo-Beneficio,
permite definir la factibilidad de las alternativas planteadas o de un proyecto a ser
desarrollado.

La utilidad de la presente técnica es la siguiente:

• Para valorar la necesidad y oportunidad de la realización de un proyecto.

• Para seleccionar la alternativa más beneficiosa de un proyecto.
• Para estimar adecuadamente los recursos económicos necesarios, en el plazo de
realización de un proyecto.

5.2. CALCULO DE COSTO DEL SISTEMA

El Modelo de Construcción de Costo COCOMO (COnstructive COst MOdel), es un modelo

empírico se utiliza para la estimación de costos de un software.

Para realizar el cálculo de costos relacionando al sistema se toma en consideración los

siguientes aspectos:

112
E: Es el esfuerzo en hombre/mes.

KLCD: Es el minero estimado de miles de líneas de código.

5.2.1. ANÁLISIS DE COSTO

El factor de conversión a KLDC se presenta en la siguiente figura que muestra el nivel al que
pertenece la herramienta PHP utilizada en el sistema

LENGUAJE NIVEL FACTOR LDC/PF

C 2.5 128

ANSI BASIC 5 6464

JAVA 6 53

PL/I 4 80

ANSI COBOL 74 3 107

VISUAL BASIC 7.00 46

ASP 9.00 36

PHP 11.00 29

VISUAL C++ 9.50 34

Tabla 5. Conversión de Puntos de Función a KLDC

Fuente: [T-Chambi, 2007]

LDC= PD obtenido* FactorLDC/PF

113
LDC= 332 * 29

LDC=9628

KLDC=9628 / 1000

Miles de líneas de código  KLDC=9.6

Las formulas básicas de esfuerzo, tiempo y personal que se requiere, son las siguientes:

𝒑𝒆𝒓𝒔𝒐𝒏𝒂𝒔
𝑬 = 𝐚𝒃 (𝑲𝑳𝑫𝑪)𝒃𝒃 [ ]
𝒎𝒆𝒔

𝑫 = 𝐜𝒃 𝑬𝒅𝒃 [𝒎𝒆𝒔𝒆𝒔]

Donde:

E: Esfuerzo aplicado en personas por mes.

D: tiempo de desarrollo en meses cronológico.

KLDC: Número estimado de líneas de código distribuidas (en miles).

PROYECTO DE SOFTWARE 𝐚𝒃 𝒃𝒃 𝐜𝒃 𝐝𝒃

Orgánico 2.1 1.01 2.2 0.34

Semi – acoplado 3.0 1.12 2.5 0.35

Empotrado 3.6 1.20 2.5 0.32

Tabla 5. Coeficiente ab y cb y los exponentes bb y db

Fuente: [PRESSMAN, 2002]

114
Los proyectos de software son semi-acoplados ya que son proyectos intermedios en tamaño
y complejidad, esto hace que satisfagan requisitos poco o medio rígido, tal es el caso del
software desarrollado.

• Calculo de esfuerzo:

E= 2.1*(9.63)1.01

E=20.6 [personas/mes]

• Calculo de tiempo:

D=2.2*(20.6)0.34

D=6.15 [mes]

Tiempo  7 meses
• Calculo de personal:

Numero de programadores

E/D = 20.6/6.15

Personas 3.35

Personal  4 personas
• Productividad:

PR= LDC/E

PR=9628 / 20.6

PR=467.38 [LDC/persona mes]

• Costo total del proyecto:

115
 Pago por mes por persona =1500
Costo Mes= 4*1500
Costo Mes  6000

• Costo total del proyecto:

Costo Total=6000*7 = 42000 Bolivianos

Por tanto se concluye que se requieren 4 desarrolladores y un trabajo aproximado de 7 meses

y el costo total del proyecto será de 42000 bolivianos.

Los costos de nuestro sistema se describen en la siguiente tabla:

DESCRIPCIÓN CANTIDAD COSTO CANTIDAD TOTAL

MES MESES

Desarrolladores 4 1500 Bs 7 42000 Bs

Software - Ya se compro - 0 Bs

Equipo 2 Ya existe - 0 Bs

adiestramiento - 750 Bs ½ 750 Bs

TOTAL 42750 Bs

Tabla 5. Análisis de costos

Fuente: Elaboración propia

Lo que lleva a que el costo total dado por COCOMO es de 68250 Bs.

116
5.2.2. BENEFICIO

Los beneficios del presente proyecto de grado para la empresa ITSeven son económicos
como los alcances inmediatos por la rapidez de información que brinda el sistema. El sistema
proveerá accesos y transferencias de información en tiempo real, esto hará que la información
sea oportuna y precisa, a continuación describiremos los beneficios que presentara el sistema:

• Todos los datos están centralizados en una sola base de datos, esto ayuda a que la
información sea oportuna y eficiente.
• Se pueden realizar informes en tiempo real.
• Se evita el gasto innecesario de papel, de esta manera reduce costos de operaciones.
• Con el software se mejora la atención a los clientes, ya que mejorar la velocidad de
procesos.

Estos son algunos de los beneficios que brinda el sistema, pero cabe destacar también que
brindara beneficios en cuanto a ganancias y reducción de costos económicos. La empresa no
realizó ninguna inversión económica inicial en este proyecto lo cual genera un ahorro del
costo estimado del proyecto. En los próximos años solo se gastara en costos de
mantenimientos que son mucho menor a las ganancias que representa la implementación del
sistema.

5.2.2.1. VALOR ACTUAL NETO (VAN)

El método de valor presente neto, considera el valor del dinero en el tiempo y resulta de
comparar el valor presente de los beneficios de un proyecto menos el valor de la inversión
inicial. Cuando el valor presente neto es positivo, el proyecto es viable ya que cubre la
inversión y genera beneficios adicionales. Cuando el valor presente neto es negativo el
proyecto debe rechazarse ya que los beneficios esperados no cubren la inversión inicial.

Entonces, el criterio VAN de decisión es el siguiente:

117
Si VAN >0 el proyecto se acepta (es positivo)

Si VAN <0 el proyecto se rechaza (es negativo)

Este método elimina la desventaja de los dos anteriores en relación con el valor del dinero en
el tiempo, para su cálculo requiere de tiempo y compromiso de este concepto además de una
tasa de descuento para realizar los cálculos.

La fórmula que permite calcular es la siguiente:

𝒏
𝑹𝒕
𝑽𝑨𝑵 = (∑ ) − 𝑰𝟎
(𝟏 − 𝒊)𝒕
𝒕=𝟏

Donde:

Rj= flujo de efectivo (beneficio – costo del periodo j)

t= Periodo de Tiempo que van desde 1 hasta n

i= tasa de rendimiento esperada. (15%)

I0 = Inversión inicial

90310.8
𝑉𝐴𝑁 = ( ) − 13500
∑5𝑡=1(1− 0.15)𝑡

𝑽𝑨𝑵 = 15448.85

El VAN es mayor a la inversión producirá ganancias por encima de la rentabilidad, ya que el

resultado es positivo, podemos decir entonces que es factible el desarrollo del proyecto.

118
5.2.2.2. LA TASA INTERNA DE RETORNO TIR

Inglés: IRR, Internal Rete of Return. Es un indicador de la rentabilidad de un proyecto, la

tasa % de rendimiento anual acumulado que genera una inversión. Su fórmula busca una
tasa de rentabilidad interno que iguale los flujos netos de caja con la inversión inicial.

Suele definirse con la tasa de descuento que iguala el VAN a cero y suele presentarse
complementando al VAN. El importe de la inversión debe incluirse en NEGATIVO en el
rango de los flujos de caja. En términos generales: Las inversiones más interesantes son
aquellas que proporcionan mayor TIR.

𝑄1 𝑄2 𝑄𝑛
0 = −𝐼0 + + + ⋯ +
(1 + 𝑟) (1 + 𝑟)2 (1 + 𝑟)𝑛

r: Es la tasa

Q: los distintos flujos de fondos

 Si TIR es inferior a la tasa de descuento de la empresa, la inversión debería ser

desestimada.
 Si TIR es superior la tasa de descuento de la empresa la inversión es factible.

La ventaja de TIR es que mide la rentabilidad en términos de porcentuales y, en consecuencia,

es de fácil compresión.

TIR a 5 años  33%

El resultado obtenido indica que el valor es superior, por tanto el proyecto es factible.

5.2.2.3. ANÁLISIS DE BENEFICIO/ COSTO

La relación beneficio/costo es un índice que señala si los flujos de caja cubren o no la

inversión, en términos financieros viene a ser lo siguiente:

119
B/C = A / Inversión

A = Flujo 1 / ( 1 + i ) 1 + Flujo 2 / ( 1 + i ) 2 + … + Flujo n / ( 1 + i ) n

A equivale al valor actual de los flujos de caja netos, si A es igual a la inversión entonces la
relación B/C es 1. Si A supera la inversión, entonces la relación B/C es mayor a uno, lo
contrario sucede si A no supera la inversión, en este caso es menor a 1.

Entonces el criterio para elegir un proyecto es: B/C > 1

A continuación aplicando esta dormila a los resultados de VAN de nuestro proyecto nos
indica:

B/C = 15448.85/13500 =1.14

Con este resultado podemos decir que el proyecto es rentable para la empresa. Es decir que
por cada boliviano invertido se recupera 0.14 de ganancia.

120
 CAPITULO VI

CONCLUSIONES Y RECOMENDACIÓN

6.1. CONCLUSIONES

Una vez finalizado el proyecto de grado Sistema Web de Control de pedidos y ventas para la
empresa ITSeven Soluciones Informáticas, se ha logrado alcanzar el objetivo principal
planteado que indicaba el desarrollar un sistema web que mejore el control de pedidos y
ventas, cumpliendo con las necesidades de la empresa.

Tomando en cuenta los objetivos planteados se llega a las siguientes conclusiones:

 Se logra mejorar el tiempo empleado en la atención de ventas de productos a los

clientes, ya que se realiza este proceso de forma más automático y con este proceso
poder evitar errores en cálculos.
 Se logró mejorar el registro de los productos, se tiene las características detalladas de
los mismos y así con estos registros mejorar la atención al cliente.
 Se logra disminuir los tiempos en la generación de reportes tanto de productos,
pedidos y ventas, para así poder tener un mejor control del movimiento de la empresa.
 Se logró tener registro de los clientes y de esta manera poder tratar a cada cliente de
manera personalizada, obteniendo información oportuna y en tiempo real de los
mismos y los pedidos y compras que realizaron en la empresa.
 Se logró que el usuario pueda acceder al sistema con un determinado privilegio por
medio de una autenticación donde debe registrar su nombre de usuario y contra sea.
 Los reportes pueden ser exportados, impresos y guardados en formato PDF.
 El empleo de la metodología OpenUP para el desarrollo de la aplicación Web, ha
facilitado la elaboración y extracción del sistema.

121
6.2. RECOMENDACIONES

A partir de este trabajo se propone las siguientes recomendaciones, con el fin de buscar el
mejoramiento del sistema:

 Con respecto al análisis y diseño del sistema, cuando se requiera la ampliación y

creación de nuevos módulos, ser recomienda primero revisar la documentación para
poder tomar una buena decisión, ya que el sistema presenta elementos reutilizables
que podrían ser utilizados en los módulos nuevos.
 Se recomiendo para trabajos futuros con características similares utilizar algún
framework, que facilite el desarrollo del producto.
 Se recomiendo a la empresa, implementar, utilizar y administrar el sistema de acuerdo
las instrucciones brindadas.
 La revisión periódica por cierto periodo de tiempo es recomendables para eficiencia
y un funcionamiento adecuado del sistema.

122
BIBLIOGRAFÍA
Referencias bibliografías

1. [PRESSMAN, 2002] Pressman Roger S, 2002 INGENIERÍA DE SOFTWARE UN

ENFOQUE PRACTICA. 5ta Edición Madrid España.
2. [T-Matta, 2011] “Sistema web para el control de ventas y facturación usando agentes
inteligentes”, importadora de fármacos “IMESMAT” por: Patricia Evelyn Matta
Catacora UMSA. 2011.
3. [T-Quisbert, 2011] “Sistema de control de ventas e inventarios”, ILLIMANI
NATURAL CONFORT por: Luis Omar Quisbert Lima. UMSA. 2011.
4. [T-Ochoa, 2011] “sistema informático comercial para la gestión de almacenes y
ventas de fármacos utilizando un CMS”, Red De Farmacias Niño De Jesús por: María
Rosario Ochoa Choque.UMSA.2011
5. [T-Chambi, 2007], sistema de Gestión Académica para el Instituto Superior Simón
Bolívar”, 2007
6. IanSommerville, Ingenieria de Software 7ma edición España, Universidad de
Alicante, 2005

Referencias de Internet

1. Ingeniería de Software OPEN UP http://epf.eclipse.org/wikis/openup/index.htm

2. [UWE,2014] UWE –UML BASED WEB ENGIMEERING, LMU – Ludwig-
Maximilians-Universit MünchenInstitute for InformaticsResearch Unit of
Programming and SoftwareEngineering
http://uwe.pst.ifi.lmu.de/teachingTutorialProcessSpanish.html
3. Open Up – businesscase por Garcilaso Jordana, MUG Bs As – Oct/08
4. businesscase.googlecode.com/.../Introducción%20a%20Open%20UP.ppt

123
5. Metodología Agil: Open UP (Open Unificado Process) viernes 16 de agosto de 2013
http://lordpakus.blogspot.com/2013/08/metodologias-agiles-openup-open-
unified.html.
6. [gimson,2012], Metodologías ágiles y desarrollo basado en conocimiento por Lic.
Loraine Gimson, 2012
7. http://sedici.unlp.edu.ar/bitstream/handle/10915/24942/Documento_completo__.pdf
8. [T-ESPE, 2013], Análisis, diseño, desarrollo e implementación de un sistema web
para el control de un taller técnico. Por: Novilos Quirola Gabriel y Coronel Franco
Fernando, 2013. http://repositorio.espe.edu.ec/handle/21000/7622
9. Aplicando uwe un ejemplo didáctico, por Lic. Omar Esgaib y Lic. Maricio Merin,
2009 http://es.slideshare.net/millernegro/aplicando-uwe-un-ejemplo-didactico
10. CRM Customer Relationship Management, Departamento de Lenguaje y Sistemas
Informaticos II www.Kybele.urj.es, 2013
11. ANÁLISIS DEL MODELO DE NEGOCIOS C.R.M. (CUSTOMER
RELATIONSHIP MANAGEMENT), EN LAS EMPRESAS COMERCIALES DE
LA CIUDAD DE PORTOVIEJO Y SU INCIDENCIA EN LA GESTIÓN Y
RELACIÓN CON LOS CLIENTES”, Barreiro y Zorrilla, 2010
http://repositorio.utm.edu.ec/bitstream/123456789/2327/1/TESIS%20DEL%20CR
M.pdfCaracteristicas de una solución CRM, Remberto Yorga 2012
12. Caracteristicas de una solución CRM, Remberto Yorga 2012
http://es.slideshare.net/remyor09/caracteristicas-de-una-solucion-de-crm
13. CRM: GESTIÓN DE LAS RELACIONES CON CLIENTES, Cristhian Herrera,
2010.
http://www.adictosaltrabajo.com/blogs/profiles/detail.php?autor=9&page=2&elems
PerPage=15

124