Blanca Carolina Ramos

UNIVERSIDAD SALESIANA DE BOLIVIA
INGENIERA DE SISTEMAS
PROYECTO DE GRADO
SISTEMA DE GESTIN PARA EL CONTROL DE LA COMERCIALIZACIN DE

LAS LNEAS DE PRODUCTOS DE PANIFICACIN, LCTEOS Y CEREALES
APLICANDO EL MODELO DE GESTIN ORIENTADA AL CLIENTE CRM
CASO: DISTRIBUIDORA CRISURT
Postulante : Blanca Carolina Ramos Calle
Docente Gua : Lic. Carmen Rosa Mollinedo Laura
La Paz Bolivia
2012
1
NDICE DEL PERFIL
1 CAPTULO I: GENERALIDADES............................................................11
1.1 INTRODUCCIN.....................................................................................11
1.2 ANTECEDENTES...................................................................................12
1.2.1 ANTECEDENTES DEL TEMA............................................................12
1.2.2 ANTECEDENTES INSTITUCIONALES.............................................13
1.2.3 ANTECEDENTES DE OTROS PROYECTOS DE GRADO...............14
1.3 PLANTEAMIENTO DEL PROBLEMA.....................................................17
1.3.1 DESCRIPCIN DEL MBITO DE ESTUDIO.....................................17
1.3.2 PROBLEMA CENTRAL......................................................................18
1.3.3 PROBLEMAS ESPECFICOS............................................................18
1.4 OBJETIVOS............................................................................................19
1.4.1 OBJETIVO CENTRAL........................................................................19
1.4.2 OBJETIVOS ESPECFICOS..............................................................20
1.5 JUSTIFICACIONES................................................................................21
1.5.1 JUSTIFICACIN SOCIAL..................................................................21
1.5.2 JUSTIFICACIN TCNICA................................................................21
1.5.3 JUSTIFICACIN PRCTICA.............................................................23
1.5.4 JUSTIFICACIN ECONMICA.........................................................23
1.6 APORTES...............................................................................................24
1.6.1 APORTES DEL PROYECTO..............................................................24
1.6.2 APORTE ACADMICO.......................................................................25
1.7 ALCANCES.............................................................................................25
1.7.1 DELIMITACION MODULAR...............................................................25
1.7.1.1 MDULO DE SEGURIDAD....................................................................25
2
1.7.1.2 MDULO DE REGISTRO DE PROVEEDORES Y PRODUCTOS........25
1.7.1.3 MDULO DE COMPRAS Y ALMACENES.............................................26
1.7.1.4 MDULO DE VENTAS y GESTION DE CLIENTES potenciales...........26
1.8 MTODOS..............................................................................................26
1.8.1 MTODO DE DESARROLLO ORIENTADO A OBJETOS CON UML26
1.8.2 MTODO PARA PROBAR EL SOFTWARE.......................................27
1.8.2.1 PRUEBAS DE CAJA BLANCA...............................................................27
1.8.3 MODELOS..........................................................................................27
1.8.3.1 MODELO PARA LA GESTIN DE LA RELACIN CON LOS CLIENTES

(CRM) 27
1.8.3.2 MODELO ITERATIVO INCREMENTAL..................................................28
1.8.3.3 MODELO DE ESTIMACIN DEL PROYECTO......................................28
1.8.3.4 MODELO PARA EVALUAR LA CALIDAD DEL SOFTWARE.................29
1.8.4 TCNICAS..........................................................................................29
1.8.4.1 TCNICAS PARA RECOLECTAR INFORMACIN...............................29
2 CAPTULO II: MARCO TERICO..........................................................31
2.1 INGENIERA DE SOFTWARE................................................................31
2.1.1 UNA VISIN GENERAL DE LA INGENIERA DE SOFTWARE.........32
2.2 PROCESOS, MTODOS Y HERRAMIENTAS.......................................32
2.2.1 PROCESOS........................................................................................32
2.2.2 MTODOS..........................................................................................35
2.2.3 HERRAMIENTAS................................................................................36
2.3 SISTEMAS DE GESTIN.......................................................................37
2.3.1 ETAPA DE IDEACIN........................................................................38
2.3.2 ETAPA DE PLANIFICACIN..............................................................38
3
2.3.3 Etapa de Implementacin...................................................................38
2.3.4 Etapa de Control.................................................................................39
2.4 METODOLOGAS, MODELOS Y TCNICAS EMPLEADAS.................39
2.4.1 METODOLOGAS...............................................................................39
2.4.1.1 MTODO DE DESARROLLO ORIENTADO A OBJETOS CON UML....39
2.4.1.1.1 DIAGRAMA DE CASOS DE USO.......................................................40
2.4.1.1.2 DIAGRAMA DE ACTIVIDADES...........................................................43
2.4.2 MTODO PARA PROBAR EL SOFTWARE.......................................47
2.4.2.1 PRUEBA DE CAJA BLANCA..................................................................47
2.4.2.1.1 Prueba del camino bsico...................................................................48
2.4.2.2 PRUEBA DE Caja negra.........................................................................51
2.4.2.2.1 LIMITACIONES....................................................................................53
2.4.3 MODELOS..........................................................................................54
2.4.3.1 MODELO DE GESTIN ORIENTADA AL CLIENTE (CRM)..................54
2.4.3.2 MODELO iterativo INCREMENTAL........................................................56
2.4.3.2.1 Fases del modelo.................................................................................58
2.4.4 MODELO DE ESTIMACIN DEL PROYECTO..................................60
2.4.4.1 COCOMO II.............................................................................................60
2.4.4.1.1 MTRICAS DE SOFTWARE...............................................................61
2.4.5 MODELO PARA EVALUAR LA CALIDAD DEL SOFTWARE.............66
2.4.5.1 CALIDAD DEL SOFTWARE...................................................................66
2.4.5.2 MODELO McCall.....................................................................................68
2.5 ARQUITECTURA....................................................................................75
2.5.1 ARQUITECTURA CLIENTE-SERVIDOR...........................................75
2.5.1.1 MODELO DE CLIENTE LIGERO (THIN-CLIENT)..................................78
4
2.5.1.2 MODELO DE CLIENTE RICO (FAT-CLIENT)........................................78
2.6 MARCO APLICATIVO.............................................................................78
2.6.1 MICROSOFT VISUAL STUDIO 2010.................................................78
2.7 Microsoft SQL Server 2008 R2 Enterprise..............................................79
2.7.1 SQL (Structured Query Language).....................................................79
2.7.2 Descripcin de SQL Server 2008.......................................................79
2.7.3 Soluciones..........................................................................................80
2.7.3.1 Business Intelligence..............................................................................80
2.7.3.2 Virtualizacin y consolidacin de servidores..........................................80
2.7.3.3 Consolidacin de servidores...................................................................80
2.7.3.4 Data Warehouse.....................................................................................80
2.7.3.5 Desarrollo de aplicaciones......................................................................81
2.8 SAP Crystal Reports...............................................................................81
2.9 MTODOS..............................................................................................82
2.9.1 MTODO DE INVENTARIO...............................................................82
2.9.1.1 FIRST IN, FIRST OUT (FIFO PEPS)...................................................82
3 CAPITULO III: ANLISIS COSTO Y BENEFICIO..................................84
3.1 COSTOS DE DESARROLLO.................................................................84
3.1.1 COSTOS DE HARDWARE.................................................................84
3.1.2 COSTOS DE SOFTWARE (LICENCIAS)...........................................85
3.2 ESTIMACIN DE COSTOS DEL SOFTWARE.......................................86
3.3 BENEFICIOS...........................................................................................93
3.3.1 BENEFICIOS TANGIBLES.................................................................94
3.3.2 BENEFICIOS INTANGIBLES.............................................................94
3.4 ANLISIS COSTO BENEFICIO..............................................................95
5
3.5 COSTO DE IMPLANTACIN DEL SISTEMA..........................................95
3.5.1 COSTOS DE ADQUISICIN DE EQUIPOS.......................................95
3.5.2 COSTOS DE ADQUISICIN DE MUEBLES......................................98
3.5.3 COSTO DE CAPACITACIN..............................................................98
4 CAPITULO IV: INGENIERA DEL PROYECTO....................................100
4.1 INTRODUCCIN..................................................................................100
4.2 ESPECIFICACIN DE REQUISITOS PARA EL PRIMER INCREMENTO

O MDULO DE SEGURIDAD...............................................................................100
4.2.1 Anlisis de requerimientos................................................................100
4.2.1.1 DESCRIPCIN DEL PROBLEMA........................................................100
4.2.1.2 FASE DE REQUERIMIENTOS.............................................................101
4.2.1.2.1 RECOPILACIN DE LA INFORMACIN..........................................101
4.2.1.2.2 PARTICIPANTES DEL PROYECTO..................................................101
4.2.1.2.3 OBJETIVO DE DESARROLLO.........................................................101
4.2.2 DISEO DEL SISTEMA...................................................................101
4.2.2.1 DIAGRAMAS DE CASOS DE USO......................................................101
4.2.2.2 DIAGRAMA DE ACTIVIDADES............................................................105
4.2.2.3 DIAGRAMA DE estados........................................................................106
4.2.2.4 DISEO DE componentes....................................................................107
4.2.2.5 DISEO DE FORMULARIOS...............................................................107
4.2.2.5.1 PANTALLA REGISTRO DATOS DE USUARIO.................................107
4.2.2.5.2 PANTALLA REGISTRO DE perfil de USUARIO................................108
4.2.2.5.3 PANTALLA de ASIGNACIN de roles a perfiles de usuarios...........108
4.2.2.6 DISEO DE BASE DE DATOS.............................................................109
4.2.3 PRUEBAS.........................................................................................109
6
4.2.3.1 PRUEBAS DE CAJA BLANCA.............................................................109
4.2.3.1.1 CDIGO FUENTE REGISTRO DE USUARIOS.............................110
4.2.3.2 PRUEBA DE CAJA NEGRA..................................................................114
4.2.3.2.1 FORMULARIO DE REGISTRO DE USUARIOS...............................114
4.3 ESPECIFICACIN DE REQUISITOS PARA EL SEGUNDO

INCREMENTO O MODULO DE REGISTRO DE PROVEEDORES Y PRODUCTOS
115
4.3.1.2.3 OBJETIVO DE DESARROLLO..........................................................116
4.3.2 DISEO DEL SISTEMA....................................................................117
4.3.2.3 DIAGRAMA DE ESTADOS...................................................................120
4.3.2.4 DISEO DE componentes....................................................................121
4.3.2.5.1 PANTALLA REGISTRO DE DATOS DEL PROVEEDOR..................122
4.3.2.5.2 PANTALLA REGISTRO DE DATOS DEL PRODUCTO....................123
4.3.3 PRUEBAS.........................................................................................124
4.3.3.1.1 CDIGO FUENTE REGISTRO DE PRODUCTOS........................125
7
4.3.3.2.1 FORMULARIO REGISTRO DE PRODUCTOS.................................129
4.4 ESPECIFICACIN DE REQUISITOS PARA EL TERCER INCREMENTO

O MODULO COMPRAS Y ALMACENES.............................................................130
4.4.1.2.3 objetivos del proyecto........................................................................131
4.4.2.3 DIAGRAMA DE ESTADOS...................................................................137
4.4.2.4 DIagrama DE componentes..................................................................138
4.4.2.5.1 COMPRAS.........................................................................................140
4.4.2.5.2 ALMACENES.....................................................................................145
4.4.3 PRUEBAS DEL SISTEMA................................................................150
4.4.3.1.1 CDIGO FUENTE REGISTRO DE COMPRA DIRECTA...............150
4.4.3.2.1 FORMULARIO REGISTRO DE compra directa................................157
4.5 ESPECIFICACIN DE REQUISITOS PARA EL CUARTO

INCREMENTO O MODULO VENTAS Y GESTIN DE CLIENTES pOTENCIALES
158
8
4.5.1.2.3 OBJETIVO DE DESARROLLO.........................................................159
4.5.2.3 DIAGRAMA DE estado.........................................................................167
4.5.2.4 diagrama de componentes...................................................................169
4.5.2.5.1 PANTALLA DE REGISTRO DE NUEVA VENTA...............................171
4.5.2.5.2 PANTALLA DE VENTAS REALIZADAS............................................171
4.5.2.5.3 PANTALLA REGISTRO DE DATOS DEL CLIENTE..........................172
5 REFERENCIAS.....................................................................................175
REFERENCIAS BIBLIOGRFICAS..................................................................175
REFERENCIAS ELECTRNICAS....................................................................175
6 ANEXOS...............................................................................................180
7 ANEXO A ORGANIGRAMA DE LA DISTRIBUIDORA CRISURT...180
8 ANEXO B MATRIZ DE PROCESOS ADMINISTRATIVOS.................182
9 ANEXO C DIAGRAMA DE PROBLEMAS Y OBJETIVOS.................187
10 ANEXO D CRONOGRAMA DE ACTIVIDADES................................189
9
11 ANEXO E - COSTO SOFTWARE.........................................................191
CAPITULO I
GENERALIDADE
S
1 CAPTULO I: GENERALIDADES
1.1 INTRODUCCIN
Hoy en da se ha visto que en nuestra sociedad el avance de la informtica ha
creciendo y que nos permite un mejor manejo y desarrollo en las empresas, ya
10
sean estas empresas grandes, medianas o pequeas. En la mayora de los casos,
las empresas que cuentan con algn sistema informtico de gestin o de control,
son las empresas grandes, las cuales invirtieron mucho capital, algunas empresas
medianas cuentan con algn sistema de informacin, pero no en su totalidad, lo
cual no sucede en las empresas pequeas y microempresas, donde an se
trabaja con mtodos tradicionales y el manejo de la informacin es a lo sumo en
formato de hojas electrnicas (Excel) y algunos casos se realiza manualmente. Es
por eso que se considera la informacin como un factor muy importante, ya que el
mal uso que se le pueda dar a esta informacin puede dejar a la distribuidora sin
datos precisos, confiables, necesarios y oportunos poniendo en riesgo la
integridad de la distribuidora asa los clientes, los gerentes se vern en la
necesidad de tomar decisiones basndose solamente en su experiencia los cuales
generan una cadena de datos errneos en la organizacin y al mismo tiempo
incertidumbre en la cantidad de compras, ventas y cantidad de productos
almacenados sean estos faltantes o sobrantes.
En tal sentido con el presente proyecto se propone desarrollar un sistema que

permitir a la organizacin de la DISTRIBUIDORA CRISURT gestionar todos
los procesos relacionados con la COMERCIALIZACION y en especial con los
CLIENTES, siendo estos desde la adquisicin de PRODUCTOS e
inventariacin de la misma, hasta la venta de todos los productos como tal,
de manera adecuada y oportuna al mismo tiempo lograr una buena GESTIN
DE LOS CLIENTES usando el modelo de CRM esta es una estrategia
enfocada hacia cliente la implantacin efectiva de CRM permite mejorar
relaciones con los clientes conocindolos mejor y permitiendo disminuir los
costo en la consecucin de nuevos prospectos y aumentar la fidelidad de
los ya existentes, lo cual en ambos casos significa el incremento de las
ventas y mas rentabilidad para la distribuidora.
1.2 ANTECEDENTES
1.2.1 ANTECEDENTES DEL TEMA

Qu es un sistema de gestin?
11
Un sistema de gestin es una estructura probada para la gestin y mejora
continua de las polticas, los procedimientos y procesos de la organizacin.
Un sistema de gestin ayuda a lograr los objetivos de la organizacin mediante

una serie de estrategias, que incluyen la optimizacin de procesos, el enfoque
centrado en la gestin y el pensamiento disciplinado.
La implementacin de un sistema de gestin eficaz puede ayudar a:
Gestionar los riesgos sociales, medioambientales y financieros
Mejorar la efectividad operativa
Reducir costos
Aumentar la satisfaccin de clientes y partes interesadas
Proteger la marca y la reputacin
Lograr mejoras continuas
Potenciar la innovacin
Eliminar las barreras al comercio
Aportar claridad al mercado
El uso de un sistema de gestin probado le permite renovar constantemente su

objetivo, sus estrategias, sus operaciones y niveles de servicio.
Qu es un CRM?
El modelo de CRM (Customer Relationship Management) gestin de las

relaciones con los clientes. El CRM consiste en una estrategia de la organizacin
en la cual centra sus esfuerzos en el conocimiento de sus clientes, detectando sus
necesidades, aumentando su grado de satisfaccin, incrementando su fidelidad a
la empresa e incrementando la rentabilidad o beneficios del cliente a la empresa,
mediante el anlisis de las informaciones extradas por los clientes desde los
diferentes canales o medios de comunicacin.
12
El CRM se refiere a aquellas aplicaciones que las empresas pueden utilizar para
administrar todos los aspectos de sus encuentros con los clientes como llamadas
telefnicas del rea de ventas, hasta sitos web de autoservicio donde los clientes
pueden aprender acerca de los productos y de su compra, o el anlisis de los
clientes y los sistemas de administracin de campaa. [WEB 01]
1.2.2 ANTECEDENTES INSTITUCIONALES
La DISTRIBUIDORA CRISURT encargada de la comercializacin de productos

de panificacin, lcteos, cereales se encarga de distribuir sus distintas lneas de
productos en la ciudad de El Alto, la DISTRIBUIDORA CRISURT est ubicada
en la ciudad de El Alto, en la Av. Santa Fe # 2095 de la zona 16 de Febrero, siendo
creada el 15 de septiembre del ao 2008 con el gerente propietario Eleuterio
Crispin Ramos Quispe, la misma que luego se convirti en asociacin donde se
atiende pedidos de las distintas tiendas y clientes de la ciudad de El Alto, esta
distribuidora cuenta con 11 empleados. Ver ANEXO A
La competencia en el mercado de productos de panificacin, lcteos y cereales

es fuerte. Pero la DISTRIBUIDORA CRISURT no solo ha conseguido asentarse
en el mercado, sino que ha logrado alcanzar a sus competidores gracias no solo al
espritu cooperativista de la distribuidora si no tambin as con todo el personal de
la misma.
1.2.3 ANTECEDENTES DE OTROS PROYECTOS DE GRADO

A continuacin se muestra la siguiente tabla de trabajos afines relacionados al
proyecto PROPUESTO.
Proyecto de grado: CRM-IS Customer RelationShip Management Information

System Sistema de Informacin para la Gestin de la Relacin con los Clientes
Institucin: UMSA Ao: 2009 Autor: Rosemary Montevilla Tancara
13
Descripcin:
El presente proyecto Sistema de Informacin para la Gestin de la Relacin con
los Clientes proporciona a la empresa a realizar una gestin adecuada con los
clientes permitindole a la organizacin identificar, atraer e incrementar la lealtad
de sus consumidores y sus potenciales clientes.
Proyecto de grado: Sistema de gestin de control Administrativo y financiero.

Caso: Empresa de Caf Criollo
Institucin: USB Ao: 2005 Autor: Soria Galbaro Juan
Descripcin:
La presente tesis tiene por objetivo desarrollar un sistema de informacin y control
administrativo y financiero que automatiza los procesos del personal ventas e
inventarios para la empresa de caf criollo proporcionando informacin
actualizada oportuna y eficiente que coadyuva a la toma de decisiones
administrativas y financieras.
Proyecto de grado: Sistema de gestin y seguimiento para almacn de

materiales de vidrio Caso: Carrera de Qumica
Institucin: UMSA Ao: 2011 Autor:Manueco Nava Denisse Micaela
Descripcin:
El Instituto de Investigaciones de la Carrera de Qumica, cuenta con un almacn
de materiales de vidrio que ofrece servicios a toda la poblacin estudiantil
perteneciente a esta, el presente trabajo es el desarrollo e implementacin del
sistema de gestin y seguimiento de informacin para la unidad de almacn de
materiales de vidrio contribuyendo a un mejor manejo y seguimiento de la
informacin adems que facilite el registro, actualizacin, control del movimiento
de materiales como ser prstamos, devoluciones y la obtencin de un pronstico
de la cantidad ptima de adquisicin de los materiales.
Proyecto de grado: Sistema de gestin para almacn de reactivos Caso: Carrera
de Qumica
Institucin: UMSA Ao: 2011 Autor: Apaza Quispe Lourdes Nelly
Descripcin:
El presente proyecto Sistema de Gestin para Almacn de Reactivos de la
14
Carrera de Qumica, surge en funcin a la necesidad de controlar y administrar
toda la informacin que se genera en el Almacn y tiene por objetivo principal:
Disear, desarrollar e implementar un Sistema de Gestin para Almacn de
Reactivos, que permitir optimizar todos los procesos logrando controlar la fecha
de expiracin y las cantidades existentes en almacn, poniendo a disponibilidad
informacin actualizada y oportuna para la toma de decisiones.
Fuente: [Elaboracin propia]

Base: Biblioteca de informtica UMSA, Biblioteca USB
Los trabajos mencionados con la modalidad de proyecto de grado sern de ayuda

en el desarrollo del presente proyecto, ya que se proporcionaran parmetros que
ayudaran a la realizacin correcta y con buenos antecedentes. Como se pudo
distinguir, todos estos proyectos estn enfocados a ser un sistema que controlar
determinadas reas de una empresa.
La diferencia del primer antecedente con el presente proyecto es que ese proyecto
Sistema de Informacin para la Gestin de la Relacin con los Clientes
proporciona a la empresa a realizar una gestin adecuada con los clientes
permitindole a la organizacin identificar, atraer e incrementar la lealtad de sus
consumidores y sus potenciales clientes. Y el presente proyecto realiza un control
adecuado de lo que es almacn en especfico compras, ventas de productos.
La diferencia del segundo antecedente con el presente proyecto es que ese

proyecto tiene por objetivo desarrollar un sistema de informacin y control
administrativo y financiero que automatiza los procesos del personal ventas e
inventarios para la empresa de caf criollo proporcionando informacin actualizada
oportuna y eficiente que coadyuva a la toma de decisiones administrativas y
financieras, en nuestro proyecto realizaremos un buen control de la
comercializacin adems de los productos trasferidos a otros almacenes.
La diferencia del tercer antecedente con el presente proyecto es que ese proyecto
realiza un sistema de gestin y seguimiento de informacin para la unidad de
almacn de materiales de vidrio contribuyendo a un mejor manejo y seguimiento
15
de la informacin a la encargada del almacn que facilite el registro la obtencin
de un pronstico de la cantidad ptima de adquisicin de los materiales, en
nuestro proyecto el sistema realiza el control y trabaja con las distintas reas que
existen en la Distribuidora realizando as un buen control en las ventas de la
distribuidora.
La diferencia del cuarto antecedente es que el proyecto Sistema de Gestin para

Almacn de Reactivos de la Carrera de Qumica, controla y administra toda la
informacin que se genera en el Almacn poniendo a disponibilidad informacin
actualizada y oportuna para la toma de decisiones, departe del personal en
nuestro sistema al ser una distribuidoras encargada de compras, ventas se
aplicar un modelo de enfocado al cliente adems de usar un modelo de
inventarios.
1.3 PLANTEAMIENTO DEL PROBLEMA

1.3.1 DESCRIPCIN DEL MBITO DE ESTUDIO
Despus de realizar la investigacin preliminar se identific que las principales

actividades relacionadas con las compras, ventas y almacenes en la distribuidora
son:
Adquisicin de productos (panificacin, lcteos, cereales y galletera).

Planificacin de trabajos a realizar
Clculo de la cantidad de stock actual de productos
Registro de pedidos de clientes
Proceso de compras en sus fases de:
Generacin de pedidos
Anulacin de pedidos
Edicin de pedidos
Confirmacin de pedido a proveedor
Confirmacin de compra
Proceso de compra directa
Venta de los productos a clientes.
16
Proceso de traspasos entre almacenes
Realizar nuevos traspasos de un almacn a otro
Anular traspasos realizados antes de la recepcin del almacn
destino
Confirmar ingreso de productos traspasados de almacn
Ver ingresos de productos a almacn
Actualizar stock de productos existente en almacn
Proceso de salidas varias de almacn
Gestin de clientes
La toma de decisiones est relacionada con respecto a las ventas realizadas de

productos (cantidad y productos) y con los stocks actuales en almacenes, de esta
manera se calcula tambin los pedidos a realizar al proveedor.
La distribuidora DISTRIBUIDORA CRISURT se realiza de forma manual y

semiautomtica con los problemas y dificultades que esto conlleva, como se ve en
la Matriz de procesos administrativos. Ver ANEXO B.
1.3.2 PROBLEMA CENTRAL
Los procesos actuales de control de comercializacin y almacenes

de productos en la distribuidora DISTRIBUIDORA CRISURT son realizados
manualmente, lo cual ocasiona redundancia 1 de registros, perdida de informacin 2,
errores3 en los informes y reportes finales, esto afecta a la toma de decisiones de
gerencia y administracin con respecto a la adquisicin de productos, en el control
de ventas y almacenes adems de no contar con una buena gestin de los
clientes, identificar, atraer o incrementar la lealtad en sus consumidores as como
identificar nuevos y potenciales clientes.
1 Redundancia: El concepto se utiliza para nombrar al uso abundante o descomunal de un concepto o de un vocablo y a
la reiteracin de datos incluidos en textos o mensajes que permite, pese a la prdida de parte de ellos, rearmar su
CONTENIDO.
2 Perdida de informacin: se refiere al extravo de datos por la mala documentacin o mal manejo de archivos.
3 Errores: Un error es algo equivocado o desacertado. Puede ser una ACCIN, un concepto o una cosa que no se realiz
de manera correcta
17
1.3.3 PROBLEMAS ESPECFICOS
Las ventas son registradas manualmente y no se cuenta con datos
oportunos y exactos de la demanda real por tanto existen errores en la
estimacin de pedidos.
Los datos obtenidos no son exactos para la demanda por tanto no se
planifica correctamente la generacin de pedidos a proveedor.
Redundancia de registros y duplicidad de datos lo que dificulta la
elaboracin de informes relacionados con las compras y las ventas
realizadas, informacin que actualmente depende de la pericia del dueo.
El control de los productos existentes en almacn no se registra
sistemticamente por tanto no se cuenta con informacin real de las
cantidades exactas de productos en almacn.
Es inexistente el control en almacn, respecto a las salidas de productos de

este, ya que existe registros errneos de los productos que salen e
ingresan a almacenes.
Almacenes no cuenta con un correcto control de stock de productos ya que

los mismos ingresan y salen de almacenes como salidas varias y no se
cuenta con los registros de los mismos.
La distribuidora no cuenta con registros y reportes de clientes y

proveedores.
Los pedidos y compras de productos son registradas manualmente lo que

ocasiona errores en el proceso de compras.
1.4 OBJETIVOS
1.4.1 OBJETIVO CENTRAL

