sistema de administración y ventas para importadora...
TRANSCRIPT
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
Página 19
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
Referencia Función Categoría
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
Referencia Función Categoría
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
Referencia Función Categoría
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
Referencia Función Categoría
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
Referencia Función Categoría
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
Referencia Función Categoría
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
Referencia Función Categoría
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
Referencia Función Categoría
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
Referencia Función Categoría
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.
Referencia Función Categoría
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.
Referencia Función Categoría
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
Hardware (Requerimientos mínimos) Software
• Procesador: Intel Centrino Duo 1.5 GHz
• Memoria RAM: 2GB
• Disco Duro: SATA-160 GB.
• Tarjeta de Red: 10/100 Mbps.
• Ubuntu 10.4 (Lucide, núcleo Linux 2.6.32,
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)
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.
• Ubuntu 10.4 (Lucide, núcleo Linux 2.6.32,
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
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
Actores :Administrador
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
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas :R.1.4
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas : R.1.5
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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.
Referencia Cruzadas :R.2.1
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas :R.2.3
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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.
2.- El sistema solicita los datos necesarios para realizar la búsqueda.
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
Actores :Administrador
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
Referencias Cruzadas :R.2.4
Curso Normal de Eventos
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
Actores :Administrador
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
Referencias Cruzadas :R.2.5
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas :R.3.1
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas : R.3.2
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
pantalla. Se ejecuta paso 3.
Página 88
4.1.1.3.3 Caso de Uso: Buscar Categoría
Actores :Administrador
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
Referencia Cruzadas : R.3.3
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
1.- Este caso de uso comienza cuando el Administrador indica al sistema que desea buscar una categoría, en base a tipo.
2.- El sistema solicita los datos necesarios para realizar la búsqueda.
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
Actores :Administrador
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
Referencia Cruzadas :R.3.4
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
resultado de la búsqueda.
Tipo :Secundario
Referencia Cruzadas :R.3.5
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas :R.4.1
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
mensaje en pantalla. Se ejecuta paso 3.
Página 92
4.1.1.4.2 Caso de Uso: Modificar Usuario
Actores :Administrador
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
Referencia Cruzadas :R.4.2
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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.
6.- El sistema guarda los cambios realizados.
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
Actores :Administrador
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
Referencia Cruzadas :R.4.3
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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.
2.- El sistema solicita los datos necesarios para realizar la búsqueda.
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
Actores :Administrador
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
Referencia Cruzadas :R.4.4
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
resultado de la búsqueda.
Tipo :Secundario
Referencia Cruzadas :R.4.5
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas :R.4.6
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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.
6.- El sistema guarda los cambios realizados.
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 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.
Actores :Administrador
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
Referencia Cruzadas :R.5.1
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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.
6.- El sistema guarda los cambios realizados.
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 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
Referencia Cruzadas :R.5.2
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Referencia Cruzadas :R.6.1
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
mensaje en pantalla. Se ejecuta paso 3.
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
Referencia Cruzadas :R.6.2
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
1.- Este caso de uso comienza cuando el cajero indica al sistema que desea buscar una pre-venta por fecha.
2.- El sistema solicita los datos necesarios para realizar la búsqueda.
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
pantalla. Se ejecuta paso 3.
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.
Referencia Cruzadas :R.6.3
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Línea 4a :Los datos ingresados no son válidos. El sistema notifica el Cajero con un mensaje en
pantalla. Se ejecuta paso 3.
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
Referencia Cruzadas :R.2.3
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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.
2.- El sistema solicita los datos necesarios para realizar la búsqueda.
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
Línea 4a :Los datos ingresados no son válidos. El sistema notifica el Cajero con un mensaje en
pantalla. Se ejecuta paso 3.
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.
Referencia Cruzadas :R.6.4
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Referencia Cruzadas :R.6.5
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
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
mensaje en pantalla. Se ejecuta paso 3.
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
Referencia Cruzadas :R.6.6
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Este caso de uso está descrita previamente en el punto 4.5.2.2.3, Descripción de caso de uso Realizar
Ventas.
4.1.3.2.3 Caso de Uso: Verificar producto
Este caso de uso está descrita previamente en el punto 4.5.2.2.5, Descripción de caso de uso Realizar
Ventas.
4.1.3.2.4 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 Realizar
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.
Referencia Cruzadas :R.7.1
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas :R.8.1
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas :R.8.2
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
1.- Este caso de uso inicia cuando el administrador solicita al Sistema un informe de Productos.
2.- El Sistema genera informe de Productos.
3.- El Sistema muestra el informe generado.
Página 115
4.1.3.3.3 Caso de Uso: Informe Proveedores
Actores :Administrador
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
Referencia Cruzadas :R.8.3
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
1.- Este caso de uso inicia cuando el administrador solicita al Sistema un informe de Productos.
2.- El Sistema genera informe de Productos.
3.- El Sistema muestra el informe generado.
Página 116
4.1.3.3.4 Caso de Uso: Informe Ventas
Actores :Administrador
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
Referencia Cruzadas :R.8.4
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas :R.8.5
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas :R.8.6
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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.
3.- El Sistema muestra el informe generado.
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
Actores :Administrador
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
Referencia Cruzadas :R.9.1
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
mensaje en pantalla. Se ejecuta paso 3.
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.
4.1.3.4.4 Caso de Uso: Verificar 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
Actores :Administrador
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.
Referencia Cruzadas :R.9.2
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Línea 4a :Los datos ingresados no son válidos. El sistema notifica al administrador con un
mensaje en pantalla. Se ejecuta paso 3.
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
Actores :Administrador
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
Referencia Cruzadas :R.10.1
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas :R.10.2
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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
Referencia Cruzadas :R.10.3
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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.
5.- El Sistema verifica que los datos proporcionados sean correctos.
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
Actores :Administrador
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
Referencia Cruzadas :R.10.1
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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.
5.- El Sistema verifica que los datos proporcionados sean correctos.
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
Actores :Administrador
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
Referencia Cruzadas :R.10.2
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Actores :Administrador
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.
Referencia Cruzadas :R.10.3
Curso Normal de Eventos
Acción del Actor Respuesta del Sistema
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
Línea 4a :Los datos ingresados no son válidos. El sistema notifica al administrador con un
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
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
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
Resultados esperados
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.
Resultados obtenidos
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.
Evaluación de la prueba No se encontraron errores en esta prueba.
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.
Resultados obtenidos
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.
Evaluación de la prueba No se encontraron Errores en esta prueba
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
Resultados esperados
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.
Resultados obtenidos
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.
Evaluación de la prueba No se encontraron errores en esta prueba.
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
Evaluación de la prueba No se encontraron Errores en esta prueba
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
Resultados esperados
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.
Resultados obtenidos
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.
Evaluación de la prueba No se encontraron errores en esta prueba.
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