Facturacion I Bimestre
-
Upload
andrea-alvarez -
Category
Documents
-
view
1.266 -
download
1
description
Transcript of Facturacion I Bimestre
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
2
INDICE
PAG.
i. TEMA…………………………………………………………………………………..iii
ii. OBJETIVOS………………………………………………………………………….iv
a. GENERALES........................................................................................iv
b. ESPECIFICOS......................................................................................iv, v
iii. JUSTIFICACION...............................................................................................vi
iv. ALCANCE.........................................................................................................vii, viii
v. RESPORTES………………………………………..……………………..…….…..ix
vi. LIMITACIONES................................................................................................x
1. MARCO TEORICO...........................................................................................11
2. 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…………………………………………………….……..33
3. CONCLUSIONES…………………………………………………………………….…..…..42, 43
4. RECOMENDACIONES…………………………………………………………………..….. 44
5. BIBLIOGRAFIA…………………………………………………………………………..…….45, 46
3
i. Tema: “DESARROLLO DE APLICACION PARA SERVICIOS DE
VENTA DE PRODUCTOS DE CONSUMO MASIVO”.
4
ii. Objetivos
a. 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.
5
El usuario usuario Vendedor realizar búsquedas de productos,
ventas de productos y generar la factura correspondiente a la
venta.
6
iii. Justificación
El proyecto se a realizara debido a la necesidad de requerir más rapidez
y eficiencia como también seguridad al momento de realizar sus
compras/ventas de productos, es necesario las evoluciones tecnológicas en
las centros que brindan atención al cliente, siendo así muy importante la
creación de sistemas que nos brinden estas características.
También tiene como propósito el presente proyecto, el poder mejorar el
sistema de facturación para agilizar la emisión de comprobantes de crédito
fiscal (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 a
los usuarios finales como al propietario del mismo.
El impacto a corto y mediano plazo de esta aplicación será de llevar el
control de venta de su mercadería como el almacenamiento de información de
sus productos en stock en una Base de Datos. Para ello desea sistematizar la
mercadería en stock y sus facturas emitidas al cliente.
Esta aplicación será implementada en el lenguaje Java con la API
NetBeans y su base de datos será creada en Microsoft Access que es un
SGBD relacionales orientado a entornos personales u organizaciones
pequeñas que permite crear ficheros que pueden ser fácilmente gestionados
por una interfaz grafica. También permite manipular los datos, realizar las
respectivas consultas, formularios para introducir datos e informes para
presentar la información del usuario.
7
iv. Alcance
Este proyecto trata de construir una aplicación para llevar un registro
por 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 los
usuarios en los procesos que correspondan al mismo.
La aplicación podrá imprimir el formato de factura predefinida la
información requerida. Así mismo podrá ingresar datos de los productos
pertenecientes a la empresa en una base de datos con una autentificación
específica.
La aplicación contara con dos usuario Administrador y Vendedor: de
acuerdo con las caracterices de usuario que se registre, la aplicación
determinara 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.
8
Llevando así un histórico total acumulativo diario con el fin de facilitar la
lectura de ventas al realizar el cierre de caja diario.
9
v. Reportes a presentar
La necesidad de presentar reportes ha surgido de mal control de ventas de
productos 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.
10
vi. Limitaciones
Algunas 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
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
RUC/CI Cliente
Fecha Emisión
Factura
Nombre Cliente
Dirección Cliente
Teléfono Cliente
Cuerpo
Código
Producto Cantidad Producto Descripción Producto
Valor Unitario
Producto Subtotal Producto
Pie
Subtotal
12
Factura
IVA
……………………………… Descuentos
Cello
Empresa 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
13
Comunicación entre dos entes que tienen características similares de
comunicación en este caso la base de datos y la GUI del software
1.5 Microsoft Access
Es un sistema de gestión de bases de datos relacionales para los
sistemas operativos Microsoft Windows, desarrollado por Microsoft y orientado
a ser usado en un entorno personal o en pequeñas organizaciones. Este
programa permite manipular los datos en forma de tablas (formadas por filas y
columnas)
Esta aplicación empleara en la aplicación un almacena miento de datos en una
BD relacional, que contienen la información ordenada de una forma
organizada.
1.5.1 Tabla.- Son los objetos principales de bases de datos que se utilizan para
guardar datos. Está compuesta por campos o Registros
1.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 la
década de los noventa, proporciona potencia, robustez y seguridad que muy
pocos lenguajes le pueden igualar, sin olvidar su rasgo más conocido: es
totalmente portable. Está basado en lenguajes como C y C++, no obstante se
14
encuentra en constante desarrollo, las nuevas tecnología surgen y se
desarrollan a gran velocidad haciendo de java un lenguaje cada día mejor y
que cubre prácticamente todas las aéreas de la computación y la
comunicación, desde teléfonos móviles hasta servidores de aplicaciones [5]
1.6.1 NetBeans IDE.- Es una IDE (Intregrated Development Environment) de
JAVA entorno integrado de desarrollo, este trabaja a nivel de proyectos el cual
incluyes 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ódigo
ofrecido para simplificar la tarea de programación que las aplicaciones pueden
llamar cuando necesiten.
1.6.3 GUI (Interfaz grafica de usuario).- esta presenta un mecanismo
amigable al usuario para interactuar con una aplicación. Una GUI `proporciona
a un aplicación una “Apariencia visual” única. Al proporcionar distintas
aplicaciones en las que los componentes de la interfaz de usuario sean
constantes e intuitivos.
1.6.3.1 Botón.- es un componente en el que el usuario hace clic para
desencadenar cierta acción, una aplicación de Java puede utilizar varios
botones.
1.6.3.2 Evento.- un evento se generan cuando se oprimen y sueltan las teclas
en el teclado o por el mouse.
1.7 Un diagrama de clases
15
Sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de
contenimiento. Un diagrama de clases está compuesto por los siguientes
elementos:
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 desarrollo
de software formulada por “Kent Beck”. La programación extrema se diferencia
de las metodologías tradicionales principalmente en que pone más énfasis en
la adaptabilidad que en la previsibilidad. Otra particularidad de XP es tener
como parte del equipo al usuario final creando transparencia y un clima de
agilidad entre desarrolladores y clientes reduciendo el costo de cambio en las
etapas de vida del sistema y combinando las mejores prácticas de desarrollo
de software. Se destaca por su simplicidad, comunicación y reutilización de
código [4]
En la implementación de la metodología XP se realiza de acuerdo a las
siguientes fases de construcción:
16
Figura 2: Faces de costruccion de la metodologia XP
1.8.1 Historias de Usuario; Tienen el mismo propósito que los casos de uso y
constituyen una técnica utilizada en la metodología XP. Estas nos especificaran
los 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 considerado
la siguiente plantilla.
Figura 3: Plantilla de Historia de Usuario
Las historias de usuarios tendrán 3 aspectos cruciales:
Tarjetas: Contienen información necesaria para identificar la historia de usuario
17
Conversación: El cliente y el gerente del software con la finalidad de analizar
la historia y ampliar los detalles si así lo requiere, la misma que se realizara en
forma verbal cuando sea posible y documentada cuando lo requiera el
desarrollo del software
Confirmación: Realizada mediante pruebas de aceptación con el objetivo de
confirmar la correcta implementación de las historias de usuario
1.8.2. Tarjetas CRC: Representa Responsabilidades y Colaboraciones de las
Clases y su Interacción. La plantilla que se utilizara se utilizara es la siguiente:
Figura 4: Plantilla de Tarjetas CRC
1.8.3 Pruebas del sistema; Aquí se determina la aceptación de funcionalidad
que posee un sistema en base a las historias de usuario antes especificadas.
Para la documentación formal de las pruebas de aceptación, se implementara
la siguiente plantilla
18
Figura 5: Plantilla de prueba de aceptacioon
1.9. Prototipos
Es una herramienta de apoyo para el curso de cada una de las
actividades del desarrollo del sistema, para la creación del mismo es preciso
seguir el proceso de desarrollo de prototipos:
Figura 6: Plantilla de Historia de Usuario
19
1.9.1 Prototipos Desechables; este se encarga de validar derivar los
requerimientos del sistema, usado con los requerimientos que no se conoce
bien teniendo un periodo de vida corto.
1.10. Login.
Nombre o alias que se le da a una persona para permitirle el acceso al
sistema 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 empresa
1.13 Control. Se utiliza para seleccionar el control del producto. Cuando el
producto sale de las manos del productor, se pierde el control debido a que
pasa a ser propiedad del comprador y este puede hacer lo que quiere con el
producto. Ello implica que se pueda dejar el producto en un almacén o que se
presente en forma diferente en sus anaqueles. Por consiguiente es más
conveniente usar un canal corto de distribución ya que proporciona un mayor
control.
1.14 Arquitectura de Software.
Arte, ciencia y tecina de proyectar y construir espacios para que el
hombre pueda desarrollar sus actividades adecuadamente de manera sana
confortable y segura. [9]
20
Es la organización fundamental de un sistema descrito mediante:
componentes, relación entre ellos y el ambiente y principios que gruían su
diseño y evolución.
Según análisis debido análisis del sistema se ha subdividiendo así en tres
capas:
a. Capa de presentación (GUI)
b. Capa de Negocio
c. Capa de Acceso a datos
21
2. Análisis y diseño de la aplicación en función a la Metodología XP
2.1 Fase1: Exploración
Es esta fase los clientes plantean a grandes rasgos las historias de
usuario 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 Usuario
Numero:01 Nombre: Autentificación de usuarios
Usuario: Administrador /Vendedor
Modificación de Historia Numero: NA Iteración Asiganda: Primera
Prioridad en Negocio: Alta Riesgo en Desarrollo: Alta
Descripción:
Al ingresar a la aplicación esta le pedirá su autentificación como usuario Administrador o Vendedor, autentificación que se realizara ingresando la información correspondiente. Observaciones: en caso de ningún error al momento de autenticarse los usuarios, la
aplicación ingresara, presentara un error y no se iniciara las actividades
correspondientes.
Tabla 1.1: Historia de Usuario: Autentificación de Usuarios
22
R2.- Generar Venta.
Historia de Usuario
Numero:02 Nombre: Generar Venta
Usuario: Vendedor
Modificación de Historia Numero: 3, 5 Iteración Asiganda: Segunda
Prioridad en Negocio: Alta Riesgo en Desarrollo: Alto
Descripción:
La aplicación contara con la opción de generar una venta la cual pedirá ingresar los productos deseados por el cliente (comprador) Observaciones: en caso de que el cliente (comprador) no desee un producto en proceso
de venta, se podrá eliminar el mismo.
Tabla 1.2: Historia de Usuario: Generar Venta
R3.- Buscar Producto
Historia de Usuario
Numero:03 Nombre: Buscar Producto
Usuario: Vendedor
Modificación de Historia Numero: 1,5 Iteración Asiganda: Segunda
Prioridad en Negocio: Baja Riesgo en Desarrollo: Bajo
Descripción:
La aplicación contara con la opción de buscar un producto, esta búsqueda será realizada mediante el código del mismo, u se especifica las unidades, cuyos datos serán ingresados por el Vendedor Observaciones: una vez encontrado el producto o en caso de no haber existencias
disponibles la aplicación presentara un mensaje según sea el caso.
Tabla 1.3: Historia de Usuario: Buscar Producto
23
R4.- Generar Factura autentificado como Vendedor
Historia de Usuario
Numero:04 Nombre: Generar Factura
Usuario: Vendedor
Modificación de Historia
Numero:1,2,3,5
Iteración Asiganda: Tercera
Prioridad en Negocio: Alta Riesgo en Desarrollo: Alto
Descripció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 la
aplicación.
Tabla 1.4: Historia de Usuario: Generar Factura
R5.- Manipulación de productos.
Historia de Usuario
Numero:05 Nombre: Manipulación de productos
Usuario: Administrador
Modificación de Historia Numero: 1 Iteración Asiganda: Primera
Prioridad en Negocio: Alta Riesgo en Desarrollo: Alto
Descripción:
La aplicación le permitirá al Administrador la manipulación de productos que posee el Micro-Mercado, este podrá ingresar editar y eliminar productos Observaciones: Una vez realizadas cualquiera de estas opciones, la base de datos de la
aplicación se actualizara.
Tabla 1.5: Historia de Usuario: Manipulación de productos
R6.-Reporte de ventas
24
Historia de Usuario
Numero:06 Nombre: Reporte de ventas
Usuario: Administrador
Modificación de Historia Numero:
1,2,3,5
Iteración Asiganda: Tercera
Prioridad en Negocio: Media Riesgo en Desarrollo: medio
Descripción:
El Administrador podrá visualizar una lista de las ventas realizadas en el día, vista en la cual serán presentadas todas las características de venta, como por ejemplo: una descripción de los productos vendidos, descripción de venta y factura y descripción del cliente (comprador) al cual se realizo la venta. Observaciones: las ventas se podrán eliminar y editar.
Tabla 1.6: Historia de Usuario: Reportes de Ventas
R7.- Visualización de Productos
Historia de Usuario
Numero:07 Nombre: Visualizaciónde Productos
Usuario: Administrador
Modificación de Historia Numero: 1,5 Iteración Asiganda: Tercera
Prioridad en Negocio: Baja Riesgo en Desarrollo: Bajo
Descripción:
La aplicación contara con la opción de en listar los productos de la empresa y visualizar sus características como su estado dentro de la misma, estos estados pueden ser: vendido, en stock y caducado Observaciones: una vez encontrado el producto se podrá visualizar un coteo de los mismos
de cada unos de los tres estados del producto..
Tabla 1.7: Historia de Usuario: Visualización de Productos
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 Usuarios
Pantalla: Generar Venta y Búsqueda de Productos
Figura 7.2: Pantalla: Generar Venta y Búsqueda de Productos
26
Pantalla: Generar Factura
Figura 7.3: Pantalla: Generar Factura
Pantalla: Manipulación de Productos
Figura 7.4: Pantalla: Manipulación de Productos
27
Pantalla: Ingresar producto
Figura 7.5: Pantalla: Ingresar Producto
Pantalla: Modificar Producto
Figura 7.6: Pantalla: Modificar producto
28
Pantalla: Eliminar Producto
Figura 7.7: Pantalla: Eliminar producto
Pantalla: Reporte de Ventas
Figura 7.8: Pantalla: Reporte de Ventas
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 horas
Estimación de historias de usuario
NUMERO HISTORIA DE USUARIO TIEMPO 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
30
Taba 2.1: Estimación tiempo en base a las historias de Usuario
2.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 XP
Plan 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
Roles de usuarios
20/04/2012 28/04/2012
Fase 3. Plan de
iteraciones
Planificación de
Iteraciones
29/04/2012 08/05/2012
Fase 4. Producción - Primera versión del
sistemas
09/05/2012 30/06/2012
Fase 5. Cierre de
Proyecto
Manual de usuario
para administración
del sitio
Versión final del
proyecto
Entrega del
proyecto.
1 /07/2012 3/07/2012
Taba 2.2: Plan de Entregables
31
2.2.3 Roles de usuario; Específica los roles que cada unos de los integrantes
del equipo de desarrollo de software que desempeña en el desarrollo de la
aplicación, tomando en cuenta que el clienta desempeña un papel importante
del 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 proyecto
2.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
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
Tabla 3.1: Cuadro entregables: Historial de versiones por Historias de Usuario
2.3.2. Historial de seguimientos por Iteraciones
Tabla 3.2: Cuadro entregables: Historial de seguimientos por Iteraciones
ITERACION Nº HISTORIA DE USUARIO PRIORIDAD ENTREGA ACTIVIDAD DEPEND RIESGO VESION
ESTADO DE DESARROLLO PRUEBAS
Primera 1 Autentificación de usuarios 1 Nueva NA Alto 1 En curso No
aprobado
Segunda 2 Generar Venta 2 Nueva 1,3,5 Alto 1 Nulo No
aprobado
Segunda 3 Buscar Producto 2 Nueva 1,5 Bajo 1 Nulo
No
aprobado
Tercera 4 Generar Factura 3 Nueva 1,2,3,5 Alto 1 Nulo
No aprobado
Primera 5 Manipulación de productos 1 Nueva 1 Alto 1 Nulo
No aprobado
Tercera 6 Reporte de ventas 3 Nueva 1,2,3,5 Medio 1 Nulo
No
aprobado
Tercera 7 Visualización de Productos 3 Nueva 1,5 Bajo 1 Nulo
No
aprobado
ITERACION Nº HISTORIA DE USUARIO
FECHA PLANIFICACION ITERACIONES LANZAMIENTO
ESTADO DESARROLLO PRUEBAS
Primera 1
Autentificación de usuarios
09/05/2012 12/05/2012 02/07/2012 En curso
No aprobada
5
Manipulación de productos
13/05/2012 27/05/2012 02/07/2012 Nula
No aprobada
Segunda 2 Generar Venta 28/05/2012
02/06/2012 02/07/2012 Nula No
aprobada
3 Buscar Producto 03/06/2012
07/06/2012 02/07/2012 Nula No
aprobada
Tercera 4 Generar Factura 08/06/2012
15/06/2012 02/07/2012 Nula No
aprobada
6 Reporte de ventas 16/06/2012
23/06/2012 02/07/2012 Nula No
aprobada
7
Visualización de Productos
24/06/2012 30/06/2012 02/07/2012 Nula
No aprobada
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
Nº HISTORIA DE USUARIO TAREA
ESTADO DE DEARROLLO RESPONSABLE
ESFUERZO ESTIMADO (días )
ESFUERZO REAL INVERTIDO (días)
ESFUERZO POR REALIZAR (días)
1 Autenticación de Usuarios
Especificación de Pruebas completo
Andrea Álvarez 0.5 1 0
Monitoreo de herramientas XP completo
Andrea Álvarez 1 4 0
Diseño de Interfaz completo Andrea Álvarez 1 2 0
Diseño CRC completo Andrea Álvarez 1 nulo Nulo
Diagrama de Base de Datos nulo
Andrea Álvarez 1 nulo Nulo
Programación de Interfaz nulo
Andrea Álvarez 1 nulo Nulo
Pruebas de aceptación nulo
Andrea Álvarez 1 nulo Nulo
Esfuerzos totales 6 nulo Nulo
2 Generar Venta
Especificación de Pruebas completo
Andrea Álvarez 0.5 1 0
34
Monitoreo de herramientas XP completo
Andrea Álvarez 1 4 0
Diseño de Interfaz completo Andrea Álvarez 0.5 2 0
Diseño CRC completo Andrea Álvarez 0.5 nulo Nulo
Diagrama de Base de Datos nulo
Andrea Álvarez 1 nulo Nulo
Programación de Interfaz nulo
Andrea Álvarez 1 nulo Nulo
Pruebas de aceptación nulo
Andrea Álvarez 0.5 nulo Nulo
Esfuerzos totales 5 nulo Nulo
3 Buscar Producto
Especificación de Pruebas completo
Andrea Álvarez 0.5 1 0
Monitoreo de herramientas XP completo
Andrea Álvarez 2 4 0
Diseño de Interfaz completo Andrea Álvarez 0.5 2 0
Diseño CRC completo Andrea Álvarez 0.5 nulo Nulo
Diagrama de Base de Datos nulo
Andrea Álvarez 1 nulo Nulo
Programación de Interfaz nulo
Andrea Álvarez 2 nulo Nulo
Pruebas de aceptación nulo
Andrea Álvarez 0.5 nulo Nulo
Esfuerzos totales 5 nulo Nulo
4 Generar Factura
Especificación de Pruebas completo
Andrea Álvarez 0.5 1 0
Monitoreo de herramientas XP completo
Andrea Álvarez 2 4 0
Diseño de Interfaz completo Andrea Álvarez 1 2 0
Diseño CRC completo Andrea Álvarez 1 nulo Nulo
Diagrama de Base de Datos nulo
Andrea Álvarez 1 nulo Nulo
Programación de Interfaz nulo
Andrea Álvarez 3 nulo Nulo
Pruebas de aceptación nulo
Andrea Álvarez 0.5 nulo Nulo
Esfuerzos totales 8 nulo Nulo
5 Manipulación de Productos
Especificación de Pruebas completo
Andrea Álvarez 1 1 0
Monitoreo de herramientas XP completo
Andrea Álvarez 2 4 0
Diseño de Interfaz completo Andrea Álvarez 1 2 0
Diseño CRC completo Andrea 1 nulo Nulo
35
Álvarez
Diagrama de Base de Datos nulo
Andrea Álvarez 5 nulo Nulo
Programación de Interfaz nulo
Andrea Álvarez 4 nulo Nulo
Pruebas de aceptación nulo
Andrea Álvarez 1 nulo Nulo
Esfuerzos totales 15 nulo Nulo
6 Reporte de Ventas
Especificación de Pruebas completo
Andrea Álvarez 0.5 1 0
Monitoreo de herramientas XP completo
Andrea Álvarez 2 4 0
Diseño de Interfaz completo Andrea Álvarez 1 2 0
Diseño CRC completo Andrea Álvarez 1 nulo Nulo
Diagrama de Base de Datos nulo
Andrea Álvarez 1 nulo Nulo
Programación de Interfaz nulo
Andrea Álvarez 3 nulo Nulo
Pruebas de aceptación nulo
Andrea Álvarez 0.5 nulo Nulo
Esfuerzos totales 8 nulo Nulo
7 Visualización de Productos
Especificación de Pruebas completo
Andrea Álvarez 0.5 1 0
Monitoreo de herramientas XP completo
Andrea Álvarez 2 4 0
Diseño de Interfaz completo Andrea Álvarez 1 2 0
Diseño CRC completo Andrea Álvarez 1 nulo Nulo
Diagrama de Base de Datos nulo
Andrea Álvarez 1 nulo Nulo
Programación de Interfaz nulo
Andrea Álvarez 2 nulo Nulo
Pruebas de aceptación nulo
Andrea Álvarez 0.5 nulo Nulo
Esfuerzos totales 7 nulo Nulo
Tabla 3.3: Historial de Seguimiento de Tares Activas
36
2.4.2 Ejecución de Iteración; Permite Visualizar la forma de implementación
de cada Historia de Usuario en base a tarjetas CRC (Responsabilidades y
Colaboraciones de las Clases) y especificación de escenarios
respectivamente.
2.4.2.1 Especificación de Escenarios en base a las historias de usuario
ESCENARIO Nº 1: AUTENTIFICACION DE USUARIO
Propó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
Autentificar usuario
obtenerUsuario
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
37
ESCENARIO Nº 2: MANIPULACION DE PRODUCTOS
Propó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ón
Tarjeta CRC: Productos
TARJETA CRC
Numero: 02 Escenario: Manipulación de Productos
Nombre CRC: Productos
Responsabilidades Colaboradores Métodos
Ingreso de Productos
Edición de Productos
Eliminación de Productos
Buscar Productos
ingresarProductos
editarProductos
eliminarProductos
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 VENTAS
Propósito Escenario:
Levar un registro de las ventas diarias del micro-mercado
Facturar la ventas del mismo
38
Tarjeta CRC: Ventas
TARJETA CRC
Numero: 03 Escenario: Registro de Ventas
Nombre CRC: Ventas
Responsabilidades Colaboradores Métodos
Nueva Venta
Edición de Venta
Eliminación de Venta
Buscar Venta
Procesar Venta
Facturar Venta
ingresarVenta
editarVenta
eliminarVenta
buscarVenta
procesarVenta
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 Ventas
2.4.3. Diagrama de Entidades. Este se usa para visualizar las relaciones entre
las clases que involucran la aplicación
Diagrama de Clases
39
Figura 8: Diagrama de clases
2.4.4 Arquitectura de la Aplicación y Descripción de Componentes
Aquí se describe la arquitectura de la aplicación y sus componentes
2.4.4.1 Descripción de componentes:
Componente Descripción
Interfaces Interfaces a utilizar
Autentificación Esta para la verificación de usuarios
Generar Venta En listar productos para venta
Factura Genera factura a imprimir de venta correspondiente
Manipulación de Datos Seleccionar opción de producto
Ingresar Datos Ingresa los datos del producto y envía a guardar
Editar Datos Modifica los datos de un producto especifico
Eliminar Datos Suprime los datos de un producto Especifico
40
Clases Clases a utilizar
Productos Servirá para la manipulación de productos en la base de datos
Empleados Verificación de Usuarios a loguearse
Vendedor Comprueba la opción y procesa la acción
Administrador Comprueba la opción y procesa la acción seleccionada
Factura Genera y Imprime Factura
Venta Genera Venta
Cliente Posee los datos del Cliente
Base de Datos
Empleados Contiene datos del Empleado y su tipo
Productos Contiene datos de los productos que posee la empresa
Ventas Contiene datos de las ventas realizadas
Figura 9.1: Descripción de Componentes de la Aplicación
2.4.4.2 Arquitectura de la Aplicación y BD del sistema
Figura 10: Arquitectura de la Aplicación
41
2.5 Fase 5: Cierre del Proyecto.
Debido a que el cliente no tiene más historias para ser incluidas en el
sistema, es decir han sido satisfechas sus necesidades ahora es acorde llenar
sus expectativas con lo que respecta al rendimiento, confiabilidad y eficiencia
del sistema. Para esto generamos la documentación final del sistema que es
las especificaciones de pruebas.
2.5.1 Especificacion de Pruebas; Para esta aplicación se especifican las
pruebas de acuerdo a las Historias de Usuario pertenecientas a las diferentes
Iteraciones, mas adelante en el trascurso de proyecto
42
3. CONCLUSIONES
Debido a la gran competencia que existe en el mercado, la empresa
“Nueva Granada” debe de buscar la manera de poder mantenerse a la
altura de los demás y con una posición en el mercado. De esta manera
se beneficia la propia compañía, como también sus clientes, sabiendo
que una compañía bien organizada trabaja con más rapidez y con mejor
calidad.
Después de dialogar con el economista Cristian Villamagua, cliente del
proyecto y analizar conjuntamente los procesos de venta y cierre de caja
diario en su empresa, se pudo observar que estos procesos se realizan
manualmente, dando lugar a posibles alteraciones en las ventas de
productos como en los datos de ventas.
Los problemas presentados inicialmente concernientes a la metodología
aplicada en el proyecto se han sido solventando en el transcurso de
desarrollo de la aplicación, permitiéndome de esta manera conocer la
ventajas de una metodología ágil como lo es la metodología XP,
brindándonos resultados visibles y funcionales a corto plazo
Se tuvo retrasos en el calendario establecido en la planificación del
proyecto, debido al tiempo invertido a consultas sobre la correcta
metodología aplicable al proyecto en curso, como también, mas tarde
surgieron más retrasos debido a consultas sobre fases y procesos de la
Metodología XP, la cual se eligió implementar.
La planificación XP para la implementación de Iteraciones en este
proyecto es basada en un entorno que involucra al cliente como
43
miembro del equipo de desarrollo de la aplicación, así mismo abarca lo
posible y lo deseable, en donde se busca un tiempo ideal para el
desarrollo del proyecto.
44
4. RECOMENDACIONES:
Se recomienda la implementación de una metodología ágil en el
desarrollo de un software, para abarcar los constantes cambios del
mismo y minimizar riesgos.
Definir y representar de forma clara, concreta y precisa la información
concerniente a las historias de usuario y así optimizar la implementación
en el desarrollo del proyecto
Utilizar las herramientas de desarrollo que nos brinde la metodología de
desarrollo de software escogida
Profundizar los conocimientos referentes a la metodología de desarrollo
de software escogida antes de iniciar un proyecto, con la finalidad de
evitar confusiones y retrasos en los tiempos establecidos
45
5. BIBLIOGRAFIA
[1] Martínez P. & Iglesias A. & Castro E. (2008). Ingeniería Técnica en
Informática de Gestión. Madrid: Departamento de Informática Universidad
Carlos III. OCW
[2] Jackson D & Devadas S. (2001) Curso práctico en Ingeniería de Software
Modelo 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. Departamento
de 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 en
Java. (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.
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,