Desarrollar un Sistema de gestin para el control 4 de comercializacin y
almacenes apoyado con el modelo de gestin de clientes (CRM) para la
4Sistema de Control: Sistema o subsistema que est constituido por un conjunto de componentes que regulan el
comportamiento de un sistema (o de s mismos) para lograr un objetivo.
Cualquier sistema (organizaciones, seres vivos o mquinas) puede tener sistemas de control.
18
DISTRIBUIDORA CRISURT de esta forma eliminar la redundancia de datos, la
duplicidad de registros5, informes incompletos para que estos contengan datos
precisos6y seguros7 los mismos puedan brindar informacin eficiente8 y oportuna
apoyando a la toma de decisiones de parte del gerente y personal de la
distribuidora, adems de que el modelo CRM ayudara a la distribuidora identificar,
atraer, e incrementar la lealtad de sus consumidores y potenciales clientes.
1.4.2 OBJETIVOS ESPECFICOS
Automatizar el registro de venta de productos proporcionando informacin

oportuna y exacta de la demanda de los mismos.
Por medio de la automatizacin contar con datos exactos de la demanda

real de ventas y por medio de los datos llegar a una correcta planificacin
de pedidos.
Proveer mecanismos de seguridad que permitan un control interno del

sistema, as como la creacin de usuarios y otorgacin de permisos
Validar los datos en registros para evitar la duplicidad de datos y no

dificulte as la elaboracin de informes relacionados no solo con la compra
de productos, las ventas realizadas e informacin de almacn.
Sistematizar el control de almacn de productos terminados sea como

productos defectuosos, productos con fallas y producto rotos o vencidos,
para poder contar con la informacin real, precisa y exacta de almacn.
Automatizar el control de productos para evitar informes con registros

errneos de almacn que ingresan y salen del mismo.
5 Registros: En programacin, es un tipo de dato estructurado formado por la unin de varios elementos bajo una misma
estructura
6 Precisin: La precisin es la necesidad y obligacin de exactitud y concisin a la hora de ejecutar algo.
7 Seguridad: Es el rea de la informtica que se enfoca en la proteccin de la infraestructura computacional y todo lo
relacionado con esta (incluyendo la informacin contenida). Para ello existen una serie de estndares, protocolos, mtodos,
reglas, herramientas y leyes concebidas para minimizar los posibles riesgos a la infraestructura o a la informacin
8 Eficacia: Capacidad de lograr el efecto que se desea o se espera.
19
Por medio de la sistematizacin validar los campos para que as los datos
sean ingresados de manera obligatoria, y no as ocasionen errores en la
estimacin de compras.
Sistematizar los registros y reportes de clientes, proveedores ventas.
Sistematizar los pedidos y compras de productos para evitar errores en el

proceso de compra.
1.5 JUSTIFICACIONES
1.5.1 JUSTIFICACIN SOCIAL
El presente trabajo se justifica socialmente por que el sistema brindara informacin

oportuna a:
Gerente General: Los cuales utilizaran este software para generacin de

informes completos, con el cual podrn tomar decisiones precisas y
oportunas en el rea comercial.
Personal en general como los administradores, contadores, encargados de

almacenes, secretarias y vendedores los cuales podrn elaborar informes
precisos y seguros, adems del personal encargado de registros de ventas,
encargado de registros de compras, con los cuales podrn realizar registros
de los clientes al momento de la compra o de la venta de productos para
luego poder obtener informes precisos y completos.
En especial brindara informacin ntegra sobre los pedidos realizados

beneficiando al cliente preferentemente del pedido que realizo y efectuando un
proceso fcil para la persona encargada de la recepcin de compras en la
operacin de sistema, as mismo de tener una buena gestin de los clientes.
1.5.2 JUSTIFICACIN TCNICA
Se justifica tcnicamente porque se mejora los procesos, ya que con el desarrollo

del sistema propuesto se incursionara en nuevos mtodos y tcnicas de
tratamiento de la informacin basada en la ingeniera de sistemas las cuales
20
permitirn procesar los datos de forma que proporcionar informacin de calidad.
De esta manera este sistema brindar reportes con garantas de exactitud,
confiabilidad, factibilidad de acceso y como tambin seguridad para el personal
que no est autorizado, adems de que este sistema ser de fcil uso, contando
con entornos agradables para los usuarios del sistema.
En la distribuidora donde se desarrolla el sistema se cuenta con el Hardware y el

Software necesario para la elaboracin de este proyecto, ya que podemos
mencionar que recientemente se adquirieron nuevos equipos, los cuales son
adecuados para que se tenga un sistema adecuado, de los cuales se obtuvieron
los datos necesarios y se los representa en las siguientes tablas.
Cuadro 1.1: RECURSOS DE HARDWARE DE LA DISTRIBUIDORA
RECURSOS DE HARDWARE DE LA DISTRIBUIDORA
DISPOSITIVO DESCRIPCIN
Procesador 1 Ghz requerimiento ptimo 2 Ghz

Memoria RAM 1Gb requerimiento ptimo 2Gb
Disco duro 120 Gb requerimiento ptimo 180 Gb
Monitor 1024 x 600
Lector de Discos DVD
Tarjeta de video 64 Mb RAM requerimiento ptimo 128
Mb RAM

Cuadro 1.2: RECURSOS DE SOFTWARE DE LA DISTRIBUIDORA
RECURSOS DE SOFTWARE DE LA DISTRIBUIDORA
DESCRIPCIN TIPO
Sistema Operativo Windows 7

Manejador de Base de Datos SQL server 2008
Herramienta de desarrollo Microsoft Visual Studio Ultimate 2010
21
1.5.3 JUSTIFICACIN PRCTICA
Con el desarrollo del proyecto planteado se resolver un problema real

relacionado con el control de comercializacin, almacn y la gestin de los clientes
el mismo adems se implantara con tecnologa que la organizacin puede adquirir
y a esta se le implementar el software necesario para obtener un eficiente uso del
sistema.
1.5.4 JUSTIFICACIN ECONMICA
Al usar software del presente proyecto se podr estimar con certeza el costo real
de compras considerando: pedidos en espera, pedidos confirmados, traspasos
entre almacenes y tiempo de sta manera se favorecer a la distribuidora en la
reduccin de gastos y costos por errores de estimacin o planificacin de las
compras a realizar para el almacn, adems de mejorar la competitividad de la
DISTRIBUIDORA CRISURT en el mercado ya que la misma cuenta con los
recursos de hardware (equipos de escritorio) necesarios, adems de contar con la
conexin a internet y un tcnico encargado de soporte, al mismo tiempo la
distribuidora cuenta con los recursos de software bsicos como el de ser el
sistema operativo sin contar as con el lenguaje y el gestor de B.D. para el
desarrollo del software los cuales se detallan en la siguiente tabla.
Cuadro 1.3: REQUERIMIENTOS PARA EL DESARROLLO DEL SOFTWARE
RECURSO CANTIDAD DETALLE UTILIDAD PRECIO($us)
Microsoft Lenguaje
Visual Studio 630
Licencias 1 Licencia Ultimate
de de Pago 2010
Software SQL server Gestor de
1 2008 base de 970
datos
1 Licencia SAP Crystal Diseo de
22
Gratuita Report informes -----
Fuente: [Elaboracin propia basada en las WEB 02, WEB 03 en fecha

24/10/12]
1.6 APORTES
En el presente proyecto de grado se cuenta con los siguientes aportes:
Aportes del proyecto
Aportes acadmicos
1.6.1 APORTES DEL PROYECTO
Un sistema de gestin est relacionado con reas como ser:
Ingeniera de sistemas.
Informtica.
Redes de telecomunicaciones.
Administracin de empresas.
Contabilidad.
Las cuales nos llevan a la evolucin de la tecnologa.
Para la implementacin del presente proyecto se emplear el Modelo iterativo

incremental, mtodo de anlisis y diseo de sistemas orientado a objetos, mtodo
de pruebas, modelo de calidad, modelo UML, tcnicas de seguridad (encriptacin
de datos, contraseas, etc.). La implementacin del sistema requiere utilizar
mtodos, modelos y tcnicas de aplicacin para resolver el problema a estudio.
1.6.2 APORTE ACADMICO
La aplicacin de un modelo de gestin orientada al cliente (CRM) que permita

identificar, captar y fidelizar a clientes de la distribuidora. La integracin del modelo
dentro del sistema apoyar a la elaboracin de reportes de historial de cualquier
cliente, que productos adquiri ultimadamente, etc. como una herramienta para
asegurar la calidad de atencin a los clientes de la distribuidora, este se constituye
23
en el aporte. Y adems del empleo de estndares para la especificacin de
requerimientos.
1.7 ALCANCES
El sistema de gestin para el control de la comercializacin tiene como propsito

dar solucin a la seguridad y control de la informacin que procesa la distribuidora
juntamente con el modelo CRM y su intencin de ayudar a gestionar a los clientes
permanentes y potenciales. Adems de administrar las operaciones y
transacciones de la distribuidora. Los mdulos que tendr el sistema son:
Mdulo de seguridad.
Mdulo de tablas registro de proveedores, clientes y productos.
Mdulo de compras y almacenes.
Mdulo de gestin de clientes y ventas.
1.7.1 DELIMITACION MODULAR
1.7.1.1 MDULO DE SEGURIDAD
Permite realizar la configuracin de usuarios, datos de la empresa y su

estructura, datos de documentacin necesaria para realizar operaciones
dentro de la distribuidora.
1.7.1.2 MDULO DE REGISTRO DE PROVEEDORES Y PRODUCTOS
Permite registrar los datos de clientes, proveedores, productos y su

clasificacin.
1.7.1.3 MDULO DE COMPRAS Y ALMACENES
Permite realizar pedidos, compras de productos a los proveedores; as

mismo el manejo de almacenes, que registran salidas, traspasos, ingresos
de productos.
24
1.7.1.4 MDULO DE VENTAS Y GESTION DE CLIENTES POTENCIALES
Permite realizar ventas de productos a los clientes, donde tiene la opcin de

utilizar factura o nota de remisin como documento de respaldo, adems
que podr realizar ventas al contado o al crdito. Al igual que permite
obtener datos y reportes de los clientes de la distribuidora.
1.8 MTODOS
1.8.1 MTODO DE DESARROLLO ORIENTADO A OBJETOS CON UML

Se debe tomar en cuenta que el estndar UML no define un proceso de desarrollo
especfico, tan solo se trata de una notacin, es por eso que se utilizara el modelo
propuesto por Craig Larman [Craig Larman, 2002] que se ejecuta un ciclo de vida
iterativo e incremental dirigido por casos de uso, que se utiliza en los modelos
UML.
Se abarca todo el ciclo de vida, empezando por los requerimientos y terminando

en el proceso del funcionamiento del sistema, proporcionando as una visin
completa y coherente de la produccin de sistemas de software. [Luiz Capretz,
Miriam Capretz, 1996].
Diagrama de Casos de uso
Diagrama de Secuencia
Diagrama de Actividades
1.8.2 MTODO PARA PROBAR EL SOFTWARE
El mtodo que se usa para la prueba del presente software ser la siguiente:
1.8.2.1 PRUEBAS DE CAJA BLANCA
En programacin, se denomina cajas blancas a un tipo de pruebas de software

que se realiza sobre las funciones internas de un mdulo.
La prueba de la caja blanca es un mtodo de diseo de casos de prueba que usa

la estructura de control del diseo procedimental para derivar los casos de prueba.
25
Las pruebas de caja blanca intentan garantizar que:
Se ejecutan al menos una vez todos los caminos independientes de cada

mdulo.
Se utilizan las decisiones en su parte verdadera y en su parte falsa.
Se ejecuten todos los bucles en sus lmites.
Se utilizan todas las estructuras de datos internas [WEB 04].
1.8.3 MODELOS
1.8.3.1 MODELO PARA LA GESTIN DE LA RELACIN CON LOS CLIENTES

(CRM)
El modelo de CRM (Customer Relationship Management) consiste en una

estrategia de la organizacin en la cual centra sus esfuerzos en el conocimiento
de sus clientes, detectando sus necesidades, aumentando su grado de
satisfaccin, incrementando su fidelidad a la empresa e incrementando la
rentabilidad o beneficios del cliente a la empresa, mediante el anlisis de las
informaciones extradas por los clientes desde los diferentes canales o medios de
comunicacin.
El CRM se refiere a aquellas aplicaciones que las empresas pueden utilizar para
administrar todos los aspectos de sus encuentros con los clientes como llamadas
telefnicas del rea de ventas, hasta sitos web de autoservicio donde los clientes
pueden aprender acerca de los productos y de su compra, o el anlisis de los
clientes y los sistemas de administracin de campaa. [WEB 05]
1.8.3.2 MODELO ITERATIVO INCREMENTAL
La herramienta a utilizar para el presente proyecto y el que se adecua a este, es el

modelo iterativo Incremental ya que se analiza una institucin de compra de
productos y venta de productos acabados, pues este modelo combina elementos
26
del modelo lineal secuencial de forma escalonada, mientras progresa el tiempo en
el calendario.
El incremental es un modelo de tipo evolutivo que est basado en varios ciclos

Cascada Realimentados aplicados repetidamente, con una filosofa iterativa.
Bajo este modelo se entrega software por partes funcionales ms pequeas,

pero reutilizables, llamadas incrementos. En general cada incremento se
construye sobre aquel que ya fue entregado. Cada secuencia lineal o Cascada
produce un incremento y a menudo el primer incremento es un sistema bsico,
con muchas funciones suplementarias (conocidas o no) sin entregar.
El cliente utiliza inicialmente ese sistema bsico, y el resultado de su uso y

evaluacin puede aportar al plan para el desarrollo del/los siguientes incrementos
(o versiones).
Luego de cada integracin se entrega un producto con mayor funcionalidad que el

previo. El proceso se repite hasta alcanzar el software final completo.
Siendo iterativo, con el modelo incremental se entrega un producto parcial pero

completamente operacional en cada incremento, y no una parte que sea usada
para reajustar los requerimientos (como si ocurre en el modelo de construccin de
prototipos). [WEB 06].
1.8.3.3 MODELO DE ESTIMACIN DEL PROYECTO
El modelo COCOMO II permitir realizar la estimacin del proyecto. COCOMO II

propuesto y desarrollado por Barry Boehm [WEB 07], es uno de los modelos de
estimacin de costos mejor documentados y utilizados. El modelo permite
determinar el esfuerzo y tiempo que se requiere en un proyecto de software a
partir de una medida del tamao del mismo expresada en el nmero de lneas de
cdigo que se estimen generar para la creacin del producto software.
27
1.8.3.4 MODELO PARA EVALUAR LA CALIDAD DEL SOFTWARE
Cuando se trata de evaluar la calidad de un producto software hay que tener en

cuenta que la calidad es un concepto muy complejo y que adems, depende
mucho del punto de vista que se adopte. Esto representa una gran dificultad para
la evaluacin formal de la calidad de software Piattini [WEB 08]
El modelo McCall se usar para la evaluacin de la calidad del presente software,

este modelo se basa en descomponer el concepto de calidad de tres usos o
capacidades importantes para un producto software que son las siguientes:
Visin de usuario
Visin de la direccin
Visin del desarrollador
1.8.4 TCNICAS
1.8.4.1 TCNICAS PARA RECOLECTAR INFORMACIN
Las tcnicas para recoleccin de informacin que se usarn son las siguientes:
Entrevistas y cuestionarios a :
- Gerente General, es la persona que nos brinda informacin general de la
empresa.
- Gerente Comercial, es la persona que nos informa sobre los ingresos y
egresos de la empresa.
- Gerente de Produccin, es la persona que nos dar informacin ms
detallada sobre las reas que existen y las tareas que se generan en dichas
reas de la institucin.
- Encargado de almacenes, que nos brindara la informacin sobre los
informes y los reportes que ellos necesitan en almacenes para un buen
control de la produccin que entra y sale.
- Reactiveros, los cuales nos informaran sobre los tipos, cantidad y otras
caractersticas de los reactivos que necesitan registrar.
- Al personal de diferentes reas, las cuales nos darn un informe ms
detallado sobre el trabajo que se realiza en cada rea conociendo as los
requerimientos del personal.
28
CAPITULO II
MARCO
TERICO
29
2 CAPTULO II: MARCO TERICO
2.1 INTRODUCCIN
En este captulo se especifican los fundamentos tericos principales para el

desarrollo del proyecto desde la recopilacin de la informacin aplicacin de los
modelos, mtodos, procesos y herramientas, hasta la implantacin del proyecto.
De la cual se aplic el modelo CRM para una mejor gestin de clientes.
2.2 INGENIERA DE SOFTWARE
Ingeniera de software es la disciplina o rea de la Ingeniera que ofrece mtodos

y tcnicas para desarrollar y mantener software. La creacin del software es un
proceso intrnsecamente creativo y la Ingeniera del Software trata de sistematizar
este proceso con el fin de acotar el riesgo del fracaso en la consecucin del
objetivo creativo por medio de diversas tcnicas que se han demostrado
adecuadas en base a la experiencia previa. Esta ingeniera trata con reas muy
diversas de la informtica y de las ciencias de la computacin, tales como
construccin de compiladores, sistemas operativos, o desarrollos Intranet/Internet,
abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de
sistemas de informacin y aplicables a infinidad de reas: negocios, investigacin
cientfica, medicina, produccin, logstica, banca, control de trfico, meteorologa,
derecho, Internet, Intranet, etc.
Una definicin precisa an no ha sido contemplada en los diccionarios, sin

embargo se pueden citar una de las definiciones ms prestigiosas:
Disciplina de ingeniera que comprende todos los aspectos de la produccin del

software, desde las etapas inciales de la produccin del sistema, hasta el
mantenimiento de este despus de que se utiliza; Comprende las formas prcticas
para desarrollar y entregar un software til [Ian Sommerville]
30
2.2.1 UNA VISIN GENERAL DE LA INGENIERA DE SOFTWARE
La Ingeniera del software es una tecnologa estratificada. Se apoya sobre un

enfoque de calidad. El fundamento es la capa de proceso, que se refiere a la unin
que mantiene juntas las capas de tecnologa que refieren el desarrollo racional y
oportuno de la ingeniera del software. El proceso define un marco de trabajo para
un conjunto de reas claves de proceso que se deben establecer para la entrega
efectiva de la tecnologa de la ingeniera del software. [Roger S. Pressman]
2.3 PROCESOS, MTODOS Y HERRAMIENTAS

2.3.1 PROCESOS
Etapas del proceso
La ingeniera de software requiere llevar a cabo numerosas tareas, dentro de

etapas como las siguientes:
Anlisis de requerimientos
Extraer los requisitos y requerimientos de un producto de software es la primera

etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el
software tiene que hacer, se requiere de habilidad y experiencia en la ingeniera de
software para reconocer requerimientos incompletos, ambiguos o contradictorios.
El resultado del anlisis de requerimientos con el cliente se plasma en el
documento ERS, Especificacin de Requerimientos del Sistema, cuya estructura
puede venir definida por varios estndares, tales como CMMI.
La captura, anlisis y especificacin de requerimientos (incluso pruebas de ellos),

es una parte crucial; de esta etapa depende en gran medida el logro de los
objetivos finales. Se han ideado modelos y diversos procesos de trabajo para
estos fines. Aunque an no est formalizada, ya se habla de la Ingeniera de
requerimientos, por ejemplo en dos captulos del libro de Sommerville.
Especificacin
31
La Especificacin de Requisitos describe el comportamiento esperado en el
software una vez desarrollado. Gran parte del xito de un proyecto de software
radicar en la identificacin de las necesidades del negocio (definidas por la alta
direccin), as como la interaccin con los usuarios funcionales para la
recoleccin, clasificacin, identificacin, priorizacin y especificacin de los
requisitos del software.
Entre las tcnicas utilizadas para la especificacin de requisitos se encuentran:
Casos de Uso,
Historias de usuario,
Arquitectura
La integracin de infraestructura, desarrollo de aplicaciones, bases de datos y

herramientas gerenciales, requieren de capacidad y liderazgo para poder ser
conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El
rol en el cual se delegan todas estas actividades es el del Arquitecto. El Arquitecto
de Software es la persona que aade valor a los procesos de negocios gracias a
su valioso aporte de soluciones tecnolgicas. La Arquitectura de Sistemas en
general, es una actividad de planeacin, ya sea a nivel de infraestructura de red y
hardware, o de Software. La Arquitectura de Software consiste en el diseo de
componentes de una aplicacin (entidades del negocio), generalmente utilizando
patrones de arquitectura. El diseo arquitectnico debe permitir visualizar la
interaccin entre las entidades del negocio y adems poder ser validado, por
ejemplo por medio de diagramas de secuencia. Un diseo arquitectnico describe
en general el cmo se construir una aplicacin de software.
Entre las herramientas para disear arquitecturas de software se encuentran:
Enterprise Architect
Microsoft Visio for Enterprise Architects
32
Programacin
Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera
de software, pero no necesariamente es la que demanda mayor trabajo y ni la ms
complicada. La complejidad y la duracin de esta etapa est ntimamente
relacionada al o a los lenguajes de programacin utilizados, as como al diseo
previamente realizado.
Prueba
Consiste en comprobar que el software realice correctamente las tareas indicadas

en la especificacin del problema. Una tcnica de prueba es probar por separado
cada mdulo del software, y luego probarlo de forma integral, para as llegar al
objetivo. Se considera una buena prctica el que las pruebas sean efectuadas por
alguien distinto al desarrollador que la program, idealmente un rea de pruebas;
sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En
general hay dos grandes formas de organizar un rea de pruebas, la primera es
que est compuesta por personal inexperto y que desconozca el tema de pruebas,
de esta forma se evala que la documentacin entregada sea de calidad, que los
procesos descritos son tan claros que cualquiera puede entenderlos y el software
hace las cosas tal y como estn descritas. El segundo enfoque es tener un rea
de pruebas conformada por programadores con experiencia, personas que saben
sin mayores indicaciones en qu condiciones puede fallar una aplicacin y que
pueden poner atencin en detalles que personal inexperto no considerara.
Documentacin
Todo lo concerniente a la documentacin del propio desarrollo del software y de la

gestin del proyecto, pasando por modelaciones (UML), diagramas, pruebas,
manuales de usuario, manuales tcnicos, etc.; todo con el propsito de eventuales
correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
33
Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos

requisitos. Esto puede llevar ms tiempo incluso que el desarrollo inicial del
software. Alrededor de 2/3 de toda la ingeniera de software tiene que ver con dar
mantenimiento. Una pequea parte de este trabajo consiste en arreglar errores, o
bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas.
De manera similar, alrededor de 2/3 de toda la ingeniera civil, arquitectura y
trabajo de construccin es dar mantenimiento
2.3.2 MTODOS
Los mtodos de la ingeniera de software. Suministran el cmo construir

tcnicamente el software. Los mtodos abarcan un amplio espectro de tareas que
incluyen: planificacin y estimacin de proyectos, anlisis de los requerimientos
del sistema y del software, diseo de procedimientos algortmicos, codificacin,
prueba y mantenimiento.
Los mtodos de la ingeniera de software introducen frecuentemente una notacin

especial orientada al lenguaje o grfica y a un conjunto de criterios para la calidad
del software.
La ingeniera de software tiene varios modelos, paradigmas o filosofas de

desarrollo en los cuales se puede apoyar para la realizacin de software, de los
cuales podemos destacar a stos por ser los ms utilizados y los ms completos:
Modelo en cascada o Clsico (modelo tradicional)
Modelo de prototipos
Modelo en espiral
Desarrollo por etapas
34
Desarrollo iterativo y creciente o Iterativo e Incremental
RAD (Rapid Application Development)
Proceso Unificado
RUP (Proceso Unificado de Rational)
2.3.3 HERRAMIENTAS
Suministran un soporte automtico o semiautomtico para los mtodos. Cuando

se integran las herramientas de forma que la informacin creada por una
herramienta pueda ser usada por otra, se establece un sistema para el soporte del
desarrollo del software llamado ingeniera de software asistido por computadora,
por mencionar alguna de estas herramientas existen las herramientas CASE 9.
Combina del software, hardware y base de datos para crear un entorno de la
ingeniera de software
2.4 SISTEMAS DE GESTIN

Un Sistema de Gestin ayuda a lograr las metas y objetivos de una organizacin
mediante una serie de estrategias, que incluyen la optimizacin de procesos, el
enfoque centrado en la gestin y el pensamiento disciplinado. Por tanto el Sistema
de Gestin es un conjunto de etapas unidas en un proceso continuo, que deja
trabajar ordenadamente una idea hasta lograr mejoras y su continuidad.
Un Sistema de Gestin hace que las empresas funcionan como unidades
completas con una visin compartida. Ello engloba la informacin compartida,
evaluaciones comparativas, trabajo en equipo y un funcionamiento acorde con los
ms rigurosos principios de calidad y del medioambiente.
La implementacin de un sistema de gestin eficaz en una Organizacin puede
ayudar a esta en: gestionar los riesgos sociales, medioambientales y financieros,
mejora en la efectividad operativa, Reduccin de costos, Aumento en la
satisfaccin de clientes y partes interesadas, protege la marca y la reputacin,
9 CASE: Ingeniera de software asistida por computadora [computer aided software engineering].
35
logra mejoras continuas, potencia la innovacin, eliminar las barreras al comercio
y aporta claridad al mercado.
Un Sistema de Gestin se desarrolla principalmente en 4 etapas:
Etapa de Ideacin
Etapa de Planeacin
Etapa de Implementacin
Etapa de Control
2.4.1 ETAPA DE IDEACIN
Esta etapa consiste en trabajar en la idea que guiar los primeros pasos del
proceso de creacin que se logra con el sistema de gestin propuesto. Existen
varias metodologas para lograr refinar la idea. Siendo la ms conocida la
conocida como Lluvia de ideas o Brainstorming, que consiste en generar el
mximo de ideas para obtener un amplio espectro de posibilidades en dnde
atacar. Este proceso consiste en que un grupo o una persona, durante un tiempo
prudente se enfocan en generar o lanzar ideas sin restricciones, pero que tengan
cercana con el tema que se est tratando. Una vez que se tenga un listado
adecuado, se procede a analizar las ideas y a pulir su cercana con lo que
realmente se quiere. La idea central de este proceso es que aqu se debe definir
claramente el objetivo perseguido, es decir se debe plantear la pregunta Qu
queremos lograr?. Una vez definido, se procede al Cmo lograrlo? y se pasa a
la siguiente etapa.
2.4.2 ETAPA DE PLANIFICACIN

