1.1 IntroducciónLa realidad de muchos negocios bolivianos es que actualmente continúan llevando un control de sus ventas manual, lo cual no es muy eficiente ya que esto lleva más tiempo y puede ocasionar errores al momento de llevar cuentas.
El comercio electrónico emergió desde hace mucho tiempo en los Estados Unidos los que actualmente en muchos países ya realizan las ventas y compras mediante las páginas web o incluso en las redes Sociales realizan la venta y compra de productos.
En Bolivia todavía no se realiza la venta y compra de productos en la web en su totalidad, en este proyecto realizaremos la implementación de un sistema de ventas de una Salteñeria.
En este proyecto se utilizarán 2 metodologías que son la OOHDM que nos servirá para el desarrollo de toda nuestra documentación como también utilizaremos la metodología XP también conocida como XP Programing que utilizaremos más para la recaudación de nuestra información es decir describir todos los requerimientos en historias de Usuario, enviar esa información a los desarrolladores para que comiencen la codificación y el diseño del sistema sea más rápido, efectivo y en poco tiempo después evaluar revisar las pruebas del sistema y corregir o modificar el sistema según lo mencione el usuario y describir en las historias de usuario para reiniciar el proceso del desarrollo del sistema.
Como también demostraremos el equipo necesario para su implantación es decir los servidores, routers, switches y computadoras,
1.2 AntecedentesA las ventas se le conoce como una forma de transacción o un como un intercambio de productos, pero por un valor monetario, que antiguamente no se conocía, y se comercializaba mediante el trueque que también es una forma de intercambio de productos, pero no tiene un valor monetario. Pero después de un largo periodo el hombre fue evolucionando e invento la moneda, pero no se conoce certeramente en qué lugar se emitieron las primeras monedas ni cuando se empezaron a circular con un valor de cambio, sin embargo, algunas fuentes revelan que comenzaron a utilizar los hititas.
Antes del 2.500 antes de Cristo existía en las ciudades del valle del Tigris y del Éufrates, en las del Indo y en las del Nilo un tipo de moneda muy especial.
Las gentes traían la parte sobrante de sus productos a los templos de las ciudades amuralladas. Allá los sacerdotes contables abrían una cuenta corriente con fichas de barro a cada persona, ingresando sus productos en el almacén del templo y estableciendo una cantidad de dinero abstracto en función de las mercancías ingresadas, podemos deducir que desde que existió en ese entonces una forma precaria de la moneda las comercializaciones y las formas de transacción de un negocio ha ido evolucionando hasta la actualidad en la cual efectuamos nuestro comercio con mucho más criterio y más audacia.
El comercio electrónico, también conocido como e-commerce (electronic commerce) o bien negocios por Internet o negocios online, consiste en la compra y venta de productos o de servicios a través de medios electrónicos, tales como Internet y otras redes informáticas.
La cantidad de comercio llevada a cabo electrónicamente ha crecido de manera extraordinaria debido a Internet. Una gran variedad de comercio se realiza de esta manera, estimulando la creación y utilización de innovaciones como la transferencia de fondos electrónica, la administración de cadenas de suministro, el marketing en Internet, el procesamiento de transacciones en línea (OLTP), el intercambio electrónico de datos (EDI), los sistemas de administración del inventario y los sistemas automatizados de recolección de datos.
1.3 Planteamiento del ProblemaBolivia no tiene un gran índice de penetración de las tecnologías de la información a diferencia de sus vecinos, lo cual ocasiona que la gente no esté tan acostumbrada al uso de sistemas computarizados para el control de determinadas tareas.
1.3.1 Problema PrincipalActualmente la mayoría de los negocios bolivianos no cuentan con un sistema que registre y modifique los datos actuales de dicho negocio.
Ocasionando un manejo de información empírica de parte de los responsables esto genera la perdida de la misma y una deficiencia en el crecimiento del establecimiento.
1.3.2 Problemas Específicos Existe perdida de Información de los recursos actuales en el negocio. No hay control sobre las ventas generando incertidumbre en el negocio. Presenta retrasos en los cálculos por falta de información
1.4.1 Objetivo GeneralDesarrollar un sistema para el almacenamiento de información de los recursos actuales, las ventas realizadas por cada día en cada sucursal
1.4.2 Objetivos Específicos Simplificar la contabilidad y el registro de las tareas envueltas en el negocio. Facilitar el ingreso de las ventas, además de reducir los errores del cajero. Determinar en forma exacta las ventas realizadas en ciertos periodos del
año.
1.5 Límites de Proyecto Los Limites del Proyecto son:
El Sistema no controlara el horario laboral de sus empleados. El cajero solo podrá tener el control de productos para las ventas y el
control de ventas por cada sucursal. Solamente el Administrador es el que podrá tener un informe completo de
las ventas realizadas en las distintas sucursales.
1.6 Alcances del ProyectoLos Alcances del Proyecto son:
El Administrador podrá controlar las ventas en las Sucursales, los Productos necesarios y a la Gestión de Usuario.
El Sistema registrara a un Usuario como el Empleado El Registro de las Ventas se almacenará en una base de datos cuya página
seria vía web. El Administrador podrá actualizar y modificar los datos del sistema
CAPITULO II: METODOLOGIA DE DESARROLLO
2.1 Selección de MetodologíasPara el desarrollo de este proyecto de este proyecto haremos uso de dos metodologías
OOHDM. - Para generar documentación
XP. - Para desarrollar el proyecto en poco tiempo
2.2 Metodología OOHDMObject-Oriented Hypermedia Design Method (OOHDM) es un método orientado a modelos para el desarrollo de aplicaciones Web. Este método permite a los diseñadores especificar una aplicación Web mediante el uso de varios meta-modelos especializados: conceptual, navegación y de interfaz de usuario.
Algunas Características a resaltar:
OOHDM está basada en el paradigma de la orientación a objetos. A diferencia de HDM, no sólo propone un modelo para representar a las
aplicaciones multimedia, sino que propone un proceso predeterminado para el que indica las actividades a realizar y los productos que se deben obtener en cada fase del desarrollo.
Existen varios intérpretes de estos modelos encargados de producir una aplicación Web basada en ellos: el ambiente HyperDE y el framework Cazon.
2.3 Proceso de desarrollo El siguiente grafico nos muestra cómo interactúan de alguna manera las etapas o fases de esta metodología, pero la explicación de las mismas se presenta a continuación.
2.4 Fases o etapas OOHDM propone el desarrollo de aplicaciones hipermedia a través de un proceso compuesto por cuatro Fases: diseño conceptual, diseño navegacional, diseño de interfaces abstractas e implementación.
2.4.1 Obtención de RequerimientosLa herramienta en la cual se fundamenta esta fase son los diagramas de casos de usos, los cuales son diseñados por escenarios con la finalidad de obtener de manera clara los requerimientos y acciones del sistema.
2.4.2 Diseño ConceptualSe construye un modelo orientado a objetos que represente el dominio de la aplicación usando las técnicas propias de la orientación a objetos.
La finalidad principal durante esta fase es capturar el dominio semántico de la aplicación teniendo en cuenta el papel de los usuarios y las tareas que desarrollan.
2.4.3 Diseño NavegacionalLa estructura de navegación de una aplicación hipermedia está definida por un esquema de clases de navegación específica, que refleja una posible vista elegida.
En OOHDM hay una serie de clases especiales predefinidas, que se conocen como clases navegacionales:
Nodos: Los nodos son contenedores básicos de información de las aplicaciones.
Los nodos contendrán atributos de tipos básicos (donde se pueden encontrar tipos como imágenes o sonidos) y enlaces.
Enlaces: Los enlaces reflejan la relación de navegación que puede explorar el usuario. Ya sabemos que para un mismo esquema conceptual puede haber diferentes:
o Estructuras de accesoo Los menuso Los indiceso Las guías de ruta
2.4.4 Diseño de Interfaz AbstractaEsto consiste en definir:
Qué objetos de interfaz va a percibir el usuario El camino en el cuál aparecerán los diferentes objetos de navegación Qué objeto de interfaz actuarán en la navegación La forma de sincronización de los objetos multimedia y el interfaz de
transformaciones.
MODELOS DE VISTAS ABSTRACTAS DE DATOS (ADVs): los modelos de los ADVs no son más que representaciones formales que se usan para mostrar todo esto.
2.4.5 ImplementaciónUna vez cumplidas las 4 fases anteriores solo queda llevar los objetos a un lenguaje concreto de programación:
Productos: Aplicación ejecutable Herramientas: El entorno del lenguaje de programación Mecanismos: Los ofrecidos por el lenguaje Objetivo de diseño: Obtener la aplicación ejecutable
2.5 Metodología XPCuando se requiere que un software sea desarrollado de manera ágil las metodologías enfocadas a este tema son la solución para que los desarrolladores se adapten a los cambios a los que puede estar sujeto un proyecto de software, y así asegurar un sistema que tenga éxito.
Para quienes trabajan en la metodología ágil es más importante hacer un software de buena calidad, que hacer una documentación excelente, pero para que el software sea funcionarle se necesita la colaboración constante del cliente y los miembros de un equipo de trabajo.
La programación extrema en sí, comienza mucho antes de que Kent Beck, el creador de las metodologías agiles propusiera su nombre, ya que en 1989 Cunningham quien trabaja para la compañía “Wyatt Software” utilizó muchas técnicas que adoptaban principios de XP.
Fue en 1999 cuando el Ingeniero en ciencias de la computación Beck, dio nombre a esta metodología ágil, aduciendo que serviría para realizar un producto final con excelencia, desde ahí quienes apoyan estos principios han hecho que esta metodología sea muy conocida
XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos, muy cambiantes y donde existe un alto riesgo técnico.
2.5.1 ActoresAunque en otras fuentes de información aparecen algunas variaciones y extensiones de roles XP, en este apartado describiremos los roles de acuerdo con la propuesta original de Beck.
2.5.1.1 ProgramadorEl programador escribe las pruebas unitarias y produce el código del sistema. Debe existir una comunicación y coordinación adecuada entre los programadores y otros miembros del equipo.
2.5.1.2 ClienteEl cliente escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio. El cliente es sólo uno dentro del proyecto, pero puede corresponder a un interlocutor que está representando a varias personas que se verán afectadas por el sistema.
2.5.1.3 Encargado de pruebas (Tester)El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.
2.5.1.4 Encargado de seguimiento (Tracker)El encargado de seguimiento proporciona realimentación al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. También realiza el seguimiento del progreso de cada iteración y evalúa si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cuándo es necesario realizar algún cambio para lograr los objetivos de cada iteración.
2.5.1.5 Entrenador (Coach)Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guías a los miembros del equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente.
2.5.1.6 ConsultorEs un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Guía al equipo para resolver un problema específico.
2.5.1.7 Gestor (Big boss)Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.
2.6 Proceso de DesarrolloLa Programación extrema usa un enfoque orientado a objetos como paradigma de desarrollo, y engloba un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades estructurales: Planeación, diseño, codificación y pruebas.
2.7 Fases o etapasEste método se basa principalmente en 4 valores o principios bien definidos:
2.7.1 PlaneaciónLa Actividad de planeación comienza escuchando la actividad para recabar requerimientos que permite que los miembros técnicos del equipo XP entiendan y adquieran la sensibilidad de la salida y características principales y funcionalidad que se requieren.
Escuchar lleva a la creación de algunas historias (también llamadas historias de usuario) que describen la salida necesaria, características y funcionalidad del software que se va a elaborar.
Después los miembros del equipo XP evalúan cada historia y le asignan un costo, medido en semanas de desarrollo. Si se estima la historia requiere más de 3 semanas de desarrollo, se pide al cliente que la descomponga en historias más chicas y de nuevo se asigna un valor y costo. Es Importante observar que en cualquier momento se puede escribir nuevas historias.
Los Clientes y Desarrolladores trabajan juntos para decidir cómo agrupar las historias en la siguiente entrega (el siguiente incremento de software) que desarrollara el equipo XP. Una vez que se llega a un compromiso sobre la entrega (acuerdo sobre las historias por incluir, la fecha de entrega y otros aspectos del proyecto), el equipo XP ordena las historias que serán desarrolladas en una de tres formas
1) Todas las historias se implementarán de inmediato (en pocas semanas)
2) Las Historias con más valor entraran a la programación de actividades y se implementaran en primer lugar
3) Las Historias más riesgosas formaran parte de la programación de actividades y se implementaran primero.
La Velocidad del Proyecto es el número de historias de los clientes implementados durante la primera entrega. La Velocidad del Proyecto se usa para:
1) Ayudar a estimar las fechas de entrega y programar las actividades para las entregas posteriores.
2) Determinar si se ha hecho un gran compromiso para todas las historias durante todo el desarrollo del proyecto. En caso de que ocurra, se modifica el contenido de las entregas o se cambian las fechas de entrega final
A medida que avanza el trabajo, el Cliente puede agregar historias, cambiar el valor de una ya existente, descomponerlas o eliminarlas.
2.7.2 DiseñoEl Diseño XP sigue rigurosamente el principio MS (Mantenlo Sencillo). Un diseño sencillo siempre prefiere sobre una representación más compleja. Además, el diseño guía la implementación de una historia conforme se escribe.
Si en el diseño de una historia se encuentra un problema de diseño difícil, XP recomienda la creación inmediata de un prototipo operativo de esa porción del diseño. Entonces, se implementa y evalúa el prototipo del diseño el prototipo del diseño, llamado solución en punta. El objetivo es disminuir el riesgo cuando comience la implementación verdadera y validar las estimaciones originales para la historia que contiene el problema de diseño.
El Objetivo del rediseño en XP es controlar dichas modificaciones, surgiendo pequeños cambios en el diseño que son “Capaces de mejorarlo de forma radical” [Fow00]. Sin embargo, debe notarse que el esfuerzo que requiere el rediseño aumenta en forma notable con el tamaño de la aplicación.
Un concepto central en XP es que le diseño ocurre tanto antes como después de que comienza la codificación. Rediseñar significa que el diseño se hace de manera continua conforme se construye el sistema. En realidad, la actividad de construcción en si misma dará al equipo XP una guía para mejorar el diseño.
2.7.3 CodificaciónDespués de que las historias han sido desarrolladas y de que se ha hecho el trabajo de diseño preliminar, el equipo no inicia la codificación, sino que desarrolla una serie de pruebas unitarias a cada una de las historias que se van a incluir en la entrega en curso (incremento de software). Una vez creada la prueba unitaria,
El desarrollador esta mejor capacitado para centrarse en lo que debe implementarse para pasar la prueba. Una vez que el código está terminado se le aplica de inmediato una prueba unitaria, con lo que se obtiene retroalimentación instantánea para los desarrolladores.
XP recomienda que dos personas trabajen juntas en una estación de trabajo con el objeto de crear código para una historia. Esto da un mecanismo para la solución de problemas de tiempo real (el código se revisa conforme se crea),
A medida que las parejas de programadores terminan su trabajo, el código que desarrollan se integra con el trabajo de los demás. En Ciertos casos, esto lleva a cabo a diario un equipo de integración. En otros, las parejas de programadores tienen la responsabilidad de la integración
Esta estrategia de “Integración continua” ayuda a evitar los problemas de compatibilidad e interfaces y brinda un ambiente de “Prueba de Humo”.
2.7.4 PruebasLas Pruebas de aceptación XP también llamadas pruebas del cliente, son especificadas por el cliente y se centran en las características y funcionalidades generales del sistema que son visibles y reversibles por parte del cliente. Las pruebas de aceptación se derivan de las historias de los usuarios que se han implementado como parte de la liberación del software.
Las Pruebas unitarias que se crean deben implementarse con el uso de una estructura que permita automatizarlas (de modo que puedan ejecutarse en repetidas veces y con la facilidad) Esto estimula una estrategia de pruebas de regresión.
Esto da al equipo XP una indicación continua del avance y también lanza señales de alerta si las cosas marchan mal “Corregir pequeños problemas cada cierto número de horas toma menos tiempo que resolver problemas enormes justo antes del plazo final”
2.8 Notación UMLUnified Modeling Language es un lenguaje de propósito general para el modelado orientado a objetos. UML combina notaciones provenientes desde:
Modelado Orientado a Objetos
Modelado de Datos
Modelado de Componentes
Modelado de Flujos de Trabajo (Workflows)
UML comenzó como el “Método Unificado”, con la participación de Grady Booch y Jim Rumbaugh. Se presentó en el OOPSLA’95. El mismo año se unió Ivar
Jacobson. Los “Tres Amigos” son socios en la compañía Rational Software. Herramienta CASE Rational Rose
2.8.1 Tipos de diagramas UMLDiagrama de Casos de Uso
Diagramas de casos de Uso de Alto Nivel
Diagramas de Casos de Uso Expandido
Diagrama de Secuencia
Diagrama de Componentes
Diagrama de Despliegue
2.8.1.1 Diagrama de Casos de UsoCasos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje. No pertenece estrictamente al enfoque orientado a objeto, es una técnica para captura de requisitos.
Se clasifican esencialmente en dos tipos: Casos de uso de alto nivel y casos de uso expandidos.
2.8.1.1.1 Diagrama de Casos de Uso de alto nivelEstos casos de uso generalmente son muy breves describiendo procesos en dos o tres oraciones. Este caso de uso se puede representar de dos maneras: gráfica como se muestra en la Figura y de acuerdo a su estructura como se muestra en su descripción.
Actor
CasoUso2
CasoUso3
CasoUso1
«uses»
Nombre del sistema
2.8.1.1.2 Diagrama de Casos de Uso expandidoSon descripciones extensas que pueden contener cientos de oraciones con las cuales se realiza la descripción de un proceso completo. Este caso de uso se representa gráficamente como se muestra en la figura y su estructura de descripción se describe en la Tabla.
2.8.2 Diagrama de secuenciasEste diagrama (también llamado diagrama de interacción) muestra las interacciones entre un conjunto de objetos (clases, actores) Ordena la secuencia
según el tiempo en que tienen lugar. Muestran el orden de las llamadas en el sistema. Es imposible representar en un solo diagrama la secuencia de todas las llamadas posibles del sistema.
2.8.1.3 Diagrama de clasesEl Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones
CAPITULO III: MARCO PRACTICO
3.1 Estudio de factibilidadSe realizó el estudio de factibilidad, para poder ver si el realizar el sistema es una solución factible, dicho estudio se encuentra en el Anexo 1
3.2 Plan de desarrollo
3.3 Análisis de la situación actualActualmente la mayoría de las tiendas del país no cuentan con un sistema de ventas computarizado, lo cual dificulta el control de las ventas y ganancias, provoca pérdidas de producto y dificulta el control del personal. Para poder ver esto de manera más grafica utilizaremos diagramas de casos de uso y diagramas de secuencia.
3.4 Especificación de requerimientosEn la especificación de requerimientos se muestra a los actores del sistema, el proceso que llevaran al cabo de realizar alguna tarea además se menciona a las historias de usuario que es la primera etapa de la metodología XP como también los actores de esta metodología.
3.4.1 Tabla de actoresCargo Perfil DescripciónVendedor de tienda
Vendedor Se ocupa de la venta de productos y la recepción de nuevo inventario
Dueño o Administradores de la tienda
Administrador Además de vender y recibir productos se encarga del análisis de reportes de ganancias y pérdidas de la tienda.
Cargo Perfil DescripciónEmpleado -- Se ocupa de atender mesas, no
interactúa directamente con el sistema que se está produciendo.
Cliente -- Es al que se entregara el producto, no interactúa directamente con el sistema que se esta produciendo.
3.4.2 Tabla de procesosProceso DescripciónGestión de Usuarios Un proceso donde se podrán registrar a los usuarios
que tendrán acceso al sistema.Autenticar usuario Proceso donde se verificará al momento de ingresar
al sistema que el usuario introducido este registrado.Venta Proceso donde se registrará una venta.Añadir Inventario Proceso donde se registrará la llegada de nuevo
inventario.Listar Compras Dar una lista de objetos comprados por un cliente o
añadidos a inventario.Buscar productos Poder realizar búsquedas de productos disponibles
en la tienda.Reportes Proceso que se encargara de la generación de
reportes ordenados por día, mes, año o sucursal donde podremos ver las entradas y salidas de dinero de una tienda.
Administrar productos disponibles
Proceso que se encarga de añadir, modificar o inactivar productos disponibles en la tienda.
3.4.3 Historias de usuarioPara la recolección y documentación de requisitos se usó la herramienta de historias de usuario la cual se encuentra en el anexo 2.
3.4.4 Tabla de requisitosNro.
Requerimiento Tipo
R1 Registro de ventas realizadas FuncionalR2 Añadir inventario FuncionalR3 Registro de productos ofrecidos por la tienda FuncionalR4 Generación de reportes FuncionalR5 Permisos diferenciados de acuerdo al tipo de usuario FuncionalR6 Compatibilidad con distintos navegadores No
funcionalR7 Modificación de precio de productos disponibles en la
tienda.Funcional
R8 Modificación de productos disponibles en la tienda. FuncionalR9 Autentificación del Administrador y Vendedor FuncionalR10 Elaboración de Informes y reportes Funcional
R11 Compatibilidad en un servidor Linux No Funcional
Nro.
Requerimiento Tipo
R12 Validar los datos ingresados por el Administrador y Vendedor (tipo de datos ingresados en cada campo).
Funcional
R13 Resguardo de la información del Sistema de Ventas en una base de datos del sistema.
Oculto
R14 Acceso del Administrador y del Vendedor para el registro de productos vía web
Evidente
R15 Acceso restringido para otros usuarios no registrados en el Sistema.
Evidente
Actor de XP ResponsableProgramadores Tomy Callizaya Quispe
Hugo Mauricio Villegas ValenciaJulio Cesar Chuquimia GonzalesBrandon Felipe Merlo Loza
Cliente Tomy Callizaya QuispeTesters Julio Cesar Chuquimia Gonzales
Brandon Felipe Merlo LozaTracker Hugo Mauricio Villegas ValenciaCoach Hugo Mauricio Villegas ValenciaConsultor Jhonny Brandon Charca MamaniBig boss Tomy Callizaya Quispe
3.4.5 Representación gráfica de los requisitosPara la representación gráfica de los requisitos usaremos notación UML con los diagramas de casos de uso.
3.4.5.1 Diagrama de Caso de Uso de Alto Nivel
Caso de Uso: Sistema de VentasActores: Vendedor, Administrador, Cliente, EmpleadoTipo: Primario
RealDescripción: Un Sistema que nos ayudara con el control de ventas y de
Inventario
3.4.5.2 Casos de Uso ExpandidoCaso de Uso Registro de Productos
Gestion de Usuarios
Registro de Productos
Informes y Reportes
Control de Ventas
Sistema de Control de Ventas
Añadir Productos
Conexion con la base
de datos
Administad
or
Mostrar Productos
Uses
Uses
Registro de Productos
Caso de uso Registro de ProductoActores AdministradorPropósito Añadir productos para poder venderlos posteriormenteTipo Primario
RealReferencia Cruzada R3, R7, R8, R14
Curso normal de accionesAcción del actor Respuesta del sistema
1 Añadir productos
3.Guardar modificaciones
5. Cerrar Sesión
2. Conexión con la base de datos para actualizar el stock de productos y descuento de capital en caso de pagar por dicho producto4.Almacenar las modificaciones en la Base de Datos 6.Salir al menú principal
Caso de Uso Control de ventas
Seleccionar Productos
Conexion con la base
de datos
Mostrar total
Administrador
Control de ventas
Uses
Uses
Caso de uso Control de ventasActores AdministradorPropósito Venta de productos cuando un cliente lo soliciteTipo Primario
RealReferencia Cruzada R4, R5, R9
Curso normal de accionesAcción del actor Respuesta del sistema
1. Seleccionar productos
3. Volver al menú
2. Conexión con la base de datos para descontar el stock de productos y actualizar de capital en caso de pagar por dicho producto4.Mostrar menú
Caso de Uso Informes y Reportes
Administrador
Seleccionar tipo de reporte
Consultar base de
datos
Mostrar reporte
Informes y Reportes
Caso de Uso: Informes y ReportesActores: AdministradorPropósito: Proceso que se encargara de la generación de reportes
ordenados por día mes, año o sucursal donde podremos ver las entradas y salidas de dinero de una tienda
Tipo: PrimarioEsencial
Referencia Cruzada:
R4, R5, R8, R12, R14
CURSOS NORMAL DE ACCIONESACCION DEL ACTOR RESPUESTA DEL SISTEMA
1. Ingresar, verificar los reportes del mes o año
2. Volver al menu
3. Mostrar todos los reportes por mes o por año
4. Mostrar menu
Caso de Uso Gestión de Usuarios
Gestion de Usuarios
Administrador
Registrar Usuario
Registra usuario en la
DB
Modifica usuario
Caso de Uso: Gestión de UsuariosActores: AdministradorPropósito: Un proceso donde se podrán registrar a los usuarios que
tendrán acceso al sistema, también se podrá modificar información de los mismos usuarios, activarlos o inactivarlos.
Tipo: PrimarioReal
Referencia Cruzada:
R5, R9, R15
CURSOS NORMAL DE ACCIONESACCION DEL ACTOR RESPUESTA DEL SISTEMA
1.Ingresar datos del usuario o cliente
3. Usuario
5.Inactivar usuario
2.Almacenara y mostrar todos los datos del usuario 4.Mostrar información nueva de usuario6.Evitar que el usuario entre al sistema
3.5 Análisis del sistema3.5.1 Glosario de términosTermino DescripciónInventario El inventario representa la existencia de bienes
almacenados destinados a realizar una operación, sea de compra, alquiler, venta, uso o transformación. Debe aparecer, contablemente, dentro del activo como un activo circulante.
Ganancia Ganancia es la acción y efecto de ganar (adquirir caudal o aumentarlo, obtener un sueldo en un trabajo, quedarse con lo que se disputa en un juego, conquistar una plaza). El término suele referirse a la utilidad que resulta de un trato o una acción.
Perdida Beneficio negativo. Disminución de la riqueza o neto patrimonial de la empresa, situación producida cuando los gastos son superiores a los ingresos
Administración La administración puede ser entendida como la disciplina que se encarga de realizar una gestión de los recursos (ya sean materiales o humanos) en base a criterios científicos y orientada a satisfacer un objetivo concreto.
Reportes El reporte puede ser la conclusión de una investigación previa o adoptar una estructura de problema-solución en base a una serie de preguntas.
Producto Un producto es un objeto que se ofrece en un mercado con la intención de satisfacer aquello que necesita o que desea un consumidor.
Control La palabra control proviene del término francés controle y significa comprobación, inspección, fiscalización o intervención. También puede hacer referencia al dominio, mando y preponderancia, o a la regulación sobre un sistema
Registro de Datos Registrar es la acción que se refiere a almacenar algo o a dejar constancia de ello en algún tipo de documento. Un dato, por su parte, es una información que posibilita el acceso a un conocimiento.
3.6 Diseño de ProcesosPara el diseño de los procesos haremos uso de la metodología OOHDM.
3.6.1 Diseño Conceptual: modelo conceptual
3.6.2 Diseño de la Base de DatosPara el diseño de bases de datos primero haremos uso del diagrama entidad relación para poder identificar entidades y como estas se relacionan posteriormente pasaremos a usar el diagrama de clases UML (Diagrama relacional) para diseñar la base de datos.
Diagrama entidad relación
Diagrama de clases
3.6.3 Diseño de la InterfazInicio sistema
Inicio administrador
Inicio Vendedor
Iniciar Sesión
3.6.4 Diseño NavegacionalActor Administrador
Actor Vendedor
3.6.5 Diseño de la arquitecturaEn el diseño de la arquitectura se demostrará como es que va ser diseñado nuestra arquitectura es decir las capas para el acceso a la base de datos.
3.6.5.1 Arquitectura
Index.php Inicio Sesion.html Index.php
Reportes
Nueva Venta
Nueva Compra
Añadir/Modificar Produccion
Ver Inventario
Añadir Usuario
Cerrar Usuario
index.php Iniciar sesion.html
index.php
Nueva Venta
Nueva Compra
Cerrar Sesion
La arquitectura elegida será la arquitectura 3 capas ya que con esta arquitectura tendremos un servidor de la aplicación el cual podrá ser ingresado por medio de Internet por distintos clientes ubicados dentro de cada sucursal del negocio.
3.7 Construcción del sistemaSe muestra las imágenes de las interfaces como por ejemplo la interfaz principal, de inicio de sesión, del administrador y del vendedor de la sucursal.
3.7.1 Construcción de la Interfaz: pantallas
Pantalla de inicio
Pantalla de Inicio de Sesión
Pantalla de inicio del Administrador
Pantalla de Inicio de Vendedor
3.7.2 Construcción de la Base de Datos
3.7.3 Código del SistemaDatos para la conexión con la base de datos<?php$host = "localhost";//Donde esta el servidor de la base de datos en este caso esta en la misma PC
$user = "root";//el usuario de la base de datos$pw= "maradona";//la contraseña del usuario de la base de datos$db = "ventas";//el nombre de la base de datos?>
Inicio de sesión<?php
session_start();include ("conexion.php");if(isset($_POST['usuario'])&&!empty($_POST['usuario'])&&//Verificamos que el espacio
usuario de la pantalla de inicio de sesion este llenadoisset($_POST['contrasena'])&&!empty($_POST['contrasena'])){//Verificamos que el
espacio contraseña de la pantalla de inicio de sesion este llenado$con=mysql_connect($host,$user,$pw)//Obtenemos los datos para conectarnos a
la base de datosor die("problemas de conexion");mysql_select_db($db,$con)//seleccionamos la base de datosor die("problemas de conexion");$sel=mysql_query("SELECT usuario,contrasena,tipo,estado,id_usuario FROM
usuario WHERE usuario='$_POST[usuario]'",$con);//en la anterior fila sacamos los datos necesarios de la tabla usuario donde
sea igual al usuario introducido$sesion=mysql_fetch_array($sel);if($_POST['contrasena']==$sesion['contrasena']&&$sesion['estado']==1){//
Verificamos si la contraseña es correca ademas si la cuenta esta activa$_SESSION['username']=$_POST['usuario'];//Para ver si inicio sesion$_SESSION['tipo']=$sesion['tipo'];//Para saber que tipo de usuario es$_SESSION['id_usuario']=$sesion['id_usuario'];include"index.php";
}else{include"errorSesion.html";
}}
?>
Index con selección de usuarios<?phpsession_start();if (isset($_SESSION['username'])){//verificamos si la sesion esta iniciada
switch ($_SESSION['tipo']){//mostramos una pagina distinta de acuerdo al tipo de usuario
case 1:include ("restringidoVendedor.html");break;
case 2:include ("restringidoAdministrador.html");break;
}}else{
include ("principal.html");//en caso de no tener una sesion iniciada no hacemos nada}?>
Cerrar sesión<?phpsession_start();
if (isset($_SESSION['username'])){session_destroy();//Borramos la sesion iniciada y con ello los pesos
SESSIONinclude"index.php";
}else{
include"index.php";}
?>
4 BibliografíaKendall. (2011). Analisis y Diseño de Sistemas. Mexico: Pearson.
Letelier P. (2011). Métodologías ágiles para el desarrollo de software: eXtreme Programming (XP). mayo 26,2016, de CyTA Sitio web: http://www.cyta.com.ar/ta0502/v5n2a1.htm
Arturo Zenteno. (2011). Métodologías ágiles para el desarrollo de software: eXtreme Programming (XP). mayo 26,2016, de OOHDM Sitio web: https://oohdm.wordpress.com/2011/02/01/hello-world/
5 AnexosANEXO 1: ESTUDIO DE FACTIBILIDAD
Título: Sistema de Control de Ventas
Org. Empresa: MC Forist
Responsables: Hugo Mauricio Villegas Valencia
Tomy Callizaya Quispe
Julio Cesar Chuquimia Gonzales
Brandon Felipe Merlo Loza
Elaboración: Tomy Stark
1 Definición de Alcances y Objetivos
Problema Principal
Actualmente la mayoría de los negocios bolivianos no cuentan con un sistema que registre y modifique los datos actuales de dicho negocio.
Ocasionando un manejo de información empírica de parte de los responsables esto genera la perdida de la misma y una deficiencia en el crecimiento del establecimiento.
Problemas Específicos
Existe perdida de Información de los recursos actuales en el negocio. No hay control sobre las ventas generando incertidumbre en el negocio. Presenta retrasos en los cálculos por falta de información
Determinación de Objetivos
Los Objetivos a Cumplir son:
Objetivo General
Desarrollar un sistema para el almacenamiento de información de los recursos actuales, las ventas realizadas por cada día en cada sucursal
Objetivos Específicos
Simplificar la contabilidad y el registro de las tareas envueltas en el negocio. Facilitar el ingreso de las ventas, además de reducir los errores del cajero. Determinar en forma exacta las ventas realizadas en ciertos periodos del
año.Alcances del Proyecto
Los Alcances del Proyecto son:
El Administrador podrá controlar las ventas en las Sucursales, los Productos necesarios y a la Gestión de Usuario.
El Sistema registrara a un Usuario como el Empleado El Registro de las Ventas se almacenará en una base de datos cuya
página seria vía web. El Administrador podrá actualizar y modificar los datos del sistema
Límites de Proyecto
Los Limites del Proyecto son:
El Sistema no controlara el horario laboral de sus empleados. El cajero solo podrá tener el control de productos para las ventas y el
control de ventas por cada sucursal. Solamente el Administrador es el que podrá tener un informe
completo de las ventas realizadas en las distintas sucursales.
2 Estudio del Sistema Existente
A continuación, se presentan los procesos actuales que realiza un negocio de ventas:
3 Modelo Lógico
3.1 DFD Nivel 0
3.2 DFD Nivel 1
4 Acuerdo de Conformidad
Título: Sistema de Control de Ventas Empresa: -----
Personal: Responsables: Hugo Mauricio Villegas Valencia
Brandon Felipe Merlo Loza
Tomy Callizaya Quispe
Julio Cesar Chuquimia Gonzales
En fecha 9 de abril con el presente documento, se presentó el análisis de situación y problemas encontrados en la actualidad del sistema utilizado proponiendo una solución de desarrollo de un sistema apropiado; de esta manera de acuerdo a los requerimientos de sus sistemas, queremos certificar la conformidad de la propuesta ya presentada
Alternativa 1: Desarrollo de un SistemaAl desarrollar un Sistema se cubrirán los requerimientos específicos de los que precisa el sistema actual para su optimización y además será de fácil almacenamiento, manejo de datos y actualización de datos acerca de las ventas realizadas por día.
Alternativa 2: Compra de un sistema ya desarrolladoOtra opción sería la compra de un sistema, de esta manera se podrá ahorrar tiempo y algo de dinero, ya que el sistema al estar desarrollado solo habría que hacer unos pequeños ajustes.
6 Decidir un curso de Acción
Al revisar los sistemas de ventas ya desarrollados nos encontramos con el problema de que estos no se adecuan lo suficiente a los requerimientos del cliente y por tanto se tardaría más en la adaptación de dichos sistemas que al desarrollo de un nuevo sistema. Por tanto, decidimos desarrollar el sistema.
7 Plan de Desarrollo
El plan de desarrollo seguido para la realización del presente proyecto fue el siguiente:
8 Estudio de Factibilidad
8.1 Estudio de Factibilidad técnica
Para la Implementación del Sistema se requerirá mínimamente de los siguiente:
Hardware Cliente/ServidorCANTIDAD EQUIPO DESCRIPCION1 Impresora ZEBRA GC420 – Impresora de
etiquetas Velocidad de impresión 102 mm/seg interface USB, RS232, paralelo, resolución de impresión de 103 dpi
20Ghz Cuarta Generación, memoria DDR3 1600 CODEX, Disco duro externo de 1TB Toshiba, Tarjetas madre ASUS B855M-G, Tarjeta de video GEFORCE GT210 1GB, Tarjeta de sonido Creative 7,1 24 bits, Copiador DVD LG Sata, Monitor Samsung LED 19WIDE, Teclado Genius KB06 PS2 o USB, Mouse DELUX USB, Cable USB(alargador)
8.2 Estudio de Factibilidad Económica
Software ServidorCaracterísticas VersiónWindows Server 2016
Hardware Cliente/ServidorCANTIDAD EQUIPO DESCRIPCION P.
UnitarioC. Total
1 Impresora ZEBRA GC420 – Impresora de etiquetas Velocidad de impresión 102 mm/seg interface USB, RS232, paralelo, resolución de impresión de 103 dpi
2885.97 2885.97
2Computadoras
Microprocesador Intel Core i5-4460 3, 20Ghz Cuarta Generación, memoria DDR3 1600 CODEX, Disco duro externo de 1TB Toshiba, Tarjetas madre ASUS B855M-G, Tarjeta de video GEFORCE GT210 1GB, Tarjeta de sonido Creative 7,1 24 bits, Copiador DVD LG Sata, Monitor Samsung LED 19WIDE, Teclado Genius KB06 PS2 o USB, Mouse DELUX USB, Cable USB(alargador)
2700.00 5400.00
8285.97
Software ServidorCaracterísticas Versión CostoWindows Server 2016 3351.69
