Sistema de Administración y Ventas para Importadora...

UNIVERSIDAD DEL BÍO-BÍO

FACULTAD DE CIENCIAS EMPRESARIALES

DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN

Y TECNOLOGÍAS DE LA INFORMACIÓN

Sistema de Administración y Ventas para

Importadora Villablanca

José Isaías Riquelme Sepúlveda

Hans Petter Villablanca Lagos

MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO DE EJECUCIÓN EN

COMPUTACIÓN E INFORMÁTICA

Chillán, Agosto 2010

Página 1

UNIVERSIDAD DEL BÍO-BÍO

FACULTAD DE CIENCIAS EMPRESARIALES

DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN

Y TECNOLOGÍAS DE LA INFORMACIÓN

Sistema de Administración y Ventas para

Importadora Villablanca

José Isaías Riquelme Sepúlveda

Hans Petter Villablanca Lagos

PROFESOR GUÍA : SRA. MARCELA PINTO.

PROFESOR INFORMANTE : SR. LUIS GAJARDO.

NOTA FINAL EXAMEN TÍTULO : _____________________________

MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO DE EJECUCIÓN EN

COMPUTACIÓN E INFORMÁTICA

Chillán, Agosto 2010

Página 2

Resumen

Importadora Villablanca, es una empresa con fines de lucro dedicada a la comercialización de

productos de librería, ferretería, juguetería, colchones y muebles. Con presencia en la ciudad de

Chillán, cuenta con una amplia cartera de clientes a lo largo de la provincia de Ñuble.

La empresa actualmente posee un sistema de escritorio operativo desde el 2009, el cuál evidencia una

serie de problemas, que se resumen en; lentitud en búsqueda de información de productos, inexistencia

de seguridad en la base de datos, inconsistencia en la base de datos, inconsistencia en la información,

además, inestabilidad en la ejecución de los diferentes módulos de la aplicación.

El objetivo principal de este proyecto es construir una aplicación que apoye la gestión de las áreas de

administración, ventas e inventario de la Empresa. Además, debe dar solución a los problemas

detectados mencionados anteriormente. El desarrollo se basa en la metodología incremental,

dividiéndose en dos incrementos, los que fueron evaluados por el administrador de la empresa. Se

utilizó el enfoque Orientado a Objetos (OO), el patrón de diseño Data Access Object (DAO) bajo la

arquitectura Modelo Vista Controlador (MVC).

Cómo conclusión de este proyecto se puede mencionar que los procesos operativos implementados en

el nuevo sistema redujo un 85% aproximadamente del tiempo de espera en buscar un producto, las

ventas minimizaron el tiempo de espera en un 66% aproximadamente, para las pre ventas se estima una

disminución de un 68% aproximadamente en el tiempo de espera. Además, cómo resultado el sistema

quedó en marcha blanca en la empresa.

Página 3

ÍndiceResumen.....................................................................................................................................................3Introducción General..................................................................................................................................9 Capítulo I: Descripción del problema y de la solución propuesta...........................................................11

1.1 Introducción..................................................................................................................................11 1.2 Análisis de la Organización..........................................................................................................12

1.2.1 Descripción General de la Organización..............................................................................12 1.2.2 Misión ..................................................................................................................................13 1.2.3 Visión....................................................................................................................................13 1.2.4 Clientes.................................................................................................................................13 1.2.5 Ventas....................................................................................................................................13 1.2.6 Competidores........................................................................................................................14 1.2.7 Recursos Humanos...............................................................................................................14 1.2.8 Organigrama.........................................................................................................................15 1.2.9 Definición de las Funciones de Interés.................................................................................15

1.3 Situación Actual del Sistema........................................................................................................18 1.3.1 Situación Informática Actual................................................................................................18 1.3.2 Situación actual de los procesos a tratar...............................................................................18

1.3.2.1 Gestión de productos ....................................................................................................18 1.3.2.2 Gestión de Ventas .........................................................................................................21

1.4 Problema.......................................................................................................................................21 1.5 Solución planteada.......................................................................................................................22

1.5.1 Descripción...........................................................................................................................22 1.5.2 Objetivo................................................................................................................................23 1.5.3 Requerimientos funcionales..................................................................................................24 1.5.4 Requerimientos no funcionales.............................................................................................25 1.5.5 Requerimientos técnicos para el desarrollo de la aplicación................................................25 1.5.6 Requerimientos Operacionales.............................................................................................26 1.5.7 Funciones del Sistema..........................................................................................................26

1.5.7.1 Requerimientos generales.............................................................................................27 1.5.7.1.1 Gestión de proveedores de la empresa..................................................................27 1.5.7.1.2 Gestión de producto de la empresa.......................................................................28 1.5.7.1.3 Gestión de categorías de la empresa.....................................................................28 1.5.7.1.4 Gestión de usuario para el sistema........................................................................29 1.5.7.1.5 Gestión de contraseña y accesos...........................................................................29 1.5.7.1.6 Realizar ventas......................................................................................................30 1.5.7.1.7 Realizar pre-ventas................................................................................................30 1.5.7.1.8 Gestión de informes..............................................................................................31 1.5.7.1.9 Realizar compras en el sistema.............................................................................31 1.5.7.1.10 Gestión de ventas de la empresa.........................................................................31 1.5.7.1.11 Gestión de compras de la empresa......................................................................32

1.5.8 Limitaciones del Proyecto....................................................................................................32 1.5.9 Metodología a utilizar...........................................................................................................33

CAPÍTULO II: Estudio de Factibilidad..................................................................................................35 2.1 Introducción a Estudio de Factibilidad........................................................................................35

Página 4

...........................................................................................................................................................352.2 Factibilidad Técnica......................................................................................................................36

2.2.1 Requerimientos técnicos para el desarrollo del Sistema .......................................................372.2.2 Requerimientos técnicos para la puesta en marcha...............................................................372.2.3 Características Comerciales del Software Requerido............................................................39

2.3 Factibilidad Operativa...................................................................................................................422.4 Factibilidad Económica.................................................................................................................43

2.4.1 Determinación de costos........................................................................................................432.4.1.1 Costos de Implementación e inversión..........................................................................43

2.4.2 Estimación de Ingresos o Beneficios.....................................................................................462.4.3 Determinación de Flujos Netos de Caja................................................................................47

2.5 Factibilidad de Fechas...................................................................................................................502.6 Factibilidad Política.......................................................................................................................502.7 Conclusiones Estudio de Factibilidad...........................................................................................51

Capítulo III: Descripción de la Metodología utilizada y de la herramientas de implementación...........52 3.1 Introducción..................................................................................................................................52 3.2 Metodología utilizando.................................................................................................................53

3.2.1 Orientación a Objetos...........................................................................................................53 3.2.1.1 Características de la programación orientada objetos...................................................53 3.2.1.2 Ventajas de la orientación a objetos..............................................................................54

3.2.2 UML.....................................................................................................................................55 3.2.3 Análisis Orientado a Objetos................................................................................................55

3.2.3.1 Casos de Uso.................................................................................................................56 3.2.3.2 Diagramas de Casos de Uso..........................................................................................56 3.2.3.3 Diagramas de Secuencia...............................................................................................57 3.2.3.4 Modelo Conceptual.......................................................................................................57

3.2.4 Diseño Orientado a Objetos..................................................................................................58 3.2.4.1 Diagramas de colaboración...........................................................................................58 3.2.4.2 Diagramas de Clases del Sistema.................................................................................59

3.2.5 Ciclo de desarrollo Modelo Incremental..............................................................................59 3.2.6 Arquitectura..........................................................................................................................60

3.2.6.1 Definición de las Capas................................................................................................61 3.2.7 Patrones de diseño................................................................................................................63

3.2.7.1 Patrón Data Access Object............................................................................................64 3.2.7.2 Patrón Transfer Object..................................................................................................65 3.2.7.3 Patrón Singleton............................................................................................................65 3.2.7.4 Controlador...................................................................................................................66 3.2.7.5 Bajo Acoplamiento .......................................................................................................66 3.2.7.6 Value Object..................................................................................................................67 3.2.7.7 Factoría Simple.............................................................................................................67 3.2.7.8 Fabricación Pura...........................................................................................................67

3.2.8 Modelo Vista Controlador....................................................................................................68 3.3 Herramientas a Utilizar................................................................................................................70

3.3.1 MySQL 5.0.45 .....................................................................................................................70 3.3.2 Ubuntu 10.4 (Lucide, núcleo Linux 2.6.32, con GNOME 2.30)..........................................71 3.3.3 Netbeans 6.8 ........................................................................................................................72 3.3.4 OpenOffice.org 3.2...............................................................................................................72

Página 5

3.3.5 SUN - java 6 – jre/jdk versión 6.20......................................................................................73 3.3.6 Dia 0.97.1.............................................................................................................................73

3.4 Conclusiones................................................................................................................................74 CAPÍTULO IV: Análisis.........................................................................................................................75

4.1 Comentarios Previos al Análisis ..................................................................................................76 4.1.1 Descripción de Casos de Uso Primer Incremento................................................................77

4.1.1.1 Descripción de Casos de Uso Gestionar Proveedor......................................................77 4.1.1.1.1 Caso de Uso: Ingresar Proveedor..........................................................................77 4.1.1.1.2 Caso de Uso: Modificar Proveedor.......................................................................78 4.1.1.1.3 Caso de Uso: Buscar Proveedor............................................................................79 4.1.1.1.4 Caso de Uso: Eliminar Proveedor.........................................................................80 4.1.1.1.5 Caso de Uso: Verificar Proveedor.........................................................................81

4.1.1.2 Descripción de Casos de Uso Gestionar Producto........................................................82 4.1.1.2.1 Caso de Uso: Ingresar nuevo Producto.................................................................82 4.1.1.2.2 Caso de Uso: Modificar Producto.........................................................................83 4.1.1.2.3 Caso de Uso: Buscar Productos............................................................................84 4.1.1.2.4 Caso de Uso: Eliminar producto...........................................................................85 4.1.1.2.5 Caso de Uso: Verificar producto...........................................................................86

4.1.1.3 Descripción de Casos de Uso Gestionar Categorías.....................................................87 4.1.1.3.1 Caso de Uso: Ingresar nueva Categoría................................................................87 4.1.1.3.2 Caso de Uso: Modificar Categoría........................................................................88 4.1.1.3.3 Caso de Uso: Buscar Categoría.............................................................................89 4.1.1.3.4 Caso de Uso: Eliminar Categoría..........................................................................90 4.1.1.3.5 Caso de Uso: Verificar Categoría..........................................................................91

4.1.1.4 Descripción de Casos de Uso Gestionar Usuario.........................................................92 4.1.1.4.1 Caso de Uso: Ingresar Usuario..............................................................................92 4.1.1.4.2 Caso de Uso: Modificar Usuario...........................................................................93 4.1.1.4.3 Caso de Uso: Buscar Usuario................................................................................94 4.1.1.4.4 Caso de Uso: Eliminar Usuario.............................................................................95 4.1.1.4.5 Caso de Uso: Verificar Usuario.............................................................................96 4.1.1.4.6 Caso de Uso: Cambiar Privilegio..........................................................................97

4.1.1.5 Descripción de Casos de Uso Gestionar Contraseña y acceso.....................................98 4.1.1.5.1 Caso de Uso: Cambiar contraseña.........................................................................98 4.1.1.5.2 Caso de Uso: Validar Usuario...............................................................................99

4.1.2 Diagrama de Secuencia del Sistema Primer Incremento....................................................100 4.1.2.1 Diagramas de Secuencia Gestionar Producto.............................................................100

4.1.2.1.1 Diagrama de Secuencia Ingresar Nuevo Producto..............................................100 4.1.2.1.2 Diagrama de Secuencia Modificar Producto.......................................................100 4.1.2.1.3 Diagrama de Secuencia Buscar Productos..........................................................101 4.1.2.1.4 Diagrama de Secuencia Eliminar producto.........................................................101 4.1.2.1.5 Diagrama de Secuencia Verificar producto.........................................................102

4.1.3 Descripción de Casos de Uso Segundo Incremento...........................................................103 4.1.3.1 Descripción de Casos de Uso Realizar Ventas............................................................103

4.1.3.1.1 Caso de Uso: Ingresar Pre-Venta.........................................................................103 4.1.3.1.2 Caso de Uso: Buscar Pre-Venta...........................................................................104 4.1.3.1.3 Caso de Uso: Agregar Producto..........................................................................105 4.1.3.1.4 Caso de Uso: Buscar Producto............................................................................106

Página 6

4.1.3.1.5 Caso de Uso: Eliminar Producto.........................................................................107 4.1.3.1.6 Caso de Uso: Finalizar Venta..............................................................................108 4.1.3.1.7 Caso de Uso: Realizar Pago Efectivo..................................................................109 4.1.3.1.8 Caso de Uso: Imprime Tickets............................................................................110

4.1.3.2 Descripción de Casos de Uso Realizar Pre-Ventas.....................................................111 4.1.3.2.1 Caso de Uso: Agregar producto...........................................................................111 4.1.3.2.2 Caso de Uso: Buscar producto............................................................................111 4.1.3.2.3 Caso de Uso: Verificar producto..........................................................................111 4.1.3.2.4 Caso de Uso: Eliminar producto..........................................................................111 4.1.3.2.5 Caso de Uso: Finalizar Pre-Venta........................................................................112 4.1.3.2.6 Caso de Uso: Imprime Tickets............................................................................113

4.1.3.3 Descripción de Casos de Uso Gestionar Informes......................................................114 4.1.3.3.1 Caso de Uso: Inventario Producto.......................................................................114 4.1.3.3.2 Caso de Uso: Informe Producto..........................................................................115 4.1.3.3.3 Caso de Uso: Informe Proveedores.....................................................................116 4.1.3.3.4 Caso de Uso: Informe Ventas..............................................................................117 4.1.3.3.5 Caso de Uso: Informe Comparativo Ventas........................................................118 4.1.3.3.6 Caso de Uso: Informe Monitoreo Usuario..........................................................119

4.1.3.4 Descripción de Casos de Uso Realizar Compras........................................................120 4.1.3.4.1 Caso de Uso: Ingresar Proveedor........................................................................120 4.1.3.4.2 Caso de Uso: Buscar proveedor .........................................................................121 4.1.3.4.3 Caso de Uso: Agregar producto..........................................................................121 4.1.3.4.4 Caso de Uso: Verificar producto.........................................................................121 4.1.3.4.5 Caso de Uso: Eliminar Producto.........................................................................121 4.1.3.4.6 Caso de Uso: Finalizar Compra..........................................................................122

4.1.3.5 Descripción de Casos de Uso Gestionar Ventas..........................................................123 4.1.3.5.1 Caso de Uso: Buscar Ventas................................................................................123 4.1.3.5.2 Caso de Uso: Mostrar Detalle Ventas..................................................................124 4.1.3.5.3 Caso de Uso: Anular Venta..................................................................................125

4.1.3.6 Descripción de Casos de Uso gestionar Compras.......................................................126 4.1.3.6.1 Caso de Uso: Buscar Compras............................................................................126 4.1.3.6.2 Caso de Uso: Mostrar Detalle Compras..............................................................127 4.1.3.6.3 Caso de Uso: Modificar Compra.........................................................................128

4.1.4 Diagramas de Secuencias del Sistema Segundo Incremento..............................................129 4.1.4.1 Diagrama de Secuencias Realizar Ventas...................................................................129

4.1.4.1.1 Diagrama de Secuencia Ingresar Pre-Venta........................................................129 4.1.4.1.2 Diagrama de Secuencia Buscar PreVenta............................................................129 4.1.4.1.3 Diagrama de Secuencia Agregar Producto..........................................................130 4.1.4.1.4 Diagrama de Secuencia Buscar Producto............................................................130 4.1.4.1.5 Diagrama de Secuencia Verificar Producto.........................................................131 4.1.4.1.6 Diagrama de Secuencia Eliminar Producto.........................................................131 4.1.4.1.7 Diagrama de Secuencia Finalizar Venta..............................................................132 4.1.4.1.8 Diagrama de Secuencia Realizar Pago Efectivo.................................................132 4.1.4.1.9 Diagrama de Secuencia Imprime Tickets............................................................133

4.2 Diagrama Modelo Conceptual....................................................................................................134 Capítulo V: Diseño................................................................................................................................135

5.1 Consideraciones previas al Diseño.............................................................................................135

Página 7

5.1.1 “Adopción y Adaptación” de Patrones...............................................................................135 5.1.1.1 Controlador + Singleton..............................................................................................136 5.1.1.2 DAO + Value Object...................................................................................................136 5.1.1.3 Factoría Simple...........................................................................................................136

5.2 Diagramas de Colaboración Primer Incremento........................................................................137 5.2.1 Diagramas de Colaboración Gestionar Producto...............................................................137

5.2.1.1 Diagrama de Colaboración Ingresar nuevo Producto.................................................137 5.2.1.2 Diagrama de Colaboración Modificar Producto.........................................................138 5.2.1.3 Diagrama de Colaboración Buscar Productos............................................................139 5.2.1.4 Diagrama de Colaboración Eliminar producto...........................................................140 5.2.1.5 Diagrama de Colaboración Verificar producto...........................................................141

5.3 Diagramas de Colaboración Segundo Incremento.....................................................................142 5.3.1 Diagrama de Colaboración Realizar Venta.........................................................................142

5.3.1.1 Diagrama de Colaboración Ingresar Pre-Venta...........................................................142 5.3.1.2 Diagrama de Colaboración Buscar Pre-Venta.............................................................143 5.3.1.3 Diagrama de Colaboración Agregar Producto............................................................144 5.3.1.4 Diagrama de Colaboración Eliminar Producto...........................................................145 5.3.1.5 Diagrama de Colaboración Finalizar Venta................................................................146 5.3.1.6 Diagrama de Colaboración Imprime Ticket................................................................147 5.3.1.7 Diagrama de Colaboración Realizar Pago Efectivo....................................................147

5.4 Diagrama de Clases....................................................................................................................148 6 Capítulo V: Pruebas............................................................................................................................149

6.1 Pruebas Funcionales...................................................................................................................149 6.1.1 Ingresar al sistema..............................................................................................................149 6.1.2 Ingresar Proveedor..............................................................................................................150 6.1.3 Eliminar un proveedor........................................................................................................151 6.1.4 Ingresar Producto................................................................................................................152 6.1.5 Eliminar Producto...............................................................................................................153 6.1.6 Ingresar nuevo usuario........................................................................................................154 6.1.7 Realizar Venta.....................................................................................................................155

Conclusiones..........................................................................................................................................156Bibliografía............................................................................................................................................159

Página 8

Introducción General

En la actualidad, la automatización de la información es fundamental para cualquier empresa

competitiva. Optimizar los recursos a través de la tecnología es el eje de un buen desarrollo económico.

De esta forma situaciones cotidianas como el envío de correos electrónicos, labores de oficina, buscar

información por la web e incluso encontrar y generar verdaderas redes sociales, dejan de manifiesto la

necesidad de comunicación del ser humano como también su interés por controlar y manejar la realidad

en que se desenvuelve.

Las organizaciones no están exentas de esta tendencia, “el mercado actual exige un alto nivel de

competitividad que lleva a las empresas a intervenir en tecnología que optimice sus procesos

productivos en los niveles de materia prima, recursos humanos y de información”.

Atendiendo a esta necesidad del mercado es que nos hemos insertado en la Empresa Importadora

Villablanca, tras un estudio de su realidad productiva se ha detectado deficiencias fundamentales a

saber:

• En el proceso de ventas, existe lentitud en la búsqueda de productos en el sistema actual, por lo

que conlleva a una calidad menor en la atención a los clientes.

• El sistema de Inventario, arroja errores en la información otorgada por el sistema, por mal

diseño de la base de datos, por lo cual, la empresa ha dejado inoperativo el uso de los

inventarios. de acuerdo a las necesidades actuales de la organización.

A partir de lo anterior este informe documenta cada uno de los pasos a seguir durante el desarrollo del

Sistema, el que fue concebido con el ciclo de vida Iterativo Incremental en base a dos elementos, que

serán detallados posteriormente. Con la finalidad de hacer clara su lectura, se ha estructurado de la

siguiente manera:

Página 9

Capítulo 1: Descripción del Problema y de la Solución propuesta. En este capítulo, se procederá a

describir la organización para la cual se desarrollará el Sistema, especificando las deficiencias

detectadas y las características generales de la solución propuesta.

Capítulo 2: Estudio de factibilidad. Tal como su nombre lo indica, en este capítulo se procede a evaluar

el proyecto en los ámbitos técnico, operacional, económico, temporal y político.

Capítulo 3: Descripción de la Metodología utilizada y de las Herramientas de implementación. Es el

marco teórico donde se describe toda la metodología y las herramientas de implementación a utilizar,

con la finalidad de permitir al lector comprender los capítulos posteriores.

Capítulo 4: Análisis. Se procede a especificar los casos de uso de los dos incrementos que abarcará el

Sistema. Se describen textualmente y se representan gráficamente a través de diagramas de casos de

uso y diagramas de secuencia del Sistema. Finalmente se ilustra el Diagrama de Modelo Conceptual del

Sistema.

Capítulo 5: Diseño. Aquí realiza el diseño Orientado a Objetos de los dos incrementos que abarcará el

Sistema. Se ilustran los diagramas de colaboración y el diagrama de Clases del Sistema, que una vez

culminados permiten dar paso a la etapa de implementación.

Capítulo 6: Pruebas. Se documenta la aplicación de las pruebas a las que fue sometido el Sistema

(pruebas de caja negra, de esfuerzo y de aceptación de usuario) en base a los casos de uso más

representativos.

Finalmente, se adjuntan anexos; diagramas de casos de uso, diagramas de secuencias, diagramas de

colaboración, diagramas de clases detallado, modelo de dato, pantallas del sistema.

Página 10

1 Capítulo I: Descripción del problema y de la solución propuesta

1.1 Introducción

En el presente capítulo se da a conocer la Empresa para la cual se desarrolla este proyecto, cuyo

objetivo es diseñar e implementar un sistema de Administración y Ventas, generado en base a las