Este paso constituye una etapa fundamental y el punto de partida de la accin
directiva, ya que supone el establecimiento de sub-objetivos y los cursos de accin
para alcanzarlos. Es as que en esta etapa, se definen las estrategias que se
utilizarn, la estructura organizacional que se requiere, el personal que se
asignara, el tipo de tecnologa que se necesita, los recursos que se van emplear y
la clase de controles que se aplicaran en todo el proceso.
36
2.4.3 ETAPA DE IMPLEMENTACIN
Esta etapa se entiende por gestin, es decir la accin y efecto de administrar.
Pero, en un contexto empresarial, esto se refiere a la direccin que toman las
decisiones y las acciones para alcanzar los objetivos trazados. Se debe destacar
que las decisiones y acciones que se toman para llevar adelante un propsito, se
sustentan en los mecanismos o instrumentos administrativos (estrategias, tcticas,
procedimientos, presupuestos, etc.), que estn sistmicamente relacionados y que
se obtienen del proceso de planificacin.
2.4.4 ETAPA DE CONTROL
Esta etapa es una funcin administrativa, de carcter regulador, que permite

verificar si la actividad, proceso, unidad, sistema, etc., est cumpliendo sus
objetivos o alcanzando los resultados que se esperan. Por tanto se debe sealar
que la finalidad del control es la deteccin de errores, fallas o diferencias, en
relacin a un planteamiento inicial, para su correccin y/o prevencin. Por tanto, el
control debe estar muy relacionado con los objetivos inicialmente definidos, por lo
que debera permitir la medicin y cuantificacin de los resultados, la deteccin de
desviaciones y el establecimiento de medidas correctivas y preventivas,
empezando desde ya a considerar que las medidas preventivas sern las ms
convenientes para la organizacin.
2.5 METODOLOGAS, MODELOS Y TCNICAS EMPLEADAS

2.5.1 METODOLOGAS
2.5.1.1 MTODO DE DESARROLLO ORIENTADO A OBJETOS CON UML
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y

documentar los elementos que forman un sistema software orientado a objetos. Se
ha convertido en el estndar de facto de la industria, debido a que ha sido
impulsado por los autores de los tres mtodos ms usados de orientacin a
objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron
contratados por la empresa Rational Software Co. para crear una notacin
37
unificada en la que basar la construccin de sus herramientas CASE. En el
proceso de creacin de UML han participado, no obstante, otras empresas de gran
peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, as como
grupos de analistas y desarrolladores. Esta notacin ha sido ampliamente
aceptada debido al prestigio de sus creadores y debido a que incorpora las
principales ventajas de cada uno de los mtodos particulares en los que se basa
(principalmente Booch, OMT y OOSE). UML ha puesto fin a las llamadas guerras
de mtodos que se han mantenido a lo largo de los 90, en las que los principales
mtodos sacaban nuevas versiones que incorporaban las tcnicas de los dems.
Con UML se fusiona la notacin de estas tcnicas para formar una herramienta
compartida entre todos los ingenieros software que trabajan en el desarrollo
orientado a objetos. Uno de los objetivos principales de la creacin de UML era
posibilitar el intercambio de modelos entre las distintas herramientas CASE
orientadas a objetos del mercado. Para ello era necesario definir una notacin y
semntica comn. Hay que tener en cuenta que el estndar UML no define un
proceso de desarrollo especfico, tan solo se trata de una notacin. En este curso
se sigue el mtodo propuesto por [Craig Larman] que se ajusta a un ciclo de vida
iterativo e incremental dirigido por casos de uso.
2.5.1.1.1 DIAGRAMA DE CASOS DE USO
Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos
de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se
refiere a su interaccin externa. En el diagrama de casos de uso se representa
tambin el sistema como una caja rectangular con el nombre en su interior. Los
casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada
actor est unido a los casos de uso en los que participa mediante una lnea. En la
figura se muestra un ejemplo de Diagrama de Casos de Uso para un cajero
automtico.
38
Figura 2.1: Ejemplo de caso de uso
Fuente: [WEB 09]
Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son:
actores, casos de uso y relaciones entre casos de uso.
Actores
Un actor es algo con comportamiento, como una persona (identificada por

un rol), un sistema informatizado u organizacin, y que realiza algn tipo de
interaccin con el sistema. Se representa mediante una figura humana
dibujada con palotes. Esta representacin sirve tanto para actores que son
personas como para otro tipo de actores.
Casos de Uso
Un caso de uso es una descripcin de la secuencia de interacciones que se

producen entre un actor y el sistema, cuando el actor usa el sistema para
llevar a cabo una tarea especfica. Expresa una unidad coherente de
funcionalidad, y se representa en el Diagrama de Casos de Uso mediante
una elipse con el nombre del caso de uso en su interior. El nombre del caso
39
de uso debe reflejar la tarea especfica que el actor desea llevar a cabo
usando el sistema.
Relaciones entre Casos de Uso
Un caso de uso, en principio, debera describir una tarea que tiene un

sentido completo para el usuario. Sin embargo, hay ocasiones en las que
es til describir una interaccin con un alcance menor como caso de uso.
La razn para utilizar estos casos de uso no completos en algunos casos,
es mejorar la comunicacin en el equipo de desarrollo, el manejo de la
documentacin de casos de uso. Para el caso de que queramos utilizar
estos casos de uso ms pequeos, las relaciones entre estos y los casos
de uso ordinarios pueden ser de los siguientes dos tipos:
Incluye (<>): Un caso de uso base incorpora explcitamente a otro caso de

uso en un lugar especificado en dicho caso base. Se suele utilizar para
encapsular un comportamiento parcial comn a varios casos de uso. En la
figura se muestra cmo el caso de uso Realizar Reintegro puede incluir el
comportamiento del caso de uso Autorizacin.
Figura 2.2: Ejemplo de caso de uso (include)
Fuente: [WEB 09]
Extiende (<>): Cuando un caso de uso base tiene ciertos puntos (puntos
de extensin) en los cuales, dependiendo de ciertos criterios, se va a
realizar una interaccin adicional. El caso de uso que extiende describe un
comportamiento opcional del sistema (a diferencia de la relacin incluye
40
que se da siempre que se realiza la interaccin descrita) En la figura se
muestra como el caso de uso Comprar Producto permite explcitamente
extensiones en el siguiente punto de extensin: info regalo. La interaccin
correspondiente a establecer los detalles sobre un producto que se enva
como regalo estn descritos en el caso de uso Detalles Regalo.
Figura 2.3: Ejemplo de caso de uso (extend)
Fuente: [WEB 09]
Generalizacin: Entonces la Generalizacin es la actividad de identificar

elementos en comn entre conceptos y definir las relaciones de una
superclase (concepto general) y subclase (concepto especializado). Es una
manera de construir clasificaciones taxonmicas entre conceptos que
entonces se representan en jerarquas de clases. Las subclases
conceptuales son conformes con las superclases conceptuales en cuanto a
la intencin y extensin."
En la tercera forma de relaciones entre casos de uso, existe una relacin

generalizacin/especializacin. La notacin es una lnea slida terminada
en un tringulo dibujado desde el caso de uso especializado al caso de uso
general.
2.5.1.1.2 DIAGRAMA DE ACTIVIDADES
El diagrama de actividades sirve para representar el sistema desde otra

perspectiva, y de este modo complementa a los anteriores diagramas vistos.
Grficamente un diagrama de actividades ser un conjunto de arcos y nodos.
Desde un punto de vista conceptual, el diagrama de actividades muestra cmo
fluye el control de unas clases a otras con la finalidad de culminar con un flujo de
41
control total que se corresponde con la consecucin de un proceso ms complejo.
Por este motivo, en un diagrama de actividades aparecern acciones y actividades
correspondientes a distintas clases. Colaborando todas ellas para conseguir un
mismo fin. Ejemplo: Hacer un pedido.
Contenido del diagrama de actividades

Bsicamente un diagrama de actividades contiene:
Estados de actividad, Estados de accin, Transiciones, Objetos.
Estados de actividad y estados de accin
La representacin de ambos es un rectngulo con las puntas redondeadas, en

cuyo interior se representa bien una actividad o bien una accin. La forma de
expresar tanto una actividad como una accin, no queda impuesta por UML, se
podra utilizar lenguaje natural, una especificacin formal de expresiones, un
metalenguaje, etc. La idea central es la siguiente: Un estado que represente
una accin es atmico, lo que significa que su ejecucin se puede considerar
instantnea y no puede ser interrumpida En la figura, podemos ver ejemplos
de estados de accin.
Figura 2.5: Ejemplo de estado de accin
Fuente: [Web 09]
En cambio un estado de actividad, s puede descomponerse en ms sub-

actividades representadas a travs de otros diagramas de actividades. Adems
estos estados s pueden ser interrumpidos y tardan un cierto tiempo en
completarse.
42
Transiciones
Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o

de accin. Esta transicin se produce como resultado de la finalizacin del
estado del que parte el arco dirigido que marca la transicin. Como todo flujo
de control debe empezar y terminar en algn momento, podemos indicar esto
utilizando dos disparadores de inicio y fin tal y como queda reflejado en el
ejemplo de la figura.
Figura 2.6: Ejemplo de transiciones
Fuente: [WEB 09]

Bifurcaciones
Un flujo de control no tiene porqu ser siempre secuencial, puede presentar

caminos alternativos. Para poder representar dichos caminos alternativos o
bifurcacin se utilizar como smbolo el rombo. Dicha bifurcacin tendr una
transicin de entrada y dos o ms de salida. Para poder cubrir todas las
posibilidades se puede utilizar la palabra ELSE, para indicar una transicin
obligada a un determinado estado cuando el resto de guardas han fallado. En la
figura podemos ver un ejemplo de bifurcacin.
43
Figura 2.7: Ejemplo de bifurcacin
Fuente: [WEB 09]
Divisin y unin
No slo existe el flujo secuencial y la bifurcacin, tambin hay algunos casos en

los que se requieren tareas concurrentes. UML representa grficamente el proceso
de divisin, que representa la concurrencia, y el momento de la unin de nuevo al
flujo de control secuencial, por una lnea horizontal ancha. En la figura podemos
ver cmo se representa grficamente.
Figura 2.8: Ejemplo de divisin y unin
Fuente: [WEB 09]
Calles
Cuando se modelan flujos de trabajo de organizaciones, es especialmente til

dividir los estados de actividades en grupos, cada grupo tiene un nombre concreto
44
y se denominan calles. Cada calle representa a la parte de la organizacin
responsable de las actividades que aparecen en esa calle. Grficamente quedara
como se muestra en la figura.
Figura 2.9: Ejemplo de calles
Fuente: [WEB 09]
2.5.2 MTODO PARA PROBAR EL SOFTWARE
2.5.2.1 PRUEBA DE CAJA BLANCA
Las pruebas de caja blanca (tambin conocidas como pruebas de caja de cristal
o pruebas estructurales) se centran en los detalles procedimentales del software,
por lo que su diseo est fuertemente ligado al cdigo fuente. El testeador escoge
distintos valores de entrada para examinar cada uno de los posibles flujos de
ejecucin del programa y cerciorarse de que se devuelven los valores de salida
adecuados.
Al estar basadas en una implementacin concreta, si sta se modifica, por regla

general las pruebas tambin debern redisearse.
Aunque las pruebas de caja blanca son aplicables a varios niveles (unidad,
integracin y sistema), habitualmente se aplican a las unidades de software. Su
cometido es comprobar los flujos de ejecucin dentro de cada unidad (funcin,
45
clase, mdulo, etc.) pero tambin pueden testear los flujos entre unidades durante
la integracin, e incluso entre subsistemas, durante las pruebas de sistema.
A pesar de que este enfoque permite disear pruebas que cubran una amplia
variedad de casos de prueba, podra pasar por alto partes incompletas de la
especificacin o requisitos faltantes, pese a garantizar la prueba exhaustiva de
todos los flujos de ejecucin del cdigo analizado.
Las principales tcnicas de diseo de pruebas de caja blanca son:
Pruebas de caminos bsicos
Pruebas de flujo de datos
Pruebas de bifurcacin
Pruebas de flujo de control
2.5.2.1.1 PRUEBA DEL CAMINO BSICO
El mtodo del camino bsico (propuesto por McCabe) permite obtener una medida
de la complejidad de un diseo procedimental, y utilizar esta medida como gua
para la definicin de una serie de caminos bsicos de ejecucin, diseando casos
de prueba que garanticen que cada camino se ejecuta al menos una vez.
2.5.2.1.1.1 NOTACIN DEL GRAFO DE FLUJO O GRAFO DEL PROGRAMA
Representa el flujo de control lgico con la siguiente notacin:
Figura 2.10: Notacin del grafo flujo
46
Fuente: [WEB 04]
A continuacin se muestra un ejemplo basado en un diagrama de flujo que
representa la estructura de control del programa.
Figura 2.11: Ejemplo de la estructura de control
Fuente: [WEB 04]
Figura 2.12: Ejemplo de grafo de flujo
47
Fuente: [WEB 04]
En el grafo de flujo
Cada nodo representa una o ms sentencias procedimentales.
Un solo nodo puede corresponder a una secuencia de pasos del proceso y a

una decisin.
Las flechas (aristas) representan el flujo de control.
Cualquier representacin del diseo procedimental se puede traducir a un grafo de

flujo.
2.5.2.1.1.2 COMPLEJIDAD CICLOMTICA
Es una medida que proporciona una idea de la complejidad lgica de un
Programa.
La complejidad ciclo matica coincide con el nmero de regiones del grafo de

flujo
La complejidad ciclo matica, V(G), de un grafo de flujo G, se define como:
V (G) = Aristas - Nodos + 2
La complejidad ciclo matica, V (G), de un grafo de flujo G, tambin se define
Como: V (G) = Nodos de predicado + 1
A partir del grafo de flujo de la figura anterior, la complejidad ciclomtica

sera:
Como el grafo tiene cuatro regiones, V (G) = 4
Como el grafo tiene 11 aristas y 9 nodos, V (G) = 11 - 9 - 2 = 4
Como el grafo tiene 3 nodos predicado, V (G) = 3 + 1 = 4
48
A partir del valor de la complejidad ciclomtica obtenemos el nmero de caminos
independientes, que nos dan un valor lmite para el nmero de pruebas que
tenemos que disear.
En el ejemplo, el nmero de caminos independientes es 4, y los caminos

independientes son:
1-11
1-2-3-4-5-10-1-11
1-2-3-6-7-9-10-1-11
1-2-3-6-8-9-10-1-11
2.5.2.1.1.3 PASOS DEL DISEO DE PRUEBAS MEDIANTE EL CAMINO

BSICO
Obtener el grafo de flujo, a partir del diseo o del cdigo del mdulo
Obtener la complejidad ciclomtica del grafo de flujo
Definir el conjunto bsico de caminos independientes
Determinar los casos de prueba que permitan la ejecucin de cada uno de

los caminos anteriores
Ejecutar cada caso de prueba y comprobar que los resultados son los
esperados.
2.5.2.2 PRUEBA DE CAJA NEGRA
Las pruebas de caja negra se centran en lo que se espera de un mdulo, es decir,

intentan encontrar casos en que el mdulo no se atiene a su especificacin. Por
ello se denominan pruebas funcionales, y el probador se limita a suministrarle
datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar
haciendo el mdulo por dentro.
49
Las pruebas de caja negra estn especialmente indicadas en aquellos mdulos
que van a ser interfaz con el usuario (En sentido general: teclado, pantalla,
ficheros, canales de comunicaciones, etc.) Este comentario no obsta para que
sean tiles en cualquier mdulo del sistema.
A la vista de los requisitos de un mdulo, se sigue una tcnica algebraica conocida

como "clases de equivalencia". Esta tcnica trata cada parmetro como un modelo
algebraico donde unos datos son equivalentes a otros. Si logramos partir un rango
excesivamente amplio de posibles valores reales a un conjunto reducido de clases
de equivalencia, entonces es suficiente probar un caso de cada clase, pues los
dems datos de la misma clase son equivalentes.
El problema est pues en identificar clases de equivalencia, tarea para la que no

existe una regla de aplicacin universal; pero hay recetas para la mayor parte de
los casos prcticos:
Si un parmetro de entrada debe estar comprendido en un cierto rango,

aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.
Si una entrada requiere un valor concreto, aparecen 3 clases de

equivalencia: por debajo, en y por encima del rango.
Si una entrada requiere un valor de entre los de un conjunto, aparecen 2

clases de equivalencia: en el conjunto o fuera de l.
Si una entrada es booleana, hay 2 clases: si o no.
los mismos criterios se aplican a las salidas esperadas: hay que intentar
generar resultados en todas y cada una de las clases.
50
2.5.3 MODELOS
2.5.3.1 MODELO DE GESTIN ORIENTADA AL CLIENTE (CRM)
CRM de la sigla del trmino en ingles (Customer Relationship Management),

Gestin de las Relaciones con el Cliente, el nombre en si hace referencia a dos
conceptos.
Estrategia de negocio
Sistemas informticos para soportar esta estrategia.
CRM como estrategia de negocio: Se basa en conseguir una mayor cuota de

mercado mediante el afianzamiento y crecimiento de la base de clientes
deseados. Es decir, ganar y mantener a los clientes que le convienen a la
empresa. Este concepto puede parecer obvio, pero no lo es. En la mayor parte de
las empresas supone un cambio en la cultura del negocio, en los procesos, y en
los sistemas de soporte.
Tradicionalmente las empresas se centraban en el producto o servicio en vez de

en el cliente. Se desarrollaba un producto y mediante campaas de marketing de
consumo masivo se intentaba venderlo. Sin embargo, la estrategia empresarial del
CRM pasa de un enfoque centrado en el producto a un enfoque centrado en el
cliente. El cliente pasa a ser el centro de atencin de la empresa, pasamos el
marketing de consumo masivo al marketing de uno a uno, hay que darle a cada
cliente los productos y servicios que necesita. Todas las interacciones del cliente
con la empresa tienen que ser personalizadas, independientemente de en qu
rea de la empresa se d y el motivo que la origine.
Esta nueva estrategia pone al cliente en el centro del negocio. Y si se implementa

de la forma adecuada, nos permitir adquirir cada vez ms informacin sobre
nuestros clientes de forma que podamos planificar de forma ms eficaz y eficiente
todas las reas de negocio de nuestra empresa. De esta forma obtendremos
numerosos beneficios, conseguiremos hacer un marketing ms efectivo, una mejor
51
planificacin de servicios y obtener mucho ms control sobre las ventas y finanzas
de la compaa.
Por lo tanto, el CRM como estrategia de negocio implica todas las relaciones con
el cliente, ya sean marketing, ventas o servicio. Nos ayuda a poner al cliente
primero, proveyndonos de una gran cantidad de informacin para hacer nuestro
negocio mucho ms efectivo. Y ayuda a tener una visin mucho ms clara del
rendimiento de nuestras actividades.
Software para la administracin de la relacin con los clientes. Sistemas

informticos de apoyo a la gestin de las relaciones con los clientes, a la venta y al
marketing.
El CRM como sistema informtico: hace referencia al conjunto de todas las

aplicaciones necesarias para dar soporte a esta estrategia empresarial. Estos
sistemas tienen que proporcionar formas automatizadas de manejar a los clientes,
ya sean a travs de canales tradicionales o de Internet. Deben proporcionar la
automatizacin de la fuerza de ventas, el marketing, y el servicio y soporte al
cliente como reas principales. Con este significado CRM se refiere al sistema que
administra un DATA WAREHOUSE (almacn de datos) con la informacin de la
gestin de ventas y de los clientes de la empresa.
En cada una de estas reas se dan un sin fin de desafos tecnolgicos y una gran
cantidad de posibilidades de mejora a la hora de introducir un sistema CRM. Sin
embargo, lo ms importante es que el sistema sea un todo y no un conjunto de
aplicaciones para funcionalidades especficas que comparte informacin bsica de
los clientes. El sistema debe permitir a cualquier representante de la compaa, ya
sea de ventas o servicio, acceder a toda la informacin necesaria del cliente poder
ofrecer un trato lo ms personalizado posible independientemente del tipo de
transaccin que se realice. De nada vale un sistema con unas funcionalidades
impresionantes, pero estancas, en cada rea de la organizacin.
52
Por lo tanto, los sistemas CRM deben proporcionar el soporte necesario para la
estrategia de negocio centrada en el cliente. Y deben de hacerlo de una forma
integrada, proporcionando soporte a todo el front-office, de forma que toda la
informacin relacionada este en un mismo lugar y sea fcilmente accesible. De
esta forma conseguiremos que la estrategia de negocio centrada en el cliente
pueda ser una realidad en la empresa.
En resumen la estrategia empresarial del CRM, junto con las herramientas

informticas adecuadas, permite a una empresa construir una base slida de
clientes, mejorando la eficacia y eficiencia de sus procesos, y obteniendo como
resultado un aumento de sus beneficios. Lo que permite afirmar que la
implantacin del CRM en una empresa, si se realiza de la forma adecuada,
obtendr un retorno de la inversin (ROI) que de sobra justificar el
esfuerzo. [WEB 05]
2.5.3.2 MODELO ITERATIVO INCREMENTAL
El software evoluciona con el tiempo. Los requisitos del usuario y del producto
suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la
competencia hacen que no sea posible esperar a poner en el mercado un
producto absolutamente completo, por lo que se debe introducir una versin
funcional limitada de alguna forma para aliviar las presiones competitivas.
En esas u otras situaciones similares los desarrolladores necesitan modelos de

progreso que estn diseados para acomodarse a una evolucin temporal o
progresiva, donde los requisitos centrales son conocidos de antemano, aunque no
estn bien definidos a nivel detalle.
Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez
ms completas y complejas, hasta llegar al objetivo final deseado; incluso
evolucionar ms all, durante la fase de operacin.
En resumen, un modelo incremental lleva a pensar en un desarrollo modular, con

entregas parciales del producto software denominados incrementos del sistema,
que son escogidos segn prioridades predefinidas de algn modo. El modelo
53
permite una implementacin con refinamientos sucesivos (ampliacin o mejora).
Con cada incremento se agrega nueva funcionalidad o se cubren nuevos
requisitos o bien se mejora la versin previamente implementada del producto
software.
Este modelo brinda cierta flexibilidad para que durante el desarrollo se incluyan
cambios en los requisitos por parte del usuario, un cambio de requisitos propuesto
y aprobado puede analizarse e implementarse como un nuevo incremento o,
eventualmente, podr constituir una mejora/adecuacin de uno ya planeado.
Aunque si se produce un cambio de requisitos por parte del cliente que afecte
incrementos previos ya terminados (deteccin/incorporacin tarda) se debe
evaluar la factibilidad y realizar un acuerdo con el cliente, ya que puede impactar
fuertemente en los costos.
La seleccin de este modelo permite realizar entregas funcionales tempranas al

cliente (lo cual es beneficioso tanto para l como para el grupo de desarrollo). Se
priorizan las entregas de aquellos mdulos o incrementos en que surja la
necesidad operativa de hacerlo, por ejemplo para cargas previas de informacin,
indispensable para los incrementos.
El modelo iterativo incremental no obliga a especificar con precisin y detalle

absolutamente todo lo que el sistema debe hacer, (y cmo), antes de ser
construido (como el caso del cascada, con requisitos congelados). Slo se hace
en el incremento en desarrollo. Esto torna ms manejable el proceso y reduce el
impacto en los costos. Esto es as, porque en caso de alterar o rehacer los
requisitos, solo afecta una parte del sistema. Aunque, lgicamente, esta situacin
se agrava si se presenta en estado avanzado, es decir en los ltimos
incrementos. En definitiva, el modelo facilita la incorporacin de nuevos requisitos
durante el desarrollo.
Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se

implementa funcionalidad parcial. Tambin provee un impacto ventajoso frente al
cliente, que es la entrega temprana de partes operativas del software.
54
El modelo proporciona todas las ventajas del modelo en cascada realimentado,
reduciendo sus desventajas slo al mbito de cada incremento. [WEB 06]
Figura 2.13: Modelo iterativo incremental para el ciclo de vida del software
Fuente: [WEB 06]
Nota: Puede ser considerado y til, en cualquier momento o incremento incorporar

temporalmente el paradigma MCP como complemento, teniendo as una mixtura
de modelos que mejoran el esquema y desarrollo general.
2.5.3.2.1 FASES DEL MODELO.
En esta fase se analizan las necesidades de los usuarios finales del

software para determinar qu objetivos debe cubrir. De esta fase surge una
memoria llamada SRD (documento de especificacin de requisitos), que
55
contiene la especificacin completa de lo que debe hacer el sistema sin
entrar en detalles internos.
Diseo del Sistema
Se descompone y organiza el sistema en elementos que puedan elaborarse

por separado, aprovechando las ventajas del desarrollo en equipo. Como
resultado surge el SDD (Documento de Diseo del Software), que contiene
la descripcin de la estructura relacional global del sistema y la
especificacin de lo que debe hacer cada una de sus partes, as como la
manera en que se combinan unas con otras.
Diseo del Programa
Es la fase en donde se realizan los algoritmos necesarios para el

cumplimiento de los requerimientos del usuario as como tambin los
anlisis necesarios para saber que herramientas usar en la etapa de
Codificacin.
Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de

prototipos as como de pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programacin y su versin se crean las

bibliotecas y componentes reutilizables dentro del mismo proyecto para
hacer que la programacin sea un proceso mucho ms rpido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y

se comprueba que funciona correctamente y que cumple con los requisitos,
antes de ser entregado al usuario final.
Implantacin
56
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los
programadores ya realizaron exhaustivas pruebas para comprobar que el
sistema no falle.
Mantenimiento
Una de las etapas que creo considerables porque se destina un 75% de los
recursos, es el mantenimiento del Software ya que al utilizarlo como usuario
final puede ser que no cumpla con todas nuestras expectativas.
2.5.4 MODELO DE ESTIMACIN DEL PROYECTO
2.5.4.1 COCOMO II
El modelo original COCOMO se public por primera vez en 1981 por Barry Boehm
y reflejaba las prcticas en desarrollo de software de aquel momento. En la
dcada y media siguiente las tcnicas de desarrollo software cambiaron
drsticamente. Estos cambios incluyen el gasto de tanto esfuerzo en disear y
gestionar el proceso de desarrollo software como en la creacin del producto
software, un giro total desde los mainframe que trabajan con procesos batch
nocturnos hacia los sistemas en tiempo real y un nfasis creciente en la
reutilizacin de software ya existente y en la construccin de nuevos sistemas que
utilizan componentes software a medida.
Estos y otros cambios hicieron que la aplicacin del modelo COCOMO original
empezara a resultar problemtica. La solucin al problema era reinventar el
modelo para aplicarlo a los 90. Despus de muchos aos de esfuerzo combinado
entre USC-CSE1, IRUS y UC Irvine22 y las Organizaciones Afiliadas al Proyecto
COCOMO II, el resultado es COCOMO II, un modelo de estimacin de coste que
refleja los cambios en la prctica de desarrollo de software profesional que ha
surgido a partir de los aos 70. Este nuevo y mejorado COCOMO resultar de
gran ayuda para los estimadores profesionales de coste software.
Por tanto, COCOMO II es un modelo que permite estimar el coste, esfuerzo y

