Facturacion I Bimestre
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Facturacion I Bimestre

on

  • 1,168 views

Es el informe de una aplicación que permite la automatización y facturación de sus ventas que realiza el micro-mercado “Nueva Granada”.

Es el informe de una aplicación que permite la automatización y facturación de sus ventas que realiza el micro-mercado “Nueva Granada”.

Statistics

Views

Total Views
1,168
Views on SlideShare
1,168
Embed Views
0

Actions

Likes
0
Downloads
31
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Facturacion I Bimestre Document Transcript

  • 1. Universidad Técnica Particular de Loja Escuela de Ciencias de la Computación Programación Avanzada. Estudiante en Formación: Andrea R. Álvarez M.Docente: Ing. Pablo Alejandro Quezada Sarmiento Loja – Ecuador 2012 1
  • 2. INDICE PAG.i. TEMA…………………………………………………………………………………..iiiii. OBJETIVOS………………………………………………………………………….iv a. GENERALES........................................................................................iv b. ESPECIFICOS......................................................................................iv, viii. JUSTIFICACION...............................................................................................viiv. ALCANCE.........................................................................................................vii, viiiv. RESPORTES………………………………………..……………………..…….…..ixvi. LIMITACIONES................................................................................................x1. MARCO TEORICO...........................................................................................112. METODOLOGÍA XP…………………………………………………………………….……21 2.1 FASE 1: EXPLORACION…………………………………..……………………..21 2.2 FASE 2: PLANIFICACION…………………………………………………….…..21 2.3 FASE 3: PLAN ITERACIONES……………………………………………….…..31 2.4 FASE 4: PRODUCCION…………………………………………………….……..333. CONCLUSIONES…………………………………………………………………….…..…..42, 434. RECOMENDACIONES…………………………………………………………………..….. 445. BIBLIOGRAFIA…………………………………………………………………………..…….45, 46 2
  • 3. i. Tema: “DESARROLLO DE APLICACION PARA SERVICIOS DE VENTA DE PRODUCTOS DE CONSUMO MASIVO”. 3
  • 4. ii. Objetivosa. Objetivo General:  Desarrollar de una aplicación que permita la automatización y facturación de sus ventas que realiza el micro-mercado “Nueva Granada”.b. Objetivos Específicos:  Aplicar la lógica aprendida como métodos, excepciones, recursividad, clases, programación orientada a objetos, etc.  Brindar al cliente un servicio más eficiente y seguro, optimizando así las ventas del micro-mercado  Brindar Rapidez y agilidad al momento de la facturación en el micro-mercado “Nueva Granada”  Crear una aplicación tanto para el administrador como para el Cajero/a de la empresa que sea fiable, eficiente y confiable al momento de emitir facturar de ventas, como también al manipular los datos de los productos que posee la empresa.  El usuario Administrador podrá realizar manipulación de datos como: consultas sobre las ventas realizadas al día, productos en stock, así mismo puede ingresar, modificar y eliminar los datos de productos que se encuentren almacenado en la base de datos. 4
  • 5.  El usuario usuario Vendedor realizar búsquedas de productos, ventas de productos y generar la factura correspondiente a la venta. 5
  • 6. iii. Justificación El proyecto se a realizara debido a la necesidad de requerir más rapidezy eficiencia como también seguridad al momento de realizar suscompras/ventas de productos, es necesario las evoluciones tecnológicas enlas centros que brindan atención al cliente, siendo así muy importante lacreación de sistemas que nos brinden estas características. También tiene como propósito el presente proyecto, el poder mejorar elsistema de facturación para agilizar la emisión de comprobantes de créditofiscal (facturas de consumidor final), y así brindar un mejor servicio al cliente Esto beneficiara a la empresa en el proceso y control de ventas tanto alos usuarios finales como al propietario del mismo. El impacto a corto y mediano plazo de esta aplicación será de llevar elcontrol de venta de su mercadería como el almacenamiento de información desus productos en stock en una Base de Datos. Para ello desea sistematizar lamercadería en stock y sus facturas emitidas al cliente. Esta aplicación será implementada en el lenguaje Java con la APINetBeans y su base de datos será creada en Microsoft Access que es unSGBD relacionales orientado a entornos personales u organizacionespequeñas que permite crear ficheros que pueden ser fácilmente gestionadospor una interfaz grafica. También permite manipular los datos, realizar lasrespectivas consultas, formularios para introducir datos e informes parapresentar la información del usuario. 6
  • 7. iv. Alcance Este proyecto trata de construir una aplicación para llevar un registropor cada compra que realicen los clientes (compradores) del micro-mercado“Nueva Granada” con el fin de brindar una rápida y eficiente atención al cliente. Esta brindara una Interfaz grafica que guie intuitivamente a losusuarios en los procesos que correspondan al mismo. La aplicación podrá imprimir el formato de factura predefinida lainformación requerida. Así mismo podrá ingresar datos de los productospertenecientes a la empresa en una base de datos con una autentificaciónespecífica. La aplicación contara con dos usuario Administrador y Vendedor: deacuerdo con las caracterices de usuario que se registre, la aplicacióndeterminara las actividades al cual podrá acceder el mismo. El usuario “Vendedor” podrá realizar búsquedas de productos en stock de la empresa, para agregarlos y eliminarlos de las ventas requeridas por el cliente (comprador) El usuario “Vendedor” será quien genere la factura de la venta respectiva. El usuario “Administrador” será quien realice la manipulación (ingreso, edición y eliminación) de datos de productos que posee la empresa en la base de datos del sistema. Finalmente el administrador de la aplicación visualizara las ventas realizadas al final del día, con opción a editar o eliminar las mismas. 7
  • 8. Llevando así un histórico total acumulativo diario con el fin de facilitar lalectura de ventas al realizar el cierre de caja diario. 8
  • 9. v. Reportes a presentar La necesidad de presentar reportes ha surgido de mal control de ventas deproductos que existe en el micro-mercado. a. Este reporte deberá presentar las ventas de los productos realizadas al final del día. El mismo nos dará conocimiento y mejor control de los productos en stock. b. Otro reporte a presentar serán los productos de acuerdo a un estado (stock, vendidos y/o vencidos) de los mismo, enfocado en la optimización de adquisición de productos de la empresa. 9
  • 10. vi. LimitacionesAlgunas restricciones que se deben tomar en cuenta: a. La aplicación no será un sistema completo en el aspecto de control total de materia prima b. La aplicación no contara con un sistema contable c. El sistema no puede validar la información de pago d. Tener en cuenta que los vendedores pueden ser clientes del micro- mercado. e. La aplicación contara con dos usuarios disponibles: administrador y vendedor. f. El administrador podrá visualizar la utilidad en ventas y numero de productos en stock al finalizar el día. g. El usuario (cajero/a) podrá realizar ventar y presentar la factura así como también visualizar los productos disponibles a cualquier hora del día 10
  • 11. 1. Marco Teórico 1.1. Factura Es un documento tributario de compra y venta que registra la transacción comercial obligatoria y aceptada por ley. Este comprobante tiene para acreditar la venta de mercaderías u otros afectos, porque con ella queda concluida la operación. La factura tiene por finalidad en esta aplicación acreditar la transferencia de productos del micro-mercado para sustentar gastos y costos para efecto tributario. Y su presentación quedaría más o menos así:Encabezado Nombre Empresa Nº Factura Dirección Empresa RUC /CI Teléfono Empresa Nº Autorizado Fecha EmisiónRUC/CI Cliente FacturaNombre ClienteDirección ClienteTeléfono ClienteCuerpo Código Valor Unitario Producto Cantidad Producto Descripción Producto Producto Subtotal ProductoPie Subtotal 11
  • 12. Factura IVA ……………………………… Descuentos CelloEmpresa Firma Cliente Total a Pagar Figura 1: Factura de Venta 1.2. Almacenamiento En relación con ordenadores o computadoras, es cualquier dispositivo capaz de almacenar información procedente de un sistema informático. 1.3 Base de Datos (Thomas M. Connolly, Carolyn E. Begg, “Sistema de Base de Datos”, Univesidad of Paisley, Cuarta edicio (2010) ) Cualquier conjunto de datos organizados para su almacenamiento en la memoria de un ordenador o computadora, diseñado para facilitar su mantenimiento y acceso de una forma estándar. La información se organiza en campos y registros. Un campo se refiere a un tipo o atributo de información, y un registro, a toda la información sobre un individuo. Esta aplicación trata de aportar nociones básicas de desarrollo de bases de datos basándose en un enfoque Conceptual, Lógico y Físico de las mismas basadas en los modelos de datos E/R y Relacional. 1.4 Conexión 12
  • 13. Comunicación entre dos entes que tienen características similares decomunicación en este caso la base de datos y la GUI del software1.5 Microsoft Access Es un sistema de gestión de bases de datos relacionales para lossistemas operativos Microsoft Windows, desarrollado por Microsoft y orientadoa ser usado en un entorno personal o en pequeñas organizaciones. Esteprograma permite manipular los datos en forma de tablas (formadas por filas ycolumnas)Esta aplicación empleara en la aplicación un almacena miento de datos en unaBD relacional, que contienen la información ordenada de una formaorganizada.1.5.1 Tabla.- Son los objetos principales de bases de datos que se utilizan paraguardar datos. Está compuesta por campos o Registros1.5.1.1 Campo o Registro: estos pueden tener un solo tipo de dato: texto,fecha, numérico, cadena, carácter, etc.1.6 Java. Es un ante todo un lenguaje de programación moderno, diseñado en ladécada de los noventa, proporciona potencia, robustez y seguridad que muypocos lenguajes le pueden igualar, sin olvidar su rasgo más conocido: estotalmente portable. Está basado en lenguajes como C y C++, no obstante se 13
  • 14. encuentra en constante desarrollo, las nuevas tecnología surgen y sedesarrollan a gran velocidad haciendo de java un lenguaje cada día mejor yque cubre prácticamente todas las aéreas de la computación y lacomunicación, desde teléfonos móviles hasta servidores de aplicaciones [5]1.6.1 NetBeans IDE.- Es una IDE (Intregrated Development Environment) deJAVA entorno integrado de desarrollo, este trabaja a nivel de proyectos el cualincluyes los recursos necesarios para construir un programa: Archivos,Bibliotecas, Imágenes, Sonidos, etc. [6]1.6.2 Bibliotecas en Java.- Java nos ofrece un conjunto de Bibliotecas, códigoofrecido para simplificar la tarea de programación que las aplicaciones puedenllamar cuando necesiten.1.6.3 GUI (Interfaz grafica de usuario).- esta presenta un mecanismoamigable al usuario para interactuar con una aplicación. Una GUI `proporcionaa un aplicación una “Apariencia visual” única. Al proporcionar distintasaplicaciones en las que los componentes de la interfaz de usuario seanconstantes e intuitivos.1.6.3.1 Botón.- es un componente en el que el usuario hace clic paradesencadenar cierta acción, una aplicación de Java puede utilizar variosbotones.1.6.3.2 Evento.- un evento se generan cuando se oprimen y sueltan las teclasen el teclado o por el mouse.1.7 Un diagrama de clases 14
  • 15. Sirve para visualizar las relaciones entre las clases que involucran elsistema, las cuales pueden ser asociativas, de herencia, de uso y decontenimiento. Un diagrama de clases está compuesto por los siguienteselementos:1.7.1 Clase: una clase tiene, atributos, métodos y visibilidad.1.7.2 Relaciones: Herencia, Composición, Agregación, Asociación y Uso[8]1.8 Metodología XP Es la metodología más destacada de los procesos ágiles de desarrollode software formulada por “Kent Beck”. La programación extrema se diferenciade las metodologías tradicionales principalmente en que pone más énfasis enla adaptabilidad que en la previsibilidad. Otra particularidad de XP es tenercomo parte del equipo al usuario final creando transparencia y un clima deagilidad entre desarrolladores y clientes reduciendo el costo de cambio en lasetapas de vida del sistema y combinando las mejores prácticas de desarrollode software. Se destaca por su simplicidad, comunicación y reutilización decódigo [4]En la implementación de la metodología XP se realiza de acuerdo a lassiguientes fases de construcción: 15
  • 16. Figura 2: Faces de costruccion de la metodologia XP1.8.1 Historias de Usuario; Tienen el mismo propósito que los casos de uso yconstituyen una técnica utilizada en la metodología XP. Estas nos especificaranlos requerimientos del usuario y representan la unidad funcional en el proyecto,es aquí donde cliente describe las características que el sistema debe poseer,esto se realizara mediante tarjetas y para su presentación se ha consideradola siguiente plantilla. Figura 3: Plantilla de Historia de UsuarioLas historias de usuarios tendrán 3 aspectos cruciales:Tarjetas: Contienen información necesaria para identificar la historia de usuario 16
  • 17. Conversación: El cliente y el gerente del software con la finalidad de analizarla historia y ampliar los detalles si así lo requiere, la misma que se realizara enforma verbal cuando sea posible y documentada cuando lo requiera eldesarrollo del softwareConfirmación: Realizada mediante pruebas de aceptación con el objetivo deconfirmar la correcta implementación de las historias de usuario1.8.2. Tarjetas CRC: Representa Responsabilidades y Colaboraciones de lasClases y su Interacción. La plantilla que se utilizara se utilizara es la siguiente: Figura 4: Plantilla de Tarjetas CRC1.8.3 Pruebas del sistema; Aquí se determina la aceptación de funcionalidadque posee un sistema en base a las historias de usuario antes especificadas.Para la documentación formal de las pruebas de aceptación, se implementarala siguiente plantilla 17
  • 18. Figura 5: Plantilla de prueba de aceptacioon1.9. Prototipos Es una herramienta de apoyo para el curso de cada una de lasactividades del desarrollo del sistema, para la creación del mismo es precisoseguir el proceso de desarrollo de prototipos: Figura 6: Plantilla de Historia de Usuario 18
  • 19. 1.9.1 Prototipos Desechables; este se encarga de validar derivar losrequerimientos del sistema, usado con los requerimientos que no se conocebien teniendo un periodo de vida corto.1.10. Login. Nombre o alias que se le da a una persona para permitirle el acceso alsistema siempre y cuando estén registrados.1.11. Password Contraseña o clave para autentificar el ingreso a un lugar o sitio.1.12 Actualización Insertar, eliminar, modificar los productos de la empresa1.13 Control. Se utiliza para seleccionar el control del producto. Cuando elproducto sale de las manos del productor, se pierde el control debido a quepasa a ser propiedad del comprador y este puede hacer lo que quiere con elproducto. Ello implica que se pueda dejar el producto en un almacén o que sepresente en forma diferente en sus anaqueles. Por consiguiente es másconveniente usar un canal corto de distribución ya que proporciona un mayorcontrol.1.14 Arquitectura de Software. Arte, ciencia y tecina de proyectar y construir espacios para que elhombre pueda desarrollar sus actividades adecuadamente de manera sanaconfortable y segura. [9] 19
  • 20. Es la organización fundamental de un sistema descrito mediante:componentes, relación entre ellos y el ambiente y principios que gruían sudiseño y evolución.Según análisis debido análisis del sistema se ha subdividiendo así en trescapas: a. Capa de presentación (GUI) b. Capa de Negocio c. Capa de Acceso a datos 20
  • 21. 2. Análisis y diseño de la aplicación en función a la Metodología XP2.1 Fase1: Exploración Es esta fase los clientes plantean a grandes rasgos las historias deusuario que son de interés para la primera entrega del producto.2.1.1 Historias de usuario; Estas nos especificaran los requerimientos del software y representan la unidad funcional en el proyecto, es aquí donde cliente describe las características que el sistema debe posee Especificación de historias de usuario basadas en las necesidades del cliente:R1.- Autentificación de usuarios (Administrador /Vendedor) Historia de UsuarioNumero:01 Nombre: Autentificación de usuariosUsuario: Administrador /VendedorModificación de Historia Numero: NA Iteración Asiganda: PrimeraPrioridad en Negocio: Alta Riesgo en Desarrollo: AltaDescripción:Al ingresar a la aplicación esta le pedirá su autentificación como usuario Administrador oVendedor, autentificación que se realizara ingresando la información correspondiente.Observaciones: en caso de ningún error al momento de autenticarse los usuarios, laaplicación ingresara, presentara un error y no se iniciara las actividadescorrespondientes. Tabla 1.1: Historia de Usuario: Autentificación de Usuarios 21
  • 22. R2.- Generar Venta. Historia de UsuarioNumero:02 Nombre: Generar VentaUsuario: VendedorModificación de Historia Numero: 3, 5 Iteración Asiganda: SegundaPrioridad en Negocio: Alta Riesgo en Desarrollo: AltoDescripción:La aplicación contara con la opción de generar una venta la cual pedirá ingresar losproductos deseados por el cliente (comprador)Observaciones: en caso de que el cliente (comprador) no desee un producto en procesode venta, se podrá eliminar el mismo. Tabla 1.2: Historia de Usuario: Generar VentaR3.- Buscar Producto Historia de UsuarioNumero:03 Nombre: Buscar ProductoUsuario: VendedorModificación de Historia Numero: 1,5 Iteración Asiganda: SegundaPrioridad en Negocio: Baja Riesgo en Desarrollo: BajoDescripción:La aplicación contara con la opción de buscar un producto, esta búsqueda será realizadamediante el código del mismo, u se especifica las unidades, cuyos datos seráningresados por el VendedorObservaciones: una vez encontrado el producto o en caso de no haber existenciasdisponibles la aplicación presentara un mensaje según sea el caso. Tabla 1.3: Historia de Usuario: Buscar Producto 22
  • 23. R4.- Generar Factura autentificado como Vendedor Historia de UsuarioNumero:04 Nombre: Generar FacturaUsuario: VendedorModificación de Historia Iteración Asiganda: TerceraNumero:1,2,3,5Prioridad en Negocio: Alta Riesgo en Desarrollo: AltoDescripción:La aplicación le permitirá al Vendedor facturar las ventas.Observaciones: Se guardara la descripción de la factura en la base de datos de laaplicación. Tabla 1.4: Historia de Usuario: Generar FacturaR5.- Manipulación de productos. Historia de UsuarioNumero:05 Nombre: Manipulación de productosUsuario: AdministradorModificación de Historia Numero: 1 Iteración Asiganda: PrimeraPrioridad en Negocio: Alta Riesgo en Desarrollo: AltoDescripción:La aplicación le permitirá al Administrador la manipulación de productos que posee elMicro-Mercado, este podrá ingresar editar y eliminar productosObservaciones: Una vez realizadas cualquiera de estas opciones, la base de datos de laaplicación se actualizara. Tabla 1.5: Historia de Usuario: Manipulación de productosR6.-Reporte de ventas 23
  • 24. Historia de UsuarioNumero:06 Nombre: Reporte de ventasUsuario: AdministradorModificación de Historia Numero: Iteración Asiganda: Tercera1,2,3,5Prioridad en Negocio: Media Riesgo en Desarrollo: medioDescripción:El Administrador podrá visualizar una lista de las ventas realizadas en el día, vista en lacual serán presentadas todas las características de venta, como por ejemplo: unadescripción de los productos vendidos, descripción de venta y factura y descripción delcliente (comprador) al cual se realizo la venta.Observaciones: las ventas se podrán eliminar y editar. Tabla 1.6: Historia de Usuario: Reportes de VentasR7.- Visualización de Productos Historia de UsuarioNumero:07 Nombre: Visualizaciónde ProductosUsuario: AdministradorModificación de Historia Numero: 1,5 Iteración Asiganda: TerceraPrioridad en Negocio: Baja Riesgo en Desarrollo: BajoDescripción:La aplicación contara con la opción de en listar los productos de la empresa y visualizarsus características como su estado dentro de la misma, estos estados pueden ser:vendido, en stock y caducadoObservaciones: una vez encontrado el producto se podrá visualizar un coteo de los mismosde cada unos de los tres estados del producto.. Tabla 1.7: Historia de Usuario: Visualización de Productos 24
  • 25. 2.1.2 Prototipos; Interfaces de la aplicación basadas en la vista del cliente.Pantalla: Autentificación de usuarios Figura 7.1: Pantalla: Autentificación de UsuariosPantalla: Generar Venta y Búsqueda de Productos Figura 7.2: Pantalla: Generar Venta y Búsqueda de Productos 25
  • 26. Pantalla: Generar Factura Figura 7.3: Pantalla: Generar FacturaPantalla: Manipulación de Productos Figura 7.4: Pantalla: Manipulación de Productos 26
  • 27. Pantalla: Ingresar producto Figura 7.5: Pantalla: Ingresar ProductoPantalla: Modificar Producto Figura 7.6: Pantalla: Modificar producto 27
  • 28. Pantalla: Eliminar Producto Figura 7.7: Pantalla: Eliminar productoPantalla: Reporte de Ventas Figura 7.8: Pantalla: Reporte de Ventas 28
  • 29. Pantalla: Visualizacion de Productos Figura 7.9: Pantalla: Visualización Productos 2.2. Fase2: Planificación Para la elaboración planificacion, es necesario identificar las historias de usuario y establecer la prioridad de cada una de ellas, realizando una estimación del esfuerzo necesario. 2.2.1 Valoración de Historias de Usuario; Como punto importante en la planificación de Entregables, se considera la estimación de historias de usuario, aquí se especifica un tiempo estimado para la elaboración de cada una en base a un día de 2 horasEstimación de historias de usuario TIEMPONUMERO HISTORIA DE USUARIO ESTIMADO DIAS HORAS 1 Autentificación de usuarios 3 6 2 Generar Venta 5 10 3 Buscar Producto 5 10 4 Generar Factura 8 16 5 Manipulación de productos 15 30 6 Reporte de ventas 8 16 7 Visualización de Productos 7 14 TIEMPO ESTIMADO TOTAL 51 102 29
  • 30. Taba 2.1: Estimación tiempo en base a las historias de Usuario2.2.2 Plan de entregas; Para la elaboración del plan de entregas del presente proyecto, aplicando los parámetros de la metodología aplicada al desarrollo de este software se determina un plan de entrega, mediante la estimación por fases de la metodología XPPlan de entrega: Fases y Pasos Hitos Inicio Fin Fase 1. Exploración - Historias de Usuario 27/03/2012 19/04/2012 Fase 2.Planificacion  Plan de entregas 20/04/2012 28/04/2012  Roles de usuarios Fase 3. Plan de  Planificación de 29/04/2012 08/05/2012 iteraciones Iteraciones Fase 4. Producción - Primera versión del 09/05/2012 30/06/2012 sistemas Fase 5. Cierre de  Manual de usuario 1 /07/2012 3/07/2012 Proyecto para administración del sitio  Versión final del proyecto  Entrega del proyecto. Taba 2.2: Plan de Entregables 30
  • 31. 2.2.3 Roles de usuario; Específica los roles que cada unos de los integrantesdel equipo de desarrollo de software que desempeña en el desarrollo de laaplicación, tomando en cuenta que el clienta desempeña un papel importantedel este equipo. Roles Encargado Programador : Andrea Álvarez Cliente : Cristian Villamagua Tester: Andrea Álvarez Analista/programador: Andrea Álvarez Diseñador de interfaz: Andrea Álvarez Administrador de base de datos (DBA): Andrea Álvarez Taba 2.3: Roles que desempeña dentro del proyecto2.3 Fase 3: Plan de Iteraciones En esta fase incluye varias iteraciones sobre la aplicación antes de ser entregada, esto se realiza mediante lanzamientos pequeños y frecuentes que corresponden a las tareas para completar la implementación de cada iteración. En un acuerdo con el cliente, el cual establece la prioridad de cada historia de usuario de acuerdo con el valor que aporta para el negocio y el desarrollador, quien estima el esfuerzo requerido para cada 31
  • 32. historia de usuario así como el tiempo empleado para cada iteración. Se especifica como cuadros de entregables por Historias de usuario: 2.3.1. Historial de versiones por Historias de Usuario PRIORIDAD ESTADO DE ITERACION Nº HISTORIA DE USUARIO ENTREGA ACTIVIDAD DEPEND RIESGO VESION DESARROLLO PRUEBAS No Primera 1 Autentificación de usuarios 1 Nueva NA Alto 1 En curso aprobado No Segunda 2 Generar Venta 2 Nueva 1,3,5 Alto 1 Nulo aprobado No 3 Buscar Producto 2 Nueva 1,5 Bajo 1 Nulo Segunda aprobado No 4 Generar Factura 3 Nueva 1,2,3,5 Alto 1 Nulo Tercera aprobado No 5 Manipulación de productos 1 Nueva 1 Alto 1 Nulo Primera aprobado No 6 Reporte de ventas 3 Nueva 1,2,3,5 Medio 1 Nulo Tercera aprobado No 7 Visualización de Productos 3 Nueva 1,5 Bajo 1 Nulo Tercera aprobado Tabla 3.1: Cuadro entregables: Historial de versiones por Historias de Usuario 2.3.2. Historial de seguimientos por Iteraciones FECHA PLANIFICACION ESTADOITERACION Nº HISTORIA DE USUARIO ITERACIONES LANZAMIENTO DESARROLLO PRUEBAS Autentificación de No 1 09/05/2012Primera usuarios 12/05/2012 02/07/2012 En curso aprobada Manipulación de No 5 13/05/2012 productos 27/05/2012 02/07/2012 Nula aprobada No 2 Generar Venta 28/05/2012Segunda 02/06/2012 02/07/2012 Nula aprobada No 3 Buscar Producto 03/06/2012 07/06/2012 02/07/2012 Nula aprobada No 4 Generar Factura 08/06/2012Tercera 15/06/2012 02/07/2012 Nula aprobada No 6 Reporte de ventas 16/06/2012 23/06/2012 02/07/2012 Nula aprobada Visualización de No 7 24/06/2012 Productos 30/06/2012 02/07/2012 Nula aprobada Tabla 3.2: Cuadro entregables: Historial de seguimientos por Iteraciones 32
  • 33. 2.4 Fase 4: Producción Esta fase demanda de la producción, finalización, pruebas adicionales y revisiones de rendimiento del sistema; para que, así este pueda ser trasladado al entorno cliente y ser implementado. 2.4.1 Seguimiento Iteración; Par esto es fundamental la comunicación entre las personas que intervienen en el proyecto (cliente / desarrollador), cuya finalidad está enfocada en el encuentro, determinación y establecimiento de problemas y soluciones de una tarea de desarrollo de la aplicación. 2.4.1.1 Reporte por Iteración.- El objetivo es el control de las tareas asignadas a cada iteración, aquí podremos visualizar el desarrollo del proyecto. En base a: Historial de seguimiento de tareas Activas ESFUERZO ESFUERZO ESFUERZO REAL POR HISTORIA DE ESTADO DE ESTIMADO INVERTIDO REALIZARNº USUARIO TAREA DEARROLLO RESPONSABLE (días ) (días) (días) Autenticación Especificación de Andrea1 de Usuarios Pruebas completo Álvarez 0.5 1 0 Monitoreo de Andrea herramientas XP completo Álvarez 1 4 0 Andrea Diseño de Interfaz completo Álvarez 1 2 0 Andrea Diseño CRC completo Álvarez 1 nulo Nulo Diagrama de Base Andrea de Datos nulo Álvarez 1 nulo Nulo Programación de Andrea Interfaz nulo Álvarez 1 nulo Nulo Pruebas de Andrea aceptación nulo Álvarez 1 nulo Nulo Esfuerzos totales 6 nulo Nulo Generar Especificación de Andrea2 Venta Pruebas completo Álvarez 0.5 1 0 33
  • 34. Monitoreo de Andrea herramientas XP completo Álvarez 1 4 0 Andrea Diseño de Interfaz completo Álvarez 0.5 2 0 Andrea Diseño CRC completo Álvarez 0.5 nulo Nulo Diagrama de Base Andrea de Datos nulo Álvarez 1 nulo Nulo Programación de Andrea Interfaz nulo Álvarez 1 nulo Nulo Pruebas de Andrea aceptación nulo Álvarez 0.5 nulo Nulo Esfuerzos totales 5 nulo Nulo Buscar Especificación de Andrea3 Producto Pruebas completo Álvarez 0.5 1 0 Monitoreo de Andrea herramientas XP completo Álvarez 2 4 0 Andrea Diseño de Interfaz completo Álvarez 0.5 2 0 Andrea Diseño CRC completo Álvarez 0.5 nulo Nulo Diagrama de Base Andrea de Datos nulo Álvarez 1 nulo Nulo Programación de Andrea Interfaz nulo Álvarez 2 nulo Nulo Pruebas de Andrea aceptación nulo Álvarez 0.5 nulo Nulo Esfuerzos totales 5 nulo Nulo Generar Especificación de Andrea4 Factura Pruebas completo Álvarez 0.5 1 0 Monitoreo de Andrea herramientas XP completo Álvarez 2 4 0 Andrea Diseño de Interfaz completo Álvarez 1 2 0 Andrea Diseño CRC completo Álvarez 1 nulo Nulo Diagrama de Base Andrea de Datos nulo Álvarez 1 nulo Nulo Programación de Andrea Interfaz nulo Álvarez 3 nulo Nulo Pruebas de Andrea aceptación nulo Álvarez 0.5 nulo Nulo Esfuerzos totales 8 nulo Nulo Manipulación Especificación de Andrea5 de Productos Pruebas completo Álvarez 1 1 0 Monitoreo de Andrea herramientas XP completo Álvarez 2 4 0 Andrea Diseño de Interfaz completo Álvarez 1 2 0 Diseño CRC completo Andrea 1 nulo Nulo 34
  • 35. Álvarez Diagrama de Base Andrea de Datos nulo Álvarez 5 nulo Nulo Programación de Andrea Interfaz nulo Álvarez 4 nulo Nulo Pruebas de Andrea aceptación nulo Álvarez 1 nulo Nulo Esfuerzos totales 15 nulo Nulo Reporte de Especificación de Andrea6 Ventas Pruebas completo Álvarez 0.5 1 0 Monitoreo de Andrea herramientas XP completo Álvarez 2 4 0 Andrea Diseño de Interfaz completo Álvarez 1 2 0 Andrea Diseño CRC completo Álvarez 1 nulo Nulo Diagrama de Base Andrea de Datos nulo Álvarez 1 nulo Nulo Programación de Andrea Interfaz nulo Álvarez 3 nulo Nulo Pruebas de Andrea aceptación nulo Álvarez 0.5 nulo Nulo Esfuerzos totales 8 nulo Nulo Visualización Especificación de Andrea7 de Productos Pruebas completo Álvarez 0.5 1 0 Monitoreo de Andrea herramientas XP completo Álvarez 2 4 0 Andrea Diseño de Interfaz completo Álvarez 1 2 0 Andrea Diseño CRC completo Álvarez 1 nulo Nulo Diagrama de Base Andrea de Datos nulo Álvarez 1 nulo Nulo Programación de Andrea Interfaz nulo Álvarez 2 nulo Nulo Pruebas de Andrea aceptación nulo Álvarez 0.5 nulo Nulo Esfuerzos totales 7 nulo Nulo Tabla 3.3: Historial de Seguimiento de Tares Activas 35
  • 36. 2.4.2 Ejecución de Iteración; Permite Visualizar la forma de implementaciónde cada Historia de Usuario en base a tarjetas CRC (Responsabilidades yColaboraciones de las Clases) y especificación de escenariosrespectivamente.2.4.2.1 Especificación de Escenarios en base a las historias de usuario ESCENARIO Nº 1: AUTENTIFICACION DE USUARIOPropósito Escenario: Autentificar a los usuarios de la aplicación (Administrador / Vendedor) Tarjeta CRC: Autentificación TARJETA CRC Numero: 01 Escenario: Autentificación de usuario Nombre CRC: Autentificación Responsabilidades Colaboradores Métodos Obtener perfil del usuario obtenerUsuario Autentificar usuario setUsuario Observaciones: Se controlara el ingresan de usuarios participantes en la aplicación (Administrador/ vendedor) de acuerdo al cargo q posee en la empresa. Tabla4.1: Tarjeta CRC: Autentificación de Usuario 36
  • 37. ESCENARIO Nº 2: MANIPULACION DE PRODUCTOSPropósito Escenario: Administración de Productos que posee la empresa por el Administrador de la aplicación. Búsqueda de Productos por el Vendedor de la aplicaciónTarjeta CRC: Productos TARJETA CRC Numero: 02 Escenario: Manipulación de Productos Nombre CRC: Productos Responsabilidades Colaboradores Métodos Ingreso de Productos ingresarProductos Edición de Productos editarProductos Eliminación de Productos eliminarProductos Buscar Productos verProductos Observaciones: Los productos serán ingresados, editados y eliminados por el administrador. Así mismo la búsqueda de productos será realizada tanto por el administrador como por el Vendedor de la Aplicación Tabla 4.2: Tarjeta CRC: Manipulación de productos ESCENARIO Nº 3: RESGISTRO DE VENTASPropósito Escenario: Levar un registro de las ventas diarias del micro-mercado Facturar la ventas del mismo 37
  • 38. Tarjeta CRC: Ventas TARJETA CRC Numero: 03 Escenario: Registro de Ventas Nombre CRC: Ventas Responsabilidades Colaboradores Métodos Nueva Venta ingresarVenta Edición de Venta editarVenta Eliminación de Venta eliminarVenta Buscar Venta buscarVenta Procesar Venta procesarVenta Facturar Venta facturarVenta Observaciones: Las ventas serán creadas, procesada y facturada por el Vendedor de la aplicación. Las ventas serán buscadas, editadas y eliminadas por el administrador de la Aplicación Tabla 4.3: Tarjeta CRC: Registro de Ventas2.4.3. Diagrama de Entidades. Este se usa para visualizar las relaciones entrelas clases que involucran la aplicaciónDiagrama de Clases 38
  • 39. Figura 8: Diagrama de clases2.4.4 Arquitectura de la Aplicación y Descripción de ComponentesAquí se describe la arquitectura de la aplicación y sus componentes2.4.4.1 Descripción de componentes:Componente DescripciónInterfaces Interfaces a utilizarAutentificación Esta para la verificación de usuariosGenerar Venta En listar productos para ventaFactura Genera factura a imprimir de venta correspondienteManipulación de Datos Seleccionar opción de productoIngresar Datos Ingresa los datos del producto y envía a guardarEditar Datos Modifica los datos de un producto especificoEliminar Datos Suprime los datos de un producto Especifico 39
  • 40. Clases Clases a utilizarProductos Servirá para la manipulación de productos en la base de datosEmpleados Verificación de Usuarios a loguearseVendedor Comprueba la opción y procesa la acciónAdministrador Comprueba la opción y procesa la acción seleccionadaFactura Genera y Imprime FacturaVenta Genera VentaCliente Posee los datos del ClienteBase de DatosEmpleados Contiene datos del Empleado y su tipoProductos Contiene datos de los productos que posee la empresaVentas Contiene datos de las ventas realizadas Figura 9.1: Descripción de Componentes de la Aplicación2.4.4.2 Arquitectura de la Aplicación y BD del sistema Figura 10: Arquitectura de la Aplicación 40
  • 41. 2.5 Fase 5: Cierre del Proyecto. Debido a que el cliente no tiene más historias para ser incluidas en elsistema, es decir han sido satisfechas sus necesidades ahora es acorde llenarsus expectativas con lo que respecta al rendimiento, confiabilidad y eficienciadel sistema. Para esto generamos la documentación final del sistema que eslas especificaciones de pruebas.2.5.1 Especificacion de Pruebas; Para esta aplicación se especifican laspruebas de acuerdo a las Historias de Usuario pertenecientas a las diferentesIteraciones, mas adelante en el trascurso de proyecto 41
  • 42. 3. CONCLUSIONESDebido a la gran competencia que existe en el mercado, la empresa“Nueva Granada” debe de buscar la manera de poder mantenerse a laaltura de los demás y con una posición en el mercado. De esta manerase beneficia la propia compañía, como también sus clientes, sabiendoque una compañía bien organizada trabaja con más rapidez y con mejorcalidad.Después de dialogar con el economista Cristian Villamagua, cliente delproyecto y analizar conjuntamente los procesos de venta y cierre de cajadiario en su empresa, se pudo observar que estos procesos se realizanmanualmente, dando lugar a posibles alteraciones en las ventas deproductos como en los datos de ventas.Los problemas presentados inicialmente concernientes a la metodologíaaplicada en el proyecto se han sido solventando en el transcurso dedesarrollo de la aplicación, permitiéndome de esta manera conocer laventajas de una metodología ágil como lo es la metodología XP,brindándonos resultados visibles y funcionales a corto plazoSe tuvo retrasos en el calendario establecido en la planificación delproyecto, debido al tiempo invertido a consultas sobre la correctametodología aplicable al proyecto en curso, como también, mas tardesurgieron más retrasos debido a consultas sobre fases y procesos de laMetodología XP, la cual se eligió implementar.La planificación XP para la implementación de Iteraciones en esteproyecto es basada en un entorno que involucra al cliente como 42
  • 43. miembro del equipo de desarrollo de la aplicación, así mismo abarca loposible y lo deseable, en donde se busca un tiempo ideal para eldesarrollo del proyecto. 43
  • 44. 4. RECOMENDACIONES:Se recomienda la implementación de una metodología ágil en eldesarrollo de un software, para abarcar los constantes cambios delmismo y minimizar riesgos.Definir y representar de forma clara, concreta y precisa la informaciónconcerniente a las historias de usuario y así optimizar la implementaciónen el desarrollo del proyectoUtilizar las herramientas de desarrollo que nos brinde la metodología dedesarrollo de software escogidaProfundizar los conocimientos referentes a la metodología de desarrollode software escogida antes de iniciar un proyecto, con la finalidad deevitar confusiones y retrasos en los tiempos establecidos 44
  • 45. 5. BIBLIOGRAFIA[1] Martínez P. & Iglesias A. & Castro E. (2008). Ingeniería Técnica enInformática de Gestión. Madrid: Departamento de Informática UniversidadCarlos III. OCW[2] Jackson D & Devadas S. (2001) Curso práctico en Ingeniería de SoftwareModelo UML. USA: Universidad Massachusetts. OCW.http://ocw.usal.es/ensenanzas-tecnicas/ingenieria-del-software/contenidos/Tema2-Modeloobjeto-1pp.pdf[3] Deitel P. (2008). JAVA: Como Programar. México: Pearson Educación[4] Fernández G. (2002). Introducción a Extreme Programming. Departamentode Ingeniería del software.http://www.dsi.uclm.es/asignaturas/42551/trabajosAnteriores/Presentacion-XP.pdf[5] Camacho D. (2003). Programación, Algoritmos y Ejercicios Resueltos enJava. (USA) Madrid: Departamento de Informática Universidad Carlos III 2003[6] Gimeno J. (2007). Introducción a NetBeans. Madrid: Universidad de Madrid.OCW[7] Connolly T. & Begg C. (2010). Sistema de Base de Datos. (4ta edición).Madrid: Univesidad of Paisley. 45
  • 46. [8] Pérez H. (2008) Modelo de Clases. Chile: Universidad de Chile,Departamentos de Ciencias de la Computación. http://www.dcc.uchile.cl/[9] Naranjo M. (2006). Fundamentos de Definición de Arquitectura de Software.Chile: Universidad de chile Salón de Informática, 46