deficiencias que se detectaron en su proceso productivo.

En una primera etapa, se explican los aspectos más importantes de cada proceso, identificando las

funciones más significativas que serán de interés para el desarrollo de este proyecto.

Posteriormente, se describe la situación del sistema con el cual se está operando, para dejar de

manifiesto los problemas a solucionar a lo largo de este trabajo e implementar las nuevas soluciones a

las necesidades detectadas en dicho análisis con el cliente, generando en las metodologías a seguir en el

desarrollo del proyecto

Página 11

1.2 Análisis de la Organización

1.2.1 Descripción General de la Organización

NOMBRE FICTICIO : Importadora Villablanca

NOMBRE LEGAL : John Albert Villablanca Lagos

GIRO : Grandes Tiendas

RUT : 13.577.796 – K

DOMICILIO LEGAL : Maipón #850

FONO – FAX : (042) – 221603

PERSONA CONTACTADA: Sr. John Villablanca

CARGO : Dueño y Administrador

CORREO ELECTRÓNICO : [email protected]

Importadora Villablanca, es una empresa dedicada a la comercialización de productos importados y

nacionales, para el Hogar, Construcción y Deportes, enfocado en un segmento rural y urbano. Se

encuentra ubicada en calle Maipón #850, Chillán.

Se trata de una empresa catalogada como PYME (Pequeña y Mediana Empresa, de acuerdo a los

volúmenes de ventas), que compite con empresas de similares características y con el sector retail de la

ciudad de Chillán, aprovechando la ubicación en la que se encuentra instalada, tratando de aprovechar

al máximo al público que transita por dicho sector, el cual tiene como objetivo captar al público que

busca calidad y lo más cercano al terminal rural.

En el año 2009, la empresa decidió iniciar su participación en el mercado de Chillán en el sector del

terminal rural “La Merced”, al mismo tiempo abarcar al máximo las necesidades del mercado en que se

encuentra ubicado.

Página 12

1.2.2 Misión

“La misión de Importadora Villablanca es ofrecer a todos nuestros clientes excelencia en el servicio,

proporcionando diversidad de productos a los mejores pecios del mercado, logrando así, satisfacer

todas sus necesidades”

1.2.3 Visión

“La visión de Importadora Villablanca es lograr ser una empresa líder a nivel regional en la

comercialización de productos innovadores y con los precios más competitivos del mercado”

1.2.4 Clientes

La empresa recibe en promedio a 300 clientes diariamente, entre ellos el 70% corresponde a personas

de diversas zonas rurales, el 25% provienen de la zona urbana y un 5% de empresas e instituciones.

1.2.5 Ventas

Estas fluctúan cerca de un millón de dólares anuales, de los cuales se dividen en distintos sectores

como; gasfitería, juguetería, deportes, plásticos, textil, aluminio, vajillas, siendo los más participativos,

mueblería, ferretería y librería. Además, cabe señalar que el stock diario de salida es de 1.783 productos

en promedio.

Página 13

La importadora contiene una cantidad de 4.525 tipos de productos, donde el 25% corresponde a

librería, el 25% a ferretería/gasfitería y el 50% en los otros sectores. En librería y ferretería/gasfitería se

concentra un margen de utilidad de un 50%, siendo estos los más rentables del negocio, debido a, que

la mayoría de los productos son importados y consolidan a la empresa.

1.2.6 Competidores

Entre los principales competidores, se encuentran las empresas “El Campesino” (ex-Rey de la Luca) e

“Importadora Panamá”. Ambas se abocan a las mismas actividades de Importadora Villablanca,

teniendo una ventaja competitiva en el segmento rural, por la ubicación en que se encuentran.

1.2.7 Recursos Humanos

El equipo de trabajo está formado por 12 personas todos con contratos indefinidos, que desarrollan

distintas funciones en la empresa; un administrador, un jefe de Sala, dos encargados de áreas, dos

cajeros y siete vendedores.

El personal se encuentra capacitado y formado para entregar un servicio de calidad, se ejercen técnicas

de motivación como bonos, incentivos y remuneración superior a la del mercado. El trabajo se

desarrolla en un ambiente laboral agradable, una fluida comunicación entre el Administrador y el

personal.

Página 14

1.2.8 Organigrama

La ilustración 1, muestra el organigrama de Importadora Villablanca.

1.2.9 Definición de las Funciones de Interés

Las funciones necesarias para llevar a cabo las operaciones en esta organización, se desarrollan con

sistemas que se encargan de dichas funciones. Sin embargo, no resultan ser del todo eficiente para sus

necesidades reales. Es por esto que el Administrador se ha interesado en revertir la situación en que se

encuentran, solicitando un análisis profundo de los aspectos más críticos a la hora de determinar la

productividad del personal, la calidad de la atención a los clientes y en ayuda a la gestión de la

administración.

El Administrador ha puesto a disposición toda la información necesaria para poder llevar a cabo un

análisis de todos los procesos, con el único objetivo de establecer las bases para plantear algunas

soluciones, de esta manera, se mencionarán los factores de los puntos críticos que inciden en la

productividad de la Importadora Villablanca.

Página 15

Ilustración 1: Organigrama de Importadora Villablanca

Productividad del personal:

Ante todo, la capacidad del trabajo depende de una serie de factores, entre los cuales se cuentan el

grado medio de destreza del personal y el nivel de progreso de las tecnologías a utilizar en la

organización, esto queda de manifiesto en el siguiente desglose.

• La cantidad de tiempo invertido en realizar una pre-venta, generar un tickets puede llegar a

superar los 15 minutos.

• Además, el cajero debe volver a ingresar los productos al sistema para realizar la venta,

invirtiendo la misma cantidad de tiempo que la pre-venta, generando un atraso en la atención de

los clientes que desean cancelar.

• Los informes se deben manipular para las tomas de decisiones de la empresa, incurriendo en un

tiempo de más de 30 minutos.

Es por eso que para elevar la productividad de la empresa es necesario economizar tiempo y trabajo del

personal vale decir, desarrollar las actividades en un menor tiempo para mejorar la eficiencia y

competitividad.

Calidad de la atención a los clientes:

La calidad de la atención a los clientes, se enfoca en satisfacer sus necesidades reales, con eficiencia y

eficacia en la atención, generando así una actitud positiva de estos hacia la empresa, lo que se

demuestra en términos de re-compra y/o recomendación. En estos momentos, los puntos críticos que

afectan directamente este ítem son:

• Demora en la consulta de stock.

• Precio de productos.

• Tiempo de 5 minutos al realizar una venta en la caja, generando filas de clientes a la espera de

ser atendidos.

Página 16

En la actualidad, la "satisfacción del cliente" se encuentra en un nivel medio, con un 87% de

cumplimiento de las expectativas a cumplir a los Clientes.

Gestión de la administración:

La Gestión de la Administración, se refiere al uso de la información en la empresa, mientras el nivel

más bajo de la organización requiere información interna de tipo histórico. Para realizar estos tipos de

análisis se requiere invertir tiempo para la corrección de los informes confeccionados en el sistema

actual, tales como:

• Inventario de productos.

• Informe de productos.

• Informe de proveedores.

• Informe de ventas.

• Monitoreo usuario.

• Informe comparativo de ventas.

• Informe producto bajo stock crítico.

• Valor comparativo de producto.

Página 17

1.3 Situación Actual del Sistema

1.3.1 Situación Informática Actual

• Software de gestión:

Software de Gestión y negocios (BOSS): Aplicación desarrollada con FiveWin y

xHarbour con base de datos Access.

• Software Ofimática:

Microsoft Office 2003, utilizado ampliamente como complemento al software de

gestión actual.

Firefox para el uso del correo electrónico.

• Equipos Computacionales:

En la actualidad, Importadora Villablanca consta con seis computadoras, de las cuales,

dos se ocupan cotidianamente en las cajas, una en el caso que la demanda sea alta, otra en

recepción, en la oficina del Administrador, las que ocupan como sistema operativo

Microsoft Windows XP Profesional, a excepción del servidor que utiliza Linux.

1.3.2 Situación actual de los procesos a tratar

1.3.2.1 Gestión de productos

Cabe señalar, que para satisfacer la demanda de sus clientes, Importadora Villablanca mantiene un

stock en promedio de 280.000 productos. Que son comercializados con 75 proveedores a nivel

nacional. A continuación un resumen de proveedor versus productos.1

1 Algunos productos son vendidos por más de un proveedor.

Página 18

Ilustración 2: Cantidad de producto por proveedor

Proveedores Cant Proveedores CantA.W. FABER-CASTELL CHILE 43 INDUSTRIAL Y COMERCIAL SA 46AMADO FELIPE EL HAYEECK Y 3 INV. JONG BOR LTDA. 176AMERICA IMPORTS LTDA 90 INVERSIERRA S.A. 86ANGELICA ZEPEDA HENRIQUEZ 18 JIMENEZ Y CIA. LTDA. 9ARIRANG S.A. 132 JOHN VILLABLANCA LAGOS 123CECILIA ALEJANDRA ARAYA S 3 JUAN CARLOS SANTOS SEPULV 9CECOSUD RETAIL S.A. 1 JUAN CARLOS ZALAZAR 7CLAUDIO ROMERO GACITUA 2 JUAN RODRIGUEZ 5COMERCIAL DORAL S.A. 13 JULIO CESAR CRUZ MEDINA 11COMERCIAL E IMPORTADORA D 151 LIBESA S.A. 256COMERCIAL E INDUSTRIAL JA 11 LUIS OSSES VISTOZO 2COMERCIAL ESPUNYTEX LTDA. 11 MACETERO PLASTICO SOCIEDA 15COMERCIAL GONZALEZ Y MONR 16 MANUALIDADES ROCA LTDA 28COMERCIAL IMPOGAR LTDA 53 MARIBEL DE LAS MERCEDES C 91COMERCIAL LEVANI LTDA 40 MAURICIO EDURDO ALEGRIA V 31COMERCIAL SCHMIDT Y CIA L 11 MAURICIO KISHINEVSKY ROSE 136COMERCIALIZADORA ORIENTE 2 MIGUEL ANGEL HERRERA RUIZ 53CRISTALERIAS TORO S.A.I.C 4 MIRIAM DEL CARMEN MALVERD 4DOMINGO ANTONIO SEPULVEDA 2 MONICA JUDITH CATALAN MUÑ 8ELIAS MAZU Y CIA. LTDA. 21 MY PLASTIC LTDA 2EMILIO SANDOVAL POO S.A. 3 NEW HOME LTDA. 121ENLOZADOS CONDOR S.A. 44 ORBITAL S.A. 95EVA CORINA DAHMEN BONILLA 66 PATRICIO ANTONIO TAPIA PR 6FALABELLA RETAIL S.A. 2 PRONOBEL S.A. 300FRANCISCO ELIAS ALLES ARA 9 PROVEEDORES INTEGRALES DE 293GISELA LORENA CUEVAS TOLO 6 QUIMICA Y ADHESIVOS PATEL 21GOLDZWEIG Y ORTEGA LTDA 8 RODRIGO ADOLFO AZOCAR GAR 78GREGORIO GONZALEZ ORTEGA 16 RO-ROPLAST SA 49IMP Y EXP ASIA-LATAM LTDA 15 SERVICIOS HIDROELECTRICO 9IMP. D"ASSTI S.A. 113 SOC COM MARISIO HNAS LTDA 14IMPORTADORA ANDRETTI TRAD 32 SOC COMERCIAL E INDUSTRIA 2IMPORTADORA MALIK LTDA 60 SOC INDUSTRIAL COMERCIAL 69IMPORTADORA MIRTEX LTDA 97 SOCIEDAD COMERCIAL BLUE M 281IMPORTADORA ROURKE Y KUSC 59 SOCIEDAD IMPORTADORA Y E 32IMPORTADORA SANTA ELENA L 85 SOCIEDAD INDUSTRIAL SCHUL 8IMPORTADORA VICTORIA S.A. 174 SURTI VENTAS LTDA 28IMPORTADORA Y EXPORTADORA 156 TEC HARSEIM LTDA 52XIMENA LORETO RODRIGUEZ R 41 SIN CLASIFICACIÓN 460

SUMATORIA 4629

Las características de los productos son; códigos de barras, código de proveedor (más de 1 en algunos

casos), costo y precio de venta. Por otro lado, existe un código padre, en dónde, un producto está

asociado a otro.

La situación actual con que se llevan a cabo los procesos son de interés para el desarrollo de este

proyecto.

Para realizar dichas tareas relacionadas con la gestión de productos, se cuenta con un sistema de

inventario. El cual permite visualizar los productos en el sistema, en donde algunos productos se

transforman en inactivos automáticamente, los que en el momento de venderlos no son encontrados.

Dicho sistema funciona de manera deficiente, manteniéndose en forma independiente al sistema de

ventas con el de inventario, lo que conlleva a una pérdida de datos por las inconsistencias de los

procesos internos del sistema.

A la hora de ingresar un producto, mientras existan dos terminales abiertos en el Módulo Ingresar

Productos, se produce un enlazamiento entre ellos, lo que ocasiona, duplicidad de código e inclusive

precio, ocasionando un grave problema en el inventario.

En el momento, mientras un empleado necesite buscar información de un producto en el sistema de

ventas e inventario, incurre en un gran tiempo de búsqueda en la base de datos del sistema asociado, ya

sea para buscar stock y precio o para vender los productos sin saber los códigos, tienen que buscar por

su descripción y el sistema actual no puede hacer un filtro de tal manera que la búsqueda sea más

rápida y expedita. El tiempo que demora, desde que seleccionó buscar hasta recibir la respuesta en

pantalla es de 32 segundos aproximadamente, esta demora causa una pérdida de ventas muy notoria en

días de alta demanda.

Página 20

1.3.2.2 Gestión de Ventas

Para realizar una venta, el vendedor realiza el siguiente proceso: hace una simulación o cotización de

venta que será llevada a la caja. Luego el cajero ingresa los códigos y cantidades de productos que

están en la simulación, lo que conlleva unos dos minutos aproximadamente si la lista es extensa lo que

implica una tardanza en la atención del cliente.

Cuándo se realiza una venta en un momento dado, el número del documento tiene el mismo folio de

uno anulado, ocasionando un grave problema en el inventario e informes de gestión de la empresa.

1.4 Problema

En base a lo expuesto anteriormente, se puede detectar los siguientes problemas:

• Las Deficiencias del Sistema actual

A) El sistema de inventario y venta, que posee actualmente la Importadora Villablanca,

presenta algunos problemas de modelamiento de la Base de Datos y defectos en el diseño.

B) El sistema actual, no se pudo ajustar al 100% a las necesidades de la empresa, tales como:

Problemas con la seguridad de los datos, estos al ser procesados generan una mala

información o en su efecto duplica los datos, se hizo referencia en el punto 1.3.2

(Gestión de los Productos, Gestión de Ventas). Por lo estudiado, el Administrador no

considera seguro el sistema actual, al no satisfacer las necesidades a cabalidad debido a

que, se pierde la conexión con el servidor abruptamente mientras es utilizada por algún

empleado, debiendo configurarlo cada vez que sucede dicho problema, perdiendo así las

ventas u operaciones que se está realizando en un momento dado. Estas deficiencias, son

provocadas por las inconsistencias que se han reflejado en el Inventario Final.

Página 21

• Desaprovechamiento de los recursos hardware y software con que cuenta la empresa: En

la Importadora Villablanca existe una cantidad de 6 computadores, algunos de ellos sólo se

ocupan para ver los productos/stock, procesamiento de texto, planillas, correo electrónico y

navegación por la web, los que son desaprovechados de manera considerable para el potencial

existente en los recursos hardware y software con que cuenta la empresa. Dos computadores

hacen una absoluta participación del proceso de ventas, pues los demás sólo se utilizan para

consultas de productos.

Por otro lado, al generar informes de gestión, estos entregan información errónea, debido a la

inconsistencia que existe en los datos. Lo que implica incurrir en tiempo extraordinario de trabajo en la

administración de la empresa.

1.5 Solución planteada

1.5.1 Descripción

Importadora Villablanca desea aprovechar al máximo las capacidades de los recursos con que cuentan

actualmente. Los recursos son determinantes para poder idear la solución factible a dicha organización,

ya que se sabe de ante mano, las condiciones en que se encuentra para la construcción de un nuevo

sistema. En el Capítulo II de este informe, se hará un Estudio de la Factibilidad Técnica de este

Proyecto.

La solución planteada al problema en que se encuentra la Importadora Villablanca, consiste en

implementar un nuevo sistema computacional para reemplazar el sistema actual, que le permita al

personal realizar ventas de manera eficiente, obtener informes reales para la gestión de la

administración. En los procesos se pretende otorgar interacción entre inventario, ventas y gestión de la

Administración. La aplicación será de escritorio y estará instaladas en los distintos terminales de

ventas, cajas y administración de la organización. Esta aplicación permitirá que los procesos se lleven a

cabo sólo en las dependencias de la empresa y tendrán la opción de imprimir los tickets de ventas, pre

Página 22

ventas e informes para la gestión de la administración. Con la solución planteada, se pretende obtener

una mayor utilidad de los recursos computacionales que existen en la Importadora. Así, se otorgará al

personal de la empresa herramientas automatizadas más eficaces para el desarrollo de los procesos de

ventas, obteniendo luego una mejora en la gestión para la organización, para la toma de decisiones, en

el control de inventario y en una atención de calidad a sus clientes.

1.5.2 Objetivo

Implementar un sistema totalmente nuevo, que integre los módulos de ventas, pre ventas, provedores y

los productos, con una base de datos segura. La motivación de este proyecto es el desarrollo de un

software base, cuya documentación sea útil para incorporar nuevas funcionalidades con un mínimo de

implementación para versiones posteriores a la entrega de este proyecto.

El sistema debe cumplir con las siguientes características:

• Contar con un módulo de ventas integrado con el módulo de inventarios

• Debe contemplar una interfaz atractiva, fácil de mantener y operar, con accesos rápidos por

teclado.

• Rapidez en la búsqueda de productos para las ventas.

• Implementar un reporte de monitoreo de eventos realizados por los distintos usuarios;

vendedores y cajeros.

• Generar reportes de inventario valorizado.

• Generar reporte de ventas y pre ventas.

• Generar reporte de proveedores.

• Generar reporte de detalle de productos.

• Crear perfiles de usuarios, para permitir la confidencialidad de la información al momento de

acceder a ella.

Página 23

• Disponer de una base de datos segura y confiable.

• Los tiempos de respuestas del sistema no deben exceder los 3 segundos como máximo para

búsqueda de productos.

1.5.3 Requerimientos funcionales

Los requerimientos funcionales son definiciones de los servicios que proveerá el sistema, la forma en

que reaccionará ante las entradas y cómo se comportará ante situaciones particulares. En algunas

ocasiones también es importante destacar las restricciones del sistema.

Los requerimientos funcionales detectados para la aplicación a construir se determinan en base a los

objetivos del proyecto expuestos en el punto anterior.

• Debe contar con un módulo de ventas, el cual tiene que estar integrado al módulo de inventario,

permitiendo así poder consultar automáticamente sobre un producto, permitir realizar descuento

previamente autorizados, realizar ventas guardando los registros con la cantidad de productos,

descripción, valor, subtotal, total de la venta, el nombre del vendedor que realizó la venta y la

impresión del ticket.

• Debe contar con un módulo para generar informes de ventas, productos e inventarios para la

gestión administrativa de la empresa.

• Implementar un reporte en apoyo a la toma de decisiones, con el propósito de justificar las

compras a otros proveedores.

• Implementar un reporte de monitoreos, dónde se registrarán todos los eventos realizados por los

usuarios, para su posterior revisión.

• Contar con un módulo de pre-venta, consiste en tener una lista de productos que desea comprar

y al efectuar la venta ingresar el código de la pre-venta.

Página 24

1.5.4 Requerimientos no funcionales

Estos requerimientos especifican las restricciones de los servicios ofrecidos por la aplicación a

construir. Su detalle se muestra a continuación:

• La aplicación deberá proveer una interfaz atractiva a los usuarios, además de ser intuitiva, para

permitir su fácil operación.

• Crear perfiles de usuario, para permitir la confidencialidad de la información al momento de

acceder a ella.

• Disponer de una base de datos segura y confiable.

• El tiempo de respuesta al utilizar el sistema no debe exceder los 3 segundos como máximo para

cualquier operación.

1.5.5 Requerimientos técnicos para el desarrollo de la aplicación

• La aplicación debe correr bajo dos ambientes, Windows XP Profesional en el computador de la

oficina y en las cajas principalmente con Ubuntu.

• La aplicación debe construirse con tecnología Java, utilizando como IDE Netbeans y como

motor de base de datos MySQL. Todo esto bajo el sistema operativo Ubuntu Versión 10.04, con

kernel 2.6.32

• Para la construcción del sistema, es necesario un equipo computacional con las siguientes

características: Procesador: Pentium Dual-core 2.00 Ghz, Memoria Ram: 2GB, Disco Duro:

Sata 80 GB, Ubuntu 10.04 kernel 2.6.32, Entorno de Desarrollo NetBeans IDE 6.8.

Página 25

1.5.6 Requerimientos Operacionales

En esta etapa se presentan los requerimientos operacionales, éstos son aquellos que permiten definir los

tipos de perfiles de usuarios que utilizarán el software con los privilegios necesarios.

• Administrador: Es quien administrará la aplicación, con todo los privilegios otorgados.

• Vendedores: Podrán realizar pre-ventas, ver los productos (stock y precio).

• Cajeros: Podrán realizar ventas, pre-ventas y visualizar los productos (stock, precio y

descuentos).

1.5.7 Funciones del Sistema

En las funciones del sistema se listan los requerimientos funcionales y no funcionales más importantes

del sistema de administración y ventas de importadora Villablanca. Los requisitos consisten en

encontrar lo que se necesita realmente, de manera que tenga un significado claro para el cliente y los

miembros del equipo de desarrollo.

Los requerimientos se clasifican en las siguientes categorías según:

• Evidente: Debe realizarse y el usuario debe saber qué está realizando.