tiempo cuando se planifica una nueva actividad de desarrollo software. Est
57
asociado a los ciclos de vida modernos. El modelo original COCOMO ha tenido
mucho xito pero no puede emplearse con las prcticas de desarrollo software
ms recientes tan bien como con las prcticas tradicionales. COCOMO II apunta
hacia los proyectos software de los 90 y de la primera dcada del 2000, y
continuar evolucionando durante los prximos aos.
2.5.4.1.1 MTRICAS DE SOFTWARE
En la estimacin del tamao de software COCOMO II utiliza tres tcnicas: Puntos

Objeto, Puntos Funcin No Ajustados y Lneas de Cdigo Fuente. Adems se
emplean otros parmetros relativos al tamao que contemplan aspectos tales
como: rehso, reingeniera, conversin, y mantenimiento.
Es necesario unificar criterios de medicin de tamao, tanto para poder planificar y

controlar proyectos, como para realizar estudios y anlisis entre proyectos en pro
de la mejora de procesos.
2.5.4.1.1.1 PUNTOS FUNCIN
El modelo COCOMO II usa Puntos Funcin y/o Lneas de Cdigo Fuente (SLOC)
como base para medir tamao en los modelos de estimacin de Diseo Temprano
y Post-Arquitectura.
Las mtricas para puntos funcin estn basadas en las guas proporcionadas por
el "International Function Point User Group"-IFPUG.
Los Puntos Funcin procuran cuantificar la funcionalidad de un sistema de

software. La meta es obtener un nmero que caracterice completamente al
sistema. Son tiles estimadores ya que estn basados en informacin que est
disponible en las etapas tempranas del ciclo de vida del desarrollo de software.
COCOMO II considera solamente UFP (Puntos Funcin no ajustados).
La frmula de Albretch para calcular los puntos funcin, es la siguiente:
FP = UFP x TCF
58
Donde UFP: Puntos Funcin no Ajustados
TCF: Factor de Complejidad Tcnica
Para calcular los UFP, se deben identificar los siguientes tipos de tems:
Entradas Externas (Inputs): Entrada de datos del usuario o de control que

ingresan desde el exterior del sistema para agregar y/o cambiar datos a un
archivo lgico interno.
Salidas Externas (Outputs): Salida de datos de usuario o de control que
deja el lmite del sistema de software.
Archivo Lgicos Internos (Archivos): Incluye cada archivo lgico, es decir
cada grupo lgico de datos que es generado, usado, o mantenido por el
sistema de software.
Archivos Externos de Interface (Interfaces): Archivos transferidos o
compartidos entre sistemas de software.
Solicitudes Externas (Queries): Combinacin nica de entrada-salida,
donde una entrada causa y genera una salida inmediata, como un tipo de
solicitud externa.
La Tabla muestra como se determinan los niveles de complejidad de cada tipo de

tem en funcin del nmero y tipo de elementos de datos y archivos involucrados.
Tabla 2.1: Puntos funcin
59
Fuente: [Elaboracin basada en Boehm WEB 07]
La Tabla muestra las ponderaciones asociadas a cada tipo de tem. Estas

ponderaciones han sido derivadas y validadas empricamente mediante la
observacin de una gran variedad de proyectos.
Tabla 2.2: Peso de factor de complejidad
Fuente: [Elaboracin basada en Boehm WEB 07]
Para el clculo del Factor de Complejidad Tcnica, TCF, se considera la siguiente

frmula:
Donde los F i corresponden a los pesos asignados a los siguientes factores:
F1: Mecanismos de recuperacin y back-up confiables
F2: Comunicacin de Datos
F3: Funciones de Procesamiento Distribuido
F4: Performance
F5: Configuracin usada rigurosamente
F6: Entrada de datos on-line
F7: Factibilidad Operativa
60
F8: Actualizacin de archivos on-line
F9: Interfaces Complejas
F10: Procesamiento Interno Complejo
F11: Reusabilidad
F12: Fcil Instalacin
F13: Soporte de mltiples instalaciones
F14: Facilidad de cambios y amigabilidad
Los pesos se consideran dentro de una escala de 0 a 5, descripta a continuacin:
0: Sin influencia
1: Incidental
2: Moderado
3: Medio
4: Significativo
5: Esencial
Estas 14 caractersticas consideran aspectos como reusabilidad, performance,

complejidad, confiabilidad, etc., contemplados por COCOMO II a travs de los
factores de costo. Es por ello que este modelo utiliza los UFP como mtrica de
determinacin de tamao.
2.5.4.1.1.2 LNEAS DE CDIGO FUENTE
COCOMO II considera a la sentencia fuente lgica como lnea standard de cdigo.

Ahora bien, definir una lnea de cdigo es difcil debido a que existen diferencias
conceptuales cuando se cuentan sentencias ejecutables y de declaraciones de
61
datos en lenguajes diferentes. El objetivo es medir la cantidad de trabajo
intelectual puesto en el desarrollo de un programa.
Existen herramientas automatizadas para medir la cantidad de lneas de cdigo

fuente, como por ejemplo Amadeus. Para realizar un anlisis de mayor
especificidad, Amadeus automticamente recolecta medidas adicionales como
total de lneas fuente, de comentarios, declaraciones, interfaces, anidamientos,
sentencias ejecutables y otras.
2.5.4.1.1.3 CONVERSIN DE PUNTOS FUNCIN A LINEAS DE CDIGO

FUENTE (SLOC)
Para determinar el esfuerzo nominal en el modelo COCOMO II los puntos funcin

no ajustados tienen que ser convertidos a lneas de cdigo fuente considerando el
lenguaje de implementacin (Assembler, lenguajes de alto nivel, lenguajes de
cuarta generacin, etc.). Esto se realiza para los modelos Diseo Temprano y Post
Arquitectura teniendo en cuenta la Tabla propuesta por Jones.
2.5.5 MODELO PARA EVALUAR LA CALIDAD DEL SOFTWARE
2.5.5.1 CALIDAD DEL SOFTWARE
A la hora de definir la calidad del software se debe diferenciar entre la calidad del
producto software y la calidad del proceso de desarrollo de ste (calidad de diseo
y fabricacin). No obstante, las metas que se establezcan para la calidad del
producto van a determinar los OBJETIVOS a establecer de calidad del proceso de
desarrollo, ya que la calidad del primero va a depender, entre otros aspectos, de
sta. Sin un buen proceso de desarrollo es casi imposible obtener un buen
producto. Este proceso constituye el objeto del presente trabajo.
Pero la calidad del producto software se diferencia de la calidad de otros

productos de fabricacin industrial, ya que el software tiene sus propias
caractersticas especficas:
62
El software es un producto mental, no restringido por las LEYES de
la FSICA o por los LMITES de los procesos de fabricacin. Es algo
abstracto, un intangible.
Se desarrolla, no se fabrica. El coste est fundamentalmente en el proceso

de diseo, no en la posterior produccin en serie, y los errores se introducen
tambin en el diseo, no en la produccin.
Los costes del desarrollo de software se concentran en las tareas

de INGENIERA, mientras que en la fabricacin clsica los costes se
acentan ms en las tareas de produccin.
El software no se deteriora con el TIEMPO. No es susceptible de los efectos

del entorno y su curva de fallos es muy diferente de la del hardware. Todos
los PROBLEMAS que surjan durante el mantenimiento estaban all desde el
principio y afectan a todas las copias del mismo; no se generan nuevos
errores.
Es artesanal en gran medida. El software, en su mayora, se construye a

medida, en vez de ser construido ensamblando componentes existentes y ya
probados, lo que dificulta an ms el control de su calidad.
El mantenimiento del software es mucho ms complejo que el mantenimiento

del hardware. Cuando un componente del hardware se deteriora se sustituye
por una pieza de repuesto, pero cada fallo en el software implica un error en
el diseo o en el proceso mediante el cual se tradujo el diseo
en CDIGO mquina ejecutable.
Es engaosamente fcil realizar cambios sobre un producto software, pero

los efectos de estos cambios se pueden propagar de forma explosiva e
incontrolada.
Como DISCIPLINA, el desarrollo de software es an muy joven, por lo que

las TCNICAS de las que dispone an no estn perfeccionadas.
63
El software con errores no se rechaza. Se asume que es inevitable que el
software presente algunos errores de poca importancia.
Tambin es importante destacar que la calidad de un producto software debe ser

considerada en todos sus estados de EVOLUCIN (especificaciones, diseo,
cdigos). No basta con verificar la calidad del producto una vez finalizado cuando
los problemas de mala calidad ya no tienen solucin o su reparacin es muy
costosa.
La problemtica general a la que se enfrenta el software es:
Aumento constante del tamao y complejidad de los programas.
Carcter dinmico e iterativo a lo largo de su ciclo de vida, es decir que los

programas de software a lo largo de su vida cambian o evolucionan de una
versin a otra para mejorar las prestaciones con respecto a las anteriores.
Dificultad de conseguir productos totalmente depurados, ya que en ningn

caso un PROGRAMA ser perfecto.
Se dedican elevados RECURSOS monetarios a su mantenimiento, debido

a la dificultad que los PROYECTOS de software entraan y a la no
NORMALIZACIN a la hora de realizar los proyectos.
No suelen estar terminados en los plazos previstos, ni con los costes

estipulados, ni cumpliendo los niveles deseables de los requisitos
especificados por el usuario.
Incrementos constantes de los costes de desarrollo debido entre otros, a

unos niveles de PRODUCTIVIDAD bajos.
Los clientes tienen una alta dependencia de sus proveedores por ser en
muchos casos aplicaciones a "medida".
Procesos artesanales de produccin con ESCASEZ de herramientas.
64
Insuficientes PROCEDIMIENTOS normalizados para estipular y evaluar la
productividad, costes, y calidad.[WEB 10]
2.5.5.2 MODELO MCCALL
El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los
cuales el usuario puede contemplar la calidad de un producto, basndose en once
factores de calidad organizados en torno a los tres ejes y a su vez cada factor se
desglosa en otros criterios:
Tabla 2.3: Puntos de vista, factores y criterios del modelo McCall
Puntos De Factor Criterios

Vista O Ejes
Visin de - Facilidad de operacin: Atributos del
usuario Facilidad de uso software que determinan la facilidad de
operacin del software.
- Facilidad de comunicacin: Atributos del
software que proporcionan entradas y
salidas fcilmente asimilables.
- Facilidad de APRENDIZAJE: Atributos del
software que facilitan la familiarizacin
inicial del usuario con el software y la
transicin del modo actual de operacin.
- Formacin: El grado en que el software
ayuda para permitir que nuevos usuarios
apliquen el sistema.
- Control de accesos. Atributos del software
Integridad que proporcionan control de acceso al
software y los DATOS que maneja.
- Facilidad de AUDITORA: Atributos del
software que facilitan la auditora de los
accesos al software.
- SEGURIDAD: La disponibilidad de
65
mecanismos que controlen o protejan los
programas o los datos.
- Completitud: Atributos del software que

Correccin proporcionan la implementacin completa
de todas las funciones requeridas.
- Consistencia: Atributos del software que
proporcionan uniformidad en las tcnicas y
notaciones de diseo e implementacin.
- Trazabilidad o rastreabilidad: Atributos del
software que proporcionan una traza desde
los requisitos a la implementacin con
respecto a un entorno operativo
CONCRETO.
Visin de la - Precisin: Atributos del software que
direccin Fiabilidad proporcionan el grado de precisin
requerido en los clculos y los resultados.
- Consistencia.
- TOLERANCIA a fallos: Atributos del
software que posibilitan la continuidad del
funcionamiento bajo condiciones no
usuales.
- Modularidad: Atributos del software que
proporcionan una ESTRUCTURA de
mdulos altamente independientes.
- Simplicidad: Atributos del software que
posibilitan la implementacin de funciones
de la forma ms comprensible posible.
- Exactitud: La precisin de los clculos y
del control.
66
- EFICIENCIA en ejecucin: Atributos del
Eficiencia software que minimizan el tiempo de
procesamiento.
- Eficiencia en ALMACENAMIENTO:
Atributos del software que minimizan el
espacio de almacenamiento necesario.
Visin del - Modularidad.
desarrollado Facilidad de - Simplicidad.
r mantenimiento - Consistencia.
- Concisin: Atributos del software que
posibilitan la implementacin de una
funcin con la menor cantidad de cdigos
posible.
- Auto descripcin: Atributos del software
que proporcionan explicaciones sobre la
implementacin de las funciones.
- Modularidad.
Facilidad de - Simplicidad.
prueba - Auto descripcin.
- Instrumentacin: Atributos del software
que posibilitan la OBSERVACIN del
COMPORTAMIENTO del software durante
su ejecucin para facilitar las mediciones
del uso o la identificacin de errores.
- Auto descripcin.
Flexibilidad - Capacidad de expansin: Atributos del
software que posibilitan la expansin del
software en cuanto a capacidades
funcionales y datos.
- Generalidad: Atributos del software que
proporcionan amplitud a las funciones
implementadas.
67
- Modularidad.
- Auto descripcin.
Reusabilidad - Generalidad.
- Modularidad.
-INDEPENDENCIA entre sistema y
software: Atributos del software que
determinan su dependencia del entorno
operativo.
- Independencia del hardware: Atributos del
software que determinan su dependencia
del hardware.
- Modularidad.
Interoperabilidad - Compatibilidad de COMUNICACIONES:
Atributos del software que posibilitan el uso
de PROTOCOLOS de comunicacin e
interfaces estndar.
- Compatibilidad de datos: Atributos del
software que posibilitan el uso
representaciones de datos estndar.
- Estandarizacin en los datos: El uso de
ESTRUCTURAS de datos y de tipos
estndar a lo largo de todo el programa.
- Auto descripcin.
Portabilidad - Modularidad.
-Independencia entre sistema y software.
- Independencia del hardware.
Fuente: [Elaboracin basada en WEB 11]
68
Antes de comenzar a utilizar el modelo de McCall hay que seguir las siguientes
pautas:
1. Se aceptan los factores, criterios y mtricas que propone el modelo.
2. Se aceptan las relaciones entre factores y criterios, y entre criterios y

mtricas.
3. Se selecciona un subconjunto de factores de calidad sobre los que aplicar

los requisitos de calidad establecidos para el proyecto.
Al comienzo del proyecto habr que especificar los requisitos de calidad del
producto software, para lo cual se seleccionarn los aspectos inherentes a la
calidad deseada del producto, teniendo que considerarse para ello:
Las caractersticas particulares del propio producto que se est diseando:

por ejemplo, su ciclo de vida que si se espera que sea largo implicar un mayor
nfasis en la facilidad de mantenimiento y la flexibilidad, o bien si el sistema en
desarrollo est destinado a un entorno donde el hardware evoluciona
rpidamente implicar como requisito su portabilidad.
La relacin calidad-PRECIO, que puede evaluarse a travs del coste de

cada factor de calidad frente al beneficio que proporciona. La siguiente tabla
MUESTRA la relacin calidad-precio para cada factor considerado:
Tabla 2.4: McCall calidad - precio
Factor Beneficio /
coste
Correccin Alto
Fiabilidad Alto
69
Eficiencia Bajo
Integridad Bajo
Facilidad de uso Medio
Facilidad de Alto
mantenimiento
Facilidad de prueba Alto
Flexibilidad Medio
Portabilidad Medio
Reusabilidad Medio
Interoperabilidad Bajo
Fuente: [Elaboracin basada en WEB 11]
La determinacin de las etapas del ciclo de vida donde es necesario

evaluar cada factor de calidad para conocer en cuales se dejan sentir ms los
efectos de una calidad pobre con respecto a cada uno de los factores.
Las propias interrelaciones entre los factores debido a que algunos factores
pueden entrar en conflicto entre s: por ejemplo, la eficiencia plantea conflictos
prcticamente con todos los dems factores de calidad. La interaccin entre los
70
diversos factores a evaluar queda reflejada en la tabla I que indica la
dependencia entre los factores de McCall.
Tambin habr que establecer valores deseables para los criterios, para lo cual se
emplearn datos histricos, el promedio en la industria, y con ellos se concretarn
los valores finales y otros intermedios o predictivos en cada perodo de medicin
durante el desarrollo, as como unos valores mnimos aceptables.
En la fase de desarrollo ser necesario implementar las mtricas elegidas, analizar

sus resultados y tomar medidas correctivas cuando los valores obtenidos estn
por debajo de los mnimos aceptables. [WEB 11]
2.6 ARQUITECTURA
2.6.1 ARQUITECTURA CLIENTE-SERVIDOR
En una arquitectura cliente-servidor, una aplicacin se modela como un conjunto

de servicios proporcionados por los servidores y un conjunto de clientes que usan
estos servicios. Los clientes necesitan conocer que servicios estn disponibles,
pero normalmente no conocen la existencia de otros clientes. Clientes y servidores
son procesos diferentes, como se muestra en la figura, que representa un modelo
lgico de una arquitectura distribuida cliente-servidor.
Varios procesos servidores pueden ejecutarse sobre un nico procesador servidor:

por lo tanto, no hay necesariamente una correspondencia 1:1 entre procesos y
procesadores en el sistema.
El diseo de sistemas cliente servidor debera reflejar la estructura lgica de la

aplicacin que se est desarrollando. Una forma de ser una aplicacin se ilustra
en la figura, que muestra una aplicacin estructurada en tres capas. La capa de
presentacin est relacionada con la presentacin de la informacin al usuario y
con toda la interaccin con l. La capa de procesamiento de la aplicacin est
relacionada con la implementacin de la lgica de la aplicacin, y la capa de
gestin de datos est relacionada con todas las operaciones sobre la base de
datos. En los sistemas centralizados, estas capas no es necesario que estn
71
claramente separadas. Sin embargo, cuando se est diseando un sistema
distribuido debera hacerse una clara distincin entre ellas, de forma que sea
posible distribuir cada capa sobre una computadora diferente. [Ian Sommerville].
Figura 2.14: Arquitectura cliente-servidor
Fuente: [Ian Sommerville]
La arquitectura cliente servidor ms simple se denomina arquitectura cliente-

servidor de dos capas, en la que una aplicacin se organiza como un servidor (o
mltiples servidores idnticos) y un conjunto de clientes. Como se ve en la figura.
Figura 2.15: Computadoras en una red cliente-servidor
72
Figura 2.16: Capas de Aplicaciones
Las arquitecturas cliente-servidor de dos capas pueden ser de dos tipos: modelo
de cliente ligero y modelo de cliente rico.
Figura 2.17: Modelo de cliente ligero y cliente rico
73
2.7 MARCO APLICATIVO
2.7.1 MICROSOFT VISUAL STUDIO 2010
Microsoft Visual Studio es un ENTORNO DE DESARROLLO INTEGRADO (IDE,

por sus siglas en ingls) para sistemas operativos WINDOWS. Soporta varios
lenguajes de programacin tales como VISUAL C++, VISUAL C#, Visual J#, y
VISUAL BASIC .NET, al igual que entornos de desarrollo web como ASP.NET.
Aunque actualmente se han desarrollado las extensiones necesarias para muchos
otros.
Visual Studio permite a los desarrolladores crear aplicaciones, sitios y aplicaciones

web, as como servicios web en cualquier entorno que soporte la plataforma .NET
(a partir de la versin .NET 2002). As se pueden crear aplicaciones que se
intercomuniquen entre estaciones de trabajo, pginas web y dispositivos mviles.
Visual Studio 2010 Ultimate: Conjunto completo de herramientas de gestin del

ciclo de vida de una aplicacin para los equipos que garantizan unos resultados de
calidad, desde el diseo hasta la implementacin. Ya sea creando nuevas
soluciones o mejorando las aplicaciones existentes, Visual Studio 2010 Ultimate le
permite llevar sus ideas a la vida en un nmero creciente de plataformas y
tecnologas - incluyendo la nube y la computacin paralela. [WEB 12]
74
2.8 MICROSOFT SQL SERVER 2008 R2 ENTERPRISE
2.8.1 SQL (STRUCTURED QUERY LANGUAGE)

El lenguaje de consulta estructurado o SQL (por sus siglas en ingls structured
query language) es un lenguaje declarativo de acceso a bases de datos
relacionales que permite especificar diversos tipos de operaciones en stas. Una
de sus caractersticas es el manejo del lgebra y el clculo relacional permitiendo
efectuar consultas con el fin de recuperar de una forma sencilla informacin de
inters de una base de datos, as como tambin hacer cambios sobre ella.
2.8.2 DESCRIPCIN DE SQL SERVER 2008
SQL Server 2008 es un elemento fundamental de la Plataforma de Datos de

Microsoft, capaz de gestionar cualquier tipo de datos, en cualquier sitio y en
cualquier momento. Le permite almacenar datos de documentos estructurados,
semiestructurados o no estructurados como son las imgenes, msica y archivos
directamente dentro de la base de datos. SQL Server 2008 le ayuda a obtener
ms rendimiento de los datos, poniendo a su disposicin una amplia gama de
servicios integrados como son consultas, bsquedas, sincronizaciones, informes y
anlisis. Sus datos pueden almacenarse y recuperarse desde sus servidores ms
potentes del Data Center hasta los desktops y dispositivos mviles, permitindole
tener un mayor control sobre la informacin sin importar dnde se almacena
fsicamente.
SQL Server 2008 le permite utilizar sus datos en aplicaciones a medida

desarrolladas con Microsoft .NET y Visual Studio y tambin desde su propia
Arquitectura Orientada a Servicio (SOA) y los procesos empresariales empleando
Microsoft BizTalk Server. [WEB 13]
75
2.8.3 SOLUCIONES
2.8.3.1 BUSINESS INTELLIGENCE
SQL Server 2008 es una plataforma escalable de Business Intelligence optimizada

para la integracin de datos, elaboracin de informes y anlisis que hace posible
poner al alcance de todos usuarios la inteligencia empresarial.
2.8.3.2 VIRTUALIZACIN Y CONSOLIDACIN DE SERVIDORES
La virtualizacin de servidor, tambin conocida como virtualizacin de hardware,

es un tema de plena actualidad en el mundo de IT debido a que permite reducir de
manera drstica los costes y mejorar la agilidad de las organizaciones.
2.8.3.3 CONSOLIDACIN DE SERVIDORES
SQL Server 2008 puede contribuir a reducir los costes de hardware y

mantenimiento mediante una solucin de consolidacin de servidores flexible que
aporta un rendimiento y una manejabilidad extraordinarios a las organizaciones.
2.8.3.4 DATA WAREHOUSE
SQL Server le ofrece una plataforma de data warehouse completa y escalable que
le permite integrar datos dentro del DW ms rpidamente, escalar y gestionar
volmenes de datos y usuarios cada vez mayores facilitando a todos las vistas de
sntesis que necesitan.
2.8.3.5 DESARROLLO DE APLICACIONES
SQL Server 2008 constituye el eje central de una plataforma completa de

programacin de datos que le permite acceder y manipular datos crticos de
negocio desde toda clase de dispositivos, plataformas y orgenes de datos.
76
2.9 SAP CRYSTAL REPORTS
Crystal Reports es una aplicacin de inteligencia empresarial utilizada para

disear y generar informes desde una amplia gama de fuentes de datos (BASES
DE DATOS).
Varias aplicaciones, como MICROSOFT VISUAL STUDIO, incluyen una versin

OEM de Crystal Reports como una herramienta de propsito general para
informes/reportes. Crystal Reports se convirti en el escritor de informes estndar
cuando MICROSOFT lo liber con VISUAL BASIC.
El software Crystal Reports permite disear fcilmente informes interactivos y

conectarlos a casi cualquier origen de datos. Los usuarios se pueden beneficiar de
las funciones de ordenacin y filtro en informes, cosa que los capacita para tomar
decisiones de manera instantnea.
Asimismo, con Crystal Reports Visual Advantage se dispone todava de ms

funciones para generar informes atractivos.
Con Crystal Reports, puede:
Aprovechar al mximo la elaboracin de informes profesionales, a un precio

atractivo para todo el mundo
Capacitar al usuario final para que explore informes con parmetros y

ordenacin en informes
Minimizar los recursos de TI y desarrollo en informes interactivos
Desarrollar potentes aplicaciones Web hbridas de datos
Ahorrar tiempo en el diseo de informes
Incrustar informes de aspecto profesional en aplicaciones Java y .NET
77
Adaptar su solucin agregando herramientas de visualizacin y
administracin de informes. [WEB 14]
2.10 MTODOS
2.10.1 MTODO DE INVENTARIO
2.10.1.1 FIRST IN, FIRST OUT (FIFO PEPS)
El mtodo PEPS parte del supuesto de que las primeras unidades de productos
que se compraron fueron las que primero se vendieron. En una economa
inflacionaria esto quiere decir que el costo de las mercancas o productos
vendidos se determina con base en los precios ms antiguos y, en consecuencia,
las utilidades presentadas van a ser artificialmente ms altas, aunque los
inventarios no vendidos queden registrados, en el balance, a los precios ms
prximos o actuales.
Por supuesto, ste mtodo de valoracin de inventarios se emplea para efectos

contables ms no para propsitos tributarios, pues a mayor utilidad tambin mayor
impuesto a pagar.
El ajuste por inflacin no produce ningn efecto en la utilidad, por cuanto el crdito
que se registra en la cuenta de correccin monetaria (ingreso) se ve compensado
por el mayor valor del costo de ventas, producto, precisamente, de dicho ajuste
por inflacin. Y esto se debe a que los inventarios ms antiguos que producen el
mayor ajuste por inflacin son los que se toman como base para el clculo del
costo de la mercanca vendida. [WEB 15]
78
CAPITULO III
ANLISIS DE COSTOS
Y
BENEFICIOS
79
3 CAPITULO III: ANLISIS COSTO Y BENEFICIO
3.1 INTRODUCCIN
En este captulo se especifican los anlisis de costos que la distribuir invertir

entre los se aplican: costo de licencias, costos de software y costos de
capacitacin, adems de los beneficios que obtendrn con el presente desarrollo
del proyecto como de los beneficios tangibles.
3.1 COSTOS DE DESARROLLO

3.1.1 COSTOS DE HARDWARE
El costo del hardware se refiere al equipo con el que se desarroll el proyecto, las
caractersticas se muestran en el siguiente cuadro.
Cuadro 3.1: Costos de Hardware
COMPUTADORA PORTATIL ACER ASPIRE ONE D257 1609
PROCESADOR INTEL (R) ATOM (TM) CPU N570 @ 1.66GHz

1.67 GHz, 1MB L2 CACHE
MEMORIA INSTALADA 2.00 GB. DDR3
(RAM)
TIPO DE SISTEMA SISTEMA OPERATIVO DE 32 bits
TECLADO, MOUSE Y INCORPORADO
PARLANTES
MONITOR LED LCD 10.1
SISTEMA DE RED WIFI (CERTIFIED)
INALAMBRICO
BATERIA 6- CELL LI-ON CON UN ALMACENAMIENTO
DE 320 GB HDD
ADAPTADOR MODELO ADP 40 TH A 19 V 2.15 A
80
Fuente: [Elaboracin de acuerdo a las caractersticas del Equipo al 19 de
marzo de 2013 TC 6,96]
PRECIOS (INCLUYE IVA) $us 400
3.1.2 COSTOS DE SOFTWARE (LICENCIAS)

El costo de las licencias se detalla en la siguiente tabla:
Cuadro 3.2: Costos de Licencia
SW DESCRIPCION COSTO DE LA
LICENCIA EN $us al
7/4/13
Visual Studio 2010 Lenguaje de
Ultimate programacin de Alto 630
nivel
MICROSOFT SQL Gestor de Base de 970
SERVER 2008 R2 Datos
ENTERPRISE
SAP Crystal Report Aplicacin para disear Licencia Gratuita
y generar informes
Sistema operativo Sistema operativo 274
Windows7 Ultimate
Enterprice Architect Modelador Licencia Gratuita
Fuente: [Elaboracin propia basada en las WEB 02, WEB 03 en fecha

24/10/12]
3.2 ESTIMACIN DE COSTOS DEL SOFTWARE
A continuacin se detalla la aplicacin elegida.
Estimacin de los puntos de funcin se identifica:
Entradas
Salidas
Consultas
Ficheros
Interfaces
81
Despus se clasifica y pondera cada funcin por su nivel de complejidad:
Simple(S), Media (M), Compleja (J).
Para obtener el nivel de complejidad, se describe en la siguiente tabla las

funciones encontradas en la elaboracin del software.
Tabla 3.1: Funciones de Software
Descripcin de Funciones Entrada Salidas Consulta Archivo

s s s
S M C S M C S M C S M C
Pantalla de ingreso al X
sistema
Pantalla de men para X
Gerente General
Gerente comercial
otros usuarios
Pantalla de registro de X
usuarios
perfiles
Pantalla de asignacin de X
roles a perfiles
clientes
proveedores
productos
traspasos entre almacenes
ventas
Pantalla de clientes X
potenciales
Pantalla de reporte de X
clientes
proveedores
82
productos
Pantalla de reportes de X
ventas
Pantalla de reportes de X
almacenes
Proceso de registro de X
productos
clientes
proveedores
Proceso de funciones X
globales
Proceso de consultas X
Proceso de reportes X
Fuente: [Elaboracin propia basado en Cocomo Barry Boehm]
De la tabla de nivel de complejidad de las funciones del software se obtiene sus

valores para encontrar los puntos de funcin sin ajustar.
Tabla 3.2: Puntos Funcin
TIPO DE DIFICULTAD PES CANTIDA TOTAL TOTAL

ELEMENTO O D PUNTO ELEMENTO
S S
ENTRADAS Simple 3 8 40
Media 4 5 20
Compleja 6 0 0
Total Puntos de Funcin Entrada 60
SALIDAS Simple 4 3 12
Media 5 0 0
Compleja 7 0 0
Total Puntos de Funcin Salida 12
CONSULTAS Simple 3 2 6
Media 4 0 0
Compleja 6 0 0
Total Puntos de Funcin Consulta 6
ARCHIVOS Simple 7 6 42
83
Media 10 0 0
Compleja 15 0 0
Total Puntos de Funcin Archivos 42
TOTAL PUNTOS DE FUNCION SIN AJUSTAR 120
PF_SIN_AJUSTAR= 60 + 12 + 6 + 42
PF_SIN_AJUSTAR= 120
Para hallar el ajuste de complejidad segn las siguientes preguntas
0: Sin influencia
1: Incidental
2: Moderado
3: Medio
4: Significativo
5: Esencial
Tabla 3.3: Factores de clculo
N CARACTERSTICAS GENERALES VALOR

o
1 Mecanismos de recuperacin y back-up 3

confiables
2 Comunicacin de Datos 3
3 Funciones de Procesamiento Distribuido 2
4 Performance 3
5 Configuracin usada rigurosamente 3
6 Entrada de datos on-line 2
7 Factibilidad Operativa 5
8 Actualizacin de archivos on-line 2
84
9 Interfaces Complejas 4
10 Procesamiento Interno Complejo 3
11 Reusabilidad 3
12 Fcil Instalacin 4
13 Soporte de mltiples instalaciones 4
14 Facilidad de cambios y amigabilidad 4
TOTAL 45
Ya obtenido el total de los niveles de influencia, calculamos los factores de ajuste

(FA) de acuerdo a la siguiente frmula:
PF = PF_SIN_AJUSTAR*(0.65+0.01*Fi)
PF = 120*(0.65+0.01*45)
PF = 132
Convirtiendo los PF a lneas de cdigo (LCD), se utiliza la siguiente tabla.
Tabla 3.4: Lneas de Cdigo por lenguaje de programacin
Lenguaje LCD/P
F
C 128
ANSI BASIC 64
C++ 53
JAVA 53
SQL 13
4ta GENERACIN 20
ANSI COBOL 74 107
VISUAL 4.0 29
VISUAL BASIC 1 46
VISUAL BASIC 2 43
85
VISUAL BASIC 4 36
VISUAL BASIC 5 29
VISUAL BASIC 6 32
VISUAL BASIC 40
DOS 34
VISUAL C++ 32.61
PHP
Fuente: [BARRY BOEHM]
Como el software est desarrollado con un lenguaje de Visual.Net las lneas de

cdigo que se asemejan a esta son las de Visual Basic 6, segn Boehm se toma
el valor de 32 LDC, donde:
LDC = PF * LDC
LDC = 132 * 32
LDC = 4224
Por lo tanto el tamao del proyecto de desarrollo es de 4224 LDC.
Para determinar el costo total del desarrollo de software se utiliza el mtodo de

COCOMO modo orgnico, el cual ayudar a encontrar el esfuerzo, tiempo,
nmero de personas y el costo por lnea de cdigo segn sus frmulas:
Esfuerzo
E = 2.4 (KLDC) 1.05
Como ya se tiene la cantidad de lneas de cdigo 4224, estas las

convertimos a KLDC que equivale a 4.224 y se reemplaza en la frmula.
E = 2.4 (4.224) 1.05
E = 10.8 => 11per/mes
Tiempo
T = 2.5 (11) 0.38
86
T = 6.21 => 7 meses
Nmero de personas mes

NP = E/T
NP = 11/7
NP= 1,57
NP = 2 personas/me
Costo por lnea de cdigo
CLDC = NP * SUELDO (persona/mes)
Donde el sueldo le damos el valor de 214 $us, pago del programador [Anexo E]
CLDC = 2 * 214
CLDC = 428 $us
Luego finalmente el costo del desarrollo del software.
Costo total del desarrollo del software.

C (SW) = CLDC * T
C (SW) = 428 * 7
C (SW) = 2996 $us
Por lo tanto, el costo del desarrollo del Software es de 2996 $us.
3.3 BENEFICIOS
Un sistema puede proporcionar muchos beneficios para una organizacin y los

usuarios.
Por ejemplo automatiza los trabajos, proporciona servicios y promueve su

utilizacin.
87
Dentro de los beneficios se encuentra dos tipos:
Beneficios tangibles
Son aquellos tems que pueden ser medidos, por ejemplo, reduccin de
costos en materiales, reduccin de error, y otros.
Beneficios intangibles
Son aquellos tems que no pueden ser medidos, por ejemplo, la mejora de
la moral de los usuarios del sistema, necesidad competitiva, y otros.
3.3.1 BENEFICIOS TANGIBLES
Los beneficios tangibles para este proyecto son:
Disminucin del tiempo de errores en el proceso de compras, ventas y

gestin de clientes.
Registro automatizado del proceso de compras y ventas de los
productos.
Control de compras, ventas eficientes.
Control de almacn eficiente10, respecto a los traspasos y salidas varias
que sedan en la distribuidora.
Eliminacin de duplicidad de datos respecto a todos los procesos que se
realizan en la distribuidora.
Mejora en la toma de decisiones en un 99.99% para la compra de
productos.
3.3.2 BENEFICIOS INTANGIBLES
Los beneficios intangibles para este proyecto son:
Mejorar la imagen de la distribuidora ante los proveedores y ante los

clientes.
Abrir la posibilidad de incursionar en la sociedad de la informacin
Clientes satisfechos por la eficiencia.
10 Eficacia: Capacidad de lograr el efecto que se desea o se espera.
88
Encargados de ventas satisfechos por la eficiencia en el registro de una
nueva venta.
Encargados de compras satisfechos por la eficiencia en el proceso de la
compra de los productos.
Encargados de almacn satisfechos por el buen control de traspasos y
salidas varias en los almacenes.
3.4 ANLISIS COSTO BENEFICIO
Para realizar el anlisis de costo y beneficios se debe tomar en cuenta las

siguientes recomendaciones:
Identificar el costo de inversin ms importante del software.

Identificar costos complementarios, como de mueblera u otros.
Identificar los beneficios que tangibles e intangibles
3.5 COSTO DE IMPLANTACIN DEL SISTEMA

3.5.1 COSTOS DE ADQUISICIN DE EQUIPOS
Cuadro 3.3: Costos de adquisicin de equipos
COMPUTADORA DUAL CORE
PROCESADOR INTEL DUAL CORE 2.5 GHZ/2 MB. CACHE
PLACA MADRE INTEL DG31PR CON V/S/R
MEMORIA RAM 2 GB. DDR2 / B 800 MARCA KINGSTONE
DISCO DURO 250 GB. SATA2 SAMSUNG
CASE ATX CON TOBERA CERTIFICADA FOXCONN
FLOPPY 1.44 MB
GRABADOR DVD 20X LG HP
TECLADO GENIUS PS/2
MOUSE GENIUS PS/2
PARLANTES STANDARD ESCRITORIO
MONITOR LCD 17" SAMSUNG
89
ESTABILIZADOR ESTABILIZADOR VOLTAJE SOLIDO (IMPORTADO)

PRECIOS (INCLUYE IVA) $us 470.00

PRECIO C/MONITOR LCD 19" $us 490.00
COMPUTADORA CORE 2 DUO
PROCESADOR INTEL CORE 2DUO 2.8 GHZ
PLACA MADRE INTEL DP35DP CON S/R
MEMORIA RAM 2 GB. DDR2 BUS 800
DISCO DURO 250 GB. SATA2
TARJETA DE VIDEO PCI EXPRESS 512 MB. 860 GF
TECLADO Y MOUSE KIT MULTIMEDIA MICROSOFT
PARLANTES CON SOOBWOOFER 5.1 LABTEC
MONITOR LCD 19" LG

PRECIO (INCLUYE IVA) $us 470.00
COMPUTADORA CORE 2 QUAD/4 MB
PROCESADOR INTEL CORE 2QUAD 2.33 GHZ
PLACA MADRE INTEL DP31PR CON V/S/R
MEMORIA RAM 4 GB. DDR2 BUS 800 KINGSTON 2 X 2
90
DISCO DURO 160 GB. SATA2 SAMSUNG

776/436/570
DISQUETERA 3.5 1.44 MB
TECLADO Y KIT MULTIMEDIA MICROSOFT

MOUSE
PARLANTES CON SOOBWOOFER 5.1 LABTEC
MONITOR LCD 17" SAMSUNG
PRECIO (INCLUYE IVA) $us 650.00

3.5.2 COSTOS DE ADQUISICIN DE MUEBLES
En este punto de costo de adquisicin de muebles se tomara en cuenta el

inventario de los muebles con la que cuenta la distribuidora teniendo en cuenta los
precios en los cuales fueron adquiridos por la distribuidora.
Cuadro 3.4: Costos de adquisicin de muebles
Nro DETALLE PRECIO UNITARIO PRECIO TOTAL
5 Escritorios 240 1200
5 Sillas para escritorios 100 500
TOTAL EN Bs 1700
91
3.5.3 COSTOS DE LA RED
3.5.4 COSTO DE CAPACITACIN
El costo de capacitacin est dado por la instruccin que ser dada a los
encargados y responsables para el manejo del sistema [Anexo E].
DESCRIPCIN PRECI
O
Instruccin a responsables 20 $us
Instruccin a encargados 20 $us
Costo total de 40 $us

capacitacin
Fuente: [Elaboracin propia basada en el Anexo E]
3.6 SUMA DE COSTOS TOTALES

DESCRIPCIN PRECIO
Costo total del desarrollo del software 2996
Costo total de licencias de software 1874
Costo total de adquisicio n de equipos 2530
Costo total de adquisicio n de muebles 1700
TOTAL 9100
92
CAPITULO IV
INGENIERA
DEL
PROYECTO
93
4 CAPITULO IV: INGENIERA DEL PROYECTO
4.1 INTRODUCCIN
Como se describi anteriormente en el captulo II, en el presente captulo se

desarrollara el proyecto aplicando el modelo incremental, para tal efecto se
desarrollaran los siguientes mdulos:
Mdulo de seguridad.
Mdulo de tablas registro de proveedores, clientes y productos.
Mdulo de compras y almacenes.
Mdulo de gestin de clientes y ventas.
Utilizando el proceso de desarrollo de software a travs del modelo Incremental,

se proceder a realizar todas las fases que este representa en los mdulos
mencionados anteriormente.
Diseo del Sistema
Codificacin
Pruebas
Implantacin
Mantenimiento
4.2 ESPECIFICACIN DE REQUISITOS PARA EL PRIMER INCREMENTO O
MDULO DE SEGURIDAD
4.2.1 ANLISIS DE REQUERIMIENTOS
4.2.1.1 DESCRIPCIN DEL PROBLEMA
La distribuidora no cuenta con un control de permisos para realizar y ver

determinados procesos de la misma, despus de haber entrevistado al
gerente general de la Distribuidora, se determin que uno de los problemas
principales, es no contar con permiso de accesos a distintos procesos.
94
4.2.1.2 FASE DE REQUERIMIENTOS
4.2.1.2.1 RECOPILACIN DE LA INFORMACIN
Todos los datos en informacin que se recopilaron sobre el presente trabajo de

grado se obtuvieron en base a las siguientes fuentes:
La entrevista realizada al gerente general para la asignacin de

permisos mediante roles.
La observacin directa para ver como se restringen dichos procesos.
Los cuestionarios para recabar informacin necesaria para el
desarrollo del software.
Continuando con el anlisis del sistema ahora mencionamos algunos

requerimientos que son necesarios para la elaboracin del modulo del sistema.
4.2.1.2.2 PARTICIPANTES DEL PROYECTO
Para la elaboracin del diseo del modulo los actores que intervienen son:
Gerente General.
Desarrollador
4.2.1.2.3 OBJETIVO DE DESARROLLO
Nro. Descripcin Origen
1 Registro de usuarios que accedern al Gerente Administrativo

sistema.
2 Registrar de roles para acceso al sistema Desarrollador
3 Registro de asignacin de permisos a roles Gerente Administrativo
4 Reporte de usuarios del sistema Gerente Administrativo
Como se vio en el captulo I, con el desarrollo del presente mdulo se alcanzar el

siguiente objetivo propuesto:
Proveer mecanismos de seguridad que permitan un control interno del
sistema, as como la creacin de usuarios y otorgacin de permisos
95
4.2.2 DISEO DEL SISTEMA
4.2.2.1 DIAGRAMAS DE CASOS DE USO
Diagrama: Caso de Uso Registro de Fecha: 15/03/13

usuarios
Autor: Blanca Carolina Ramos Calle
Nombre Registro de Usuarios (Nro. 1)
Actores Gerente Administrativo, Usuario
Descripcin El gerente administrativo se encarga de otorgar un perfil a un

determinado usuario que se registra por primera vez. As como
sus datos personales del usuario, este ya tendr un men
asignado en base al perfil seleccionado.
Eventos del actor Eventos del sistema

Flujo 1. El gerente administrativo 2. Muestra la pantalla de
Principal ingresa a la opcin registro de registro de usuarios.
usuarios.
3. El gerente administrativo 4. El sistema valida datos de

registra, modifica o elimina registro de usuarios
datos de usuario introducidos por el gerente
administrativo
Precondicin Registrar el usuario
96
Poscondicin Registro satisfactorio
Diagrama: Caso de Uso Registro de perfiles Fecha: 15/03/13

Nombre Registro de perfiles (Nro. 2)
Actores Gerente Administrativo
Descripcin El Gerente Administrativo se encarga de registrar los perfiles que

existirn en la distribuidora tales como: Gerente administrativo,
almacenero, secretaria, etc.

Principal registra los nuevos perfiles registro de perfiles
correspondientes.
3. El gerente administrativo 4. El sistema valida datos de

registra, anula datos de un perfil perfiles a realizar, los cuales
fueron introducidos por el
gerente administrativo.
Precondicin Registrar el perfil
97
Diagrama: Caso de Uso Asignacin de roles a Fecha: 15/03/13

perfiles
Nombre Asignacin de roles a perfiles (Nro. 3)
Actores Gerente Administrativo
Descripcin El gerente administrativo se encarga de asignar roles a los

determinados perfiles y tambin podr realizar la modificacin de
dichos roles.

Principal realiza la asignacin de los roles registro de roles a perfiles
a los perfiles.
3. El gerente administrativo, 4. El sistema valida datos de

modifica datos de roles de asignacin de roles
perfiles asignados a determinados
perfiles.
Precondicin Registrar la asignacin a los determinados perfiles
98
4.2.2.2 DIAGRAMA DE ACTIVIDADES
Autor: Blanca Carolina Ramos Calle Fecha: 15/03/13

Diagrama de actividades registro de usuarios Diagrama de actividades registro de
perfiles
Figura 4.3: Diagrama de actividades asignacin de roles a perfiles
99
Fuente: [Elaboracin propia basada en la bibliografa electrnica de WEB 09]
4.2.2.3 DIAGRAMA DE ESTADOS
Figura 4.1: Diagrama de estado registro de usuarios
Figura 4.1: Diagrama de estado registro de perfil
Figura 4.1: Diagrama de estado asignacin de roles a perfiles
100
4.2.2.4 DISEO DE COMPONENTES
Figura 4.1: Diagrama de componentes modulo de seguridad
4.2.2.5 DISEO DE FORMULARIOS
4.2.2.5.1 PANTALLA REGISTRO DATOS DE USUARIO
En esta se tiene el registro de usuarios el cual consiste en realizar el registro de

los datos necesarios del usuario como ser: Cedula de Identidad, nombre completo,
fecha de nacimiento, direccin, telfono, email, adems de asignarle un perfil de
acceso al sistema.
101
4.2.2.5.2 PANTALLA REGISTRO DE PERFIL DE USUARIO
El registro de perfil de usuario consiste en crear nuevos perfiles, modificar los

mismos se tiene perfiles como: Administrador, almacenero, secretaria, cajero, etc.
4.2.2.5.3 PANTALLA DE ASIGNACIN DE ROLES A PERFILES DE USUARIOS
En esta parte del sistema se asigna los roles respectivos en base a un perfil
seleccionado.
102
4.2.2.6 DISEO DE BASE DE DATOS
103
4.3 ESPECIFICACIN DE REQUISITOS PARA EL SEGUNDO INCREMENTO
O MODULO DE REGISTRO DE PROVEEDORES Y PRODUCTOS
Despus de haber entrevistado a los encargados de las respectivas areas de la

Distribuidora, se determin que uno de los problemas principales, es no contar con
un control de los proveedores, clientes y productos, ni con un registro y reportes
de los datos referente a proveedores, clientes y productos.

La entrevista realizada al encargado de compras, encargado de

almacn, vendedores y secretarias para el seguimiento de los
procesos de registros de proveedores, clientes y productos.
La observacin directa para ver como generan dichos procesos.
desarrollo del tercer incremento software.

Encargado de Compras.
Encargado de Almacenes.
Vendedores.
Secretarias.
104
1 Registrar los datos de nuevos proveedores Secretaria Encargada

3 Se podr tener control correcto de los Encargado de
productos existentes en almacenes. almacenes, Secretaria
Encargada
4 Registrar los movimientos (Ingresos y Encargado de
salidas de almacn) que se tienen en almacenes, Secretaria
almacenes y salidas varias. Encargada
5 Tener informes diarios, mensuales y Encargado de
anuales de proveedores, productos y su almacenes, Secretaria
clasificacin. Encargada
Diagrama: Caso de Uso registro de proveedores Fecha: 15/03/13

Nombre Registro de proveedor (Nro. 1)
Actores Secretaria Encargada, proveedor
Descripcin La secretaria encargada registra los datos de los proveedores,

tambin puede modificar o eliminar sus respectivos datos.
105
Flujo 1. La secretaria encargada ingresa 2. Muestra la pantalla de
Principal a la opcin registro de nuevo registro de proveedores
proveedor
3. La secretaria encargada registra, 4. El sistema valida datos

modifica o elimina datos de los de los proveedores que
proveedores fueron modificados o
eliminados
Precondicin Registrar los datos de proveedores
Figura 4.15: Caso de Uso registro de productos
Diagrama: Caso de Uso registro de productos Fecha: 15/03/13

Nombre Registro de productos (Nro. 3, Nro. 4, Nro. 5)

Secretaria Encargada, Encargado de almacenes
Actores
Descripcin El encargado de almacenes est encargado de registrar los
productos nuevos, la secretaria podr modificar o eliminar los
registros de los productos las salidas varias de almacn por
motivos de fechas pasadas, productos rotos, etc. y podr ver
reportes actuales de stock de productos en cada almacn.
106
Flujo 1. El encargado almacn 2. Muestra la pantalla de
Principal registra el ingreso de nuevos registro de productos
productos en almacenes.
3. El encargado registra, anula 4. El sistema valida datos de
datos de un registro productos en almacn los
cuales fueron introducidos
por el encargado
Precondicin Registrar los productos
Figura 4.6: Diagrama de actividades registro de proveedores
Figura 4.17: Diagrama de actividades registro de productos
107
Figura 4.6: Diagrama de estado registro de proveedores
Figura 4.17: Diagrama de estado registro de productos
108
4.3.2.4 DISEO DE COMPONENTES
Figura 4.6: Diagrama de componentes registro de proveedores
109
4.3.2.5.1 PANTALLA REGISTRO DE DATOS DEL PROVEEDOR
En esta se registran los datos de nuevo proveedor, al mismo tiempo se puede

realizar la edicin de los datos de los proveedores existentes en la base de datos,
en el cual tambin en la parte derecha del formulario nos muestra un lista de
proveedores existentes en sistema, adems de mostrar un historial de compras a
proveedores.
4.3.2.5.1.1 PANTALLA REGISTRO DE CLASIFICACIN DE PRODUCTOS
110
En esta se muestran uno de los procesos importantes como ser la clasificacin de
productos los cuales se dividen en tres: tipo de producto, familia y subfamilia.
El tipo de producto consiste mostrar los tipos de productos que se tienen de

acuerdo a su respectiva clasificacin como: lcteos, panificacin, cereales, etc.
La familia es una sub categora del tipo de producto el cual muestra una sub
clasificacin de productos de acuerdo a la categora de lcteos como ser leches
saborizadas, leches enteras, leches de soya, etc.
La sub familia es una sub categora de la familia consiste en mostrar los datos de
los productos pero estos de acuerdo a un tipo de producto, una familia que se
seleccion anteriormente como ser:
Tipo de producto = Lcteos
Familia = Leches saborizadas
Sub familia = Chocolatadas, frutilla, con avena, etc.
En las tres procesos se puede realizar la adicin de nuevos datos, como la edicin
de los mismos, adems de mostrar en la parte inferior la lista de con los datos
respectivos a cada producto.
4.3.2.5.2 PANTALLA REGISTRO DE DATOS DEL PRODUCTO
111
En la misma se pueden realizar el ingreso de nuevos datos de los productos como
ser: tipo de producto, familia, sub familia, nombre, marca, etc., adems de la
edicin de los mismos, el sistema otorga un cdigo a cada producto este se puede
editar en caso de ser necesario.
112
4.4 ESPECIFICACIN DE REQUISITOS PARA EL TERCER INCREMENTO O
MODULO COMPRAS Y ALMACENES
Anteriormente se mencion el problema que presentaba la Distribuidora,

despus de haber entrevistado a los encargados y responsables de la
Distribuidora, se determin que uno de los problemas principales, es no
contar con un sistema integrado, ni centralizado para realizar el registro de
todos los datos que maneja la Distribuidora, tambin que no tiene reportes
rpidos y confiables para presentar sus respectivos informes de las
compras y control de sus almacenes.

La entrevista realizada al encargado de compras y encargado de

almacn para el seguimiento de los procesos de compras y
almacenes.

Encargado de Compras.
113
Encargado de Almacenes.
4.4.1.2.3 OBJETIVOS DEL PROYECTO

1 Registrar la compra directa de productos Encargado de compras
2 Registrar la compra por procesos de Encargado de compras
productos
3 Se podr tener control correcto de las Encargado de compras
compras realizadas.
4 Tener informes diarios, mensuales y Encargado de almacn
anuales.
5 Registrar los movimientos (Ingresos y Encargado de almacn
salidas de almacn) que se tienen en
almacenes.
6 Registrar las salidas varias de almacn por Encargado de almacn
motivo de regalos, fechas expiradas, rotos,
etc.
7 Reportes de pedidos en espera, pedidos Encargado de compras
confirmados, compras realizadas, traspasos Encargado de almacn
en espera, traspasos confirmados y salidas
varias de almacn.
Diagrama: Caso de Uso proceso de compras Fecha: 15/03/13

Autor: BCRC
114
Nombre Proceso de compras (Nro. 1, Nro. 2, Nro. 3)
Actores Encargado de compras, proveedor
Descripcin El encargado de compras registra la compra sea esta directa o

por procesos, tambin puede modificar o eliminar sus
respectivos datos.

Flujo 1. El encargado compras ingresa 2. Muestra la pantalla de
Principal a la opcin registro de compra registro de compras
directa o por procesos
3. El encargado registra, modifica o 4. El sistema valida datos

elimina datos de compras en de la compra introducidos
espera por el encargado
Precondicin Registrar la compra
115
Diagrama: Caso de Uso proceso de traspaso Fecha: 15/03/13
entre almacenes
Nombre Proceso de traspasos entre almacenes (Nro. 4, Nro. 5)
Actores Encargados de almacenes
Descripcin El encargado de almacn de la distribuidora est encargado de

registrar los traspasos entre un almacn y otro, as como de
recepcionar el ingreso de productos del traspaso realizado de
otro almacn y podr ver reportes actuales de stock de
productos en cada almacn.

Flujo 1. El encargado almacn 2. Muestra la pantalla de
Principal registra el traspaso de un registro de traspasos
almacn a otro.
3. El encargado registra, anula 4. El sistema valida datos del

datos de un registro pendiente traspaso a realizar, los cuales
recepcin. fueron introducidos por el
encargado
Precondicin Registrar el traspaso
116
Diagrama: Caso de Uso salidas varias de Fecha: 15/03/13
almacn
Nombre Salidas varias de almacn (Nro. 6)
Actores Encargados de almacn
Descripcin El encargado de almacn de la distribuidora est encargado de