• Oculta: Debe realizarse, aunque no es visible para los usuarios. Esto se aplica a muchos

servicios técnicos subyacentes, como guardar información de un mecanismo persistente de

almacenamiento. Las funciones ocultas a menudo se omiten (erróneamente) durante el proceso

de obtención de requerimientos.

Página 26

Para mayor claridad, los requerimientos se han agrupado en la siguiente tabla:

1.5.7.1 Requerimientos generales

Referencia Función Categoría

R.1 Gestión de proveedores de la empresa. Evidente

R.2 Gestión de producto de la empresa. Evidente

R.3 Gestión de categorías de la empresa. Evidente

R.4 Gestión de usuario para el sistema. Evidente

R.5 Gestión de contraseña y accesos Evidente

R.6 Realizar ventas. Evidente

R.7 Realizar pre-ventas Evidente

R.8 Gestión de informes de la empresa Evidente

R.9 Realizar compras Evidente

R.10 Gestión de ventas de la empresa. Evidente

R.11 Gestión de compras de la empresa. Evidente

Tabla 1: Requerimientos generales

1.5.7.1.1 Gestión de proveedores de la empresa


R.1.1 Ingresar un nuevo proveedor en el sistema. Evidente

R.1.2 Modificar un proveedor registrado en el sistema. Evidente

R.1.3 Buscar un proveedor registrado en el sistema. Evidente

R.1.4 Eliminar un proveedor registrado en el sistema. Evidente

R.1.5 Verificar un proveedor registrado en el sistema Oculto

Tabla 2: Requerimiento: Gestión de proveedores de la empresa

Página 27

1.5.7.1.2 Gestión de producto de la empresa


R.2.1 Ingresar un nuevo producto en el sistema. Evidente

R.2.2 Modificar un producto registrado en el sistema. Evidente

R.2.3 Buscar un producto registrado en el sistema. Evidente

R.2.4 Eliminar un producto registrado en el sistema. Evidente

R.2.5 Verificar un producto registrado en el sistema Oculto

Tabla 3: Requerimiento: Gestión de producto de la empresa.

1.5.7.1.3 Gestión de categorías de la empresa


R.3.1 Ingresar una nueva categoría en el sistema. Evidente

R.3.2 Modificar una categoría registrada en el sistema. Evidente

R.3.3 Buscar una categoría registrada en el sistema. Evidente

R.3.4 Eliminar una categoría registrada en el sistema. Evidente

R.3.5 Verificar una categoría registrada en el sistema Oculto

Tabla 4: Requerimiento: Gestión de categorías de la empresa

Página 28

1.5.7.1.4 Gestión de usuario para el sistema


R.4.1 Ingresar un nuevo usuario al sistema Evidente

R.4.2 Modificar un usuario registrado en el sistema Evidente

R.4.3 Buscar un usuario registrado en el sistema Evidente

R.4.4 Eliminar un usuario registrado en el sistema Evidente

R.4.5 Verificar un usuario registrado en el sistema Oculto

R.4.6 Cambiar Privilegio a un usuario Evidente

Tabla 5: Requerimiento: Gestión de usuario para el sistema

1.5.7.1.5 Gestión de contraseña y accesos


R.5.1 Cambiar contraseña a un usuario Evidente

R.5.2 Validar a un usuario registrado Oculto

Tabla 6: Requerimiento: Gestión de contraseña y accesos

Página 29

1.5.7.1.6 Realizar ventas


R.6.1 Ingresar pre-venta Evidente

R.6.2 Buscar pre-venta Evidente

R.6.3 Agregar producto a vender Evidente

R.2.3 Buscar producto a vender Evidente

R.2.5 Verificar producto a vender Oculto

R.6.4 Eliminar producto a vender Evidente

R.6.5 Finalizar venta Evidente

R.6.6 Realizar pago efectivo Evidente

R.6.7 Imprime tickets de venta Oculto

Tabla 7: Requerimiento: Gestión de ventas

1.5.7.1.7 Realizar pre-ventas


R.6.1 Agregar producto a vender Evidente

R.2.3 Buscar producto a vender Evidente

R.2.5 Verificar producto a vender Oculto

R.6.6 Eliminar producto a vender Evidente

R.7.1 Finalizar pre-venta Evidente

R.7.2 Imprime tickets de pre venta Oculto

Tabla 8: Requerimiento: Gestión de pre-ventas

Página 30

1.5.7.1.8 Gestión de informes


R.8.1 Informe de inventario de producto Evidente

R.8.2 Informe de productos Evidente

R.8.3 Informe de proveedores Evidente

R.8.4 Informe de ventas Evidente

R.8.5 Informe de comparativo de ventas con año anterior. Evidente

R.8.6 Informe de monitoreo de usuario Evidente

Tabla 9: Requerimiento: Gestión de informes

1.5.7.1.9 Realizar compras en el sistema


R.9.1 Ingresar proveedor Evidente

R.1.3 Buscar proveedor Evidente

R.6.1 Agregar Producto Evidente

R.2.3 Buscar Producto Evidente

R.2.4 Eliminar Producto Evidente

R.9.2 Finalizar Compra Evidente

Tabla 10: Requerimiento: Realizar compras

1.5.7.1.10 Gestión de ventas de la empresa.


R.10.1 Buscar ventas Evidente

R.10.2 Mostrar detalle ventas Evidente

R.10.3 Anular ventas Evidente

Tabla 11: requerimiento: Gestión de ventas

Página 31

1.5.7.1.11 Gestión de compras de la empresa.


R.11.1 Buscar compra Evidente

R.11.2 Mostrar detalle compra Evidente

R.11.3 Modificar compra Evidente

Tabla 12: requerimiento: Gestión de compras

1.5.8 Limitaciones del Proyecto

En el alcance del proyecto se ha acotado por motivos de tiempo de desarrollo de nuestra memoria y los

puntos fueron mencionados anteriormente. Se han seleccionado los procesos del sistema de

administración y ventas por considerarse los más críticos en la actualidad por el Administrador. Así de

esta manera, el sistema se limitará a lo relacionado con:

• Productos; despacho de productos a otra sucursal, generar códigos de barra, impresión de

códigos de barra.

• Clientes; cuenta corriente.

• Proveedores; cuenta corriente.

• Migración de datos.

Página 32

1.5.9 Metodología a utilizar

En el desarrollo del sistema a construir, se adoptará la metodología incremental con un enfoque

orientado a objetos.

El modelo de proceso incremental, combina elementos del modelo en cascada aplicados de forma

iterativa. Este modelo se aplica de manera escalonada como avanza en el tiempo. En cada secuencia se

producen incrementos de software. Así, se permite que los desarrolladores alcancen un alto nivel de

abstracción, concentrándose sólo en pequeñas partes del sistema, reservando los demás aspectos para

entregas posteriores, lo cual es una forma de reducir considerablemente los riesgos. Por lo tanto, el

desarrollo incremental permite construir un sistema agregando subconjuntos de requerimientos del

mismo.

El modelo nos ayuda a tener una activa participación del usuario, la que permite que cada avance

realizado se cumpla según sus necesidades y que el sistema se construya en forma correcta.

El tamaño del proyecto es grande y el cliente desea que los tiempos de desarrollo no sean extensos.

Al ser de carácter incremental nos permite acordar con el cliente las funcionalidades que tienen una

mayor prioridad para él; para de alguna manera garantizar el producto y someterlo a una mayor

cantidad de pruebas a lo largo de todos los incrementos, lo cual permitiría bajar la tasa de errores en

estas funcionalidades primordiales.

Con esto, más la activa participación de los usuarios, se logrará una retroalimentación que permitirá

verificar el cumplimiento de los objetivos requeridos, minimizando de manera considerable los riesgos

del proyecto.

Página 33

La entrega final del proyecto se hará en base a dos incrementos, con la metodología expuesta. El primer

incremento, en grandes rasgos, tendrá relación con las ventas e inventario. El segundo, sobre la gestión

de los informes y consultas.

Para mayor detalle sobre la metodología, revisar el capítulo III, correspondiente a la Descripción de la

metodología utilizada y de las herramientas de implementación.

Página 34

2 CAPÍTULO II: Estudio de Factibilidad

2.1 Introducción a Estudio de Factibilidad

Una vez ya definida la solución propuesta, ésta debe ser evaluada en base a distintos aspectos, para

dilucidar qué tan factible y viable es la construcción de un nuevo sistema. Es así, como en esta sección

se llevará a cabo un estudio de factibilidad de la solución planteada en el capítulo anterior, cuya

finalidad es determinar si es realizable y conveniente en todos los aspectos para ser implementada con

éxito en la organización. Dichos aspectos son los siguientes:

• Técnico : Proporciona la información referente a los recursos hardware y software

necesarios.

• Operacional : Determina el impacto del funcionamiento del nuevo sistema dentro de la

organización.

• Económico : Determina el costo en que se incurrirá al desarrollar y poner en marcha el

sistema.

• Fechas : Proporciona información sobre el tiempo que toma realizar el proyecto y

si éste está acorde con las necesidades de la organización.

• Político : Determinará en qué grado las políticas de la organización permitirán el

desarrollo y uso del sistema.

El éxito del proyecto estará entonces determinado por el grado de factibilidad que presente en cada uno

de los cinco ítems mencionados anteriormente.

Página 35

2.2 Factibilidad Técnica

Determina si el equipamiento actual con que cuenta la organización permite la realización del proyecto.

Además, al no contar con lo necesario para el desarrollo del proyecto, está la posibilidad de incorporar

nuevos recursos hardware y/o software.

Para desarrollar e implantar el sistema es necesario contar con el siguiente equipamiento:

Cantidad Descripción

1 Estación de trabajo para el desarrollo del sistema.

1 Servidor, que alojará la base de datos y la aplicación.

2 Estación de trabajo donde se ejecutará la aplicación de ventas

2 Estación de trabajo donde se ejecutará la aplicación de pre-ventas

1 Estación de trabajo donde se ejecutará la aplicación para la recepción de mercaderías

1 Estación de trabajo donde se ejecutará la aplicación para la administración

4 Lector de código de barras (uno por cada estación de trabajo)

1 Switch

3 Impresora Térmica De Tickets

Tabla 13: Equipamiento necesario para el desarrollo y puesta en marcha del Sistema.

Página 36

2.2.1 Requerimientos técnicos para el desarrollo del Sistema

Estación de trabajo para el Desarrollo

Hardware (Requerimientos mínimos) Software

• Procesador: Intel Centrino Duo 1.5

GHz

• Memoria RAM: 1GB

• Disco Duro: SATA-80 GB

• Tarjeta de red: 10/100 Mbps

• Tarjeta de video 31Mb

• Ubuntu 10.4 (Lucide, núcleo Linux 2.6.32,

con GNOME 2.30)

• SUN - java 6 - JDK

• MySQL 5.0.45

• Administrador MySQL (MySQL-Admin)

versión 5.0 r14 Ubuntu

• Netbeans 6.8

• OpenOffice.org 3.2

• Dia 0.97.1

Tabla 14: Requerimientos técnicos estación de trabajo para el desarrollo.

2.2.2 Requerimientos técnicos para la puesta en marcha

Servidor


• Procesador: Intel Centrino Duo 1.5 GHz


• Disco Duro: SATA-160 GB.

• Tarjeta de Red: 10/100 Mbps.


con GNOME 2.30)

• SUN - java 6 – jre versión 6.20

• MySQL 5.0.45

Tabla 15: Requerimientos técnicos servidor.

Página 37

Estación de trabajo (Punto de Venta)


• Procesador: Intel Centrino Duo 1.5 GHz


• Disco Duro: SATA-80 GB.

• Tarjeta de Red: 10/100 Mbps.


con GNOME 2.30)

• SUN - java 6 – jre versión 6.20

Tabla 16: Requerimientos técnicos estación de trabajo Punto de Venta.

Lector de Código de Barras

• interface: USB

• Gatillo

• Tecnología: CCD

• Rango de escaneo 45 scan / seg.

• Ancho de escaneo: 70mm.

• Fuente de luz visible luz roja LED de 660nm con barra de luz de foco.

• Distancia de escaneo: 5 cm.

• Velocidad: 75 scan/seg.

Tabla 17: Requerimientos técnicos lector de Código de Barras.

Página 38

Impresora Térmica De Tickets

• Impresión de hasta 200 mm/seg

• Impresión de recibos de logotipos, gráficos y alfanuméricos

• tipo de papel:

▪ Tamaño 79.5 +- 0.5(W) x día. 83.0

▪ Grosor: 0.06 a 0.07

• Diseño de la cubierta para mayor resistencia a los derrames

• Interfaces serial RS-232, USB 2.0 ó Paralelo Bidireccional

Tabla 18: Requerimientos técnicos Impresora Tickets.

2.2.3 Características Comerciales del Software Requerido

A continuación, se presenta un cuadro resumen con las características comerciales del software

requerido para este proyecto. Para conocer las características técnicas, revisar punto 3 del Marco

Teórico (Capítulo III).

Página 39

Software Licencia

• Ubuntu 10.4 (Lucide, núcleo Linux 2.6.32, con GNOME 2.30) • Gratuito

• SUN - java 6 – jre versión 6.20 y SUN - java 6 – JDK • Gratuito

• MySQL 5.0.45 • Gratuito

• Administrador MySQL (MySQL-Admin) versión 5.0 r14 Ubuntu • Gratuito

• OpenOffice.org 3.2 • Gratuito

• Netbeans 6.8 • Gratuito

• Dia 0.97.1 • Gratuito

Tabla 19: Características comerciales software requerido.

Para realizar un estudio de factibilidad técnica, se realizó una visita en Importadora Villablanca para

verificar si se cuenta con los recursos hardware y software necesarios, que han sido descritos

anteriormente.

Hay que hacer notar, la administración prioriza para el desarrollo y puesta en marcha del proyecto la

utilización de los recursos ya existentes en la Organización o las licencias gratuitas, así mismo, la

situación de subutilización existente con respecto a éstos. Por ende, se pretende realizar un mínimo de

inversión, que se reflejará en el Estudio de Factibilidad Económica.

A continuación, se muestra una tabla de resumen que visualiza el cumplimiento de los requerimientos

técnicos mínimos por parte del equipamiento hardware ya existente.

Página 40

Cantidad Equipamiento Cumplido

1 Estación de trabajo para el desarrollo del sistema. SI

1 Servidor, que alojará la base de datos y la aplicación. SI

2 Estación de trabajo donde se ejecutará la aplicación de ventas SI

2 Estación de trabajo donde se ejecutará la aplicación de pre-ventas NO

1Estación de trabajo donde se ejecutará la aplicación para la recepción de mercaderías

SI

1 Estación de trabajo donde se ejecutará la aplicación para la administración SI

5 Lector de código de barras (uno por cada estación de trabajo) NO

1 Switch SI

Tabla 20: Cumplimiento de Requerimientos Técnicos por parte del equipamiento existente.

Los equipos de la organización se encuentran conectados en una red de área local a través de un switch,

que a su vez se encuentra conectado a Internet el equipo del administrador y el de recepción. Se cuenta

con un plan de Internet que proporciona una velocidad de 2Mb por segundo y dirección IP fija por cada

equipo.

Hay que destacar, que la mayoría de los recursos hardware ya están disponibles en la organización.

Para desarrollar este proyecto, bastaría adquirir un equipo y dos lectores de código de barras, tal como

se mostró en la tabla 9. La Administración de Importadora Villablanca., demuestra su interés por el

desarrollo y puesta en marcha del Sistema Administración y Ventas, ha manifestado que está dispuesta

a invertir en el equipamiento en cuestión.

Con respecto a los softwares necesarios serán de uso gratuitos, por lo tanto, su adquisición nos

representan una mayor facilidad y economía para la organización. De igual manera, ocurre con los