registrar las salidas varias de almacn por motivos de fechas
pasadas, productos rotos, etc. y podr ver reportes actuales de
stock de productos en cada almacn.

Flujo 1. El encargado almacn 2. Muestra la pantalla de registro
Principal registra la salida de de salidas varias
producto(s) por motivos
varios
3. El encargado registra, 4. El sistema valida datos de

anula datos de un registro salidas varias de almacn a
realizar, los cuales fueron
introducidos por el encargado.
Precondicin Registrar la salida de producto(s) por motivos varios
117
Figura 4.9: Diagrama de actividades proceso de compras
Figura 4.10: Diagrama de actividades proceso de traspaso entre almacenes
118
Figura 4.11: Diagrama de actividades proceso de salidas varias de almacn
119
Figura 4.9: Diagrama de estado proceso de compras
Figura 4.10: Diagrama de estado proceso de traspaso entre almacenes
Figura 4.11: Diagrama de estado proceso de salidas varias de almacn
120
4.4.2.4 DIAGRAMA DE COMPONENTES
Figura 4.11: Diagrama de componentes proceso de compras
121
Figura 4.11: Diagrama de componentes proceso de traspasos entre
almacenes
122
4.4.2.5.1 COMPRAS
4.4.2.5.1.1 PANTALLA REGISTRO DE GENERAR PEDIDO
En esta parte del sistema se realiza el registro para la generacin de un pedido, en

la parte superior izquierda se tiene la bsqueda del producto por medio del
nombre o cdigo de barras del producto en la parte derecha se tiene la bsqueda
por medio de las clasificaciones mostrando luego en la parte inferior un historial de
producto seleccionado, adems de poder adicionar nuevos pedidos, realizar la
edicin de los mismos.
123
4.4.2.5.1.2 PANTALLA DE PEDIDO EN ESPERA
En esta se observa los pedidos realizados en el anterior proceso de generacin

de pedido, en esta se podr realizar la bsqueda de pedidos por fechas o por
numero de pedido.
4.4.2.5.1.3 PANTALLA PARA GENERAR ORDEN DE COMPRA AL

PROVEEDOR
124
En esta se confirma las rdenes de compra al proveedor enviando va email en la
parte inferior muestra un detalle de la orden, adems se podr realizar la
bsqueda de pedidos por fechas o por numero de pedido.
4.4.2.5.1.4 PANTALLA PARA REALIZAR LA COMPRA
125
Esta pantalla muestra los pedidos confirmados enviados a proveedores, en la cual
se podr realizar la bsqueda por fechas y numero de pedido, esta se encarga
primordialmente de registrar en ingreso de productos a almacn.
4.4.2.5.1.5 PANTALLA PARA REALIZAR LA COMPRA DIRECTA
En este se podr realizar la bsqueda de productos que deseamos comprar,

seleccionamos un lote existente o creamos un lote, se ingresan cantidades totales
y por ltimo se llena el encabezado de compra que corresponde a seleccionar un
proveedor, tipo de documento y numero de documento.
4.4.2.5.1.6 PANTALLA DE HISTORIAL BSQUEDA DE PEDIDOS EN

ESPERA Y PEDIDOS CONFIRMADOS
126
En esta se muestra el historial de pedidos, en el mismo se podr realizar la
bsqueda de pedidos por fechas o por numero de pedido.
4.4.2.5.1.7 PANTALLA DE COMPRAS REALIZADAS
127
En esta nos muestra las compras realizadas, se podr realizar la bsqueda de
pedidos por fechas o por numero de documento.
4.4.2.5.2 ALMACENES
4.4.2.5.2.1 PANTALLA REGISTRO DE TRASPASOS DE ALMACN
Esta nos permite realizar un traspaso de un almacn a otro, en el cual el sistema

se encarga de validar si existe un stock existente del producto que se desea
realizar el traspaso para esta motivo se debe seleccionar un almacn destino.
4.4.2.5.2.2 PANTALLA SALIDAS EN ESPERA DE RECEPCIN Y ANULACIN
128
En esta muestra los traspaso que estn en espera para la conclusin del mismo,
adems de realizar la anulacin del traspaso.
4.4.2.5.2.3 PANTALLA DE HISTORIAL DE SALIDAS CONFIRMADAS
En la misma nos muestra los productos que salieron del almacn en el cual se
muestra un detalle especifico del almacn destino al que fue enviado el o los
productos.
4.4.2.5.2.4 PANTALLA REGISTRO DE INGRESOS DE TRASPASOS
129
En esta se realiza el registro de ingreso de los traspasos, en esta se observara el
almacn origen que realizo el traspaso.
4.4.2.5.2.5 PANTALLA DE HISTORIAL DE TRASPASOS CONFIRMADOS
En esta se observa los traspasos confirmados, la misma nos mostrara un detalle

de los traspasos confirmados como ser el almacn origen.
4.4.2.5.2.6 PANTALLA REGISTRO DE SALIDAS VARIAS
130
En esta nos se realiza un registro de las salidas varias de productos por varios
motivos (regalos, rotos, daados, etc.), en la que se tendr que introducir el motivo
de salida que justifique la salida del producto.
4.4.2.5.2.7 PANTALLA DE HISTORIAL DE SALIDAS VARIAS
En esta nos muestra un detalle de todas las salidas varias que se realizaron, en el
cual se podr realizar la bsqueda de salidas varias por fechas.
131
132
133
4.5 ESPECIFICACIN DE REQUISITOS PARA EL CUARTO INCREMENTO O
MODULO VENTAS Y GESTIN DE CLIENTES POTENCIALES
Luego de una entrevista a los gerentes de la empresa se llego a la solucin del

problema ya que en este cuarto incremento se desarrollara la parte ms
importante del proyecto puesto que las ventas nos conllevan a tratar con los
clientes y determinar la importancia de los clientes para la distribuidora. Adems
de tener una buena gestin de los clientes y con los mismos llegar a un
crecimiento de la distribuidora brindndoles a los clientes una mejor calidad en su
atencin, siendo el mximo objetivo de obtener toda la informacin de cualquier
cliente.

La entrevista realizada al encargado de ventas y cajeros para el

seguimiento de los procesos de ventas y clientes.
La entrevista realizada a los gerentes: general, comercial,
administrativo de la distribuidora para el seguimiento de los clientes
respecto a las compras que ellos realizan.

134
Para la elaboracin del diseo del mdulo los actores que intervienen son:
Gerente General.
Gerente Administrativo
Cajeros
Vendedores

1 Ejecuta preventa Vendedor
2 Registrar la venta de productos de la Vendedor
distribuidora
3 Generar factura por las ventas realizadas Vendedor
4 Generar reportes de facturas emitidas Vendedor, cajero
5 Generar un reporte de Arqueo de caja Vendedor, cajero
6 Generar reporte de ventas realizadas a Gerente comercial
clientes
7 Pantalla de clientes potenciales. Gerente comercial
8 Descuentos y/o regalos a mejores clientes Gerente comercial
potenciales.
9 Descuentos en base a cantidad de Gerente comercial
productos vendidos a clientes.
10 Gestionar clientes potenciales Gerente comercial
11 Administracin de CRM Gerente Administrativo
12 Gestin de la informacin Gerente Administrativo
13 Registro de clientes Gerente Administrativo
14 Reporte de ventas, clientes potenciales Gerente comercial
Figura 4.12: Caso de Uso relacin de herencia entre los actores del sistema
135
136
Diagrama: Caso de Uso registro de nueva venta Fecha: 15/03/13
Nombre Registro de nueva venta (Nro. 1, Nro. 2, Nro. 3, Nro.

4, Nro. 5)
Actores Vendedor, cliente

Descripcin El vendedor encargado se encarga de realizar la
preventa respectiva luego realiza el registro de la
preventa, tambin puede modificar o eliminar sus
respectivos datos.
Flujo Principal 1. El vendedor 2. Muestra la pantalla de
encargado ingresa a la registro de preventa
opcin registro de
preventa.
3. El vendedor encargado 4. El sistema valida datos
registra, modifica o de la preventa introducidos
elimina datos de la por el vendedor encargado
preventa.
Precondicin Registrar la preventa
137
Diagrama: Caso de Uso CRM gestin Fecha: 15/03/13
vendedores
Nombre CRM Gestin de clientes vendedores (Nro. 6, Nro. 7,

Nro. 8, Nro. 9, Nro. 10)
Actores Gerente comercial
Descripcin El gerente comercial se encarga de gestionar a los clientes
ya los vendedores adems de poder adicionar un nuevo
vendedor o cliente, al mismo tiempo puede realizar la gestin
de los clientes potenciales buscando a estos por un cdigo o
alguna letra que lo identifique.
Flujo Principal 1. El gerente comercial ingresa 2. Muestra la pantalla de
a la opcin gestin de vendedor registro de cliente o
o gestin de clientes. vendedor
3. El gerente comercial registra, 4. El sistema valida datos
datos del cliente o del vendedor. del registro de los clientes
o vendedores introducidos
por el gerente comercial.
Precondicin Ingresar a la opcin gestin de cliente o vendedor
138
Diagrama: Caso de Uso administrando el CRM Fecha: 15/03/13
Nombre Administrando CRM (Nro. 11, Nro. 12, Nro. 13)

Actores Gerente administrativo
Descripcin El gerente administrativo se encarga de administrar
el CRM ya que en esta existe la gestin tanto del
personal, perfiles, usuarios y panel de control.
Flujo Principal 1. El gerente 2. Gestiona procesos del
administrativo ingresa sistema.
a la opcin de Ingreso
al sistema.
3. El gerente ingresa a 4. El sistema valida datos
uno de los procesos. del proceso actual.
Precondicin Ingresar al sistema para la administracin del CRM
Diagrama: Caso de Uso registro de Fecha: 15/03/13

clientes potenciales
139
Nombre Registro de clientes potenciales (Nro. 2)
Actores Secretaria Encargada
Descripcin La secretaria encargada se encarga de registrar a los
clientes nuevos y modificar los datos de los clientes o
eliminar.
Flujo Principal 1. La secretaria 2. Muestra la pantalla de registro
encargada registra de clientes
los datos de los
clientes.
3. La secretaria 4. El sistema valida datos del
encargada registra, registro de los clientes.
modifica o anula
datos de un registro
Precondicin Registro de clientes.
Figura 4.13: Diagrama de actividades registro de nueva venta
140
Figura 4.14: Diagrama de actividades CRM gestin de clientes - vendedores
141
Figura 4.15: Diagrama de actividades administrando el CRM
142
Figura 4.16: Diagrama de actividades registro de clientes
4.5.2.3 DIAGRAMA DE ESTADO
Figura 4.13: Diagrama de estado registro de nueva venta
143
Figura 4.14: Diagrama de estado CRM gestin de clientes
Figura 4.15: Diagrama de estado administrando el CRM
144
Figura 4.16: Diagrama de estados registro de clientes
4.5.2.4 DIAGRAMA DE COMPONENTES
Figura 4.16: Diagrama de componentes ventas y gestin de clientes
145
146
4.5.2.5.1 PANTALLA DE REGISTRO DE NUEVA VENTA
En la presente venta de registro de ventas se procede a realizar la bsqueda de

productos por cdigo de barras o cdigo de producto y se va aadiendo filas al
detalle de venta, y posteriormente se selecciona un cliente.
4.5.2.5.2 PANTALLA DE VENTAS REALIZADAS
147
En la presente ventana se tiene un listado de ventas realizadas por distintos
criterios: fecha, nro. de documento, rango de fechas y cdigo de cliente. Al ver la
cabecera y realizar clic sobre una se obtendr el respectivo detalle.
4.5.2.5.3 PANTALLA REGISTRO DE DATOS DEL CLIENTE
En la presente se realiza el registro de nuevos clientes con sus respectivos datos,

en la parte derecha tenemos la lista de clientes registrados en el sistema los
cuales tienen datos y los mismos pueden ser editados al seleccionar un registro de
la lista, adems de mostrar un historial de las ventas realizadas al cliente.
148
En esta ventana se observa la condicin de categora o clientes consecuentes, en
la cual mediante estos datos se filtrara a los clientes potenciales que compran mas
a la distribuidora, dentro de la que se observa las pestaas general, detalles y
administracin del CRM.
La ventana de previsin de ventas nos permite registrar las posibles ventas

contactadas a clientes, para su mejor atencin.
La ventana de gestin de clientes permite realizar la bsqueda de clientes

potenciales en el que se ven datos generales de un cliente seleccionado, y por la
cual se dirige a otro formulario de gestionar clientes.
149
La ventana de gestionar clientes nos permite registrar datos de contactos de
clientes y registrar alertas para un determinado cliente para permitir tener un
control de actividades a realizar o cumplir con un cliente.
150
CAPITULO V
PRUEBAS E
IMPLEMENTACIN
151
5 CAPITULO V: PRUEBAS E IMPLEMENTACIN
5.1 INTRODUCCIN
En este captulo se desarrollaran las pruebas y la implementacin del sistema
mencinados en el capitulo II las cuales son prueba de caja blanca, prueba de caja
negra y prueba de integracin, ademas del control de calidad del software
mediante las mtricas de calidad mencionados en el capitulo II estableciendo
factores de calidad que son sobresalientes en el sistema, para tener una visin del
sistema obtenido en el presente proyecto de grado.
5.2 PRUEBAS
Las pruebas estn desarrolladas para cada determinado modulo
5.2.1 PRUEBAS DEL SISTEMA PARA EL MODULO DE SEGURIDAD
5.2.1.1.1 CDIGO FUENTE REGISTRO DE USUARIOS
// Autor: Blanca Ramos Calle

// Fecha de creacin: 14/12/12
// Descripcin: Registro de Productos
if (DatosLlenados())
{ 1-2-3
if (IsDate(mktFechaNacimineto.Text)) 2-4-5
{
int codp = 0; //codigo de persona
int codu = 0; //cdigo de usuario
//devuelve el cdigo de tipo de persona
codTipoPer = PersonaBL.DevuelveCodTipoPersonaSERVER(TipoPer);
bool vExPer = false, vExUsu = false;
//Verifica si existe el nit o ci introducido
vExPer = PersonaBL.ExistePersonaNitSERVER(txtCiNit.Text.Trim(),
codTipoPer);
//Verifica si existe el login introducido
vExUsu = UsuarioBL.ExisteUsuarioDifSERVER(txtLogin.Text.Trim(), codu);
if (!vExPer) 4-6
{
txtCiNit.BackColor = System.Drawing.Color.FromArgb(((int)(((byte)
(255)))), ((int)(((byte)(255)))), ((int)(((byte)(192)))));
if (!vExUsu) 6-7
{
txtLogin.BackColor = System.Drawing.Color.FromArgb(((int)(((byte)
(255)))), ((int)(((byte)(255)))), ((int)(((byte)(192)))));
}
152
}
if (!vExPer)
{
if (!vExUsu)
{
//Metodo que se encarga de adicionar datos de usuario registrado
mtdAdicionaPersonaUsuario(UsuarioBL, PersonaBL);
MessageBox.Show("LOS DATOS FUERON GUARDADOS"); 8-9-10
btnCancelar.Visible = false;
9-11
}
else
{
MessageBox.Show("EL NOMBRE DE USUARIO YA EXISTE");
txtLogin.BackColor = Color.Pink;
}
}
else
{
MessageBox.Show("EL CI YA EXISTE");
txtCiNit.BackColor = Color.Pink;
}
}
else
{
MessageBox.Show("DEBE LLENAR DE MANERA ADECUADA EL CAMPO FECHA!");
mktFechaNacimineto.BackColor = Color.Pink;
}
}
else
{
MessageBox.Show("DEBE LLENAR TODOS LOS CAMPOS");
}
153
Figura 4.4 Diagrama de flujo
2 Grafo de Flujos del procedimiento Registro de Usuarios
Figura 4.5 grafo de flujos
154
El grafo de flujos se traza usando el cdigo fuente del procedimiento Registro de
usuarios y seleccionando las ejecuciones enumeradas en cada lnea de cdigo.
3 Determinacin de la complejidad ciclomtica del grafo de flujos
a) CC=Arcos-Nodos +2 -> CC= 10-11+2 =1

b) CC=Nmero de nodos de decisin +1 -> CC= 3+1=4
4 Determinacin de caminos
La complejidad ciclomtica nos da el nmero mnimo de grafos para el proceso de

registro de datos:
1. Camino1: 1-3
2. Camino2:1-2-5
3. Camino3: 1-2-4-6-7
4. Camino4: 1-2-4-8-10
5. Camino5: 1-2-4-8-9-11
Prueba de caminos
1. El usuario luego de haber introducido todos los datos en los campos
respectivos, en dicho se olvid llenar un campo obligatorio entonces le
muestra un mensaje de error.
2. El usuario luego de haber introducido todos los datos en los campos
respectivos, en dicho no lleno el campo fecha correctamente, entonces le
muestra un mensaje que debe llenar de manera adecuada el campo fecha.
3. Una vez introducidos los datos de registro y el login que es creado por el
usuario ya existe en otro usuario asignado entonces el sistema lo pinta.
4. Despus de haber introducido los datos correspondientes en el sistema y el
dato de carnet de identidad (C.I.) ya existe entonces el sistema nos muestra
un mensaje mencionando que el C.I. introducido ya existe.
5. Una vez validados los datos introducidos y estos estn correctos entonces
el sistema nos muestra el mensaje de que los datos han sido guardados
con xito.
155
5.2.1.2.1 FORMULARIO DE REGISTRO DE USUARIOS
CONDICIN DE CLASES VALIDAS CLASES NO VALIDAS

ENTRADA
Ced.de Identidad Longitud( n)=7 7<Longitud( n)>7
Nombre Completo Un dato valido, longitud Cualquier dato que no
<50 sea tipo string, y longitud
>50.
Fecha de nacimiento En formato 00/00/00 Cualquier formato distinto

al formato date
Direccin Un caracter valido, Cualquier dato que no

longitud <50 sea tipo caracter, y
longitud >50.
Telfono Un dato valido, longitud Cualquier dato que no
<=8 sea tipo numerico, y
longitud >8.
Email Un caracter valido, Cualquier dato que no

longitud >50.
Login usuario Un caracter valido, Cualquier dato que no
longitud >20.
156
Password Un caracter valido, Cualquier dato que no
longitud >15
Confirmar password Un caracter valido, Cualquier dato que no

longitud >15.
Resultados obtenidos:
Registro guardado con xito.
157
5.2.1.3 PRUEBA DE INTEGRACIN
5.2.1.3.1 PRUEBA DE INTEGRACIN DESENDENTE PARA EL MODULO DE

SEGURIDAD
rbol del sistema Fuente: [Elaboracin propia]
Para 2. Condicin (Autenticacin)
Tipos de prueba Caractersticas Observacin

Funcionales El mdulo satisface los requisitos Alto
propuestos para el desarrollo del mismo
as como el objetivo planteado.
158
Rendimiento Tiempo de respuesta = 15 seg Alto
Todo el sistema ocupa = 83 KB en
memoria
El flujo de dato esperado introduccin
contrasea en caso contrario no ingresa
Seguridad Los niveles de permiso a cualquier modulo Alto
solo se da si la entrada coincide con la
contrasea.
Usuario
Contrasea
Comunicaciones La comunicacin entre el mdulo de Medio
seguridad y otros es eficaz ya que los
datos son administrados correctamente y
con xito.
Volumen El sistema responde y soporta Alto
correctamente con un gran el volumen de
datos.
Sobre carga
Disponibilidad Solamente el gerente administrativo Alto
tendr acceso a ste mdulo, y el gerente
general tendr acceso a los informes
Facilidad de uso Es un sistema con facilidad de manejo con Medio
una interfaz entendible.
Operacin e La operacin de arranque y la instalacin Medio

Instalacin son fciles de comprender
Para 2.1.1. Registro de usuarios

Funcionales El mdulo satisface los requisitos propuestos Alto
159
para el desarrollo del mismo as como el
objetivo planteado.
Rendimiento Tiempo de respuesta = 2.55 seg Alto
Todo el sistema ocupa = 85 KB en memoria
contrasea.
Usuario
Contrasea
Comunicaciones La comunicacin entre el mdulo de seguridad Alto

y otros es eficaz ya que los datos son
administrados correctamente y con xito.
Volumen El sistema responde y soporta correctamente Medio
con un gran el volumen de datos.
Sobre carga
Disponibilidad Solamente el gerente administrativo tendr Alto
acceso a ste mdulo, y el gerente general
tendr acceso a los informes
Facilidad de uso Es un sistema con facilidad de manejo con Alto
Operacin e La operacin de arranque y la instalacin son Medio

Instalacin fciles de comprender
Para 2.1.1. Registro de perfiles

Funcionales El mdulo satisface los requisitos Alto
propuestos para el desarrollo del mismo
160
as como el objetivo planteado.
Todo el sistema ocupa = 85 KB en
memoria
Seguridad Los niveles de permiso a cualquier Alto
modulo solo se da si la entrada coincide
con la contrasea.
Usuario
Contrasea
Comunicaciones La comunicacin entre el mdulo de Alto
seguridad y otros es eficaz ya que los
datos son administrados correctamente y
con xito.
Volumen El sistema responde y soporta Alto
correctamente con un gran el volumen
de datos.
Sobre carga
Disponibilidad Solamente el gerente administrativo Alto
tendr acceso a ste mdulo, y el
gerente general tendr acceso a los
informes
Facilidad de uso Es un sistema con facilidad de manejo Alto
con una interfaz entendible.
Operacin e La operacin de arranque y la instalacin Medio

Para 2.1.1. Asignacin de roles a usuarios
161
objetivo planteado.
contrasea.
Usuario
Contrasea
seguridad y otros es eficaz ya que los datos
son administrados correctamente y con xito.
Volumen El sistema responde y soporta correctamente Alto
Sobre carga
Disponibilidad Solamente el gerente administrativo tendr Alto
acceso a ste mdulo, y el gerente general
Operacin e La operacin de arranque y la instalacin son Regular

162
5.2.2 PRUEBAS DEL SISTEMA PARA EL MODULO DE REGISTRO DE
PROVEEDORES Y PRODUCTOS
5.2.2.1.1 CDIGO FUENTE REGISTRO DE PRODUCTOS

if (txtCodProducto.Text.Trim() != ""
&& txtNomProducto.Text.Trim() != "" && txtPrecProducto.Text.Trim() != "0"
&& txtStockProducto.Text.Trim() != "0"
&& cbbEstadoProducto.SelectedIndex != 0 && cbbTipo.SelectedIndex != 0 &&
cbbCategoria.SelectedIndex != 0 &&
cbbSubCategoria.SelectedIndex != 0)
{ 1-2-3
CodigoProd = txtCodProducto.Text.Trim();
object[] vObj = new object[] { CodigoProd, codTipo, codFamilia,
codSubFamilia };
//Verifica la existencia de un producto a registrar
if (!ProductoBL.ExisteProductoSERVER(vObj))
{
//Adiciona el producto a la base de datos 2-4-5
mtdAdicionarProducto();
MessageBox.Show("El Producto fue Adicionado");
//Metodo que carga datos de clasificacin de productos
mtdCargaDatos();
//Deshabilita controles una vez registrado un producto
mtdDesHabilitaControles();
//Habilita botones para el inicio de un nuevo registro de producto
habilitabotones();
cbbProducto.Visible = true;
txtCodProducto.ReadOnly = true;
txtCodProducto.Enabled = false;
cbbTipo.Enabled = true;
txtBuscarProducto.Clear();
txtBuscarProducto.ReadOnly = false;
cbbTipo.Focus();
op = "for";
mtdLimpiaControles();
habilitabotones();
btnEditarProducto.Enabled = false;
txtCodProducto.ReadOnly = false;
txtCodProducto.Enabled = true;
txtBuscarProducto.Focus();
op = "for";
cbbTipo.SelectedIndex = 0;
//Mtodo que deshabilita las cajas de texto
163
mtddisabledtxt();
mtddisabledtxtload();
}
else
{
if (op == "edi")
{
//Abre un formulario para la confirmacin de realizar nuevo registro
frmConfModifPersona frmMensaje = new frmConfModifPersona("Producto", "");
frmMensaje.ShowDialog();
5-6-7
if (frmMensaje.confirma)
{
//Mtodo para confirmar cambios en la base de datos
mtdModificarProducto();
MessageBox.Show("El Producto fue Modificado");
habilitabotones(); 6-8
mtddisabledtxt();
op = "for";
}
}
else
MessageBox.Show("EL PRODUCTO YA EXISTE");
}
}
else
{
MessageBox.Show("Debe llenar todos los Datos");
//Mtodo que se encarga de colorear los campos que no se introdujeron
y //son obligatorios
mtdColoreaCampos();
}
164
Diagrama de flujo
2 Grafo de Flujos del procedimiento Registro de Productos
Figura 4.8 Grafo de flujos
[Fuente: Elaboracin propia]

productos y seleccionando las ejecuciones enumeradas en cada lnea de cdigo.
165

registro de datos:
1. Camino1: 1-3
2. Camino2:1-2-4
3. Camino3: 1-2-5-7
4. Camino4: 1-2-5-6-8
Prueba de caminos
1. El usuario luego de haber introducido datos de registro, el sistema valida

introduccin de campos obligatorios.
2. El usuario luego de haber introducido todos los datos de registro de
producto, el sistema guarda el mismo en la base de datos exitosamente.
3. Una vez introducidos los datos de registro, el sistema valida datos de
campos obligatorios.
4. Despus de haber seleccionado datos de un producto existente, se procede
a su edicin de datos y el mismo guarda cambios realizados.
5.2.2.2.1 FORMULARIO REGISTRO DE PRODUCTOS
166
ENTRADA
Cdigo de producto o Longitud( n)<=13 Longitud( n)>13
barras
Nombre Un dato valido, longitud Cualquier dato que no
<50 sea tipo string, y longitud
>50.
Marca Un dato valido, longitud Cualquier dato que no
<25 sea tipo caracter, y
longitud >25
Cdigo de producto Un caracter valido, Cualquier dato que no
longitud <=12 sea tipo caracter, y
longitud >12.
Cdigo de barras Longitud( n)=13 13<Longitud( n)<13
Descripcin Un caracter valido, Cualquier dato que no
longitud >50.
Costo producto Un dato de tipo double Cualquier dato que no
sea tipo doubl
Precio venta Un dato de tipo double Cualquier dato que no
sea tipo doubl
Seleccionar imagen Un tipo de archivo de Cualquier tipo de archivo
formato imagen <> imagen.

REGISTRO DE PROVEEDORES Y PRODUCTOS
Para 2.2.1. Registro de proveedores

objetivo planteado.
contrasea.
167
Usuario
Contrasea
proveedores y otros es eficaz ya que los datos
son administrados correctamente y con xito.
Sobre carga
Disponibilidad Solamente los responsables encargados Alto
tendrn acceso a ste mdulo, y el gerente
administrativo tendr acceso a los informes