Sistemas Operativos mencionados (Ubuntu 10.4 (Lucide, núcleo Linux 2.6.32, con GNOME 2.30). Sin

embargo, Importadora Villablanca opera en su oficina con Windows XP Professional, con las licencias

respectivas.

Página 41

Se puede concluir, que es técnicamente factible el desarrollo del proyecto, puesto que las herramientas

que se encuentran disponibles son necesarias para el inicio y la puesta en marcha del proyecto, vale la

pena decir, que la administración de igual manera está dispuesta a invertir para adquirir el

equipamiento que falta.

2.3 Factibilidad Operativa

El objetivo principal consiste en evaluar el impacto que tendrá el nuevo sistema en la organización

respecto al entorno. Asimismo, se analizará si se trabajará con él software una vez terminado. Por

consiguiente, es de vital importancia saber si los usuarios se sienten cómodos o no, si se muestran

reacios a los cambios y a la colaboración durante el desarrollo del proyecto.

El universo de usuarios está constituido por el administrador, cajeros y los vendedores de Importadora

Villablanca. Éstos estarán asociados a un perfil, en dónde se determinarán las tareas que podrán

realizar.

La empresa se preocupará de capacitar al personal al uso de las tecnologías y manejo de la aplicación

resultante, es por eso, que la aplicación debe ser de fácil uso y amigable para el usuario. Además han

demostrado su interés, apoyo y colaboración necesaria al proyecto para su buen desarrollo.

Dada la situación actual y las necesidades detectadas de la empresa, se prevé una buena aceptación del

sistema por parte de los usuarios y la administración.

Se puede concluir, que el proyecto es operacionalmente factible de realizar, ya que hay necesidades que

satisfacer y se cuenta con la colaboración del administrador y el personal para su desarrollo y operación

del proyecto.

Página 42

2.4 Factibilidad Económica

Se determinará la posibilidad de desarrollar el proyecto en base a la estimación de costos y beneficios

económicos que incurrirá en el desarrollar del proyecto.

En la Factibilidad Económica, se utilizará el indicador VAN (Valor Actual Neto), cuyo resultado nos

permitirá concluir si el proyecto es rentable o no, además, nos sirve para la valoración de las

inversiones en activos fijos, a pesar de sus limitaciones en considerar las circunstancias imprevistas o

excepcionales de mercado. El VAN es un indicador que evalúa los beneficios obtenidos en un horizonte

de tiempo determinado, si su valor es positivo el proyecto es beneficioso, considerándose el valor

mínimo de rendimiento para la inversión.

En este proyecto, es muy importante analizar la posible rentabilidad del proyecto y sobre todo si es

viable o no. Se evaluará, en un horizonte de tiempo de 5 años para invertir el capital, esperando una

rentabilidad debiendo ser mayor al menos que en otra inversión con poco riesgo (depósitos en

entidades financieras solventes). De lo contrario es más sencillo invertir el dinero en dicho producto

con bajo riesgo en lugar de dedicar tiempo y esfuerzo a la creación de un proyecto.

2.4.1 Determinación de costos

2.4.1.1 Costos de Implementación e inversión

En relación con el estudio de factibilidad técnica, en Importadora Villablanca ya cuenta con la mayoría

de las herramientas hardware, por lo tanto, se debe invertir sólo en los siguientes equipos:

Página 43

Cantidad Equipamiento Precio Unitario

1 Estación de trabajo donde se ejecutará la aplicación de pre-ventas $233.0802

1 Lector de código de barras (uno por cada estación de trabajo) $28.5003

1 Impresora Térmica De Tickets $230.5004

Total Inversión $492.080

Tabla 21: Inversión en hardware

Con respecto al Hardware, se cuenta con Ubuntu 10.4 (Lucide, núcleo Linux 2.6.32, con GNOME

2.30), el cual puede alojar la aplicación escritorio, además de tener licencia gratuita y las herramientas

de Software, por lo que se considerarán costos de inversión cero.

Con respecto al personal requerido, es necesaria la contratación de dos analistas programadores. En

dónde, se encargarán de la implementación y desarrollo del sistema.

El costo asociado al sueldo de estos profesionales, se hará en base a la siguiente información:

▪ Ambos profesionales trabajarán de lunes a viernes, 8 horas diarias.

▪ Los analistas programadores trabajarán durante 3 meses (540 horas c/u).

▪ De acuerdo a información proporcionada por un sitio Web de empleos en Internet, el

analista programador cobraría $600.000 mensual.5

Por lo tanto, los costos asociados a los sueldos del personal, corresponderían a:

Personal

Cargo Número de horas Total Pesos

Analista programador 540hrs c/u $3.600.000

Tabla 22: Sueldos del Personal requerido.

2 Valor obtenido de www.pcfactory.cl 3 Valor obtenido de www.pcfactory.cl 4 Valor obtenido de www.pcfactory.cl 5 Valor obtenido de http://quillota.olx.cl

Página 44

http://www.pcfactory.cl/

http://quillota.olx.cl/



Costos de Instalación: No será necesaria la acción de un profesional encargado de instalar el Sistema.

Se entregará a la empresa un práctico manual de instalación donde se explican detalladamente los pasos

a seguir para llevar a cabo la instalación de la aplicación.

Estos valores serán considerados como inversión en el año 0.

Para la operación del Sistema, no se requiere la contratación de personal adicional. Sin embargo, se

debe invertir en cintas térmicas y papel en rollo para las impresoras de punto ve ventas.

Los costos de operación al año se resumen en la siguiente tabla:

Insumos para Operación

Detalle Cantidad Precio Unitario Total

Papel Rollo: 79.5+/-0.5(w) diámetro 83.0 72 950 $68.400

Total Insumos $68.400

Tabla 23: Insumos para operación por año.

Mantención al Servidor

Detalle Horas por Mes Precio Por Hora Total Anual

mantención al servidor dos veces por mes (1 hora y media cada visita)

3 Horas $10.000 $360.000

Tabla 24: Mantención al servidor por año.

Estos costos serán considerados en cada uno de los 5 años en los que se evaluará el proyecto.

Página 45

2.4.2 Estimación de Ingresos o Beneficios

La Importadora Villablanca no percibirá ingresos directamente por la solución propuesta, Sin embargo,

dadas a las características el sistema permitirá un ahorro de tiempo para el personal de la empresa, en el

ámbito de los procesos del negocio o como para la gestión de la administración. Se estima que una vez

puesto en marcha el proyecto, éste permitirá ahorrar en promedio 1 hora y 30 minutos de tiempo por

cajero al día, lo que es equivalente a 39 horas al mes y a 468 horas al año por cajero.

Como referencia que el sueldo base de un cajero es de $211.250, esto representaría un ahorro de

$549.250 por cajero al año. El ahorro total al año en tiempo de operación de los cajeros, correspondería

a $1.098.500.

Por otra parte, el sistema proporcionará beneficios intangibles, ya que por sus características será una

herramienta que permitirá realizar de manera más eficiente los procesos del negocio y la gestión de la

administración.

En las siguientes tablas se demuestra un resumen de costos y beneficios del proyecto.

Resumen de costos del proyecto

Tipo Acción T° de Acción Costo

Costo de implementación e inversión

Hardware No absorbido Año 0 $492.080

Software Absorbido - -

Personal (analista programador)

No absorbido Año 0 $3.600.000

InstalaciónPersonal encargado de instalar la aplicación

Absorbido - -

Operación y MantenciónInsumos de operación No absorbido Año 1-5 $68.400

Personal encargado de mantención del servidor

No absorbido Año 1-5 $360.000

Tabla 25: Resumen de costos del proyecto

Página 46

Beneficio Estimado

Beneficios T° de Acción Valor

Ahorro en tiempo del personal Años 1-5 $1.098.500

Tabla 26: Ahorro estimados para la puesta en marcha del Sistema.

2.4.3 Determinación de Flujos Netos de Caja

Como se había mencionado anteriormente, para determinar la Factibilidad Económica de la solución

propuesta, se utilizará el indicador VAN, cuyo valor proporcionará un criterio de decisión frente al

costo de ésta.

Para su cálculo, se debe considerar:

▪ Un tiempo de vida útil del proyecto estimado en 5 años.

▪ La empresa evaluará este proyecto con una tasa de descuento del 10%.

Página 47

En la tabla siguiente, se describirán dichos datos:

Flujo Incremental

Año 0 Año 1 Año 2 Año 3 Año 4 Año 5

Ahorro $1.098.500 $1.098.500 $1.098.500 $1.098.500 $1.098.500

(Costos)

Insumos ($68.400) ($68.400) ($68.400) ($68.400) ($68.400)

Personal Mantención del Servidor

($360.000) ($360.000) ($360.000) ($360.000) ($360.000)

Total antes de Impto $670.100 $670.100 $670.100 $670.100 $670.100

Impuesto 19% $127.319 $127.319 $127.319 $127.319 $127.319

Total después Impto $542.781 $542.781 $542.781 $542.781 $542.781

(Inversión)

Hardware (492.080)

Personal (3.600.000)

Total Inversión -4.092.080 $542.781 $542.781 $542.781 $542.781 $542.781

Tabla 27: Flujo Incremental

El cálculo del VAN se realiza con la siguiente Fórmula:

Donde:

• n : Es el total de años de vida útil del proyecto, en este caso es 5.

• i : Representa el año correspondiente.

• FCi : Flujo de Caja obtenido en el año i-ésimo.

• K : Es la tasa de descuento con la que se evalúan los proyectos, en este caso será 10%

• Io : Es la Inversión Inicial, que para este caso es lo que corresponde al año 0.

Página 48

−Io∑t=1

nFCi

1K i

Entonces tenemos:

VAN(10%) = -4.092.080 + 542.781

10,101 + 542.781

10,102+

542.781

10,103+

542.781

10,104

+542.781

10,105= -4.092.080 + 493.437 +448.579 +407.799 +370.727 +337.024 = -2.034.514

VAN(10%) = -2.034.514

El resultado del Estudio de Factibilidad, lo da el VAN y tiene un valor negativo. Es decir, que no se

alcanza a recuperar la inversión dentro de los 5 años en los cuales se ha evaluado el proyecto. Por lo

tanto, este proyecto no es factible económicamente, pero al seguir deduciendo el proyecto recuperará la

inversión al sexto año, por lo tanto, es factible ya que el VAN tendría un valor de 8.268 positivo.

Por consiguiente, se puede hacer mención que el estudio tiene como finalidad evaluar este proyecto en

términos reales, es decir, en base a los costos reales del mercado, proporcionando una referencia con un

alto nivel de certeza. En la práctica, este proyecto será desarrollado por alumnos tesistas de la

Universidad del Bío-Bío que llevarán a cabo este proyecto. Por lo anterior, en la práctica, el costo en

analista/programador será de costo cero en su totalidad.

Sin embargo, debemos tener en cuenta que este aspecto monetario no es tan determinante a la hora de

decidir sobre el desarrollo del proyecto. Se debe considerar, además, los distintos beneficios intangibles

que presenta este proyecto, como son aquellos que se desprenden de la automatización de los procesos

descritos y que conllevan a una mejor y más rápida atención al cliente y todas las ventajas que esto

significa.

Página 49

2.5 Factibilidad de Fechas

En este punto, se verificará si el tiempo que se tomará en la realización del proyecto está de acuerdo

con las fechas establecidas inicialmente y si se ajusta a las necesidades de la organización. Se ha

estimado un período de 5 meses para el desarrollo y puesta en marcha de este proyecto, plazos que son

entregados por la universidad. Además se debe mencionar que la Importadora Villablanca, no ha

impuesto una fecha determinada para la ejecución y puesta en marcha del sistema. Así, la fecha de

finalización del sistema no influye en las necesidades de la organización.

En consecuencia, el proyecto se puede concluir en cuanto a la fecha propuesta, es decir, es factible el

desarrollo del sistema para la empresa.

2.6 Factibilidad Política

Este estudio evalúa si las políticas de la organización permitirán el desarrollo del proyecto, así como su

puesta en marcha y utilización.

Dadas las necesidades detectadas en base a la situación actual, la Administración de Importadora

Villablanca, cree que es necesario automatizar los procesos que abarca este proyecto. De acuerdo a lo

anterior, no hay ningún tipo de impedimento que dificulte y/o impida la realización del sistema. Al

contrario, se encuentran dispuestos a colaborar proporcionando la información necesaria para realizar

el proyecto de la mejor manera posible.

Por consiguiente, es políticamente factible el desarrollo de este proyecto, ya que no existe ningún tipo

de restricción, impedimento alguno para su desarrollo y se cuenta con el apoyo de la Administración.

Página 50

2.7 Conclusiones Estudio de Factibilidad

En conclusión, en términos del estudio de factibilidad del proyecto, podemos establecer si el proyecto

es factible de realizar. Si bien, el estudio de factibilidad económica indicó que la inversión se

recuperaría al sexto año en los términos de valores del mercado, debemos centrarnos en los beneficios

intangibles que presentará este proyecto una vez puesto en marcha. Por lo tanto, de acuerdo al análisis

de la situación actual, se requiere de un sistema automatizado que permita realizar de manera más

eficientes las tareas relacionadas con la administración y ventas. Por otro lado, los usuarios están

dispuestos a colaborar proporcionando la información necesaria para el desarrollo del Sistema.

Página 51

3 Capítulo III: Descripción de la Metodología utilizada y de la herramientas de implementación.

3.1 Introducción

Este capítulo se centra en establecer las bases sobre las cuales se trabajará durante el desarrollo del

presente proyecto. Para la construcción de todo sistema es necesaria la concepción de una forma de

trabajo metódica y ordenada, que permita abordar el problema de tal forma de alcanzar una solución

que cumpla con las expectativas de los usuarios. Para ello, es necesaria la adopción de una metodología

que guíe el trabajo del equipo de desarrollado en cada una de las etapas de la construcción del sistema,

proporcionándole una visión más clara sobre el problema a tratar y entregándole herramientas que

pueda aplicar ante situaciones específicas. Una vez definida la metodología, el espectro de

herramientas de implementación se reduce considerablemente haciendo mucho más fácil la tarea de

seleccionar aquellas que se adecuen mejor a la solución del problema.

Es por lo anterior, que antes de entrar en el detalle de la solución del problema a tratar en este proyecto

de título, se procede a describir la metodología a utilizar durante el desarrollo del sistema. Una vez

descrita la metodología, se describirá cada una de las herramientas tecnológicas que se utilizarán para

la implementación del sistema.

Página 52

3.2 Metodología utilizando

3.2.1 Orientación a Objetos

La orientación a objetos es un modelo de desarrollo de software que es usado en muchos de los

lenguajes de programación (C++, Java, Python, Eiffel, Modula-2 y otros) y en sistemas

computacionales que simulan el comportamiento del "mundo real". Éste estipula que se debe

desarrollar una aplicación en términos de objetos.

El atractivo de la orientación a objetos proporciona conceptos y herramientas con las cuales se modela

y representa el mundo real tan fielmente como sea posible. Estos conceptos y herramientas orientados a

objetos son tecnologías que permiten que los problemas del mundo real sean expresados de modo fácil

y natural.

3.2.1.1 Características de la programación orientada objetos

▪ Encapsulamiento: Un objeto encapsula datos como los procesos que se aplican a esos

datos, ocultando los detalles de su implementación. Esta importante característica

permite construir clases de objetos e inherentemente construir bibliotecas de objetos y

clases reutilizables.

▪ Abstracción: Cada objeto en el sistema sirve como modelo de un “agente” abstracto

que puede realizar trabajo, informar y cambiar su estado y “comunicarse” con otros

objetos en el sistema sin revelar cómo se implementan estas características. Los

procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están,

una variedad de técnicas son requeridas para ampliar una abstracción.

▪ Modularidad: Es la propiedad que permite subdividir una aplicación en partes más

pequeñas llamadas módulos, cada una de las cuales debe ser tan independiente como sea

posible de la aplicación en sí y de las restantes partes.

Página 53

▪ Herencia: Las clases no están aisladas, sino que se relacionan entre sí, formando una

jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de

todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el

encapsulamiento permitiendo a los objetos ser definidos y creados como tipos

especializados de objetos preexistentes.

▪ Polimorfismo: Es el comportamiento que puede tener un objeto de acuerdo a la forma

que adopte, asociados a objetos distintos, pueden compartir el mismo nombre, al

llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que

se esté usando.

3.2.1.2 Ventajas de la orientación a objetos

Las ventajas más importantes que proporciona la adopción de un enfoque orientado a objetos son las

siguientes:

▪ Mantenibilidad (facilidad de mantenimiento): Los programas que se diseñan bajo el

paradigma de orientación a objetos son más fáciles de leer y comprender y el control de

la complejidad del programa se consigue gracias a la ocultación de la información que

permite dejar visibles sólo los detalles más relevantes.

▪ Modificabilidad (facilidad para modificar los programas): Se pueden realizar añadidos

o supresiones a programas simplemente añadiendo, suprimiendo o modificando objetos.

▪ Reusabilidad: Los objetos, si han sido correctamente diseñados, se pueden usar

numerosas veces y en distintos proyectos software.

▪ Fiabilidad: Todo software orientado a objetos suele ser más fiable, ya que se basan en el

uso de objetos ya definidos que están ampliamente probados.

Página 54

3.2.2 UML

“El lenguaje Unificado de Modelado (UML, del inglés Unified Modeling Lenguaje) es un lenguaje para especificar, visualizar, construir y documentar los artefactos de los sistemas software, así como para el modelado del negocio y otros sistemas no software.”6

UML es la notación visual estándar para el modelado orientado a objetos. Comenzó como una

iniciativa de Grady Booch y Jim Rumbaugh en 1994 para combinar las notaciones visuales de sus dos

populares métodos –los métodos de Booch y OMT (Object Modeling Technique)-. Más tarde se unió

Ivar Jacobson, creador del método Objetory.

Cabe destacar que tal como se mencionó, UML es un lenguaje para especificar y no un método o un

proceso. Además será utilizado para documentar el análisis y diseño de este proyecto.

3.2.3 Análisis Orientado a Objetos

Para comenzar a trabajar en una solución computacional, es necesario describir el problema y las

necesidades o requerimientos que se deben satisfacer. El análisis pone énfasis en una investigación del

problema y los requisitos, en vez de ponerlo en una solución.

Para llevar a cabo el análisis del proyecto, se utilizarán las siguientes herramientas UML:

▪ Casos de Uso.

▪ Diagramas de Casos de Uso.

▪ Diagramas de secuencia.

▪ Modelo conceptual.

6 LARMAN, Craig. (2003): UML y Patrones. Una Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado. 2da. Edición. Prentice

Hall. Pag. 15

Página 55

3.2.3.1 Casos de Uso

Los casos de uso son documentos narrativos que describen la secuencia de eventos de un actor (agente

externo) que utiliza un sistema para completar un proceso. Son documentos de texto, no diagramas y el

modelado de casos de uso es, sobre todo, una acción de escribir texto, no dibujar7.

Existen dos tipos de casos de uso:

▪ Caso de Uso de alto nivel: Este tipo de caso de uso describe de manera muy resumida

un proceso. La ventaja de este tipo de caso de uso es que permite comprender

rápidamente las características generales del sistema, tanto en complejidad como en

funcionalidad del mismo. Conviene comentar con los casos de uso de alto nivel para

lograr entender rápidamente los principales procesos del sistema, antes de adentrarse en

su descripción más detallada.

▪ Caso de Uso expandido: Este tipo de caso de uso describe un proceso de manera más

detallada que el caso de uso de alto nivel. Es útil para alcanzar un conocimiento más

profundo de los procesos y de los requerimientos.

3.2.3.2 Diagramas de Casos de Uso

Para crear un caso de uso, el analista debe primero identificar los diferentes tipos de personas (o

dispositivos) que utiliza el sistema o producto. Estos actores actualmente representan papeles que la

gente (o dispositivos) juegan como impulsores del sistema. Definido más formalmente, un actor es algo

que comunica con el sistema o producto y que es externo al sistema en sí mismo.

La finalidad de estos diagramas es ofrecer una especie de diagrama contextual que permita conocer

rápidamente los actores externos de un sistema y las formas básicas en que lo utilizan.

7 LARMAN, Craig. (1997).: UML y patrones: Introducción al análisis y diseño orientado a objetos, Prentice-Hall.

Página 56

3.2.3.3 Diagramas de Secuencia

Un diagrama de secuencia muestra las interacciones entre los objetos ordenadas en secuencia temporal.

Muestra los objetos que se encuentran en el escenario y la secuencia de los mensajes intercambiados

entre éstos para llevar a cabo la funcionalidad descrita por el escenario.

Los diagramas de secuencia ilustran las interacciones entre objetos en un tipo de formato con el aspecto

de una valla, en el que cada objeto nuevo se añade a la derecha.8

El Diagrama de Secuencia es muy útil para observar la perspectiva cronológica de las interacciones,

muestra la secuencia explícita de mensajes y son mejores para especificaciones de tiempo real y para

escenarios complejos.

3.2.3.4 Modelo Conceptual

Un modelado del dominio muestra clases conceptuales significativas en un dominio del problema; es el

artefacto más importante que se crea durante el análisis orientado a objetos. Utilizando la notación

UML, un modelo del dominio se representa con un conjunto de diagrama de clases, en los que no se

define ninguna operación9.

Pueden mostrar:

▪ Objetos del dominio o clases conceptuales.

▪ Asociaciones entre las clases conceptuales.

▪ Atributos de las clases conceptuales.

8 LARMAN, Craig. (2003): UML y patrones: Introducción al análisis y diseño orientado a objetos y al proceso unificado. Madrid: Prentice-Hall. Segunda

Edición. Número de páginas: 624.

9 LARMAN, Craig. (2003): UML y patrones: Introducción al análisis y diseño orientado a objetos y al proceso unificado. Madrid: Prentice-Hall. Segunda

Edición. Número de páginas: 624.

Página 57

3.2.4 Diseño Orientado a Objetos

Una vez terminadas todas las tareas del análisis, corresponde seguir con el proceso de diseño. El diseño

pone énfasis en una solución conceptual que satisface los requisitos en vez de ponerlo en la

implementación.

Durante este paso se logra una solución lógica que se funda en el paradigma orientado a objetos que

finalmente será implementada en un lenguaje de programación orientado a objetos. El diseño, se presta

especial atención a la definición de los objetos software y cómo colaboran entre sí para satisfacer los

requisitos.

Para llevar a cabo el diseño de este proyecto, se utilizarán los siguientes diagramas:

▪ Diagramas de colaboración.

▪ Diagramas de clases del Sistema.

3.2.4.1 Diagramas de colaboración

Los diagramas de colaboración ilustran las interacciones entre objetos en un formato de grafo o red, en

el cual los objetos se pueden colocar en cualquier lugar del diagrama10.

Los diagramas de colaboración son diagramas de interacción que resaltan la organización estructural de

los objetos que envían y que reciben mensajes. Un diagrama de colaboración muestra un conjunto de

objetos, enlaces entre estos objetos y mensajes enviados y recibidos por estos objetos.

10 LARMAN, Craig. (2003): UML y patrones: Introducción al análisis y diseño orientado a objetos y al proceso unificado. Madrid: Prentice-Hall.

Segunda Edición. Número de páginas: 624.

Página 58

3.2.4.2 Diagramas de Clases del Sistema

Una vez terminados los diagramas de interacción, es posible identificar la especificación de las clases

software (e interfaces) que participan en la solución software y añadirles detalles de diseño. A

diferencia de las clases conceptuales del Modelo del Dominio, las clases de diseño de los diagramas de

Clases del Sistema, muestran las definiciones de las clases software en lugar de los conceptos del

mundo real.

Entre la información general que presentan estos diagramas, encontramos:

▪ Clases, asociaciones y atributos.

▪ Interfaces, con sus operaciones y constantes.

▪ Métodos.

▪ Información acerca del tipo de los atributos.

▪ Navegabilidad.

▪ Dependencias.

3.2.5 Ciclo de desarrollo Modelo Incremental

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de

reducir estos riesgos es construir sólo una parte del sistema, reservando otros aspectos para entregas

posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando

subconjuntos de requerimientos del sistema.

Página 59

El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:

▪ Construir un sistema pequeño es siempre menos riesgoso que construir un sistema

grande (filosofía del “divide y vencerás”).

▪ Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los

requerimientos planeados para los niveles subsiguientes son correctos.

▪ Si un error importante es detectado, sólo la última iteración necesita ser descartada.

▪ Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del

sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan

cambiar durante el desarrollo. Si un error importante es realizado, el incremento previo

puede ser usado.

▪ Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del

comienzo del próximo incremento, puesto que se poseerá una mejor comprensión del

problema.

▪ El cliente verá que hay avances significativos y aumentará la confianza en el proyecto.

▪ Las entrevistas serán más focalizadas.

Dada la necesidad de una solución estable, se utilizará este modelo basándonos en las distintas ventajas

que ofrece. La entrega final del proyecto se hará en dos incrementos, cuyos detalles serán expuestos en

los capítulos posteriores.

3.2.6 Arquitectura

“Una arquitectura es el conjunto de decisiones significativas sobre la organización del sistema software, la selección de los elementos estructurales y sus interfaces, con los que se compone el sistema, junto con su comportamiento tal como se especifica en las colaboraciones entre esos elementos, la composición de esos elementos estructurales y de comportamiento en subsistemas progresivamente más amplios y el estilo de arquitectura que guía esta organización –estos elementos y sus interfaces, sus colaboraciones y su composición”11.

11 LARMAN, Craig. (2003). UML y Patrones. Una Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado. 2da. E. P. H. Pág. 418

Página 60

3.2.6.1 Definición de las Capas

La arquitectura utilizada para el Sistema de Administración y Ventas de Importadora Villablanca es la

arquitectura de tres capas, esta arquitectura separa el modelo del dominio, la presentación y las

acciones basadas en datos ingresados por el usuario en tres capas diferentes:

▪ Capa Interface: Es la encargada de mostrar y leer datos. La capa vista contiene todos

los elementos que constituyen la interfaz con el usuario.

▪ Capa de Controlador: Es donde verdaderamente se resuelve el problema, también

llamada “Lógica de Negocio”. En la capa de Dominio se modela el comportamiento del

sistema. El comportamiento de la aplicación es definido por los componentes que

modelan la lógica de negocio. Estos componentes reciben las acciones a realizar a través

de la capa de presentación y llevan a cabo las tareas necesarias utilizando la capa de

persistencia para manipular la información del sistema.

▪ Capa de persistencia: Es la encargada de guardar, leer y actualizar los datos en la BD.

La capa de persistencia abstrae a la aplicación de la bases de datos que usemos, para

lograr este objetivo se ocupó el patrón de diseño Data Access Object.

En UML, la forma que existe para representar esta separación en capas es a través de “paquetes”. Una

“capa de responsabilidad” es un “paquete” que por principio de diseño siempre tiene una única

responsabilidad y su nombre la describe.

Estos paquetes son los presentados en la Figura:

Página 61

¿Cuál es el beneficio de esta separación?

▪ Las llamadas de la interfaz del usuario en la estación de trabajo, al servidor de capa

intermedia, son más flexibles que en el diseño de dos capas, ya que la estación sólo

necesita transferir parámetros a la capa intermedia.

▪ Con la arquitectura de tres capas, la interfaz del cliente no es requerida para comprender

o comunicarse con el receptor de los datos. Por lo tanto, esa estructura de los datos

puede ser modificada sin cambiar la interfaz del usuario.

▪ El código de la capa intermedia puede ser reutilizado por múltiples aplicaciones si está

diseñado en formato modular. Esto puede reducir los esfuerzos de desarrollo y

mantenimiento, así como los costos de migración.

▪ La separación de roles en tres capas, hace más fácil reemplazar o modificar una capa sin

afectar a los módulos restantes. Separando la aplicación de la base de datos, hace más

fácil utilizar nuevas tecnologías de agrupamiento y balance de cargas.

¿Por qué se ocupará la arquitectura de tres capas en este proyecto?

Página 62

Ilustración 3: Arquitectura de 3 capas

▪ La elección de la arquitectura debe ser escogida de manera que minimice los efectos de

cambios futuros en el sistema.

▪ Se utilizó la arquitectura de tres capas ya que con ella se separa de forma clara las

responsabilidades, desacoplando el código.

▪ Si en el sistema se necesita cambiar de interfaz, sólo afectará al paquete donde se

encuentran todas las interfaces. Si quisieran cambiar de motor de bases de datos, sólo

cambiaría la capa de persistencia. Por lo tanto cualquier modificación afectaría a un

paquete y no a todo el sistema.

3.2.7 Patrones de diseño

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el

desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Un patrón de

diseño es una solución a un problema de diseño no trivial que es efectiva (ya que se resolvió el

problema satisfactoriamente en ocasiones anteriores) y reutilizable (se puede aplicar a diferentes

problemas de diseño en distintas circunstancias).

Los patrones de diseño pretenden:

▪ Proporcionar catálogos de elementos reutilizables en el diseño de sistemas de software.

▪ Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y

solucionados anteriormente.

▪ Formalizar un vocabulario común entre los diseñadores.

▪ Estandarizar el modo en que se realiza el diseño.

▪ Facilitar el aprendizaje de las nuevas generaciones de diseñadores.

Asimismo, los patrones de diseño no pretenden:

Página 63

▪ Imponer ciertas alternativas de diseño frente a otras.

▪ Eliminar la creatividad inherente al proceso de diseño.

Un patrón de diseño es una abstracción de una solución en un nivel alto. Solucionan problemas que

existen en muchos niveles de abstracción. Hay patrones que abarcan las distintas etapas del desarrollo,

desde el análisis hasta el diseño y desde la arquitectura hasta la implementación.

3.2.7.1 Patrón Data Access Object

El patrón de diseño Data Access Object (DAO) sirve para abstraer y encapsular los accesos al

almacenamiento persistente, gestionar las conexiones a la fuente de datos y obtener los datos

almacenados, creando una capa de persistencia que aísla todo acceso a información persistente con esto

se aisla la lógica de negocio de la capa de persistencia.

Para el diseño de la capa de persistencia se utilizó este patrón para encapsular los accesos a la base de

datos. Para transportar los datos; Data Access Object utilizó el patrón Transfer Object como se puede

apreciar en la Figura

El patrón DAO es una solución al problema del diferencial de impedancia entre un programa de

aplicación orientado a objetos y una base de datos relacional.

Página 64

Ilustración 4: Diagrama patrón Data Access Object

3.2.7.2 Patrón Transfer Object

El patrón Transfer Object es utilizado para trasferir múltiples elementos de datos a través de capas.

DataAccessObject utiliza un Transfer Object para devolver los datos obtenidos de una consulta SQL a

la capa de domino y la capa vista utiliza un Transfer Object de tipo vista para mostrar los datos

devueltos por la capa de dominio.

Sus características principales son que la Persistencia, las Interfaces y el Controlador se tratan como

entidades separadas; esto hace que cualquier cambio producido en la Persistencia se refleje

automáticamente en cada una de las Interfaces.

Se aplicará este modelo en el Sistema de Administración y Ventas de Importadora Villablanca por la

razón que más adelante se pueda añadir más funciones al sistema, de modo que las modificaciones al

componente de la interfaces puedan ser hechas con un mínimo impacto en el componente del modelo

de datos.

3.2.7.3 Patrón Singleton

Es una clase que únicamente permite que exista simultáneamente una única instancia de sí misma y que

ofrece un punto de acceso común a ella. Este patrón nos puede ayudar en situaciones en las que

queramos que haya únicamente una única instancia de una clase, por ejemplo para tener un acceso

centralizado a un sistema de log o un sistema de caché, de forma que desde cualquier punto de la

aplicación en el que queramos utilizar estos recursos, podamos garantizar que accedamos siempre a la

misma instancia.

Página 65

3.2.7.4 Controlador

El patrón controlador asigna las responsabilidades de capturar los eventos del sistema a las clases. Los

candidatos que se proponen para estas clases son los siguientes:

▪ Clase que representa al sistema (Controlador Fachada).

▪ Clase que representa la organización global (Modelo del ambiente del sistema).

▪ Clase que representa un actor (Controlador de roles).

▪ Manejador de eventos relacionado con casos de uso (Controlador uses-case).

En el modelo de diseño de este proyecto, se eligió como el controlador a la clase que representa el

sistema (Controlador Fachada), dado que para su diseñador representa, en cierta forma, el sistema

entero.

3.2.7.5 Bajo Acoplamiento

¿Cómo dar soporte a una mínima dependencia y a un aumento en la reutilización? El acoplamiento

mide qué tan fuerte está una clase conectada con otras (es decir, cuántas clases conoce y necesita). Una

clase con bajo (o débil) acoplamiento no depende de “muchas otras” clases12. Si existen muchas

dependencias entre las distintas clases de un modelo, se tornan complejas las tareas de mantención y

corrección del mismo, así como también la posibilidad de poder extraer módulos independientes para

reutilizarlos en otro proyecto. Por lo anterior, debe haber pocas dependencias entre las clases, es decir,

debe haber un bajo acoplamiento. Para determinar el nivel de acoplamiento de clases, son muy útiles

los diagramas de colaboración de UML.

En el modelo de diseño de este proyecto el nivel de dependencia de la mayoría de las clases es bajo,

dado que cada una de éstas está relacionada a lo más con 2 clases.

12 http://www.dcc.uchile.cl/~luguerre/cc40b/clase9.html [Consulta: 18 Junio 2010]

Página 66

3.2.7.6 Value Object

Originalmente este patrón se desprende del uso del patrón DAO. Los Value Objects (Objetos de

valores) son objetos simples que no poseen lógica alguna. Por lo anterior, también llamados “dummy

objects” (objetos “tontos”, en inglés). Éstos, sólo tienen getters y setters y sirven para transportar

información entre una capa a otra. Como se mencionó anteriormente, este patrón surge de la necesidad

de transportar datos desde la capa de acceso a datos hacia la capa de lógica de negocios. Este patrón

permite entonces, un desacople entre capas y obtener un mayor rendimiento, ya que los Value Objects

son objetos livianos que ocupan poca memoria y que además permiten una abstracción de cualquier

tecnología específica13.

3.2.7.7 Factoría Simple

Este patrón permite resolver el problema que surge de la creación de objetos pertenecientes a una

misma familia. Propone asignar la responsabilidad de la creación de dichos objetos a una clase, la que

determina el tipo específico del objeto a instanciar y encapsula la complejidad del proceso de creación

del mismo.

3.2.7.8 Fabricación Pura

Consiste en la asignación de un conjunto de responsabilidades altamente cohesivo a una clase artificial

o de conveniencia que no representa un concepto del dominio del problema, algo inventado para

soportar la alta cohesión, bajo acoplamiento y reutilización. Tal clase es una fabricación de la

imaginación. Idealmente, las responsabilidades asignadas a esta fabricación soportan alta cohesión y

bajo acoplamiento, de manera que el diseño de la fabricación es muy limpio o puro, de ahí que sea una

fabricación pura14.

13 http://grimpidev.wordpress.com/2008/04/09/el-patron-dao/ [Consulta: 18 Junio 2010]

14 LARMAN, Craig. (2003): UML y patrones: Introducción al análisis y diseño orientado a objetos y al proceso unificado. Madrid: Prentice-Hall. Segunda Edición. Número de páginas: 624.

Página 67

3.2.8 Modelo Vista Controlador

El modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de

una aplicación, la interfaz de usuario y la lógica de control en tres componentes distintos. El modelo es

Sistema de Gestión de Base de Datos y el controlador representa la Lógica del negocio15.

A continuación, se describen los componentes de este modelo:

▪ Modelo: Es la representación específica de la información con la cual el sistema opera.

La lógica de datos asegura la integridad de éstos y permite derivar nuevos datos. El

modelo encapsula los datos y las funcionalidades principales de la aplicación. Este nivel

es el encargado de manejar el lugar donde se almacenará la información que tiene

relación con ella.

▪ Vista: También llamada “Capa de Presentación”, despliega toda la información al

usuario en un formato adecuado para la interacción a partir de los datos generados por el

Modelo.

▪ Controlador: También llamado “Capa de Control”, es el encargado de establecer la

comunicación entre el Modelo y las Vistas. Cada Vista tiene un componente Controlador

asociado, que se encarga de recibir las entradas del usuario (usualmente en forma de

eventos como: movimiento del ratón o entradas de teclado).

En la figura se muestra un sencillo diagrama que muestra la relación entre el modelo, la vista y el

controlador.

15 http://es.wikipedia.org/wiki/Modelo_Vista_Controlador [Consulta: 18 Junio 2010]

Página 68

Ilustración 5: Modelo Vista Controlador

Se pueden encontrar diferentes implementaciones del MVC, sin embargo, el flujo que sigue el control,

generalmente es el siguiente:

1. El usuario actúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario

pulsa un botón).

2. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la

acción solicitada por el usuario. El controlador gestiona el evento que llega,

frecuentemente a través de un gestor de eventos.

3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma

adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el

carro de la compra del usuario). Los controladores complejos están a menudo

estructurados usando un patrón de comando que encapsula las acciones y especifica su

extensión.

4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario.

La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario

donde se refleja los cambios en el modelo (por ejemplo, produce un listado del

contenido del carro de la compra).

5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo

nuevamente.

Página 69

3.3 Herramientas a Utilizar

3.3.1 MySQL 5.0.45

MySQL es un gestor de base de datos sencillo de usar e increíblemente rápido. También es uno de los

motores de base de datos más usados en Internet, la principal razón de esto es que es gratis para

aplicaciones no comerciales. Las características principales de MySQL son:

▪ Es un gestor de base de datos:

• Una base de datos, es un conjunto de datos.

• Un gestor de base de datos, es una aplicación capaz de manejar este conjunto de

datos de manera eficiente y cómoda.

▪ Es una base de datos relacional:

• Una base de datos relacional, es un conjunto de datos que están almacenados en

tablas entre las cuales se establecen unas relaciones para manejar los datos de una

forma eficiente y segura. Para usar y gestionar una base de datos relacional se usa el

lenguaje estándar de programación SQL.

▪ Es Open Source:

• El código fuente de MySQL se puede descargar y está accesible a cualquiera, por

otra parte, usa la licencia GPL para aplicaciones no comerciales.

▪ Es una base de datos muy rápida, segura y fácil de usar, Gracias a la colaboración de

muchos usuarios, la base de datos se ha ido mejorando optimizándose en velocidad.

Página 70

3.3.2 Ubuntu 10.4 (Lucide, núcleo Linux 2.6.32, con GNOME 2.30)

Ubuntu es una distribución Linux basada en Debian GNU/Linux que proporciona un sistema operativo

actualizado y estable para el usuario medio, con un fuerte enfoque en la facilidad de uso y de

instalación del sistema. Al igual que otras distribuciones se compone de múltiples paquetes de software

normalmente distribuidos bajo una licencia libre o de código abierto.

Está patrocinado por Canonical Ltd., una compañía británica propiedad del empresario sudafricano

Mark Shuttleworth que en vez de vender la distribución con fines lucrativos, se financia por medio de

servicios vinculados al sistema operativo y vendiendo soporte técnico. Además, al mantenerlo libre y

gratuito, la empresa es capaz de aprovechar los desarrolladores de la comunidad en mejorar los

componentes de su sistema operativo.

Ubuntu 10.04 Lucid Lynx se publicó el 29 de abril de 2010, e incorpora integración con "Ubuntu One

Music Store" que permite comprar música en Internet de una forma más sencilla lo cual se

complementa con el soporte por defecto para el popular iPhone e iPod touch.

En lo referente a conectividad incorpora un sistema de notificación llamado "MeMenu", el cual facilita

la administración de diferentes redes sociales, correo y mensajería instantánea.

Por el lado del software cabe destacar la versión 2.0 del Ubuntu Software Center que da la posibilidad

de instalar paquetes individuales y tiene la capacidad de monitorizar los repositorios PPA que

tengamos.

Además se incluye un manual amigable para principiantes que se actualizará con cada nueva versión de

Ubuntu y después de casi cuatro años, Ubuntu tiene un nuevo tema visual para ventanas y escritorio, un

nuevo logo y una nueva pantalla de inicio del sistema.

Página 71

3.3.3 Netbeans 6.8

NetBeans IDE, es un entorno de desarrollo, una herramienta para que los programadores puedan

escribir, compilar, depurar y ejecutar programas. Está escrito en Java, pero puede servir para cualquier

otro lenguaje de programación. Existe además un número importante de módulos para extender el

NetBeans IDE. NetBeans IDE es un producto libre y gratuito sin restricciones de uso.

También está disponible NetBeans Platform; una base modular y extensible usada como estructura de

integración para crear grandes aplicaciones de escritorio. Empresas independientes asociadas,

especializadas en desarrollo de software, proporcionan extensiones adicionales que se integran

fácilmente en la plataforma y que pueden también utilizarse para desarrollar sus propias herramientas y

soluciones.

Ambos productos son de código abierto y gratuito para uso tanto comercial como no comercial. El

código fuente está disponible para su reutilización de acuerdo con la Common Development and

Distribution License ( CDDL) v1.0 and the GNU General Public License (GPL) v2.

3.3.4 OpenOffice.org 3.2

OpenOffice.org (frecuentemente escrito OOo para abreviar) es una suite ofimática libre (código abierto

y distribución gratuita) que incluye herramientas como procesador de textos, hoja de cálculo,

presentaciones, herramientas para el dibujo vectorial y base de datos. Está disponible para varias

plataformas, tales como Microsoft Windows, GNU/Linux, BSD, Solaris y Mac OS X. Soporta

numerosos formatos de archivo, incluyendo como predeterminado el formato estándar ISO/IEC

OpenDocument (ODF), entre otros formatos comunes. A febrero de 2010, OpenOffice soporta más de

110 idiomas.

Página 72

3.3.5 SUN - java 6 – jre/jdk versión 6.20

Java es un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems a

principios de los años 90. Las aplicaciones Java están típicamente compiladas en un bytecode, aunque

la compilación en código máquina nativo también es posible. En el tiempo de ejecución, el bytecode es

normalmente interpretado o compilado a código nativo para la ejecución, aunque la ejecución directa

por hardware del bytecode por un procesador Java también es posible, las características de java son:

▪ Incluye un nuevo marco de trabajo y APIs que hacen posible la combinación de Java con

lenguajes dinámicos como PHP, Python, Ruby y JavaScript.

▪ Incluye el motor Rhino de Mozilla, una implementación de Javascript en Java.

▪ Incluye un cliente completo de Servicios Web y soporta las últimas especificaciones para

Servicios Web, como JAX-WS 2.0, JAXB 2.0, STAX y JAXP.

▪ Mejoras en la interfaz gráfica y en el rendimiento.

3.3.6 Dia 0.97.1

Dia es una aplicación informática de propósito general para la creación de diagramas, desarrollada

como parte del proyecto GNOME. Está concebido de forma modular, con diferentes paquetes de

formas para diferentes necesidades.

Dia está diseñado como un sustituto de la aplicación comercial Visio de Microsoft. Se puede utilizar

para dibujar diferentes tipos de diagramas. Actualmente se incluyen diagramas entidad-relación,

diagramas UML, diagramas de flujo, diagramas de redes, diagramas de circuitos eléctricos.

El formato para leer y almacenar gráficos es XML (comprimido con gzip, para ahorrar espacio). Puede

producir salida en los formatos EPS, SVG y PNG.

Página 73

3.4 Conclusiones

Se ha definido claramente la metodología a seguir durante el desarrollo de este proyecto. La adopción

del enfoque Orientado a Objetos y del lenguaje Unificado de Modelado, permitirá modelar el problema

de una manera clara, lo que permitirá la construcción de una solución que cumpla con las expectativas

de los usuarios. Además, el trabajo en base al ciclo de desarrollo Incremental, permitirá una

retroalimentación con los usuarios, obteniendo resultados que se acerquen cada vez más a sus

necesidades. Las herramientas de implementación seleccionadas se adecuan a la metodología adoptada.

Finalmente, se puede concluir que se tiene todo lo necesario para comenzar a trabajar en el desarrollo

del proyecto.

Página 74

4 CAPÍTULO IV: Análisis

En esta sección, se describirá la secuencia de interacciones que se dan entre los actores y el Sistema. El

universo de actores que interactuarán está compuesto por el Administrador, cajeros y vendedores que

trabajan en esta empresa.

A continuación, se muestra el diagrama de casos de uso del Sistema.

Página 75

Ilustración 6: Diagrama de Casos de Uso del Sistema

4.1 Comentarios Previos al Análisis

Antes de seguir en el análisis de este proyecto, es de suma importancia para su comprensión tener en

cuenta los siguientes puntos:

▪ Con el objetivo de permitir al lector una fácil y rápida comprensión de los casos de uso

que serán descritos en este capítulo, se ha decidido optar por dividirlos en casos de uso

más pequeños, obteniendo así una serie de casos de uso “atómicos”, que en ocasiones

estarán asociados de una u otra manera entre sí. Es por esto que será muy frecuente que

en la descripción en algunos casos de uso aparezca lo siguiente: “incluye caso de uso

<nombre del caso de uso>”. Con esto, además de facilitar la comprensión del lector, se

logrará centrar la concentración del analista y desarrollador en cada caso de uso

atómico, abstrayéndolo del funcionamiento de los demás.

▪ Los casos de uso que comúnmente serían concebidos como “eliminar”, se reducen a

“cambiar estado”. Por ejemplo, si se desea eliminar propiamente tal un producto

cualquiera, el sistema le asignará un estado “inactivo”, de tal forma que el sistema no lo

considerará a la hora de realizar ventas. Esto, corresponde a un borrado lógico, ya que al

eliminar un registro físicamente se perdería toda su información histórica asociada.

▪ Con respecto a los diagramas de secuencia, las llamadas que hace el actor hacia el

Sistema ilustrarán sólo los métodos que estarán disponibles en la clase que la

representan (los métodos que puede llamar la interfaz gráfica). En este informe se

concentrará la atención más en la lógica del negocio que en la implementación de las

interfaces gráficas. Lo anterior no significa que éstos métodos no existan, al contrario,

serán documentados en la etapa de diseño.

Página 76

4.1.1 Descripción de Casos de Uso Primer Incremento

4.1.1.1 Descripción de Casos de Uso Gestionar Proveedor

4.1.1.1.1 Caso de Uso: Ingresar Proveedor

Actores :Administrador

Propósito :Permite ingresar un proveedor nuevo al sistema.

Descripción :El Administrador indica que desea ingresar un nuevo proveedor. El

sistema despliega un formulario para ingresar los datos del proveedor (rut,

nombre o razón social, dirección, teléfono, fax, persona de contacto,

correo electrónico, cargo en la empresa). El administrador llena los datos

solicitados y el sistema finalmente almacena el nuevo proveedor.

Tipo :Primario

Referencia Cruzadas :R.1.1

Curso Normal de Eventos

Acción del Actor Respuesta del Sistema

1.- Este caso de uso comienza cuando el Administrador indica que desea ingresar un nuevo proveedor al sistema.

2.- El sistema despliega un formulario para el ingreso de datos del nuevo proveedor

3.- El Administrador proporciona los datos solicitados (rut, nombre o razón social, dirección, teléfono, fax, persona de contacto, correo electrónico, cargo en la empresa).

4.- El administrador indica que desea guardar el proveedor ingresado.

5.- Es sistema válida que los datos sean ingresados correctamente.

6.- El sistema almacena el nuevo proveedorCursos Alternativos

Línea 5a : Los datos ingresados no son válidos. El sistema notifica el Administrador con un

mensaje en pantalla. Se ejecuta paso 3.

Página 77

4.1.1.1.2 Caso de Uso: Modificar Proveedor


Propósito :Permite al Administrador modificar los datos del proveedor.

Descripción :El administrador indica que desea modificar los datos de un proveedor .

El sistema despliega los datos ( rut, nombre o razón social, dirección,

teléfono, fax, persona de contacto, correo electrónico, cargo en la

empresa) y permite editarlos. El Administrador modifica los datos y el

sistema guarda los cambios realizados.

Tipo : Primario

Referencia Cruzadas : R1.2



1.- Este caso de uso comienza cuando el Administrador solicita modificar los datos de un proveedor existente en el sistema. Para esto lo selecciona de un lista (incluye caso de uso “Buscar Proveedor”).

2.- El sistema despliega en pantalla un formulario del proveedor seleccionado y permite su edición.

3.- El Administrador modifica los datos del proveedor (nombre o razón social, dirección, teléfono, fax, persona de contacto, correo electrónico, cargo en la empresa).

4.- El Administrador indica que desea guardar los datos modificados.

5.- El sistema verifica que los datos ingresados sean correctos.

6.- El sistema guarda los cambios realizados.Cursos Alternativos

Línea 5a : Se ingresaron datos inválidos. El sistema notifica lo ocurrido con un mensaje en

pantalla. Se ejecuta paso 3.

Página 78

4.1.1.1.3 Caso de Uso: Buscar Proveedor


Propósito :Visualizar en pantalla el o los proveedores encontrados en base a los

datos ingresados por el Administrador. Dichos datos son: rut, razón social

o nombre fantasía.

Descripción :El Administrador desea buscar proveedores en base a rut, razón social o

nombre de fantasía. Para ello, proporciona al sistema los datos en base al

tipo de búsqueda que desea realizar. El sistema busca el o los vendedores

cuyos datos coinciden con los proporcionados por el Administrador y los

despliega en pantalla por medio de una lista.

Tipo : Primario

Referencia Cruzadas : R.1.3



1.- Este caso de uso comienza cuando el Administrador indica al sistema que desea buscar uno o más proveedores en base a rut, razón social o nombre de fantasía.

2.- El sistema solicita los datos necesarios para realizar la búsqueda.

3.- El administrador ingresa los datos (rut, razón social o nombre de fantasía) en base a los cuales desea que el sistema realice la búsqueda.

4.- El sistema busca y visualiza en pantalla el o los proveedores que han sido encontrados en base a los datos ingresados.

Cursos Alternativos

Línea 4a : No se encontraron los proveedores a visualizar. Se notifica lo ocurrido al

Administrador con un mensaje en pantalla. Se ejecuta paso 3.

Línea 4b : Se ingresaron datos inválidos. Se notifica lo ocurrido al Administrador con un mensaje

en pantalla. Se ejecuta paso 3.

Página 79

4.1.1.1.4 Caso de Uso: Eliminar Proveedor