Para 2.2.2. Registro de productos

objetivo planteado.
168
contrasea.
Usuario
Contrasea
Comunicaciones La comunicacin entre ambas interfaces es
eficiente ya que los datos que son guardados
en la primera (Clasificacin de productos) se
pueden reflejar en la segunda (Registro de
productos)

Sobre carga
Disponibilidad Solamente el administrador tendr acceso a Alto
ste mdulo, y el gerente administrativo
169
5.2.3 PRUEBAS DEL SISTEMA PARA EL MODULO DE COMPRAS Y

ALMACENES
5.2.3.1.1 CDIGO FUENTE REGISTRO DE COMPRA DIRECTA
// Descripcin: Registro de compra directa
varGlobalG.nuevacompra_contado_credito_GLOBAL = 1;
cbbTipoDoc.Enabled = true;
txtNroDocumento.Enabled = true;
int swconfirma;
int swconfirma = 0;
if (dgvKardex.Rows.Count > 0)
{
//Verifica si existen datos en blanco en el registro a realizar
if (!ExisteDatosBlancosCab(sw))
{
//Abre el formulario para realizar el pago de la compra realizada 1-2-3
frmPagoCompras f = new frmPagoCompras(CodUsuario,
Convert.ToString(txtMontoTotal.Text.Trim()), "ORDEN DE COMPRA",
codtransaccionG, 0);
if (f.sw_pagocompras!=0)
{
clsTransaccionBL TransaccionBL = new clsTransaccionBL();
clsUsuarioBL UsuarioBL = new clsUsuarioBL(CodUsuario);
clsPersonaBL persona = new clsPersonaBL(UsuarioBL.codpersona);
if (sw == 1)
{ 2-4-5
//Debuelve el cdigo de tipo de transaccin
codTipoTrans = TransaccionBL.DevuelveCodTipoTransSERVER("Pedido
Productos", CodLinea);
}
else
{ 4-6
Debuelve el cdigo de tipo de transaccin
170
codTipoTrans = TransaccionBL.DevuelveCodTipoTransSERVER("Compra
Productos", CodLinea);
}
int codtransaccion;
//Metodo que se encarga de obtener el cdigo de transaccin actual
codtransaccion = mtdCodigoTransaccion();
codtransaccion = codtransaccion + 1;
CodAlmacen = varGlobalG.CodAlmacenG;
int codtipodoc;
int numerodoc;
double montotot;
int codestadoventas;
if (sw == 0)
{
codtipodoc = Convert.ToInt32(cbbTipoDoc.SelectedValue);
numerodoc = Convert.ToInt32(txtNroDocumento.Text.Trim()); 6-7-8
montotot = Convert.ToDouble(txtMontoTotal.Text.Trim());
codestadoventas = 3;
}
else
{
codtipodoc = 0;
numerodoc = 0;
montotot = 0;
codestadoventas = 2;
}
string NombreEstadoVentas = "Entregado en Almacn";
clsEstadoVentasBL EstadoVentasBL = new clsEstadoVentasBL();
codestadoventas =
EstadoVentasBL.DevuelveCodEstadoVentasSERVER(NombreEstadoVentas);
string codempresa = Convert.ToString(varGlobalG.CodEmpresaG);
string codsucursal = Convert.ToString(varGlobalG.CodSucursalG);
string codalmacen = Convert.ToString(varGlobalG.CodAlmacenG);
if (codempresa == "0" || codempresa == "0")
{
codempresa = "1";
}
string ruta = codempresa + '-' + codsucursal + '-' + codalmacen;
clsKardexPagoBL KardexPagoBL = new clsKardexPagoBL(); 9-10-11
int coddocumento;
//Mtodo que devuelve el cdigo de tipo de documento
KardexPagoBL.CodigoTipoDocumentoAlmacenSERVER("ORDEN DE COMPRA",
varGlobalG.CodAlmacenG);
coddocumento = KardexPagoBL.codtipodocumento;
int nrodocactual = 0;
try
{
nrodocactual = mtdrecuperanumerodoc(coddocumento,
nrodocactual = nrodocactual + 1;
}
catch { }
//Mtodo que se encarga de actualizar el numero de documento actual
KardexPagoBL.UpdateNroDocActMSS(coddocumento, nrodocactual,
object[] objCab;
171
objCab = new object[] { codtransaccion,ruta/*ruta*/,
DateTime.Now,Convert.ToDouble(txtMontoTotal.Text.Trim()),0,
numerodoc,
tipopago/*contado-
credito*/,0,0,0,0,DateTime.Now,0,txtObservaciones.Text.Trim(),"A",
Convert.ToInt32(cbbProveedor.SelectedValue),codTipoTrans,
CodUsuario,codtipodoc,
CodAlmacen,
0,Convert.ToInt32(CodTurno),0,codestadoventas,Convert.ToString("1"),"0"
,0/*codalmacen*/,nrodocactual
};
varGlobalG.nrodocactualGLOBAL = nrodocactual;
//Metodo que se encarga de guardar la transaccin de compra a la base de
datos
TransaccionBL.AdicionarTransaccionCabSERVER(objCab);
int c = 0;
double precproduct;
CodTransaccionGLobal=codtransaccion;
foreach (DataGridViewRow fila in dgvKardex.Rows)
{
precproduct = (Convert.ToDouble(fila.Cells["precioventa"].Value) /
Convert.ToDouble(fila.Cells["cantidad"].Value));
precproduct = Math.Round(precproduct, 2);
object[] objDet;
c = c + 1;
int coddet;
//Mtodo que se encarga de obtener el codigo de transaccion detalle
coddet = mtdCodigoTransaccionDet();
coddet = coddet + 1;
objDet = new object[] { coddet,
c,
Convert.ToInt32(fila.Cells["cantidad"].Value),
precproduct,
0,
Convert.ToDouble(fila.Cells["precioventa"].Value),
0,
Convert.ToString(fila.Cells["codproducto"].Value),
Convert.ToInt32(fila.Cells["codlote"].Value),
codtransaccion,"A"
};
//Mtodo que se encarga de adicionar el detalle de la transaccin
TransaccionBL.AdicionarTransaccionDetSERVER(objDet);
}
swconfirma = 1;
mtddisabledtxt();
if (cbbProveedor.SelectedIndex == -1)
{
cbbProveedor.BackColor = Color.Pink;
}
else
{ 12-13-14
cbbProveedor.BackColor = Color.White;
}
//Limpia campos del detalle de compra
LimpiarDet();
//Limpia campos de la cabecera de compra
172
LimpiarCab();
cbbTipoProd.SelectedIndex = 0;
cbbFamilia.SelectedIndex = 0;
cbbSubFamilia.SelectedIndex = 0;
dgvKardex.Rows.Clear();
//Metodo que se encarga de cargar los lotes existentes
mtdCargaLotes();
clsTransaccionBL clsTransaccionBL = new clsTransaccionBL();
dgvHistorial.DataSource =
clsTransaccionBL.SeleccionaProductoTabSERVER("0");
sw_imagen = 0;
FotoPictureBox.Visible = false;
btnNuevaCompra.Visible = true;
btnpedidosmes.Visible = true;
btnSalirFormulario.Visible = false;
mtddisabledtxt();
disabledcbbs();
btnNuevaCompra.Enabled = true;
btnConfirmarCompraC.Visible = false;
}
else
{
}
}
else
{
MessageBox.Show("Existe Datos en Blanco en el Encabezado de Compra,
Verifique Los Datos", "Mensaje", MessageBoxButtons.OK,
MessageBoxIcon.Error);
//Metodo que colorea campos que son obligatorios y no se introducieron
mtdColoreaCamposCab(sw);
}
}
else
{
MessageBox.Show("No Existe Ningun Ingreso", "Mensaje",
MessageBoxButtons.OK, MessageBoxIcon.Information);
LimpiarDet();
}
if (swconfirma == 1)
{
frmPagoCompras form = new frmPagoCompras(CodUsuario,
Convert.ToString(txtMontoTotal.Text.Trim()), "ORDEN DE COMPRA",
CodTransaccionGLobal, 0);
form.Show(); 15-16-17-18
}
173
Diagrama de flujo
174
2 Grafo de flujo


registro de datos:
1. Camino1: 1-3
2. Camino2:1-2-5
175
3. Camino3: 1-2-4-6-8-9-11-12-14-15-17-18
4. Camino4: 1-2-4-6-7-9-10-12-13-14-15-16-18
Prueba de caminos
1. El sistema realiza la validacin de introduccin de datos al detalle de la

compra en caso de no existir ingresos en el detalle el sistema nos mostrara
un mensaje donde menciona que no existe ningn ingreso en el detalle.
2. El usuario luego de haber introducido los datos de registro de compra,
luego el sistema valida todos los campos de cabecera que han sido
llenados si falta algn campo muestra un mensaje "Existe Datos en Blanco
en el Encabezado de Compra, Verifique Los Datos".
3. El sistema antes de guardar la compra obtiene el tipo de transaccin
compra de productos, obtiene el cdigo de tipo de documento de orden de
compra, obtiene el numero de documento actual de la transaccin, adiciona
la cabecera de la transaccin y su respectivo detalle a la base de datos,
guarda el mismo exitosamente.
4. El sistema antes de guardar la compra obtiene el tipo de transaccin pedido
de productos, obtiene el cdigo de tipo de documento de orden de compra,
obtiene el numero de documento actual de la transaccin y actualiza el
mismo, adiciona la cabecera de la transaccin y su respectivo detalle a la
base de datos, guarda el mismo exitosamente.
176
5.2.3.2.1 FORMULARIO REGISTRO DE COMPRA DIRECTA

ENTRADA
Cdigo de producto o Longitud( n)<=13 Longitud( n)>13
barras
Seleccione lote Un dato valido, longitud Cualquier dato que no
<=20 sea tipo string, y longitud
>20.
Fecha de vencimiento Un dato con formato de Cualquier dato que no
tipo date 00/00/00 sea tipo date
Ingrese cantidad Longitud( n)<=7 Longitud( n)>7
Ingrese precio total Un dato de tipo double Cualquier dato que no
sea tipo doubl
Nmero de documento Longitud( n)<=10 Longitud( n)>10
Observaciones Un caracter valido, Cualquier dato que no
longitud >50.
177
COMPRAS Y ALMACENES
Para 2.3.1. Registro de compra directa

objetivo planteado.
contrasea.
Usuario
Contrasea
en la primera (Compra directa) se pueden
reflejar en la segunda (Historial)

178
Sobre carga
Disponibilidad Solamente el encargado de compras tendr Alto
acceso a ste mdulo, y el gerente

Para 2.3.2. Registro de compra por procesos

objetivo planteado.
contrasea.
Usuario
Contrasea
Comunicaciones La comunicacin entre ambas interfaces es Alto
179
en la 1ra (Generar pedido) se pueden reflejar
en la 2da (Pedidos por confirmar), 3ra
(Confirmar orden de compra), 3ra (Realizar
compra).
180
Sobre carga
Disponibilidad Solamente el encargado de compras tendr Alto

Para 2.3.3. Registro de traspaso entre almacenes

objetivo planteado.
contrasea.
181
Usuario
Contrasea
en la primera (Cambio de Almacen) se pueden
reflejar en la segunda (Ingreso de traspaso)

Sobre carga
Disponibilidad Solamente el encargado de almacn tendr Alto

182
Para 2.3.4. Registro de salidas varias

objetivo planteado.
contrasea.
Usuario
Contrasea
en la primera (Salidas varias) se pueden
reflejar en la segunda (Historial de salidas
varias)

Sobre carga
183
5.2.4 PRUEBAS DEL SISTEMA PARA EL MODULO DE VENTAS Y GESTIN

DE CLIENTES CRM
5.2.4.1.1 CDIGO FUENTE REGISTRO DE PRODUCTOS

if (txtCodProducto.Text.Trim() != ""
&& txtNomProducto.Text.Trim() != "" && txtPrecProducto.Text.Trim() != "0"
&& txtStockProducto.Text.Trim() != "0"
&& cbbEstadoProducto.SelectedIndex != 0 && cbbTipo.SelectedIndex != 0 &&
cbbCategoria.SelectedIndex != 0 &&
cbbSubCategoria.SelectedIndex != 0)
{ 1-2-3
CodigoProd = txtCodProducto.Text.Trim();
object[] vObj = new object[] { CodigoProd, codTipo, codFamilia,
codSubFamilia };
//Verifica la existencia de un producto a registrar
if (!ProductoBL.ExisteProductoSERVER(vObj))
{
//Adiciona el producto a la base de datos 2-4-5
mtdAdicionarProducto();
MessageBox.Show("El Producto fue Adicionado");
//Metodo que carga datos de clasificacin de productos
mtdCargaDatos();
//Deshabilita controles una vez registrado un producto
//Habilita botones para el inicio de un nuevo registro de producto
habilitabotones();
txtCodProducto.ReadOnly = true;
txtCodProducto.Enabled = false;
184
cbbTipo.Focus();
op = "for";
mtdLimpiaControles();
habilitabotones();
op = "for";
cbbTipo.SelectedIndex = 0;
//Mtodo que deshabilita las cajas de texto
mtddisabledtxt();
}
else
{
if (op == "edi")
{
//Abre un formulario para la confirmacin de realizar nuevo registro
frmConfModifPersona frmMensaje = new frmConfModifPersona("Producto", "");
frmMensaje.ShowDialog();
5-6-7
if (frmMensaje.confirma)
{
//Mtodo para confirmar cambios en la base de datos
mtdModificarProducto();
MessageBox.Show("El Producto fue Modificado");
habilitabotones(); 6-8
mtddisabledtxt();
op = "for";
}
}
else
MessageBox.Show("EL PRODUCTO YA EXISTE");
}
}
else
{
MessageBox.Show("Debe llenar todos los Datos");
//Mtodo que se encarga de colorear los campos que no se introdujeron
y //son obligatorios
185
mtdColoreaCampos();
}
Diagrama de flujo
2 Grafo de Flujos del procedimiento Registro de Productos
Figura 4.8 Grafo de flujos

186


registro de datos:
1. Camino1: 1-3
2. Camino2:1-2-4
3. Camino3: 1-2-5-7
4. Camino4: 1-2-5-6-8
Prueba de caminos
1. El usuario luego de haber introducido datos de registro, el sistema valida

introduccin de campos obligatorios.
2. El usuario luego de haber introducido todos los datos de registro de
producto, el sistema guarda el mismo en la base de datos exitosamente.
3. Una vez introducidos los datos de registro, el sistema valida datos de
campos obligatorios.
4. Despus de haber seleccionado datos de un producto existente, se procede
a su edicin de datos y el mismo guarda cambios realizados.
5.2.4.2.1 FORMULARIO REGISTRO DE VENTAS

ENTRADA
Cdigo de producto, Un dato valido, longitud Cualquier dato que no
barras o nombre. <50 sea tipo string, y longitud
>50.
Cantidad Un caracter valido, Cualquier dato que no

longitud <=5 sea tipo caracter, y
longitud >5.
187
Registro guardado con xito, ya sea del proceso de venta o pre-venta.

VENTAS Y GESTIN DE CLIENTES POTENCIALES
Para 2.4.1. Registro de ventas

objetivo planteado.
contrasea.
188
Usuario
Contrasea
en la primera (Realizar venta) se pueden
reflejar en la segunda (Ventas realizadas) y/ o
tercera (Preventas realizadas)

Sobre carga
189
Para 2.4.2. Registro de clientes y gestin de clientes potenciales (CRM)

objetivo planteado.
contrasea.
Usuario
Contrasea
en la primera (Registro de clientes) se
pueden reflejar en la segunda (Gestin de
clientes potenciales) y/ o tercera (Gestin de
clientes potenciales por criterios)
190
Sobre carga
Como en la opcin de gestionar cliente:
191
Operacin e La operacin de arranque y la instalacin Regular
5.3 CALIDAD DEL SOFTWARE MCCALL

Se determina la calidad del producto software de acuerdo a los criterios de McCall,
con este objetivo se realiza una evaluacin del sistema mediante pruebas de
usuarios sobre el presente software y llenado de tablas de calificacin, utilizando
la siguiente frmula:
Fq=C1*M1+C2*M2++Cn*Mn
Dnde:
Fq= Factor de calidad de software
Ci= Coeficiente de regresin
Mi= Mtricas que afectan a la calidad del software (0-10)
Los coeficientes de regresin se calculan a travs de la siguiente frmula:
Ci= ((Mt*M)exp(-1))*(Mt*Fk)
Dnde:
Mt= Matriz transpuesta de las mtricas de calidad.
Fk= Matriz de calidad de un factor determinado.
a) Factor de la facilidad de uso
192
Los datos introducidos, son resultado de encuestas a los empleados de la
empresa [Anexo F]
Tabla 4.1 Mtricas de calidad de facilidad de uso
Criterios Usuario 1 Usuario 2 Usuario 3 Usuario 4 Promedio

Operacio n 9 7 7 7 7.5
Comunicacio n 7 8 7 7 7.25
Aprendizaje 9 7 9 9 8.5
Formacio n 9 9 8 9 8.75
9 7 7 7 7 9 7 9 9
M 7 8 7 7 Fk 7 Mt 7 8 7 9
= = =
9 7 9 9 8 7 7 9 8
9 9 8 9 8 7 7 9 9
292 263 265 274 25

Mt*M= 263 243 240 249
6
265 240 243 251
Mt*Fk 23
274 249 251 260
= 3
23
4
24
2
0.37 -0.07 -0.30 0.00
(Mt*M)exp(- -0.07 0.25 0.19 -0.34
1)=
-0.30 0.19 1.77 -1.57
0.00 -0.34 -1.57 1.87
8.21
((Mt*M)exp(- 2.51
1)*(Mt*Fk))=
1.71
5.94
193
Entonces el factor de calidad para la facilidad de uso es:
Fq= 8.21*7.5 - 2.51*7.25 +1.71*8.5 - 5.94*8.75

Fq= 61.67+18.19+14.53+51.97
Fq=8.86
b) Factor de integridad
Tabla 4.2 Mtricas de calidad de integridad
Criterios Usuario Usuario Usuario Promedi

1 2 3 o
Control de accesos 7 7 7 7
Facilidad de 6 7 7 6.67
auditoria
Seguridad 7 6 7 6.67
7 7 7 7 7 6 7
M 6 7 7 Fk 7 Mt 7 7 6
= = =
7 6 7 7 7 7 7
134 133 140 14
Mt*M= 133 134 140 0
140 140 147 Mt*Fk 14

= 0
2 1 -2.86 14
7
(Mt*M)exp(-1)= 1 2 -2.86
-2.86 -2.86 5.45
194
-
1.05
((Mt*M)exp(- -
1)*(Mt*Fk))= 1.05
3.15
Entonces el factor de calidad para la integridad es:
Fq= -1.05*7 - 1.05*6.67 + 3.15*6.67
Fq= -7.35-7.00+21.00
Fq=6.65
c) Factor de correccin
Tabla 4.3 Mtricas de calidad de correccin
Criterios Usuario Usuario Usuario Promedi

1 2 3 o
Completitud 6 7 7 6.67
Consistenci 7 6 6 6.33
a
Trazabilidad 6 5 6 5.67
195
6 7 7 6 6 7 6
M 7 6 6 Fk 7 Mt 7 6 5
= = =
6 5 6 7 7 6 6
121 114 120 12
Mt*M= 114 110 115 7
120 115 121 Mt*Fk 11

= 9
12
6
0.50 0.03 -
0.53
(Mt*M)exp(- 0.03 1.42 -

1)= 1.39
- - 1.85
0.53 1.39
-
0.29
((Mt*M)exp(- 0.95
1)*(Mt*Fk))=
0.38
196
Entonces el factor de calidad para la correccin es:
Fq=-0.29*6.67 + 0.95*6.33 +0.38*5.67
Fq= -1.93 + 6.01+2.15
Fq=6.23
d) Factor de fiabilidad
Tabla 4.4 Mtricas de calidad de fiabilidad
Criterios Usuario Usuario Usuario Usuario Usuario Promedio

1 2 3 4 5
Modularidad 9 8 8 8 7 8
Simplicidad 6 7 6 6 7 6.4
Consistencia 7 8 7 8 7 7.4
Concisin 7 8 6 7 7 7
Auto 6 7 8 7 7 7
197
descripcin
24 22 21 23 23
25
7 8 7 4 4
0 9 8 8 8 7
Mt*M 22 23 21 22 21
Mt*Fk M24 6 7 6 6 7
= 8 8 0 4 9
= = 0
21 21 19 21 20
22 7 6 7 6 6
7 6 3 0 4
3 7 8 6 7 7
23 22 21 23 22
6423 6 47 80 7 78 5
7
22 21 20 22 25
23
8 89 4 5 5
1
Fk 8
=
9 6 7 7 6
Mt 8 7 6 8 7
=
8 6 7 6 8
8 6 6 7 7
7 7 6 7 7
198
0.05 0.003 0.04 0.000 0.031
1
(Mt*M)exp(- 0.05 0.02 0.02 0.004 -0.1

1)=
11.75
((Mt*M)exp(- 2.52
1)*(Mt*Fk))=
3.7
-47.42
29.2
Entonces el factor de calidad para la fiabilidad es:
Fq=11.75*8+2.52*6.4+3.70*7.4-47.42*7+29.20*7
Fq= 94+16.128+27.38-331.94+204.4
Fq=9.96
e) Factor de eficiencia
Tabla 4.5 Mtricas de calidad de eficiencia
Criterios
199
Usuario 1
Usuario 2
Promedio
Eficiencia de ejecucin
8.5
Eficiencia de almacenamiento
Fk 9
8 9
=
Mt 9 9 145 153
=
Mt*M= 153 162
15
3
Mt*Fk 16
= 2
200
2 -1.89
(Mt*M)exp(- -1.89 1.79

0.18
((Mt*M)exp(- 0.81
1)*(Mt*Fk))=
Entonces el factor de calidad para la eficiencia es:
Fq=0.18*8.5 +0.81*9
Fq= 1.53+7.29
Fq=8.82
f) Factor de mantenimiento
Tabla 4.6 Mtricas de calidad de mantenimiento
Criterios
Usuario 1
Usuario 2
201
Usuario 3
Usuario 4
Usuario 5
Promedio
Modularidad
Simplicidad
Consistencia
202
7
7.4
Concisin
Auto descripcin
7 8 6 7 7
203
M 8 7 6 7 7
=
7 6 7 6 6
7 8 6 7 7
6 5 6 7 6
Fk 8
=
7 8 7 7 6
Mt 8 7 6 8 5
=
6 6 7 6 6
7 7 6 7 7
7 7 6 7 6
204
24 22 21 23 23
25
7 8 7 4 4
0
Mt*M 22 23 21 22 21
Mt*Fk 24
= 8 8 0 4 9
= 0
21 21 19 21 20
22
7 6 3 0 4
3
23 22 21 23 22
23
4 4 0 8 5
7
22 21 20 22 25
23
8 9 4 5 5
1
0.05 0.003 0.04 0.000 0.031

1
(Mt*M)exp(- 0.05 0.02 0.02 0.004 -0.1

1)=
30.27
205
((Mt*M)exp(-1)*(Mt*Fk))=
-23.83
5.43
-15.68
5.26
Entonces el factor de calidad para el mantenimiento es:
Fq=30.27*7 -23.83*7+5.43*7.4-15.68*7+5.26*6
Fq=211.89-166.81+40.18-109.76+31.56
Fq=7.07
g) Factor de facilidad de prueba
Tabla 4.7 Mtricas de calidad de facilidad de prueba
Criterios Usuario 1 Usuario 2 Usuario 3 Usuario 4 Promedio
Modularid 7 8 6 7 7
ad
Simplicida 8 7 7 7 7.25
206
d
Auto 6 5 6 7 6
descripci
n
Instrument 7 7 7 7 7
acin
7 8 6 7 7 7 8 6 7
M 8 7 7 7 Fk 6 Mt 8 7 5 7
= = =
6 5 6 7 7 6 7 6 7
7 7 7 7 7 7 7 7 7
19 18 17 19 18
8 3 5 2 8
Mt*M 18 18 16 18 Mt*Fk 17
= 3 7 9 5 = 8
17 16 15 17 16
5 9 7 5 9
19 18 17 19 18
2 5 5 6 9
0.01 0.0006 -0.014 -0.01

4
(Mt*M)exp(- -0.1007 0.017 0.032 0.016

1)=
0.0004 0.031 0.008 0.002
207
7 9 3
0.0012 -0.072 0.001 0.08

7
-
2.26
((Mt*M)exp(- -
1)*(Mt*Fk))= 5.46
7.54
2.43
Entonces el factor de calidad para la facilidad de prueba es:
Fq=-2.26*7-5.46*7.25+7.54*6+2.24*7
Fq=-15.82-39.59+45.24+17.01
Fq=6.84
h) Factor de flexibilidad
Tabla 4.8 Mtricas de calidad de flexibilidad
Criterios Usuario Usuario Usuario Usuario Promedi

1 2 3 4 o
Auto descripcin 7 6 7 7 6.75
Capacidad de 8 7 8 7 7.5
208
expansin
Generalidad 7 7 7 7 7
Modularidad 7 8 6 7 7
7 6 7 7 6 7 8 7 7
M 8 7 8 7 Fk 8 Mt 6 7 7 8
= = =
7 7 7 7 8 7 8 7 6
7 8 6 7 7 7 7 7 7
19 18 18 19 20
8 3 4 2 1
Mt*M 18 18 17 18 Mt*Fk 18
= 3 7 2 5 = 6
18 17 17 17 19
4 2 2 8 0
19 18 17 19 19
2 5 8 6 5
209
0.02 0.000 -0.014 -0.01
6
(Mt*M)exp(- -0.101 0.017 0.032 0.016

1)=
0.000 0.04 0.008 0.002

5 9 3
0.001 -0.079 -0.002 0.08
-
0.78
((Mt*M)exp(- -
1)*(Mt*Fk))= 7.88
9.67
0.75
Entonces el factor de calidad para la flexibilidad es:
Fq=-0.78*6.75-7.88*7.5+9.67*7+0.75*7
Fq=-5.26-59.10+67.69+5.25
Fq=8.58
i) Factor de reusabilidad
Tabla 4.9 Mtricas de calidad de reusabilidad
210
Criterios Usuari Usuari Usuari Usuari Usuario Promedio
8
o1 o2 o3 o4 5 Fk 8
Generalidades 7 8 6 7 7 = 7
Modularidad 8 7 6 7 7 7 7
Independenci 7 6 7 6 6 7.47
a entre el 6
sistema y
software
Independenci 7 8 6 7 7 7
a del
hardware
Auto 6 5 6 7 6 6
descripcin
7 8 6 7 7 7 8 6 7 7
M 8 7 6 7 7 Mt 8 7 6 8 5
= =
7 6 7 6 6 6 6 7 6 6
7 8 6 7 7 7 7 6 7 7
6 5 6 7 6 7 7 6 7 6
2 2 2 2 2 25
4 2 1 3 3 0
7 8 7 4 4 Mt*Fk 24
Mt* 2 2 2 2 2 = 0
M= 2 3 1 2 1 22
211
8 8 0 4 9 3
23
2 2 1 2 2 7
1 1 9 1 0
23
7 6 3 0 4
1
2 2 2 2 2
3 2 1 3 2
4 4 0 8 5
2 2 2 2 2
2 1 0 2 2
8 9 4 5 5
0.052 0.003 0.04 0.000 0.031