Propósito :Eliminar un proveedor que se encuentre en el sistema.

Descripción :El administrador desea eliminar un proveedor. Para ello proporciona el

rut de proveedor. El sistema elimina el usuario solicitado.

Tipo :Primario




1.- Este caso de uso comienza cuando el Administrador solicita eliminar un proveedor.

2.- Caso de uso “Buscar Proveedor”.

3.- El Administrador selecciona proveedor de la lista.

4.- El sistema solicita confirmación, para eliminar el proveedor.

5.- El Administrador autoriza al sistema para eliminar el proveedor.

6.- El sistema deja en estado inactivo al proveedor.

Cursos Alternativos

Línea 5a : El Administrador no autoriza al sistema eliminar el proveedor. Se ejecuta paso 2

Página 80

4.1.1.1.5 Caso de Uso: Verificar Proveedor


Propósito :Dar a conocer si un proveedor esta registrado en el Sistema.

Descripción :El Administrador desea saber si un proveedor está registrado en el

sistema. Para ello, proporciona su rut para verificarlo. El sistema chequea

si existe un usuario con ese rut en el sistema, desplegando en pantalla el

resultado de la búsqueda.

Tipo : Secundario




1.- Este caso de uso comienza cuando el Administrador desea verificar si un proveedor está registrado en el sistema.

2.- El sistema solicita el rut del proveedor.

3.- El Administrador proporciona el rut del proveedor.

4.- El Administrador indica al sistema que desea verificar el rut ingresado.

5.- El Sistema verifica que el rut sea válido y busca en el sistema si existe un proveedor con dicho rut.

6.- El sistema despliega mensaje indicando si el proveedor se encuentra registrado en el sistema.

Casos Alternativos

Línea 5a : El rut ingresado no es válido. Se notifica el error con un mensaje en pantalla. Se

ejecuta paso 3.

Línea 6a : Si el proveedor no se encuentra se ejecuta paso 3.

Línea 6b : Si se encuentra el proveedor, se despliega un formulario con todos sus datos.

Página 81

4.1.1.2 Descripción de Casos de Uso Gestionar Producto

4.1.1.2.1 Caso de Uso: Ingresar nuevo Producto

Actores :Administrador.

Propósito :Registrar un nuevo producto en el sistema.

Descripción :El administrador indica que desea ingresar un nuevo producto. El sistema

despliega un formulario solicitando los datos (marca, nombre, categoría,

precio_c, precio_v, stock, stock_c, activo) del producto a ingresar estos

son validados para posteriormente ser almacenados.

Tipo :Primario.




1.- Este caso de uso inicia cuando el administrador indica al sistema que quiere ingresar un nuevo producto.

2.- Es sistema despliega un formulario, solicitando los datos para el nuevo producto.

3.- El administrador ingresa los datos correspondientes a un nuevo producto, que corresponden a: marca, nombre, categoría, precio_c, precio_v, stock, stock_c, activo.

4.- El sistema válida que se hallan ingresados los campos requeridos y el tipo de dato.

5.- El sistema verifica que el producto no se encuentra ya en el sistema.

6.- Es sistema guarda el nuevo producto.Cursos Alternativos

Línea 3.a :El producto viene sin código. El usuario debe indicar al sistema que debe generar uno.

Línea 4.a :Ya existe un producto asociado al código proporcionado. El sistema notificará lo

ocurrido al usuario con un mensaje.

Línea 5.a :Hay datos sin ingresar o no son válidos, el sistema muestra mensaje de error.

Página 82

4.1.1.2.2 Caso de Uso: Modificar Producto


Propósito :Permite al Administrador modificar los datos de un producto.

Descripción :El administrados solicita modificar los datos de un producto, el sistema

despliega los datos del producto (marca, nombre, categoría, precio_c,

precio_v, stock, stock_c, activo) al administrador para modificar y solicita

guardar los datos.

Tipo :Secundario

Referencias Cruzadas :R.2.2



1.- Este caso de uso comienza cuando el Administrador indica que desea modificar los datos del producto. .

2.- El sistema solicita ingresar el código o el nombre del producto a modificar.

3.- El administrador ingresa los datos pedido por el sistema.

4.- El sistema despliega un formulario con los datos del producto.

5.- El administrador modifica los datos que el sistema le permite editar, que corresponden a: marca, nombre, categoría, precio_c, precio_v, stock, stock_c, activo.

6.- El administrado indica que quiere guardar los cambios realizados.

7.- El sistema verifica que no se hayan omitido datos y que estos sean correctos.

8.- El sistema guarda los cambios realizados.

Cursos Alternativos

Línea 7a :El proceso de validación detectar datos incorrectos, Se notificará al Administrador con

un mensaje emergente. Se ejecuta paso 6.

Página 83

4.1.1.2.3 Caso de Uso: Buscar Productos


Propósito :Visualizar en pantalla el o los productos encontrados en base a los datos

ingresados por el administrador.

Descripción :El Administrador desea buscar productos. Para ello, proporciona al

sistema los datos (códigos o nombre) en base a los cuales desea realizar la

búsqueda. El sistema busca el o los productos cuyos datos coinciden con

los proporcionados por el Administrador y los despliega en pantalla.

Tipo :Primario




1.- Este caso de uso comienza cuando el Administrador indica al sistema que desea buscar uno o más productos en base a código del Producto, nombre.


3.- El Administrador ingresa los datos (código Producto del Proveedor, código del Producto, nombre)

4.- El sistema busca y visualiza en forma de una lista tabulada los productos que han sido encontrados.

Cursos Alternativos

Línea 4a : No se encuentran productos asociados a los datos ingresados. Se notifica lo ocurrido.

Se ejecuta paso 3.

Página 84

4.1.1.2.4 Caso de Uso: Eliminar producto


Propósito :Permite al Administrador eliminar un producto.

Descripción :El Administrador solicita eliminar un producto, para ello proporciona el

código del producto. El sistema elimina el producto solicitado.

Tipo :Secundario



Acción del Actor Respuesta del Sistema.

1.- Este caso de uso comienza cuando el Administrador solicita eliminar un producto.

2.- Caso de uso “Buscar producto”.

3.- El Administrador selecciona el producto de una lista.

4.- El sistema solicita confirmación, para eliminar el producto.

5.- El Administrador autoriza al sistema para eliminar el producto.

6.- El sistema deja en estado inactivo el producto.

Cursos Alternativos

Línea 5a : El Administrador no autoriza al sistema eliminar el producto. Se ejecuta paso 2.

Página 85

4.1.1.2.5 Caso de Uso: Verificar producto


Propósito :Dar a conocer si un producto está registrado en el Sistema.

Descripción :El Administrador desea saber si un producto está registrado en el sistema.

Para ello, proporciona su código e indica que desea verificarlo. El sistema

chequea si existe un producto con ese código, desplegando en pantalla el

resultado de la búsqueda

Tipo :Secundario




1.- Este caso de uso inicia cuando el Administrador desea verificar si un producto está registrado en el sistema.

2.- El sistema solicita código del producto.

3.- El Administrador proporciona el código del producto.

4.- El Administrador indica al sistema que desea verificar el código ingresado

5.- El sistema verifica que el código sea correcto y busca si existe un producto con dicho código.

6.- El sistema despliega mensaje indicando si el producto se encuentra registrado.

Cursos Alternativos

Línea 5a :El código ingresado no es válido. Se notifica el error. Se ejecuta paso 3.

Página 86

4.1.1.3 Descripción de Casos de Uso Gestionar Categorías

4.1.1.3.1 Caso de Uso: Ingresar nueva Categoría


Propósito :Registra una nueva categoría en el sistema.

Descripción :El administrador indica que desea ingresar una nueva categoría. El

sistema despliega un formulario solicitando la información de la categoría

a ingresar. Al ingresar los datos (tipo) por el administrador, estos son

validados para posteriormente ser almacenados.

Tipo :Primario




1.- Este caso de uso inicia cuando el administrador indica al sistema que quiere ingresar una nueva categoría.

2.- Es sistema despliega un formulario, solicitando los datos para la nueva categoría.

3.- El administrador ingresa los datos correspondientes a una nueva categoría, que corresponden a: tipo

4.- El administrador indica que desea guardar la categoría.

5.- El sistema verifica que la tipo de categoría no se encuentra ya en el sistema.

6.- El sistema válida que se hallan ingresado el campo requerido.

7.- Es sistema guarda la nueva categoría.

Cursos Alternativos

Línea 5a : Los datos ingresados no son válidos. El sistema notifica el Administrador con un

mensaje en pantalla, Se ejecuta paso 3.

Página 87

4.1.1.3.2 Caso de Uso: Modificar Categoría


Propósito :Permite al Administrador modificar los datos del categoría.

Descripción :El administrador indica que desea modificar los datos de una categoría.

El sistema despliega los datos (tipo) y permite editarlos. El Administrador

modifica los datos y el sistema guarda los cambios realizados.

Tipo : Primario




1.- Este caso de uso comienza cuando el Administrador solicita modificar los datos de una categoría existente en el sistema. Para esto lo selecciona de un lista (incluye caso de uso “Buscar categoría”).

2.- El sistema despliega en pantalla un formulario de la categoría seleccionado y permite su edición.

3.- El Administrador modifica el dato de la categoría (tipo).

4.- El Administrador indica que desea guardar el dato modificado.

5.- El sistema verifica que el dato ingresado sea correcto.

6.- El sistema guarda el cambio realizado.

Cursos Alternativos

Línea 5a : Se ingresaron datos inválidos. El sistema notifica lo ocurrido con un mensaje en


Página 88

4.1.1.3.3 Caso de Uso: Buscar Categoría


Propósito :Visualizar en pantalla la o las categoría encontradas en base a los datos

ingresados por el Administrador. Dicho dato es: tipo.

Descripción :El Administrador desea buscar una categoría. Para ello, proporciona al

sistema el dato (tipo) solicitado para la búsqueda que desea realizar. El

sistema busca la categoría en el sistema con el dato proporcionado por el

Administrador y los despliega en pantalla por medio de una lista.

Tipo : Primario




1.- Este caso de uso comienza cuando el Administrador indica al sistema que desea buscar una categoría, en base a tipo.


3.- El administrador ingresa el dato (tipo) en base al cuál el administrador desea que el sistema realice la búsqueda.

4.- El sistema busca y visualiza en pantalla la categoría que ha sido encontrada en base a los dato ingresado.

Cursos Alternativos

Línea 4a : No se encontraron las categorías a visualizar. Se notifica lo ocurrido al Administrador

con un mensaje en pantalla. Se ejecuta paso 3.

Línea 4b : Se ingresaron datos inválidos. Se notifica lo ocurrido al Administrador con un mensaje

en pantalla. Se ejecuta paso 3.

Página 89

4.1.1.3.4 Caso de Uso: Eliminar Categoría


Propósito :Eliminar un proveedor que se encuentre en el sistema.

Descripción :El administrador desea eliminar una categoría. Para ello proporciona el

tipo. El sistema elimina la categoría solicitada.

Tipo :Primario




1.- Este caso de uso comienza cuando el Administrador solicita eliminar una categoría.

2.- Caso de uso “Buscar Categoría”.

3.- El Administrador selecciona una categoría de la lista.

4.- El sistema solicita confirmación, para eliminar la categoría.

5.- El Administrador autoriza al sistema para eliminar la categoría .

6.- El sistema deja en estado inactivo la categoría.

Cursos Alternativos

Línea 5a : El Administrador no autoriza al sistema eliminar la categoría. Se ejecuta paso 2

Página 90

4.1.1.3.5 Caso de Uso: Verificar Categoría


Propósito :Dar a conocer si una categoría esta registrado en el Sistema.

Descripción :El Administrador desea saber si una categoría está registrada en el

sistema. Para ello, proporciona el id para verificarlo. El sistema chequea

si existe una categoría con ese id en el sistema, desplegando en pantalla el


Tipo :Secundario




1.- Este caso de uso comienza cuando el Administrador desea verificar si una categoría está registrada en el sistema.

2.- El sistema solicita el id.

3.- El Administrador proporciona el id.

4.- El Administrador indica al sistema que desea verificar el id de categoría ingresado.

5.- El Sistema verifica que el id sea válido y busca en el sistema si existe la categoría.

6.- El sistema despliega mensaje indicando si la categoría se encuentra registrado en el sistema.

Casos Alternativos

Línea 5a : El id ingresado no es válido. Se notifica el error con un mensaje en pantalla. Se ejecuta

paso 3.

Línea 6a : Si la categoría no se encuentra. Se ejecuta paso 3.

Línea 6b : Si se encuentra la categoría, se despliega un formulario con todos sus datos.

Página 91

4.1.1.4 Descripción de Casos de Uso Gestionar Usuario

4.1.1.4.1 Caso de Uso: Ingresar Usuario


Propósito :Permite ingresar un usuario nuevo al sistema..

Descripción :El Administrador indica que quiere ingresar un usuario nuevo. El sistema

despliega un formulario para el ingreso de los datos (rut, nombre, cargo

en la empresa, id de usuario, password, privilegios), el Administrador

llena los datos solicitados, para posteriormente guardarlos en el sistema

Tipo :Primario




1.- Este caso de uso inicia cuando el Administrador solicita ingresar un nuevo usuario al sistema.

2.- El sistema despliega formulario para el ingreso de los datos del usuario

3.- El administrador proporciona los datos del formulario: rut (incluye caso de uso verificar usuario), rut, nombre, cargo en la empresa, idUsuario, password, privilegios.

4.- El Administrador indica que desea guardar el usuario ingresado.

5.- El sistema valida los datos ingresados y verifica que el usuario no se encuentre ingresado en el sistema.

6.- El sistema almacena el nuevo usuario.

Cursos Alternativos

Línea 5.a : Los datos ingresados no son válidos. El sistema notifica el error. Se ejecuta paso 3.

Línea 5.a : El usuario ya se encuentra ingresado en el sistema. Se notifica lo ocurrido con un


Página 92

4.1.1.4.2 Caso de Uso: Modificar Usuario


Propósito :Permitir modificar los datos de un usuario.

Descripción :El Administrador indica que desea modificar los datos de un usuario. El

sistema despliega los datos de éste y permite editarlos. El Administrador

modifica los datos y el sistema guarda los cambios realizados.

Tipo :Secundario




1.- Este caso de uso comienza cuando el Administrador desea modificar los datos de un usuario existente en el sistema. Para esto, lo selecciona de una lista (incluye caso de uso “Buscar Usuario”).

2.- El sistema despliega en pantalla los datos del usuario seleccionado, permitiendo su edición.

3.- El administrador modifica los datos del usuario (rut, nombre, cargo en la empresa, idUsuario, password, privilegios).

4.- El administrador solicita guardar los datos modificados.

5.- El sistema verifica que los datos ingresados sean correcto.


Cursos Alternativos

Línea 5.a :Se omitieron datos obligatorios o se han proporcionado datos inválidos. El sistema

notificará lo ocurrido. Se ejecuta paso 3.

Página 93

4.1.1.4.3 Caso de Uso: Buscar Usuario


Propósito :Visualizar en pantalla el o los usuarios del sistema.

Descripción :El administrador desea buscar usuarios en base a rut, nombre, idUsuario.

Para ello, proporciona al sistema los datos en los cuales quiere realizar la

búsqueda. El sistema busca el o los usuarios cuyos datos coinciden con

los proporcionados por el Administrador y los despliega en pantalla en

una lista.

Tipo :Primario




1.- Este caso de uso comienza cuando el Administrador indica que desea buscar uno o más usuarios con los siguiente datos: rut, nombre y/o apellido paterno.


3.- El administrador ingresa los datos a los cuales desea que el sistema realice la búsqueda.

4.- Solicita al sistema que realice la búsqueda.

5.- El sistema busca y visualiza en pantalla los usuarios que han sido encontrados en base a los datos ingresados.

Cursos Alternativos

Línea 4a :No se encuentran los usuarios con los datos ingresados. Se notifica al Administrador

con un mensaje en pantalla. Se ejecuta paso 3.

Página 94

4.1.1.4.4 Caso de Uso: Eliminar Usuario


Propósito :Eliminar un usuario que se encuentre en el sistema.

Descripción :El administrador desea eliminar un usuario. Para ello proporciona el rut

de usuario. El sistema elimina el usuario solicitado.

Tipo :Primario




1.- Este caso de uso comienza cuando el Administrador solicita eliminar un usuario.

2.- El sistema solicita el rut del usuario.

3.- El Administrador ingresa los datos solicitados.

4.- El sistema valida el rut ingresado.

5.- El sistema verifica que el rut se encuentre en el sistema.

6.- El sistema solicita confirmación, para eliminar el usuario.

8.- El Administrador confirma al sistema para eliminar el usuario.

9.- El sistema elimina el usuario.

Cursos Alternativos

Línea 4a :El rut no es válido. Se notifica el error con un mensaje en pantalla. Se ejecuta paso 3.

Línea 5a :El rut no se encuentra en el sistema. Se notifica el error con un mensaje en pantalla. Se

ejecuta paso 3.

Línea 8a :El Administrador no autoriza al sistema eliminar el usuario. Se ejecuta paso 3.

Línea 9a :El sistema no autoriza eliminar usuario, se notifica si desea bloquear el usuario.

Página 95

4.1.1.4.5 Caso de Uso: Verificar Usuario


Propósito :Dar a conocer si un usuario esta registrado en el Sistema.

Descripción :El Administrador desea saber si un usuario está registrado en el sistema.

Para ello, el administrador proporciona el rut para verificarlo. El sistema

chequea si existe el usuario con ese rut desplegando en pantalla el


Tipo :Secundario




1.- Este caso de uso comienza cuando el Administrador desea verificar si un usuario está registrado en el sistema.

2.- El sistema solicita el rut de usuario.

3.- El Administrador proporciona el rut del usuario.

4.- El Administrador indica al sistema que desea verificar el rut ingresado.

5.- El Sistema verifica que el rut sea válido y busca en el sistema si existe un usuario con dicho rut.

6.- El sistema despliega mensaje indicando si el usuario se encuentra registrado en el sistema.

Casos Alternativos

Línea 5a :El rut ingresado no es válido. Se notifica el error con un mensaje en pantalla. Se ejecuta

paso 3.

Línea 6a :Si el usuario no se encuentra se ejecuta paso 3.

Línea 6b :Si el Administrador encuentra el usuario, se despliega un formulario con todos sus

datos.

Página 96

4.1.1.4.6 Caso de Uso: Cambiar Privilegio


Propósito :Permite cambiar el privilegio del usuario dependiendo de su cargo,

vendedor, cajero, jefe del personal y administrador.

Descripción :El administrador indica que desea modificar el privilegio de un usuario.

El sistema procede a cambiar el privilegio y guardarlo en el sistema. El

usuario puede operar el sistema, sólo en los procesos que se le autoriza

por el privilegio.

Tipo :Primario




1.- Este caso de uso inicia cuando el Administrador desea cambiar el privilegio del usuario. Para esto, lo selecciona de una lista (incluye caso de uso “Buscar usuario”).

2.- El sistema despliega una lista de privilegios para ser seleccionados.

3.- El administrador selecciona el privilegio autorizado para el usuario.

4.- El administrador solicita guardar los datos modificados.

5.- El sistema verifica que los datos ingresados sean correcto.


Cursos Alternativos



Página 97

4.1.1.5 Descripción de Casos de Uso Gestionar Contraseña y acceso

4.1.1.5.1 Caso de Uso: Cambiar contraseña.


Propósito :Permite cambiar la contraseña de los distintos usuarios del sistema.

Descripción :El Administrador desea cambiar la contraseña de un usuario. El sistema

solicita el rut del usuario. El Administrador cambia la contraseña y el

sistema guarda los cambios.

Tipo :Secundario




1.- Este caso de uso comienza cuando el Administrador solicita cambiar la contraseña de un usuario.

2.- El sistema solicita la nueva contraseña asignada al usuario.

3.- El Administrador proporciona los datos solicitados.

4.-. El Administrador indica que desea guardar los cambios.

5.- El sistema verifica que los datos sean válidos.


Cursos Alternativos



Página 98

4.1.1.5.2 Caso de Uso: Validar Usuario

Actores :Administrador, Vendedor, Cajero, Jefe Personal.

Propósito :Permite identificar a un usuario, permitiendo tener accesos a sus

respectivas aplicaciones.

Descripción :El Actor se identifica con su nombre de usuario y contraseña en el

sistema. El sistema verifica que los datos proporcionados sean correctos y

permite entrar a la aplicación.

Tipo :Primario




1.- Este caso de uso Comienza cuando el actor desea ingresar a su respectiva aplicación.

2.- El sistema solicita idUsuario de usuario y password.

3.- El Actor proporciona su idUsuario y password

4.- El Actor indica que desea identificarse con los datos proporcionados

5.- El sistema Verifica que el idUsuario y password sean válidos.

6.- El sistema despliega la pantalla principal y menú y opciones, habilitados para ese tipo de usuario.

Cursos Alternativos

Línea 5a : Los datos proporcionados son inválidos o se ha omitido algunos de ellos. Se notifica el

error. Se ejecuta paso 2.

Página 99

4.1.2 Diagrama de Secuencia del Sistema Primer Incremento

4.1.2.1 Diagramas de Secuencia Gestionar Producto

4.1.2.1.1 Diagrama de Secuencia Ingresar Nuevo Producto

4.1.2.1.2 Diagrama de Secuencia Modificar Producto

Página 100

Ilustración 7: Diagrama de Secuencia Ingresar nuevo Producto

Ilustración 8: Diagrama de Secuencia Modificar Producto

4.1.2.1.3 Diagrama de Secuencia Buscar Productos

4.1.2.1.4 Diagrama de Secuencia Eliminar producto

Página 101

Ilustración 9: Diagrama de Secuencia Buscar Productos

Ilustración 10: Diagrama de Secuencia Eliminar producto

4.1.2.1.5 Diagrama de Secuencia Verificar producto

Página 102

Ilustración 11: Diagrama de Secuencia Verificar producto

4.1.3 Descripción de Casos de Uso Segundo Incremento

4.1.3.1 Descripción de Casos de Uso Realizar Ventas

4.1.3.1.1 Caso de Uso: Ingresar Pre-Venta

Actores :Cajero

Propósito :Permite ingresar una pre-venta al sistema.

Descripción :El cajero indica que desea ingresar una pre-venta en el sistema. El

sistema permite el ingreso del código en el formulario desplegado,

posteriormente muestra los productos asociados en la pre-venta.

Tipo :Primario




1.- Este caso de uso comienza cuando el Cajero indica que desea ingresar una pre-venta al sistema, incluye caso de uso “Buscar PreVenta”

2.- El sistema despliega un formulario para el ingreso del código de la pre-venta.

3.- El Cajero proporciona el código de pre-venta solicitado.

4.- El sistema valida que el código sea ingresado correctamente.

5.- El sistema verifica que el código ingresado se encuentre almacenado en el sistema.

6.- El sistema despliega los productos asociados en la pre-venta.

Cursos Alternativos

Línea 4a :Los datos ingresados no son válidos. El sistema notifica el Cajero con un mensaje en

pantalla, Se ejecuta paso 3.

Línea 5a :Los datos ingresados no existen en el sistema. El sistema notifica el Cajero con un


Página 103

4.1.3.1.2 Caso de Uso: Buscar Pre-Venta

Actores :Cajero

Propósito :Buscar Pre-Venta para una venta en el sistema.

Descripción :El cajero indica que desea buscar una Pre-Venta para realizar una venta.

El sistema despliega un formulario solicitando los datos de una Pre-venta

a buscar (fecha). El cajero proporciona los datos, que son validados por

el sistema para ser finalmente mostrarlo en pantalla.

Tipo :Primario




1.- Este caso de uso comienza cuando el cajero indica al sistema que desea buscar una pre-venta por fecha.


3.- El cajero ingresa los datos (fecha).

4.- El sistema Verifica que la fecha ingresada sea válida.

5.- El sistema busca y visualiza en pantalla en una lista tabulada las pre-ventas realizadas.

Cursos Alternativos

Línea 4a :Los datos ingresados no son válidos. El sistema notifica al Cajero con un mensaje en


Página 104

4.1.3.1.3 Caso de Uso: Agregar Producto

Actores :Cajero

Propósito :Agregar producto a vender en el sistema.

Descripción :El vendedor indica que desea ingresar productos para realizar una venta.

El sistema despliega un formulario solicitando los datos del producto a

ingresar (código o descripción del producto, cantidad). El vendedor

proporciona los datos, que son validados por el sistema para ser

finalmente mostrarlo en pantalla.

Tipo :Primario.




1.- Este caso de uso se inicia cuando el Cajero desea agregar un producto a vender. Incluye caso de uso “Buscar Producto”.

2.- El sistema solicita que el usuario indique el producto a agregar (a través de su código o seleccionándolo de una lista).

3.- El Actor indica el producto proporcionando su código y la cantidad (incluye caso de uso “Verificar Producto”) o seleccionándolo de una lista.

4.- El sistema Verifica que el código y cantidad ingresado sean válida.

Cursos Alternativos



Página 105

4.1.3.1.4 Caso de Uso: Buscar Producto

Actores :Cajero

Propósito :Buscar producto para la venta en el sistema.

Descripción :El cajero indica que desea buscar un productos para realizar una venta.

El sistema despliega un formulario solicitando los datos del producto a

buscar(código o descripción del producto). El cajero proporciona los

datos, que son validados por el sistema para ser finalmente mostrarlo en

pantalla.

Tipo :Primario




1.- Este caso de uso comienza cuando el cajero indica al sistema que desea buscar un producto en base a código o nombre del producto.


3.- El cajero ingresa los datos (código o nombre)

4.- El sistema Verifica que el código o nombre ingresado sean válido.

5.- El sistema busca y visualiza en forma de una lista tabulada los productos que han sido encontrados.

Cursos Alternativos



Página 106

4.1.3.1.5 Caso de Uso: Eliminar Producto

Actores :Cajero

Propósito :Eliminar producto a vender en el sistema.

Descripción :El vendedor indica que desea eliminar un producto de la venta. El

vendedor indica que desea eliminar un producto de la venta. Para esto,

selecciona el producto de una lista para ser eliminado. El sistema guarda

los cambios realizados y actualiza el documento de venta.

Tipo :Primario.




1.- Este caso de uso comienza cuando el cajero desea eliminar un producto de la venta.

2.- El sistema otorga opción de eliminar producto de la venta.

3.- El Actor selecciona opción de eliminar producto.

4.- El sistema solicita confirmación, para eliminar el producto.

8.- El Administrador confirma al sistema para eliminar el producto.

9.- El sistema elimina el producto.

Cursos Alternativos

Línea 9.a :Se cancela confirmación de la eliminación del producto para la pre-venta. Se ejecuta

paso 3.

Página 107

4.1.3.1.6 Caso de Uso: Finalizar Venta

Actores :Cajero

Propósito :Finalizar una venta en base a los datos ingresados.

Descripción :El cajero indica que desea finalizar una venta en el sistema. Para esto,

deberá ingresar los datos requeridos por el sistema (idVendedor,

descuento, formaPago, monto pagado, observaciones).

Tipo :Primario




1.- Este caso de uso se inicia cuando el cajero indica al sistema que desea finalizar una venta.

2.- El sistema despliega formulario solicitando el ingreso de los datos para finalizar la venta.

3.- El cajero ingresa los datos (idVendedor, descuento, formaPago, montoTotal, observaciones). Además de incluir automáticamente idCajero, idVenta, fecha, codigo, nombre y cantidad de los productos asociados.

4.- El sistema válida que los datos sean ingresados correctamente.

5.- El sistema Verifica que los datos ingresados sean válidos.

6.- El sistema permite realizar pago de la venta.

Cursos Alternativos


pantalla, Se ejecuta paso 3.

Línea 5a :Los datos ingresados no existen en el sistema. El sistema notifica el Cajero con un


Página 108

4.1.3.1.7 Caso de Uso: Realizar Pago Efectivo

Actores :Cajero

Propósito :Dar a conocer al cajero si el monto proporcionado por el Cliente es

válido para cancelar el total de la venta, calculando el vuelto respectivo.

Descripción :El cajero a finalizado una Venta y desea realizar el pago en efectivo de la

venta realizada. El sistema solicita el ingreso del monto cancelado, lo

compara con el total de la venta, determina si el monto es correcto y

calcula el vuelto en caso de ser necesario.

Tipo :Primario




1.- Este caso de uso se inicia cuando el cajero a finalizando una venta y ha seleccionado la forma de pago en Efectivo.

2.- El Sistema solicita el ingreso del monto en efectivo cancelado por el Cliente.

3.- El cajero ingresa el monto cancelado.

4.- El Sistema compara el monto cancelado con el total de la Venta, desplegando en pantalla el vuelto respectivo.

Cursos Alternativos

Línea 4a :El monto ingresado es menor al total de la venta. Se notifica el error. Se ejecuta paso 2.

Página 109

4.1.3.1.8 Caso de Uso: Imprime Tickets

Actores :Cajero

Propósito :Imprimir el tickets resultante de una venta.

Descripción :El cajero ha finalizado una venta, realizando pago e imprimire el tickets

de venta respectiva. El sistema selecciona impresora, imprime y guarda

en el sistema (idVenta, fecha, hora, vendedor, cajero, forma de pago,

monto pagado, vuelto, observaciones, codigo, nombre, cantidad).

Tipo :Primario.

Referencia Cruzadas :6.7



1.- Este Caso de Uso se inicia cuando el cajero ha finalizado una Venta y se procede a imprimir el documento.

2.- El Sistema imprime el detalle de la venta (idVenta, fecha, hora, vendedor, cajero, forma de pago, monto pagado, vuelto, observaciones, codigo, nombre, cantidad)

3.- El Sistema pregunta si el documento se imprimió correctamente.

4.- El cajero indica que el documento no se imprimió correctamente.

6.- El Sistema actualiza el estado de la venta terminada y espera que el cajero inicie otra venta.

Cursos Alternativos

Línea 3a : El cajero indica que el tickets no se imprimió correctamente. El sistema ejecuta paso 2.

Página 110

4.1.3.2 Descripción de Casos de Uso Realizar Pre-Ventas

4.1.3.2.1 Caso de Uso: Agregar producto

Este caso de uso está descrita previamente en el punto 4.5.2.2.1, Descripción de caso de uso Realizar

Ventas.

4.1.3.2.2 Caso de Uso: Buscar producto


Ventas.



Ventas.

4.1.3.2.4 Caso de Uso: Eliminar producto


Ventas.

Página 111

4.1.3.2.5 Caso de Uso: Finalizar Pre-Venta

Actores :Vendedor

Propósito :Finalizar una pre-venta en el sistema.

Descripción :El actor indica que desea finalizar una pre-venta.

El vendedor indica que desea finalizar una pre-venta en el sistema. Para esto, deberá ingresar los datos requeridos por el sistema (observaciones) para próximamente imprimir tickets de pre-venta..

Tipo :Primario.




1.- Este caso de uso se inicia cuando el vendedor indica al sistema que desea finalizar una pre-venta.

2.- El sistema despliega formulario solicitando el ingreso de los datos para finalizar la venta.

3.- El vendedor ingresa los datos (observaciones). Además de incluir automáticamente idVenta, idVendedor, codigo, nombre, cantidad.

4.- El sistema procesa la pre-venta y posteriormente imprime tickets

Página 112

4.1.3.2.6 Caso de Uso: Imprime Tickets

Actores : Vendedor

Propósito :Imprimir el tickets resultante de una venta.

Descripción :El vendedor ha finalizado una pre-venta, imprimire el tickets de pre-

venta respectiva. El sistema selecciona impresora, imprime y guarda

en el sistema (idPreVenta, fecha, hora, vendedor, codigo, nombre,

cantidad, monto de la pre-venta, observaciones).

Tipo :Primario.

Referencia Cruzadas :7.2



1.- Este Caso de Uso se inicia cuando el vendedor ha finalizado una pre-venta y se procede a imprimir el documento.

2.- El Sistema imprime el detalle de la pre venta (idVenta, fecha, hora, vendedor, cajero, forma de pago, monto pagado, vuelto, observaciones, codigo, nombre, cantidad)

3.- El Sistema pregunta si el documento se imprimió correctamente.

4.- El vendedor indica que el documento se

imprimió correctamente.

5.- El Sistema actualiza el estado de la pre-venta terminada y espera que el vendedor inicie otra pre-venta.

Cursos Alternativos

Línea 3a : El vendedor indica que el tickets no se imprimió correctamente. El sistema ejecuta

paso 2.

Página 113

4.1.3.3 Descripción de Casos de Uso Gestionar Informes

4.1.3.3.1 Caso de Uso: Inventario Producto


Propósito :Emitir un informe que liste los productos activos, codigo, nombre,

categoría, stock, stock critico.

Descripción :El Administrador indica que desea obtener un informe que muestre el

stock de los productos activos listado por categoría, codigo, nombre,

stock critico.

Tipo :Primario




1.- Este caso de uso inicia cuando el administrador solicita al Sistema un informe Inventario de Productos.

2.- El Sistema genera informe de Inventario de Productos.

3.- El Sistema muestra el informe generado.

Página 114

4.1.3.3.2 Caso de Uso: Informe Producto


Propósito :Emitir un informe que liste los productos activos.

Descripción :El Administrador indica que desea obtener un informe que muestre los

detalles de los productos activos listados en codigo, nombre,

precio_venta, categoría, stock, stock critico.

Tipo :Primario




1.- Este caso de uso inicia cuando el administrador solicita al Sistema un informe de Productos.

2.- El Sistema genera informe de Productos.


Página 115

4.1.3.3.3 Caso de Uso: Informe Proveedores


Propósito :Emitir un informe que liste los productos proveedores.

Descripción :El Administrador indica que desea obtener un informe que muestre los

proveedores con los detalles (rut, razonSocial, nombreFantasia, contacto,

telefono).

Tipo :Primario




1.- Este caso de uso inicia cuando el administrador solicita al Sistema un informe de Productos.

2.- El Sistema genera informe de Productos.


Página 116

4.1.3.3.4 Caso de Uso: Informe Ventas


Propósito :Emitir un informe con todas las ventas hechas durante un período de

tiempo determinado.

Descripción :El administrador indica al Sistema que desea obtener un informe de

ventas. El Sistema Solicita ingresar las fechas de inicio y de término del

período a considerar. El administrador indica el período de tiempo y el

Sistema genera el informe solicitado.

Tipo :Primario




1.- Este caso de uso se inicia cuando administrador indica al Sistema que desea generar un informe de ventas por un período determinado.

2.- El Sistema solicita ingresar fecha de inicio y fecha de término del período a considerar.

3. El administrador proporciona las fechas solicitadas.

4.- El Sistema verifica que las fechas proporcionadas sean correctas.

5. El Sistema genera las ventas realizadas en período indicado.

Cursos Alternativos

Línea 4a :Las fechas proporcionadas son inválidas. El Sistema notifica el error. Se ejecuta paso 3.

Línea 4a :No hay ventas a visualizar. Se notifica el error. Se ejecuta paso 3.

Página 117

4.1.3.3.5 Caso de Uso: Informe Comparativo Ventas


Propósito :Emitir un informe con todas las ventas hechas durante un período de

tiempo determinado y comparandolas con el año anterior.

Descripción :El administrador indica al Sistema que desea obtener un informe de

comparativo de ventas. El Sistema Solicita ingresar las fechas de inicio y

de término del período a considerar. El administrador indica el período

de tiempo y el Sistema genera el informe solicitado comparandolo con el

año anterior.

Tipo :Primario




1.- Este caso de uso se inicia cuando administrador indica al Sistema que desea generar un informe de comparativo de ventas por un período determinado.

2.- El Sistema solicita ingresar fecha de inicio y fecha de término del período a considerar.

3. El administrador proporciona las fechas solicitadas.

4.- El Sistema verifica que las fechas proporcionadas sean correctas y existan registros.

5. El Sistema genera las ventas realizadas en período indicado.

Cursos Alternativos

Línea 4a :Las fechas proporcionadas son inválidas. El Sistema notifica el error. Se ejecuta paso 3.

Línea 4a :No hay ventas a visualizar. Se notifica el error. Se ejecuta paso 3.

Página 118

4.1.3.3.6 Caso de Uso: Informe Monitoreo Usuario


Propósito :Emitir un informe de monitoreo de usuario

Descripción :El Administrador indica que desea obtener un informe de monitoreo de

usuario que muestre idPreVenta, fecha, hora, total, idVenta, fecha, hora,

total.

Tipo :Primario




1.- Este caso de uso inicia cuando el administrador solicita al Sistema un informe de monitoreo de usuario.

2.- El Sistema genera informe de monitoreo de usuario.


Página 119

4.1.3.4 Descripción de Casos de Uso Realizar Compras

4.1.3.4.1 Caso de Uso: Ingresar Proveedor


Propósito :Permite ingresar un proveedor en la compra.

Descripción :El cajero indica que desea ingresar un proveedor en la compra. El

sistema permite el ingreso del rut en el formulario desplegado, para

realizar una compra a un proveedor.

Tipo :Primario




1.- Este caso de uso se inicia cuando el administrador desea agregar un proveedor a una compra realizada. Incluye caso de uso “Buscar proveedor”.

2.- El sistema solicita que el usuario indique el proveedor a agregar (a través de su rut o seleccionándolo de una lista).

3.- El administrador indica el proveedor proporcionando su rut(incluye caso de uso “Verificar Proveedor”) o seleccionándolo de una lista.

4.- El sistema Verifica que el rut sea válida.

Cursos Alternativos

Línea 4a :Los datos ingresados no son válidos. El sistema notifica al administrador con un


Página 120

4.1.3.4.2 Caso de Uso: Buscar proveedor

Este caso de uso está descrita previamente en el punto 4.5.2.1.2, Descripción de caso de uso Buscar

proveedor.

4.1.3.4.3 Caso de Uso: Agregar producto

Este caso de uso está descrita previamente en el punto 4.5.2.2.1, Descripción de caso de uso Agregar

Producto.


Este caso de uso está descrita previamente en el punto 4.5.2.2.5, Descripción de caso de uso Verificar

Producto.

4.1.3.4.5 Caso de Uso: Eliminar Producto

Este caso de uso está descrita previamente en el punto 4.5.2.2.4, Descripción de caso de uso Eliminar

producto.

Página 121

4.1.3.4.6 Caso de Uso: Finalizar Compra


Propósito :Finalizar una compra en el sistema.

Descripción :El administrador indica que desea finalizar una compra en el sistema.

Para esto, deberá ingresar los datos requeridos por el sistema (número de

factura, condiciones de compra, fecha de compra) y procesar los

productos ingresados, proveedor, idCompra, monto total.

Tipo :Primario.




1.- Este caso de uso se inicia cuando el administrador indica al sistema que desea finalizar la compra.

2.- El sistema despliega formulario solicitando el ingreso de los datos para finalizar la compra.

3.- El administrador ingresa los datos (número de factura, condiciones de compra, fecha de compra)). Además de incluir automáticamente idCompra, monto total y los productos, proveedor, ingresados en los casos de uso anteriores.

4.- El sistema valida los datos ingresados que sean válidos.

5.- El sistema procesa y guarda la compra.

Cursos Alternativos



Página 122

4.1.3.5 Descripción de Casos de Uso Gestionar Ventas

4.1.3.5.1 Caso de Uso: Buscar Ventas


Propósito :Permitir al administrador realizar una búsqueda general de ventas.

Descripción :El administrador indica que desea buscar ventas. El Sistema permite

buscar ventas en base a idVenta o fecha.

Tipo :Primario




1.- Este caso de uso se inicia cuando el administrador desea realizar una búsqueda general de ventas.

2.- El sistema solicita los datos en base a los cuales se realizará la búsqueda. Éstos, corresponden a: idVenta fecha.

3.- El administrador proporciona los datos en base a los cuales desea realizar la búsqueda idVenta o fecha.

4.- El administrador indica que desea buscar ventas en base a los datos proporcionados.

5.- El Sistema verifica que los datos proporcionados sean correctos.

6. El Sistema busca las ventas cuyos datos coincidan con los proporcionados por el administrador y los despliega en una lista, permitiendo examinar su detalle.

Cursos Alternativos

Línea 5a :Existen datos incorrectos. Se notifica lo ocurrido. Se ejecuta paso 3.

Página 123

4.1.3.5.2 Caso de Uso: Mostrar Detalle Ventas


Propósito :Mostrar el detalle de una venta (resumen de información de productos,

vendedor, cajero, fecha).

Descripción :El Administrador indica que desea visualizar el detalle de una venta. Para

esto, selecciona la venta de una lista. El Sistema despliega la información

de la venta (resumen de información de productos, vendedor, cajero,

fecha).

Tipo :Primario




1.- Este caso de uso se inicia cuando el administrador indica que desea examinar el detalle de una venta. Para esto, la selecciona de una lista (incluye caso de uso “Buscar Ventas”).

2.- El Sistema despliega en pantalla el detalle de la venta (resumen de información de productos, vendedor, cajero, fecha).

Página 124

4.1.3.5.3 Caso de Uso: Anular Venta


Propósito :Permitir al administrador a anular una ventas, en base a: idVenta.

Descripción :El administrador indica que desea anular ventas. El Sistema permite

anular ventas en base a: idVenta.

Tipo :Primario




1.- Este caso de uso se inicia cuando el administrador desea realizar una búsqueda general de ventas.

2.- El sistema solicita anular venta en base a idVenta.

3.- El administrador proporciona los datos en base a los cuales se desea anular una venta.


6.- El Sistema anula la la ventas en el sistema

Cursos Alternativos

Línea 5a :Los datos ingresados no existen en el sistema. El sistema notifica al administrador con

un mensaje en pantalla. Se ejecuta paso 3.

Página 125

4.1.3.6 Descripción de Casos de Uso gestionar Compras

4.1.3.6.1 Caso de Uso: Buscar Compras


Propósito :Permitir al administrador realizar una búsqueda general de compras.

Descripción :El administrador indica que desea buscar una compra. El Sistema permite

buscar una compra en base a: fecha, numeroFactura, proveedor (rut, razon

social, nombreFantasia).

Tipo :Primario




1.- Este caso de uso se inicia cuando el administrador desea realizar una búsqueda general de compras.

2.- El sistema solicita los datos en base a los cuales se realizará la búsqueda. Éstos, corresponden a: fecha, numeroFactura, proveedor (rut, razon social, nombreFantasia).

3.- El administrador proporciona los datos en base a los cuales desea realizar la búsqueda.

4.- El administrador indica que desea buscar compras en base a los datos proporcionados.


6. El Sistema busca las comras cuyos datos coincidan con los proporcionados por el administrador y los despliega en una lista, permitiendo examinar su detalle.

Cursos Alternativos

Línea 5a :Existen datos incorrectos. Se notifica lo ocurrido. Se ejecuta paso 3.

Página 126

4.1.3.6.2 Caso de Uso: Mostrar Detalle Compras


Propósito :Mostrar el detalle de una compra (resumen de información de productos,

proveedor, fecha, condicionesDeCompra).

Descripción :El Administrador indica que desea visualizar el detalle de una compra.

Para esto, selecciona la compra de una lista. El Sistema despliega la

información de la venta (resumen de información de productos, proveedor,

fecha, condicionesDeCompra).

Tipo :Primario




1.- Este caso de uso se inicia cuando el administrador indica que desea examinar el detalle de una compra. Para esto, la selecciona de una lista (incluye caso de uso “Buscar Compras”).

2.- El Sistema despliega en pantalla el detalle de la compra (resumen de información de productos, proveedor, fecha, condicionesDeCompra). .

Página 127

4.1.3.6.3 Caso de Uso: Modificar Compra


Propósito :Modificar una compra en el sistema.

Descripción :El administrador indica que desea modificar una compra en el sistema.

Para esto, deberá ingresar los datos requeridos por el sistema (número de

factura, condiciones de compra, fechaCompra) e incluir caso de uso