2 1
(Mt*M)exp(- 0.051 0.02 0.02 0.004 -0.1

1)= 8 1
0.013 0.005 0.00 0.002 0.000

2 4
0.002 0.07 -0.06 0.000 0.06

1 5
0.008 0.000 0.00 0.007 0.002

7 3 7 1
30.27
((Mt*M)exp(- -
1)*(Mt*Fk))= 23.83
5.44
212
15.68
5.41
Entonces el factor de calidad para la reusabilidad es:
Fq=30.27*7-23.83*7+5.44*7.4-15.68*7+5.41*6
Fq=211.89-166.81+40.25-109.76+32.46
Fq=8.03
j) Factor de interoperabilidad
Tabla 4.10 Mtricas de calidad de interoperabilidad

1 2 3 4 o
Compatibilidad de 6 5 6 8 6.25
comunicacin
Compatibilidad de 8 7 8 7 7.5
datos
Estandarizacin de 7 7 6 8 7
213
datos
6 5 6 8 7 6 5 6 8
M 8 7 8 7 Fk 8 Mt 8 7 8 7
= = =
7 7 6 8 6 7 7 6 8
7 8 6 7 8 7 8 6 7
19 18 18 20 20
8 3 4 1 0
Mt*M 18 18 17 19 Mt*Fk 19
= 3 7 2 3 = 3
18 17 17 19 19
4 2 2 0 0
19 18 17 22 20
2 5 8 6 4
0.02 0.0005 -0.014 -0.01

9
(Mt*M)exp(- - 0.017 0.032 0.016

1)= 0.1007
0.0337 0.005 0.001 0.002

3
214
0.001 -0.077 - 0.08
0.0017
-4.59
((Mt*M)exp(- -7.51
1)*(Mt*Fk))=
11.45
1.67
Entonces el factor de calidad para la interoperabilidad es:
Fq=-4.59*6-7.51*7.5+11.45*7+1.67*7
Fq=-27.54-56.32+80.15+11.69
Fq=7.98
k) Factor de portabilidad
Tabla 4.11 Mtricas de calidad de portabilidad

1 2 3 4 o
Auto descripcin 6 5 6 7 6
Independencia 7 7 8 7 7.25
entre sistema y
215
software
Independencia de 7 7 6 6 6.5
hardware
6 5 6 7 6 6 7 7 7
M 7 7 8 7 Fk 8 Mt 5 7 7 8
= = =
7 7 6 6 8 6 8 6 6
7 8 6 7 7 7 7 6 7
19 18 18 19 20
8 3 4 2 1
Mt*M 18 18 17 18 Mt*Fk 18
= 3 7 2 5 = 6
18 17 17 17 19
4 2 2 8 0
19 18 17 19 19
2 5 8 6 5
0.02 0.000 -0.014 -0.01

6
(Mt*M)exp(- -0.1007 0.017 0.032 0.016

1)=
0.0004 0.04 0.0089 0.002

7 3
216
0.001 -0.079 - 0.08
0.0017
-
0.48
((Mt*M)exp(- -
1)*(Mt*Fk))= 7.88
9.67
0.75
Entonces el factor de calidad para la portabilidad es:
Fq=-0.48*6-7.88*7.25+9.67*6.5+0.75*7
Fq=-2.88-57.13+62.85+5.25
Fq=8.09
5.3.1 RESULTADOS OBTENIDOS

Tabla 4.12 Factores de calidad del software
Puntos de vista Factores de calidad

(0-10)
Punto de vista de operacin del producto
Factor de facilidad de uso 8.86
217
Factor de integridad 6.65
Factor de correccin 6.23
Factor de fiabilidad 9.96
Factor de eficiencia 8.82
Punto de vista de revisin
Factor de facilidad de 7.07

mantenimiento
Factor de facilidad de prueba 6.84
Factor de flexibilidad 8.58
Punto de vista de transicin del proyecto
Factor de reusabilidad 8.03
Factor de interoperabilidad 7.98
Factor de portabilidad 8.09
TOTAL 87.11
Determinamos el factor de calidad del sistema utilizando la formula siguiente:
F(i)/n = 87.11 / 11 = 7.92
5.3.2 RESULTADOS
De los resultados obtenidos, se puede analizar que el promedio de los factores de
calidad del sistema es bueno, ya que 7.92 en un rango de 7 a 9 indica que el
sistema tiene una consistencia apropiada en cuanto a la calidad y puede llegar a
cumplir los objetivos planteados desde el principio de su desarrollo.
218
La calidad del software es muy buena, entonces el cliente puede trabajar de una
forma eficaz y eficiente, brindando un buen servicio a sus respectivos clientes, as
como tambin un control muy eficiente de los empleados y del almacn, el manejo
del sistema les resulto fcil y agradable. Haciendo su uso ms prctico y rpido
para realizar las tareas asignadas.
El manejo de sesiones facilita el trabajo para cada usuario del sistema, teniendo
cada uno de estos usuarios permisos limitados de acuerdo al tipo de usuario que
pertenezca, teniendo un men diferente de acuerdo a las labores o el cargo que
tienen en la empresa en la cual se desarroll el sistema.
La conexin que tiene el usuario con el servidor se presenta de una forma activa y
remota registrando y observando todas las operaciones procesadas.
Los mtodos y tcnicas empleados en el desarrollo del sistema, ayudaron a
manejar de una forma ordenada la solucin a los objetivos planteados.
La encriptacin de las contraseas hace ms seguro el sistema contra amenazas
ajenas, y as tener seguridad al ingresar al sistema.
6 CAPITULO VI: CONCLUSIONES Y RECOMENDACIONES
6.1 INTRODUCCIN
En este captulo se da a conocer las conclusiones a las que se lleg al finalizar el
presente proyecto de grado. Se realiza un anlisis del cumplimiento de objetivos y
se realiza recomendaciones respecto al sistema. Despus de haber culminado con
la implementacin del sistema en la distribuidora CRISURT, realizando las
pruebas respectivas se llego a lo siguiente:
219
6.2 CONCLUSIONES
Las metodologas utilizadas en este proyecto, permitieron lograr una
correcta especificacin del software a desarrollar.
El modelo McCall contribuy a determinar la calidad del software mediante
el anlisis de diferentes factores desde distintos puntos de vista.
Con el sistema desarrollado permitir a los usuarios controlar de manera
eficiente el flujo de informacin de los pedidos realizados.
El sistema desarrollado permite a los usuarios manejar de diferente manera
los documentos generados en las oficinas, ya que se ir reemplazando
paulatinamente los documentos fsicos por los digitales.
Con el proyecto se pudo dar al personal de la empresa una forma de
manejar mejor la documentacin generada.
Utilizando la tecnologa correspondiente hace que el sistema sea seguro,
evitando de esa forma que personas ajenas a la empresa puedan tener
acceso a informacin privada.
El ingreso al sistema de acuerdo a los permisos que tenga asignados el
usuario de la empresa, evita la mescla de informacin.
El manejo de la base de datos en un servidor dedicado en el exterior lo
hace seguro porque aparte de manejar una contrasea especfica para la
base de datos, el servidor dedicado tambin cuenta con su propia
seguridad.
El control de empleados que realiza el sistema mejora el control de los
mismos, ya que brinda informacin confiable y oportuna en cualquier
momento del tiempo, generando boletas de pago y planillas de sueldo
mensuales.
El sistema ayuda a un control de los clientes potenciales ya que estos son
importantes para la distribuidora.
El modelo de pronstico implementado en el sistema es de importancia
para realizar futuros pedidos de materia prima y as tener un control
adecuado de los pedidos a realizarse.
El sistema realiza un control eficiente de almacn, productos de la
distribuidora, cumpliendo as los objetivos planteados en este proyecto.
Con el sistema desarrollado se logr el correcto control de almacn,
productos y personal cumpliendo as los objetivos planteados al inicio del
proyecto.
220
6.3 RECOMENDACIONES
Tomando en cuenta la arquitectura del sistema, la persona o personas
encargadas de la administracin de la base de datos deben realizar
inspecciones de conectividad de la red, verificacin de usuarios registrados
en el servidor y un correcto mantenimiento
Se recomienda para que no existan problemas de seguridad en el acceso a
la informacin que el administrador principal del sistema, solicite el cambio
de contraseas de todos los usuarios que pertenecen al mismo, en el lapso
de tiempo que ellos consideren oportuno.
Se recomienda que los empleados de la empresa sean ordenados y
responsables con el trabajo asignado, para que as se eviten problemas
futuros.
Se puede implementar a futuro otros mdulos que completen a estos
sistemas, como por ejemplo un sistema contable u otro que se requiera en
un momento determinado del tiempo, y de acuerdo a lo que requiera la
empresa.
Se recomienda actualizar constantemente el antivirus de las computadoras,
para as asegurar que la informacin que se tiene este segura, y las
maquinas de la empresa estn confiables.
7 REFERENCIAS
REFERENCIAS BIBLIOGRFICAS
[Booch,2000] El proceso unificado de desarrollo de software. Jacobson, I.
Booch, G. Rumbaugh, J. Addison Wesley 2000
[Pressman,2002] Ingeniera de software. Un enfoque prctico. Pressman,

Roger. Quinta edicin. Mc. Graw Hill 2002
[Craig Larman,2002] Craig Larman: UML y Patrones: Introduccin al

anlisis y diseo orientado a objetos y proceso unificado. Prentice-Hall
Hispanoamericana, 2002. disponible a mediados de octubre 2002
[Luiz Capretz,Miriam Capretz,1996 ] Luiz Fernando Capretz y Miriam A. M.

Capretz: Object-Oriented Software: Design and Maintenance. Series on
221
Software Engineering and Knowledge Engineering, vol. 6. World Scientific,
1996.
[Piatini Calvo Manzano] [Cervera Luis Fernndez] Anlisis y diseo de

Aplicaciones Informticas de gestin. Una perspectiva de Ingeniera de
Software.
[IAN SOMMERVILLE] IAN SOMMERVILLE INGENIERA DE SOFTWARE

titulados "Requerimientos del software" y "Procesos de la Ingeniera de
Requerimientos".
REFERENCIAS ELECTRNICAS
[WEB 01]
HTTP://GEEKS.MS/BLOGS/MARCO/ARCHIVE/2006/03/26/81.CRM.HTML
para el modelo CRM
[WEB 02] HTTP://WWW.DIMECUANTOCUESTA.COM/PRECIO-

DE/LICENCIA-ORIGINAL-WINDOWS-7.HTML Para las tablas de costos de
licencias Windows7
[WEB 03] HTTP://WWW.ITSALINAS.COM/ Para las tablas de costos de

licencias de SAP Crystal Report, Sql Server 2008
[WEB 04] PRUEBAS DE CAJA BLANCA - ECURED

www.ecured.cu/index.php/Pruebas_de_caja_blanca para pruebas de caja
blanca
[WEB 05] HTTP://WWW.WEBANDMACROS.COM/CRM.HTML para el

modelo CRM
[WEB 06]
HTTP://ES.INGSOFTMODITERATIVOINCREMENTAL.ORG/ASIAN/LEHMA
N para modelo iterativo Incremental Lehman
[WEB 07] HTTP://ES.WIKIPEDIA.ORG/WIKI/BARRY_BOEHM para

modelo de estimacin del proyecto COCOMO II desarrollado por Barry
Boehm
[WEB 08] HTTP://ES.INGSOFTMODCALSOFT.ORG/ASIAN/PIATTINI para

modelo para evaluar la calidad de software.
222
[WEB 09] MODELADO DE SISTEMAS COM UML - TLDP-ES
es.tldp.org/Tutoriales/doc...UML/doc-modelado-sistemas-uml.pdf Para la
aplicacin mtodos orientado a UML con casos de uso y de secuencia y
actividades
[WEB 10] Calidad de software; 27/09/2011; 19:17; pdf;
HTTP://WWW.EQSOFT.NET/PRESENTAS/MODELOS_DE_CALIDAD_Y_S
OFTWARE.PDF
[WEB 11] HTTP://ES.INGSOFTMODCALSOFT.ORG/ASIAN/PIATTINI para

modelo para evaluar la calidad de software.
[WEB 12] http://jorgepedraza.wordpress.com/2010/04/13/visual-studio-

2010-esta-aqu/ Para visual studio 2010 Ultimate
[WEB 13] Microsoft SQL Server 2008 R2 Enterprise Edition DVD Espaol
WWW.INTERCAMBIOSVIRTUALES.ORG/.../MICROSOFT-SQL-SERVER-
2008-R2-ENTERPRISE-EDITION-DVD-ESPAOL PARA SQL SERVER
2008
[WEB 14] SAP CRYSTAL REPORTS, VERSION FOR VISUAL STUDIO -
SAP COMMUNITY scn.sap.com/.../crystal-reports-for-visual-studio Para
SAP Crystal Report
[WEB 15 ] MTODO DE INVENTARIOS FIFO PEPS

WWW.INTERCAMBIOSVIRTUALES.ORG/.../-mtodo-de-inventarios-fifo-
peps Para mtodo de inventarios FIFO PEPS
[WEB 16] Calidad de software; 27/09/2011; 19:17; pdf;

HTTP://WWW.EQSOFT.NET/PRESENTAS/MODELOS_DE_CALIDAD_Y_S
OFTWARE_LIBRE.PDF
223
[WEB17] http://www.lab.dit.upm.es/~lprg/material/
apuntes/pruebas/testing.htm
224
ANEXO
S
225
ANEXO A
ORGANIGRAMA DE LA
DISTRIBUIDORA
"CRISURT"
226
8 ANEXOS
9 ANEXO A ORGANIGRAMA DE LA DISTRIBUIDORA CRISURT
GERENTE
GENERAL
GERENTE GERENTE COMERCIAL

ADMINISTRATIVO
ENCARGADO DE VENDEDORES SECRETARIA

ENCARGADO DE TECNICO EN
ALMACENES SECRETARIA
COMPRAS SISTEMAS
CHOOFERES
CAJAS
227
ANEXO B
MATRIZ DE
PROCESOS
ADMINISTRATIVOS
228
10 ANEXO B MATRIZ DE PROCESOS ADMINISTRATIVOS
DESCRIPCIN RESPONSABLE MTODO PROBLEMAS

PROCESO
Control de El encargado de Encargado de Manual Perdida de

compras almacenes Revisa almacn informacin.
Semiautomtico Errores de
el pedido de
adquisicin de estimacin en
productos. requerimientos de
Registra los productos.
productos que Duplicidad de
ingresan. datos en los
Elaboracin de registros e
informes informes.
mensuales, sobre Informes sin
los productos. validacin de
Registro de la datos.
compra de Errores en la
productos por estimacin de
procesos (Pedido, compras
Registros
Anulacin de
guardados con
229
pedidos, Edicin de errores.
pedidos, Compras de
confirmacin de productos con un
pedido a proveedor incremento de
y confirmacin de precio.
compra).
Registro de la
compra de
productos de forma
directa.
Informes de
compras realizadas
Informe de stock de
productos
Control de Registro de Encargado de Manual Control errneo
almacenes ingresos de almacn de cantidades
Semiautomtico
productos existentes de
Registro de salidas insumos en
de productos almacn.
Registros de Control errneo
traspasos de de cantidades
productos a otro existentes de
almacn. productos en
Registro de salidas
almacn
varias de almacn
230
(Productos rotos, Las salidas varias
con fallas, mermas, de productos no
uso interno de estn controladas
producto o insumo.)
Registro de Registro de clientes Encargado de Libros nicos de Duplicidad de
clientes Correccin de datos registro de clientes registro registros.
de clientes Registros sin
Elaboracin de correccin
informes mensuales inmediata.
de historiales de Registros con
ventas a clientes. datos faltantes.
Registro de Registro de Encargado de Libros nicos de Duplicidad de
proveedores proveedores. registro de registro registros.
Correccin de datos proveedores Registros sin
de proveedores. correccin
Elaboracin de inmediata.
informes mensuales Registros con
de historiales de datos faltantes.
compras a
proveedores.
Control de Registrar la Encargado de Manual Duplicidad de
ventas cantidad de registro de ventas semiautomtico registros.
productos vendidos Registros sin
a determinados correccin
clientes. inmediata.
231
Registro de ventas Registros con
al crdito. datos faltantes.
Registrar los Errores en el
precios de los proceso de ventas
productos vendidos. de determinados
Emisin de facturas productos.
y/o recibos Errores en los
Elaboracin de precios de
informes diarios de determinados
ventas realizadas. productos.
232
ANEXO C
DIAGRAMA DE
PROBLEMAS Y
OBJETIVOS
233
11 ANEXO C DIAGRAMA DE PROBLEMAS Y OBJETIVOS
La correcta toma de Registro correcto de
Control correcto de
decisiones por parte clientes y
Gestin de clientes salidas varias de
de gerencia y otras proveedores
Control de ventas almacn
reas.
realizadas
Almacen tiene
control correcto de Los reporte con Los reportes
ingresos, salidas y datos precisos para muestran mayor Los reportes de
Stock de productos La economa de la Al control preciso
Los datos sean traspasos. la toma de exactitud en sus almacenes.
controlado. empresa. guardados con de los datos a
guardar. decisiones. datos.
exactitud.
Desarrollar un Sistema de gestin para el control de compras, ventas y almacenes apoyado con el modelo de
gestin de clientes (CRM) para la distribuidora DISTRIBUIDORA CRISURT
Los informes de demanda de Errores de estimacin en

Duplicidad en los registros Registros con datos
productos se elaboran con Perdida de informacin Mezcla de informacion requerimiento de materia
e informes faltantes
bastante tiempo de demora prima
Registros inadecuados por Errores en el proceso de

Las ventas son registradas Los libros no estn bien Los informes no son compras
falta de normalizacin de
manualmente documentados elaborados de forma precisa
procesos
El personal de la empresa no
No existen registros llenan los formularios
Registros e informes sin actualizados de los datos que correctamente
validacin de datos se precisan
No se tiene datos exactos de
la demanda de productos
Errores en la estimacin
Registros faltantes de salidas
Controles errneos de de compras
varias
cantidades existentes de Registros errneos de
productos con fallas de insumos y productos finales
almacn
234
ANEXO D
CRONOGRAMA
DE
ACTIVIDADES
235
12 ANEXO D CRONOGRAMA DE ACTIVIDADES
236
ANEXO E
COSTO
SOFTWARE
237
13 ANEXO E - COSTO SOFTWARE
Cotizacin realizada por Internet
Programa Lugar Costo ($us)

COSTO PERSONAL
PAGO A PROGRAMADORES
Segn investigaciones en varias empresas el pago para programadores es:
Tabla de costos de personal
Empresa Pago a Programador ($us)
En Bolivia 300
Cosmicdesign 350
Bolivia on line 250
Entonces el pago promedio de un programador es: Pago a programador = 300

$us
PAGO DE CONSULTORES O CAPACITORES
El pago bsico al personal de capacitacin segn varias empresas es:
Tabla de pago de consultores
Empresa Pago a Consultor ($us)
En Bolivia 45
Cosmicdesign 40
Bolivia on line 35
Fuente: Elaboracin propia]
238
Entonces el pago promedio de un capacitor es: Pago a Capacitor = 40 $us
PAGO SOPORTE TCNICO
El pago al personal de soporte tcnico es:
Tabla de pago de personal de soporte tcnico
Empresa Pago soporte ($us)
En Bolivia 40
Cosmicdesign 60
Bolivia on line 50
Entonces el pago promedio de soporte tcnico es: Soporte Tcnico = 50 $us
PAGO A MANTENIMIENTO A BASE DE DATOS
El pago al personal encargado de las bases de datos es:
Tabla Pago personal de mantenimiento de BD
Empresa Pago soporte ($us)
En Bolivia 70
Cosmicdesign 100
Bolivia on line 60
Entonces el pago promedio de mantenimiento de BD es: Pago a encargado de

mantenimiento de BD = 77 $us
239
ANEXO F
CUESTIONARIO
CUESTIONARIO
Con el presente cuestionario se determinara la facilidad que tiene el sistema
para los usuarios.
Evale del 1 al 10 el manejo del sistema tomando en cuenta los siguientes
parmetros:
1-4 Mala
240
5-6 Buena
7-10 Muy Buena
1.- El ingreso al sistema con su respectivo usuario y contrasea le resulto fcil.

1 2 3 4 5 6 7 8 9 10
2.- Cuando ingresa al sistema, tiene acceso a los mdulos del sistema que
usted requiere.
1 2 3 4 5 6 7 8 9 10
3.- El sistema le brinda la seguridad en los procesos que realiza.
1 2 3 4 5 6 7 8 9 10
4.- El men de los mdulos que tiene el sistema es fcil de entender.
1 2 3 4 5 6 7 8 9 10
5.- El proceso de registros nuevos es sencillo.
1 2 3 4 5 6 7 8 9 10
6.- Los mdulos a los que tiene acceso son comprensibles y fciles de manejar.
1 2 3 4 5 6 7 8 9 10
7.- Los mdulos del sistema son comprensibles.
1 2 3 4 5 6 7 8 9 10
8.- Como le parece la interaccin del sistema con el usuario.
1 2 3 4 5 6 7 8 9 10
9.- Los reportes e informes generados son correctos.
1 2 3 4 5 6 7 8 9 10
10.- El control de los empleados de la empresa es eficiente.
1 2 3 4 5 6 7 8 9 10
241

Blanca Carolina Ramos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Blanca Carolina Ramos

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDAD SALESIANA DE BOLIVIA

SISTEMA DE GESTIN PARA EL CONTROL DE LA COMERCIALIZACIN DE

CASO: DISTRIBUIDORA CRISURT

Postulante : Blanca Carolina Ramos Calle

Docente Gua : Lic. Carmen Rosa Mollinedo Laura

1.2.1 ANTECEDENTES DEL TEMA............................................................12

1.2.2 ANTECEDENTES INSTITUCIONALES.............................................13

1.2.3 ANTECEDENTES DE OTROS PROYECTOS DE GRADO...............14

1.3 PLANTEAMIENTO DEL PROBLEMA.....................................................17

1.3.1 DESCRIPCIN DEL MBITO DE ESTUDIO.....................................17

1.3.2 PROBLEMA CENTRAL......................................................................18

1.3.3 PROBLEMAS ESPECFICOS............................................................18

1.4.1 OBJETIVO CENTRAL........................................................................19

1.4.2 OBJETIVOS ESPECFICOS..............................................................20

1.5.1 JUSTIFICACIN SOCIAL..................................................................21

1.5.2 JUSTIFICACIN TCNICA................................................................21

1.5.3 JUSTIFICACIN PRCTICA.............................................................23

1.5.4 JUSTIFICACIN ECONMICA.........................................................23

1.6.1 APORTES DEL PROYECTO..............................................................24

1.6.2 APORTE ACADMICO.......................................................................25

1.7.1 DELIMITACION MODULAR...............................................................25

1.7.1.1 MDULO DE SEGURIDAD....................................................................25

1.7.1.3 MDULO DE COMPRAS Y ALMACENES.............................................26

1.7.1.4 MDULO DE VENTAS y GESTION DE CLIENTES potenciales...........26

1.8.1 MTODO DE DESARROLLO ORIENTADO A OBJETOS CON UML26

1.8.2 MTODO PARA PROBAR EL SOFTWARE.......................................27

1.8.2.1 PRUEBAS DE CAJA BLANCA...............................................................27

1.8.3.1 MODELO PARA LA GESTIN DE LA RELACIN CON LOS CLIENTES

1.8.3.2 MODELO ITERATIVO INCREMENTAL..................................................28

1.8.3.3 MODELO DE ESTIMACIN DEL PROYECTO......................................28

1.8.3.4 MODELO PARA EVALUAR LA CALIDAD DEL SOFTWARE.................29

1.8.4.1 TCNICAS PARA RECOLECTAR INFORMACIN...............................29

2 CAPTULO II: MARCO TERICO..........................................................31

2.1 INGENIERA DE SOFTWARE................................................................31

2.1.1 UNA VISIN GENERAL DE LA INGENIERA DE SOFTWARE.........32

2.2 PROCESOS, MTODOS Y HERRAMIENTAS.......................................32

2.3 SISTEMAS DE GESTIN.......................................................................37

2.3.1 ETAPA DE IDEACIN........................................................................38

2.3.2 ETAPA DE PLANIFICACIN..............................................................38

2.3.4 Etapa de Control.................................................................................39

2.4 METODOLOGAS, MODELOS Y TCNICAS EMPLEADAS.................39

2.4.1.1 MTODO DE DESARROLLO ORIENTADO A OBJETOS CON UML....39

2.4.1.1.1 DIAGRAMA DE CASOS DE USO.......................................................40

2.4.1.1.2 DIAGRAMA DE ACTIVIDADES...........................................................43

2.4.2 MTODO PARA PROBAR EL SOFTWARE.......................................47

2.4.2.1 PRUEBA DE CAJA BLANCA..................................................................47

2.4.2.1.1 Prueba del camino bsico...................................................................48

2.4.2.2 PRUEBA DE Caja negra.........................................................................51

2.4.3.1 MODELO DE GESTIN ORIENTADA AL CLIENTE (CRM)..................54

2.4.3.2 MODELO iterativo INCREMENTAL........................................................56

2.4.3.2.1 Fases del modelo.................................................................................58

2.4.4 MODELO DE ESTIMACIN DEL PROYECTO..................................60

2.4.4.1 COCOMO II.............................................................................................60

2.4.4.1.1 MTRICAS DE SOFTWARE...............................................................61

2.4.5 MODELO PARA EVALUAR LA CALIDAD DEL SOFTWARE.............66

2.4.5.1 CALIDAD DEL SOFTWARE...................................................................66

2.4.5.2 MODELO McCall.....................................................................................68

2.5.1 ARQUITECTURA CLIENTE-SERVIDOR...........................................75

2.5.1.1 MODELO DE CLIENTE LIGERO (THIN-CLIENT)..................................78

2.6 MARCO APLICATIVO.............................................................................78

2.6.1 MICROSOFT VISUAL STUDIO 2010.................................................78

2.7 Microsoft SQL Server 2008 R2 Enterprise..............................................79

2.7.1 SQL (Structured Query Language).....................................................79

2.7.2 Descripcin de SQL Server 2008.......................................................79