ingresar producto, posteriormente, procesar los productos ingresados,

proveedor, idCompra, monto total.

Tipo :Primario.




1.- Este caso de uso se inicia cuando el administrador indica al sistema que desea modificar la compra, Este caso de uso incluye “Ingresar Producto”

2.- El sistema despliega formulario solicitando el ingreso de los datos para modificar la compra.

3.- El administrador modifica los datos (número de factura, condiciones de compra, fechaCompra).

4.- El sistema válida los datos ingresados que sean válidos.

5.- El sistema guarda la compra.

Cursos Alternativos


mensaje en pantalla, Se ejecuta paso 3.

Página 128

4.1.4 Diagramas de Secuencias del Sistema Segundo Incremento

4.1.4.1 Diagrama de Secuencias Realizar Ventas

4.1.4.1.1 Diagrama de Secuencia Ingresar Pre-Venta

4.1.4.1.2 Diagrama de Secuencia Buscar PreVenta

Página 129

Ilustración 12: Diagrama de Secuencia Ingresar Pre-Venta

Ilustración 13: Diagrama de Secuencia Buscar PreVenta

4.1.4.1.3 Diagrama de Secuencia Agregar Producto

4.1.4.1.4 Diagrama de Secuencia Buscar Producto

Página 130

Ilustración 14: Diagrama de Secuencia Agregar Producto

Ilustración 15: Diagrama de Secuencia Buscar Producto

4.1.4.1.5 Diagrama de Secuencia Verificar Producto

4.1.4.1.6 Diagrama de Secuencia Eliminar Producto

Página 131

Ilustración 17: Diagrama de Secuencia Eliminar Producto

Ilustración 16: Diagrama de Secuencia Verificar Producto

4.1.4.1.7 Diagrama de Secuencia Finalizar Venta

4.1.4.1.8 Diagrama de Secuencia Realizar Pago Efectivo

Página 132

Ilustración 18: Diagrama de Secuencia Finalizar Venta

Ilustración 19: Diagrama de Secuencia Realizar Pago Efectivo

4.1.4.1.9 Diagrama de Secuencia Imprime Tickets

Página 133

Ilustración 20: Diagrama de Secuencia Imprime Tickets

4.2 Diagrama Modelo Conceptual

Página 134

Ilustración 21: Diagrama Modelo Conceptual

5 Capítulo V: Diseño

5.1 Consideraciones previas al Diseño

Antes de entrar de lleno en lo que respecta al diseño del Sistema de Administración y Ventas de

Importadora Villablanca, es necesario poner de manifiesto algunas importantes consideraciones que

serán determinantes durante todo el proceso de diseño e implementación. Éstas se muestran a

continuación:

▪ El equipo de desarrollo se compone en dos persona, que estarán a cargo del proyecto en

cada una de las etapas del ciclo de vida.

▪ La cantidad de casos de uso que abarca este proyecto, es relativamente alta (61

aproximadamente), considerando el factor mencionado anteriormente y la fecha en que

se planificó la finalización del proyecto.

▪ Existe cierta inexperiencia por parte de los desarrolladores en el manejo de algunas de

las herramientas de implementación, lo que demandará mayor tiempo de investigación

para el aprendizaje de su utilización.

▪ Para la obtención de un modelo con un alto grado de reutilización y facilidad de

mantención de sus componentes, se hace necesaria la aplicación de Patrones Orientados

a Objeto más complejos, lo que repercute directamente en la etapa de implementación

(en la escritura de más líneas de código, al aparecer más métodos, clases, interfaces,

etc.).

5.1.1 “Adopción y Adaptación” de Patrones

En esta etapa se explicaran las forma en que se adoptan los patrones de diseño en este proyecto. En el

capítulo anterior (Descripción de la Metodología utilizada y de las Herramientas de Implementación),

se mencionan la teórica de los patrones a utilizar en el desarrollo del sistema, basándose en la literatura

especializada existente.

Página 135

5.1.1.1 Controlador + Singleton

Estos patrones son utilizados de manera conjunta, ya que el patrón Controlador es utilizado para

representar a la clase que representa al Sistema y dado que es una clase de cuyas instancias consumen

muchos recursos de CPU, se implementará el patrón Singleton. De esta forma en la ejecución del

Sistema, se asegurará que la clase controlador sea instanciada sólo una vez, evitando saturar los

recursos de memoria y procesamiento de la máquina donde se ejecute la aplicación.

5.1.1.2 DAO + Value Object

El Patrón DAO, es utilizado en su esencia de encapsular los accesos a una fuente de datos

(específicamente, a la Base de Datos). Las clases DAO se comunican con la clase Controlador a través

de valores almacenados en arreglos o listas y en algunos casos, a través de value objects.

Los value objects no son más que clases con sólo getters y setters que sirven para el pasaje de datos

entre capas, evitando así el acoplamiento entre la vista, el controlador y la capa de acceso a datos. Se

utilizan los value objects como “medio de transporte de datos” aunque en ocasiones no se asignen

valores a todos los atributos, ya que éstos se asignan a medida que son necesarios en cada caso.

5.1.1.3 Factoría Simple

Este patrón, propone asignar la responsabilidad de la creación de objetos de una misma familia a una

clase Factoría, la cual en tiempo de ejecución determina el tipo específico de los objetos a instanciar.

Este patrón será utilizado para resolver el problema que surge al tener el código de un artículo y no se

sabe qué artículo es específicamente.

Página 136

5.2 Diagramas de Colaboración Primer Incremento

5.2.1 Diagramas de Colaboración Gestionar Producto

5.2.1.1 Diagrama de Colaboración Ingresar nuevo Producto

Página 137

Ilustración 22: Diagrama de Colaboración Ingresar nuevo Producto

5.2.1.2 Diagrama de Colaboración Modificar Producto

Página 138

Ilustración 23: Diagrama de Colaboración Modificar Producto

5.2.1.3 Diagrama de Colaboración Buscar Productos

Página 139

Ilustración 24: Diagrama de Colaboración Buscar Productos

5.2.1.4 Diagrama de Colaboración Eliminar producto

Página 140

Ilustración 25: Diagrama de Colaboración Eliminar producto

5.2.1.5 Diagrama de Colaboración Verificar producto

Página 141

Ilustración 26: Diagrama de Colaboración Verificar producto

5.3 Diagramas de Colaboración Segundo Incremento

5.3.1 Diagrama de Colaboración Realizar Venta

5.3.1.1 Diagrama de Colaboración Ingresar Pre-Venta

Página 142

Ilustración 27: Diagrama de Colaboración Ingresar Pre-Venta

5.3.1.2 Diagrama de Colaboración Buscar Pre-Venta

Página 143

Ilustración 28: Diagrama de Colaboración Buscar Pre-Venta

5.3.1.3 Diagrama de Colaboración Agregar Producto

Página 144

Ilustración 29: Diagrama de Colaboración Agregar Producto

5.3.1.4 Diagrama de Colaboración Eliminar Producto

Página 145

Ilustración 30: Diagrama de Colaboración Eliminar Producto

5.3.1.5 Diagrama de Colaboración Finalizar Venta

Página 146

I

lustración 31: Diagrama de Colaboración Finalizar Venta

5.3.1.6 Diagrama de Colaboración Imprime Ticket

5.3.1.7 Diagrama de Colaboración Realizar Pago Efectivo

Esta funcionalidad no será diagramada, ya que sólo forma parte de la interfaz gráfica.

Página 147

Ilustración 32: Diagrama de Colaboración Imprimir Tickets

5.4 Diagrama de Clases

Página 148

6 Capítulo V: Pruebas

El objetivo que persiguen las pruebas, es la detección de errores, estos errores ocurren en la etapa de

diseño o construcción y muchas veces sin que los desarrolladores se den cuenta.

6.1 Pruebas Funcionales

Estas pruebas corresponden a las de caja negra. Con este método los casos de prueba y los resultados se

determinan a partir de la especificación funcional del método de una clase. Es decir, la prueba de caja

negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. Una prueba de caja

negra examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la

estructura lógica interna del software.

6.1.1 Ingresar al sistema

Propósito Probar la autenticación de un usuario al sistema

Prerrequisitos Usuario debe estar registrado

Datos correctos Rut: 15161614Contraseña: 1234

Datos incorrectos Rut: vacíoContraseña: vacío

Pasos1.- teclear Rut2.- teclear contraseña3.- Hacer clic en ingresar

Resultados esperados

Si los datos fueron correctos; ingresa inmediatamente a la sesión de trabajo correspondiente.

Si los datos son incorrectos; se envía mensaje de error y reingresar los datos erróneos.

Resultados obtenidos

Cuando los datos fueron correctos ingresa al entorno de sesión correspondiente.

Cuando algunos de los datos no fueron correctos o vacíos, se mostró un mensaje informando el error y retornó al formulario para la corrección de ellos.

Evaluación de la prueba No se encontraron errores en esta prueba.

Tabla 28: Prueba funcional: Ingresar al Sistema

Página 149

6.1.2 Ingresar Proveedor

Propósito Probar el registro de nuevo proveedor en el sistema.

Prerrequisitos Usuario debe estar autentificado como administrador.

Datos correctos

Rut: 12273554Razón Social: Ana Calvez DuranNombre Fantasia: Panadería ChiloeCiudad: ChillaánDirección: Reloncaví #914Teléfono: 229025Fax: 229025Contacto: Freddy Barahonae-mail: [email protected]ón: Panadería de los Puelches

Datos incorrectos

Rut: 12273554Razón Social: vacíoNombre Fantasía: vacíoCiudad: vacíoDirección: vacíoTeléfono: vacíoFax: vacíoContacto: vacíoe-mail: vacíoObservación: vacío

Pasos

1.- Hacer Clic en la opción de menú Gestión Proveedor 2.- Hacer Clic en la opción Ingresar Proveedor 3.- Teclear Rut del proveedor 4.- Teclear Razón Social del proveedor 5.- Teclear Nombre Fantasía del proveedor 6.- Teclear Ciudad del proveedor 7.- Teclear Dirección del proveedor 8.- Teclear Teléfono del proveedor 9.- Teclear Fax del proveedor 9.- Teclear Contacto del proveedor 10.- Teclear e-mail del proveedor 11.- Teclear Observación12.- Hacer clic en Guardar

Resultados esperados Si los datos fueron correctos se envía un mensaje de datos correctos.Si los datos son incorrectos se envía mensaje de error y reingresar los datos erróneos.

Resultados obtenidosCuando los datos son correctos se envía un mensaje de datos correctos.Cuando algunos de los datos no fueron correctos o vacíos, se mostró un mensaje informando el error y retorno al formulario para la corrección.

Evaluación de la prueba No se encontraron Errores en esta prueba

Tabla 29: Prueba funcional: Ingresar Proveedor

Página 150

6.1.3 Eliminar un proveedor

Propósito Probar Eliminar un proveedor.

Prerrequisitos Usuario debe estar autentificado como Administrador.

Datos correctos Seleccionar un proveedor.

Datos incorrectos No seleccionar un proveedor.

Pasos

1.- Hacer clic en la opción de menú Gestión De Proveedor.2.- Hacer Clic en la opción Eliminar Proveedor.3.- Seleccionar un Proveedor.4.- Hacer Clic en botón Eliminar


Si se ha seleccionado un proveedor, el proveedor es eliminado.

Si no se ha seleccionado ningún proveedor, al presionar el botón Eliminar se muestra un mensaje de error indicando que se debe seleccionar un proveedor.


Cuando se seleccionó un proveedor este fue eliminado del sistema.

Cuando no se ha seleccionó un proveedor, al presionar el botón eliminar, se muestra un mensaje de error indicando que se debe seleccionar un proveedor.


Tabla 30: Prueba funcional: Eliminar Proveedor

Página 151

6.1.4 Ingresar Producto

Propósito Probar el registro de nuevo producto en el sistema.

Prerrequisitos Usuario debe estar autentificado como administrador.

Datos correctos

Código: 100010019Marca: ThermoCategoría: HogarPrecio Costo: 4765Precio Venta: 6990Stock: 25Stock crítico: 5Inactivo: Seleccionado

Datos incorrectos

Código: 100010019Marca: VacíoCategoría:VacíoPrecio Costo: VacíoPrecio Venta: VacíoStock: VacíoStock crítico: VacíoInactivo: Sin seleccionar

Pasos

1. Hacer Clic en la opción del menú Gestión de Productos2. hacer Clic en la opción Ingresar productos3. Teclear Código4. Teclear Marca5. Teclear Categoría6. Teclear Precio Costo7. Teclear Precio Venta8. Teclear Stock: Vacío9. Teclear Stock crítico10. Seleccionar Inactivo11. Hacer clic en Guardar

Resultados esperadosSi los datos fueron correctos se envía un mensaje de datos correctos.

Si los datos son incorrectos se envía mensaje de error y reingresar los datos erróneos.


Cuando los datos son correctos, se envía un mensaje de datos correctos.

Cuando algunos de los datos no fueron correctos o vacíos, se mostró un mensaje informando el error y retorno al formulario para la corrección.


Tabla 31: Prueba funcional: Ingresar Producto

Página 152

6.1.5 Eliminar Producto

Propósito Probar Eliminar un producto.

Prerrequisitos Usuario debe estar autentificado como Administrador.

Datos correctos Seleccionar un producto.

Datos incorrectos No seleccionar un producto.

Pasos

1.- Hacer clic en la opción de menú Gestión De Productos.2.- Hacer Clic en la opción Eliminar Productos.3.- Seleccionar un Productos.4.- Hacer Clic en botón Eliminar


Si se ha seleccionado un Productos, el Productos es eliminado.

Si no se ha seleccionado ningún Productos, al presionar el botón Eliminar se muestra un mensaje de error indicando que se debe seleccionar un Productos.


Cuando se seleccionó un Productos este fue eliminado del sistema.

Cuando no se ha seleccionó un Productos, al presionar el botón eliminar, se muestra un mensaje de error indicando que se debe seleccionar un Productos.


Tabla 32: Prueba funcional: Eliminar Producto

Página 153

6.1.6 Ingresar nuevo usuario

Propósito Probar el registro de nuevo usuario en el sistema.

Prerrequisitos Usuario debe estar autentificado como administrador

Datos correctos

Rut: 15161614Nombre: HansApellido Paterno: VillablancaApellido Materno: LagosContraseña: 1234abcdCiudad: ChillánComuna: ChillánDirección: Reloncaví Numero de Casa: 914Teléfono: 228504e-mail: [email protected]: administrador

Datos incorrectos

Rut: 15161614Nombre: VacíoApellido Paterno: VacíoApellido Materno: VacíoContraseña: VacíoCiudad: VacíoComuna: VacíoDirección: VacíoNumero de Casa: VacíoTeléfono: Vacíoe-mail: Vacíoprivilegio: Vacío

Pasos

1. Hacer Clic en la opción de menú Gestión Usuario2. Hacer Clic en la opción Registrar Usuario3. Teclear Rut4. Teclear Nombre5. Teclear Apellido Paterno6. Teclear Apellido Materno7. Teclear Contraseña8. Teclear Ciudad9. Teclear Comuna10. Teclear Dirección11. Teclear Numero de Casa12. Teclear Teléfono13. Teclear e-mail14. Seleccionar el privilegio administrador15. Hacer Clic en Guardar

Resultados esperados Si los datos fueron correctos se envía un mensaje de datos correctosSi los datos son incorrectos se envía mensaje de error y reingresar los datos erróneos.

Resultados obtenidosCuando los datos son correctos se envía un mensaje de datos correctos.Cuando algunos de los datos no fueron correctos o vacíos, se mostró un mensaje informando el error y retorno al formulario para la corrección de ellos


Tabla 33: Prueba funcional: Ingresar Nuevo Usuario

Página 154

6.1.7 Realizar Venta

Propósito Probar Realizar una Venta

Prerrequisitos Usuario debe estar autentificado como administrador o cajero.

Datos correctos Cantidad de productos Valor positivo

Datos incorrectos Cantidad de productos valor negativo

Pasos

1. Hacer Clic en la opción de menú Gestión Ventas2. Hacer Clic en la opción Realizar Venta3. Seleccionar pre-venta buscada o Teclear código pre-venta.4. Seleccionar el producto buscado o Teclear código del producto.5. Hacer Clic en el botón Venta6. Seleccionar Vendedor 7. Seleccionar Descuento (Dato no obligatorio)8. Seleccionar Medio de Pago.9. Teclear Cantidad de dinero a pagar10. hacer Clic en el botón Vender


Si se ingresan los datos correctamente, se envía un mensaje de Operación Exitosa.

Si los datos son incorrectos se envía mensaje de error y retorno al formulario para la corrección de ellos.


Cuando los datos son correctos se despliega pantalla Mensaje de Operación Exitosa.

Cuando los datos ingresados son erróneos, se mostró un mensaje error y retorna al formulario para la corrección de ellos.


Tabla 34: Prueba funcional: Realizar Venta

Página 155

Conclusiones

El desarrollo del proyecto permitió realizar una descripción de la situación actual haciéndose un

análisis de los requerimientos de Importadora Villablanca, debido a esto se logró determinar las

necesidades y a través de ellas el funcionamiento de los procesos de la empresa. Luego de la

construcción de la aplicación, se realiza una comparación entre los objetivos que se plantearon

inicialmente versus los resultados obtenidos. De acuerdo a éstos, tenemos lo siguiente:

▪ Los requerimientos se lograron satisfactoriamente, pudiendo ahora el administrador

controlar los procesos de ventas, inventarios, productos, compras y accesos de usuarios.

Ayudando de esta forma, la toma de decisiones de la empresa en su administración.

▪ La solución propuesta, resultó ser accesible de fácil utilización para los usuarios, lo que

es un factor significativo a la hora de familiarizarse con la aplicación, para efectuar

ventas y pre ventas.

Al momento de comenzar el desarrollo de la aplicación, se optó por utilizar un enfoque orientado a

objetos, con un modelo Vista Controlador, pensando siempre en la continuación con el desarrollo del

Sistema, considerando la reutilización de componentes y la expansibilidad del software. A partir de lo

anterior, se logró la aplicación de una plataforma base, sobre la cual se pueden agregar futuras

funcionalidades con un mínimo de implementación. La documentación generada en este informe

permite comprender de manera clara la arquitectura adoptada, de tal forma que otro desarrollador

puede tomarla, analizarla y realizar las modificaciones que se estimen convenientes en el Sistema sin

significar esto una mayor dificultad.

Página 156

La adopción del ciclo de desarrollo iterativo incremental permitió dividir el ámbito de requerimientos a

trabajar en dos incrementos. Esto permitió centrar la atención del analista/desarrollador en dos partes y

no en el sistema completo, lo que ayudó a alcanzar cierto grado de abstracción, reduciendo

considerablemente el riesgo de cometer errores durante el desarrollo de cada incremento, ya que

obviamente es menos costosa la corrección de errores en una parte del Sistema que en el Sistema

completo.

Cabe destacar la activa participación del administrador a lo largo del desarrollo del proyecto, lo que

denota su idea de construir un producto a la medida y que se adapte a las necesidades propias de la

empresa.

En el estudio de factibilidad, el proyecto resultó completamente abordable en los aspectos técnicos,

operacional, político y de fechas. Sin embargo, el estudio económico determinó que no era factible.

Esto ocurrió, debido que el estudio no considera los beneficios intangibles que este proyecto posee.

Las pruebas aplicadas en el software, permitieron la detección de errores a tiempo, para luego corregir

oportunamente y asegurar que la empresa contará con un producto de calidad al momento de ser

implementada en la empresa.

Para finalizar, se puede mencionar que los procesos operativos implementados en el nuevo sistema

redujo aproximadamente un 85% del tiempo en espera de 42 a 6 segundos en buscar un producto, las

ventas minimizaron el tiempo de espera de 3 minutos con 5 segundos a 1 minuto con 2 segundos en

promedio de una transacción, para las pre ventas se estima una disminución de un 68%

aproximadamente en el tiempo de espera. Además, cómo resultado el sistema quedó en marcha blanca

en la empresa.

Página 157

Las proyecciones futuras, es seguir implementando nuevas funcionalidades al sistema a partir de las

necesidades que se van incorporando al negocio, como también, es posible la culminación de la

impresión de facturas y boletas previa autorización del servicio de impuestos Internos, pagos con

medios de tarjetas de créditos, generación de códigos de barras para los productos, la incorporación de

un módulo especial para el área contable de la empresa, enfocado al pago de impuestos y

remuneraciones.

Página 158

Bibliografía

LARMAN, Craig. (2003): UML y patrones: Introducción al análisis y diseño orientado a objetos y al

proceso unificado. Madrid: Prentice-Hall. Segunda Edición. Número de páginas: 624.

LARMAN, Craig. (2003). UML y Patrones. Una Introducción al Análisis y Diseño Orientado a

Objetos y al Proceso Unificado. 2da. Edición. Prentice Hall. Pag. 418

PC FACTORY, cotización de computadores.

http://www.pcfactory.cl/kit.php?id=8e0c1e0e-fad1-4afc-9871-230e7963039b [Consultada: 08 junio

2010]

PC FACTORY, Impresora POS Térmica TM T88 IV Serial

http://www.pcfactory.cl/ficha.php?id=f32912a4-441d-41cc-84bd-b0c1d16e0b9a [Consultada: 08 junio

2010]

PC FACTORY, Lector Código de Barras USB CCD ZT800U http://www.pcfactory.cl/ficha.php?id=d63823ca-3001-47e3-aa67-64de0d44765b [Consultada: 08 junio

2010]

OLX, sitio de compradores y vendedores

http://quillota.olx.cl/programador-iid-103208603 [Consulta: Consultada: 01 julio 2010]

Página 159

Curso, Análisis y Diseño Orientado a Objetos

http://www.dcc.uchile.cl/~luguerre/cc40b/clase9.html [Consulta: 18 Junio 2010]

Grimpi IT Blog

http://grimpidev.wordpress.com/2008/04/09/el-patron-dao/ [Consulta: 18 Junio 2010]

Página 160

Sistema de Administración y Ventas para Importadora...

Documents

Transcript of Sistema de Administración y Ventas para Importadora...