Upload
wilder-resurreccion-enriquez
View
237
Download
0
Embed Size (px)
DESCRIPTION
Estructura de un software para la gestión de almacenes
Citation preview
DEDICATORIA:A los docentes de la facultad de
Ingeniería de Sistemas, quienes en el transcurso de mi carrera han volcado toda su sapiencia profesional a fin de buscar fortalecer nuestra capacidad académica.
AGRADECIMIENTO:En especial a mis padres, por su constante apoyo y motivación que nos alienta para seguir adelante superando momentos difíciles en la brega académica, además, por el esfuerzo que han realizado para alcanzar la meta de ser un buen profesional-
INDICE
INTRODUCCION
CAPITULO i: GESTION DEL PROYECTO
1. PLAN DE DESARROLLO DE SOFTWARE2. VISTA GENERAL DEL PROYECTO3. GESTIÓN DEL PROYECTO
CAPITULO ii: MODELADO DEL NEGOCIO
1. EMPRESA DE DEPORTES2. MODELADO DEL NEGOCIO
CAPITULO III: REQUISITOS
1. VISIÓN2. GLOSARIO3. ESPECIFICACIONES DE CASO DE USO4. MODELADO DE CASO DE USO
CAPITULO IV: ANALISIS Y DISEÑO
1. MODELO DE ANÁLISIS / DISEÑO: DIAGRAMA DE CLASES2. MODELO DE DATOS: MODELO RELACIONAL
CAPITULO V: IMPLEMENTACION
1. PROTOTIPO DE INTERFACE DE USUARIO2. GESTIÓN DE VENTA3. GESTIÓN DE ALMACÉN
CAPITULO VI: PRUEBAS
1. PRUEBAS FUNCIONALESA. Base de Datos de Prueba
2. GESTIÓN DE ALMACÉNA. Consultas Pedidos no Atendidos
B. Casos de Prueba de Atender Pedido 1) Atender Pedido Después de Consultar Dicho Pedido2) Atender Pedido de la Lista de Pedidos no Atendidos3) Atender Pedido Asignando Cantidades Negativas4) Atender Pedido Asignando Cantidades Mayores a las Disponibles
5) Atender Pedido Asignando Cantidades Mayores a las Solicitadas6) Atender Pedido sin Asignar Cantidades
C. Cancelar pedido Atendido1) Elegir opción CANCELAR en la confirmación de la Cancelación de
pedido.2) Elegir opción ACEPTAR en la opción de cancelación de pedido
D. Incidencia de Pedido1) Crear una Incidencia Normal de Almacén2) Crear una Incidencia Vacía de Almacén3) Consultar una Incidencia en Almacén4) Crear una Incidencia Normal en Ventas5) Crear una Incidencia en Ventas
E. Caso de Prueba de Pasar Pedido a Envío1) Pasar Pedido Completo a envío desde la Lista de Pedido en
Atención2) Pasar Pedido Completo a envío3) Cancelar al Pasar un Pedido Incompleto4) Pasar a envío un Pedido Incompleto generando un pedido con las
Cantidades recientes5) Pasar a envío un Pedido sin generar un Pedido con las Cantidades
Restantes
3. GESTION DE VENTASA. Caso de Prueba de Elaborar Pedido
1) Elaborar Pedido y enviar a Almacén2) Elaborar Pedido y Guardar3) Elaborar Pedido Vacío y Guardar 4) Elaborar Pedido Vacío y Enviar a Almacén5) Modificar Pedido Resaltando dos Líneas con el mismo Producto6) Modificar Pedido Añadiendo una Línea de Cantidad Fuera de Rango7) Modificar Pedido añadiendo un producto inexistente8) Modificar Pedido añadiendo una Línea y enviar a Almacén9) Modificar Pedido añadiendo y eliminando una línea de pedido y
guardar10)Modificar Dirección de envío de Pedido11)Modificar Pedidos eliminando todas las líneas12)Enviar Pedido13)Comprobar Ratio de pago del Cliente
REFERENCIAS
ANEXOS
INTRODUCCIÓN
En el presente trabajo titulado DESARROLLO DE SOFTWARE PARA EL
CONTROL DE ARTICULOS DEPORTIVOS para optar el título de Profesional
Técnico en .Informática, realizamos el desarrollo de software basado en la
metodología de Rational Unified Process (RUP), que consiste en el desarrollo
de un sistema para la gestión de artículos deportivos de una empresa del
sector de ventas de deportes a clientes tanto a mayoristas como a minoristas.
Se incluye hasta la segunda iteración de la fase de construcción, según la
división establecida en el documento Plan de Desarrollo Software. Por motivos
de privacidad no se pueden publicar los datos de la entidad para la que se
diseñó el software.
La aplicación se desarrolló bajo el lenguaje de programación Visual Basic 6.0,
teniendo que soportar tanto acceso a una base de datos Oracle como a una
base de datos Access, dependiendo de la selección del usuario en el arranque
del programa.
La importancia de la presente investigación reside en el hecho de que los
productos que comercializan tienen una rápida rotación, lo que hace que el
control sobre este activo debe ser más preciso de manera que pueda asegurar
el mayor aprovechamiento de los recursos invertidos por la empresa. Es por
esta razón que se plantea el análisis del control en todo el proceso de entrada y
salida de mercadería.
Cabe precisar que, además, se plantea el diseño e Implantación Informático
para mejorar el proceso de almacenamiento de la empresa con el objetivo de
controlar el stock de sus productos, mejorar el proceso de almacenamiento,
logrando un posicionamiento competitivo en el ámbito nacional y satisfacer las
necesidades de sus clientes.
La tesis planteada posee un tipo de investigación Descriptiva y Aplicada,
Descriptiva porque se analizó en función a dos variables (Independiente y
Dependiente), y el planteamiento de hipótesis, aplicada porque utilizaremos
programas que serán aplicadas para el desarrollo de la herramienta.
Para alimentar la información sobre los procesos en la empresa se utilizó el
método de encuestas, realizando una pre-test y pos-test que por consiguiente
fue de mucha importancia para comprobar la hipótesis planteada. Asimismo, el
desarrollo de la investigación tiene los siguientes capítulos
En el Capítulo I, tratamos acerca de la Gestión del Proyecto se muestran las
planificaciones temporales de desarrollo del proyecto en su fase de inicio y de
elaboración, así como el diario de ejecución del proyecto, junto con el diario de
construcción de la aplicación y cumplimiento de los plazos estimados.
En el Capítulo II, Modelado del Negocio se encuentran los artefactos
utilizados de la metodología RUP para definir un modelo del negocio, modelos
de objetos del negocio y el modelo del dominio.
El Capítulo III, trata sobre los Requisitos que nos ilustra acerca de los
artefactos definidos según la metodología RUP, es decir, el documento plan de
desarrollo software, el documento visión, el documento glosario y las
especificaciones tanto de los casos de uso como de los casos de pruebas
relacionados con estos. También se recoge la gestión del proyecto con la
herramienta de Rational, el Requisite Pro, con la que además de llevar el
control de toda la documentación, se puede seguir la trazabilidad entre
requerimientos de todo el proyecto. En este apartado se muestran las matrices
de atributos de todos los requerimientos así como la navegabilidad entre ellos.
Por añadidura también se muestran los casos de uso de cada subsistema
generados con la herramienta Rational Rose, y desde los cuales también se
puede consultar la especificación del caso de uso.
Asimismo en el Capítulo IV, Análisis/Diseño se muestran tanto el modelo de
análisis/diseño (diagrama de clases) como el modelo de datos (modelo entidad
- relación), desde los cuales se puede consultar la especificación de los
métodos de clase más relevantes o las especificaciones de atributos.
En el Capítulo V: Implementación se muestran los prototipos de interfaces de
usuario de la aplicación, tanto para el sistema de gestión de ventas como para
el sistema de gestión de almacén. También en este apartado se muestran los
diagramas de componentes y diagrama de despliegue que modela las
aplicaciones incorporadas en el proyecto hasta la segunda iteración de la fase
de construcción (según la definición de fases e iteraciones de la metodología
RUP) y desde los cuales, a través de los componentes se puede consultar el
código fuente de cada uno.
Por último, en el Capítulo VI: Pruebas trata acerca de la especificación de
casos de pruebas funcionales consultables mediante el navegador o bien
descargables mediante un enlace en formato zip. Se muestran únicamente los
casos de pruebas generados para los casos de uso incorporados hasta la
segunda iteración de la fase de construcción.
Por tanto concluimos que el Sistema informático del proceso de Ventas en la
citada empresa brindara información satisfactoriamente para los reportes
utilizados de acuerdo a los datos de la presente investigación busca obtener
una considerable mejora en el control de sus procesos de ventas analizando la
problemática actual e identificando las causales y estableciendo objetivos que
permitan superar las debilidades del proceso.
CAPITULO I: GESTIÓN DEL PROYECTO
En este capítulo se detalla la planificación inicial del proyecto para la fase de
inicio y la fase de elaboración (según la definición de la metodología RUP) y el
diario de ejecución del proyecto, sesión tras sesión de trabajo.
1. PLAN DE DESARROLLO DE SOFTWARE
Este Plan de Desarrollo del Software es una versión preliminar preparada para
ser incluida en la propuesta elaborada como respuesta al proyecto de prácticas
de la asignatura de Laboratorio de Sistemas de Información de la Facultad de
Informática de la Universidad Politécnica de Valencia. Este documento provee
una visión global del enfoque de desarrollo propuesto.
El proyecto está basado en la metodología de Rational Unified Process en la
que únicamente se procederá a cumplir con las tres primeras fases que marca
la metodología, constando únicamente en la tercera fase de dos iteraciones. Es
importante destacar esto puesto que utilizaremos la terminología RUP en este
documento. Se incluirá el detalle para las fases de Inicio y Elaboración y
adicionalmente se esbozarán las fases posteriores de Construcción y
Transición para dar una visión global de todo proceso.
El enfoque desarrollo propuesto constituye una configuración del proceso RUP
de acuerdo a las características del proyecto, seleccionando los roles de los
participantes, las actividades a realizar y los artefactos (entregables) que serán
generados. Este documento es a su vez uno de los artefactos de RUP.
1.1. Propósito
El propósito del Plan de Desarrollo de Software es proporcionar la
información necesaria para controlar el proyecto. En él se describe el
enfoque de desarrollo del software.
Los usuarios del Plan de Desarrollo del Software son:
El jefe del proyecto lo utiliza para organizar la agenda y
necesidades de recursos, y para realizar su seguimiento.
Los miembros del equipo de desarrollo lo usan para entender lo
qué deben hacer, cuándo deben hacerlo y qué otras actividades
dependen de ello.
1.2. Alcance
El Plan de Desarrollo del Software describe el plan global usado para
el desarrollo del “Sistema para Gestión de Artículos Deportivos LSI
03”. El detalle de las iteraciones individuales se describe en los
planes de cada iteración, documentos que se aportan en forma
separada. Durante el proceso de desarrollo en el artefacto “Visión” se
definen las características del producto a desarrollar, lo cual
constituye la base para la planificación de las iteraciones. Para la
versión 1.0 del Plan de Desarrollo del Software, nos hemos basado
en la captura de requisitos por medio del stakeholder representante
de la empresa para hacer una estimación aproximada, una vez
comenzado el proyecto y durante la fase de Inicio se generará la
primera versión del artefacto “Visión”, el cual se utilizará para refinar
este documento. Posteriormente, el avance del proyecto y el
seguimiento en cada una de las iteraciones ocasionará el ajuste de
este documento produciendo nuevas versiones actualizadas.
2. Vista General del Proyecto
2.1. Propósito, Alcance y Objetivos
La información que a continuación se incluye ha sido extraída de las
diferentes reuniones que se han celebrado con el stakeholder de la
empresa desde el inicio del proyecto, Patricio Letelier Torres.
Deportes LSI 03 lleva a cabo la venta al por mayor de artículos
deportivos a nivel internacional. La entrada en un mercado
competitivo como en el que encuentra inmersa este firma conllevará
una previsible adaptación a los nuevos sistemas de información y a la
evolución tecnológica. Por ello, Deportes LSI 03 considera necesario
el desarrollo de un nuevo sistema de gestión de los artículos
deportivos que forman parte de sus catálogos, así como las bases de
datos que recogen datos tanto estadísticos, empresariales como de
nóminas, plantillas de personal, etc., por tanto los solicitantes
demandan una gestión más rápida, automática y segura de las
gestiones de almacén y bases de datos de los distintos
departamentos.
El proyecto debe proporcionar una propuesta para el desarrollo de
todos los subsistemas implicados en la gestión de artículos deportivos
y bases de datos departamentales”. Estos subsistemas se pueden
diferenciar en siete grandes bloques:
a) Gestión de Ventas, incluyendo:
Procedimiento de venta de productos vía operadoras de
teléfono.
Procedimiento de venta mediante la atención de comerciales a
domicilio del cliente.
Procedimiento de venta mediante el sistema online, vía web.
b) Gestión de Almacenes, incluyendo:
Gestión de nuevos pedidos.
Reserva de stock para la preparación de pedidos.
Gestión de incidencias de stock.
Gestión de pedidos para envío.
Gestión de consultas de estado de pedidos
Cancelación de pedidos solicitado por el cliente
c) Gestión de Envíos, incluyendo:
Gestión de Pedidos para envío.
Gestión de recibos
d) Departamento de Recursos Humanos.
e) Departamento de Marketing.
f) Departamento de Logística.
g) Contabilidad y Facturación.
2.2. Suposiciones y Restricciones
Las suposiciones y restricciones respecto del sistema, y que se
derivan directamente de las entrevistas con el stakeholder de la
empresa son:
a) Debe contemplarse las implicaciones de los siguientes puntos
críticos:
Compatibilidad de la solución con protocolos IPv6
Caracteres multilingües
Sistemas seguros: protección de información, seguridad en las
trasmisiones de datos (PKI), etc.
Gestión de flujos de trabajo, seguridad de transacciones e
intercambio de información
Adaptación a la normativa de Protección de Datos
b) La automatización de la gestión interna del registro debe ajustarse
a la legislación vigente y considerar la previsión de la nueva
legislación referente a los dominios de tercer nivel.
El subsistema “Gestión de Almacenes” debe diseñarse como
módulo independiente para ser utilizado posteriormente en
otras regiones de los distintos almacenes no centralizados
encargados de proveer a cada región de clientes de Deportes
LSI 03.
Como es natural, la lista de suposiciones y restricciones se incrementará
durante el desarrollo del proyecto, particularmente una vez establecido el
artefacto “Visión”.
2.3. Entregables del proyecto
A continuación se indican y describen cada uno de los artefactos que
serán generados y utilizados por el proyecto y que constituyen los
entregables. Esta lista constituye la configuración de RUP desde la
perspectiva de artefactos, y que proponemos para este proyecto.
Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo
proceso iterativo e incremental), todos los artefactos son objeto de
modificaciones a lo largo del proceso de desarrollo, con lo cual, sólo
al término del proceso podríamos tener una versión definitiva y
completa de cada uno de ellos. Sin embargo, el resultado de cada
iteración y los hitos del proyecto están enfocados a conseguir un
cierto grado de completitud y estabilidad de los artefactos. Esto será
indicado más adelante cuando se presenten los objetivos de cada
iteración.
1) Plan de Desarrollo del Software
Es el presente documento.
2) Modelo de Casos de Uso del Negocio
Es un modelo de las funciones de negocio vistas desde la
perspectiva de los actores externos (Agentes de registro,
solicitantes finales, otros sistemas etc.). permite situar al sistema
en el contexto organizacional haciendo énfasis en los objetivos en
este ámbito. Este modelo se representa con un Diagrama de
Casos de Uso usando estereotipos específicos para este modelo.
3) Modelo de Objetos del Negocio
Es un modelo que describe la realización de cada caso de uso
del negocio, estableciendo los actores internos, la información que
en términos generales manipulan y los flujos de trabajo
(workflows) asociados al caso de uso del negocio. Para la
representación de este modelo se utilizan Diagramas de
Colaboración (para mostrar actores externos, internos y las
entidades (información) que manipulan, un Diagrama de Clases
para mostrar gráficamente las entidades del sistema y sus
relaciones, y Diagramas de Actividad para mostrar los flujos de
trabajo.
4) Glosario
Es un documento que define los principales términos usados en
el proyecto. Permite establecer una terminología consensuada. .
5) Modelo de Casos de Uso
El modelo de Casos de Uso presenta las funciones del sistema y
los actores que hacen uso de ellas. Se representa mediante
Diagramas de Casos de Uso.
6) Visión
Este documento define la visión del producto desde la perspectiva
del cliente, especificando las necesidades y características del
producto. Constituye una base de acuerdo en cuanto a los
requisitos del sistema.
7) Especificaciones de Casos de Uso
Para los casos de uso que lo requieran (cuya funcionalidad no sea
evidente o que no baste con una simple descripción narrativa) se
realiza una descripción detallada utilizando una plantilla de
documento, donde se incluyen: precondiciones, post-condiciones,
flujo de eventos, requisitos no-funcionales asociados. También,
para casos de uso cuyo flujo de eventos sea complejo podrá
adjuntarse una representación gráfica mediante un Diagrama de
Actividad.
8. Especificaciones Adicionales
Este documento capturará todos los requisitos que no han sido
incluidos como parte de los casos de uso y se refieren
requisitos no-funcionales globales. Dichos requisitos incluyen:
requisitos legales o normas, aplicación de estándares,
requisitos de calidad del producto, tales como: confiabilidad,
desempeño, etc., u otros requisitos de ambiente, tales como:
sistema operativo, requisitos de compatibilidad, etc.
9) Prototipos de Interfaces de Usuario
Se trata de prototipos que permiten al usuario hacerse una idea
más o menos precisa de las interfaces que proveerá el sistema
y así, conseguir retroalimentación de su parte respecto a los
requisitos del sistema. Estos prototipos se realizarán como:
dibujos a mano en papel, dibujos con alguna herramienta
gráfica o prototipos ejecutables interactivos, siguiendo ese
orden de acuerdo al avance del proyecto. Sólo los de este
último tipo serán entregados al final de la fase de Elaboración,
los otros serán desechados. Asimismo, este artefacto, será
desechado en la fase de Construcción en la medida que el
resultado de las iteraciones vayan desarrollando el producto
final.
10) Modelo de Análisis y Diseño
Este modelo establece la realización de los casos de uso en
clases y pasando desde una representación en términos de
análisis (sin incluir aspectos de implementación) hacia una de
diseño (incluyendo una orientación hacia el entorno de
implementación), de acuerdo al avance del proyecto.
11) Modelo de Datos
Previendo que la persistencia de la información del sistema
será soportada por una base de datos relacional, este modelo
describe la representación lógica de los datos persistentes, de
acuerdo con el enfoque para modelado relacional de datos.
Para expresar este modelo se utiliza un Diagrama de Clases
(donde se utiliza un profile UML para Modelado de Datos, para
conseguir la representación de tablas, claves, etc.) .
12) Modelo de Implementación
Este modelo es una colección de componentes y los
subsistemas que los contienen. Estos componentes incluyen:
ficheros ejecutables, ficheros de código fuente, y todo otro tipo
de ficheros necesarios para la implantación y despliegue del
sistema. (Este modelo es sólo una versión preliminar al final de
la fase de Elaboración, posteriormente tiene bastante
refinamiento).
13) Modelo de Despliegue
Este modelo muestra el despliegue la configuración de tipos de
nodos del sistema, en los cuales se hará el despliegue de los
componentes.
14) Casos de Prueba
Cada prueba es especificada mediante un documento que
establece las condiciones de ejecución, las entradas de la
prueba, y los resultados esperados. Estos casos de prueba son
aplicados como pruebas de regresión en cada iteración. Cada
caso de prueba llevará asociado un procedimiento de prueba
con las instrucciones para realizar la prueba, y dependiendo del
tipo de prueba dicho procedimiento podrá ser automatizable
mediante un script de prueba.
15) Solicitud de Cambio
Los cambios propuestos para los artefactos se formalizan
mediante este documento. Mediante este documento se hace
un seguimiento de los defectos detectados, solicitud de
mejoras o cambios en los requisitos del producto. Así se
provee un registro de decisiones de cambios, de su evaluación
e impacto, y se asegura que éstos sean conocidos por el
equipo de desarrollo. Los cambios se establecen respecto de la
última baseline (el estado del conjunto de los artefactos en un
momento determinado del proyecto) establecida. En nuestro
caso al final de cada iteración se establecerá una baseline.
16) Plan de Iteración
Es un conjunto de actividades y tareas ordenadas
temporalmente, con recursos asignados, dependencias entre
ellas. Se realiza para cada iteración, y para todas las fases.
17) Evaluación de Iteración
Este documento incluye le evaluación de los resultados de
cada iteración, el grado en el cual se han conseguido los
objetivos de la iteración, las lecciones aprendidas y los cambios
a ser realizados.
18) Lista de Riesgos
Este documento incluye una lista de los riesgos conocidos y
vigentes en el proyecto, ordenados en orden decreciente de
importancia y con acciones específicas de contingencia o para
su mitigación.
19) Manual de Instalación
Este documento incluye las instrucciones para realizar la
instalación del producto.
20) Material de Apoyo al Usuario Final
Corresponde a un conjunto de documentos y facilidades de uso
del sistema, incluyendo: Guías del Usuario, Guías de
Operación, Guías de Mantenimiento y Sistema de Ayuda en
Línea
21) Producto
Los ficheros del producto empaquetados y almacenadas en un
CD con los mecanismos apropiados para facilitar su
instalación. El producto, a partir de la primera iteración de la
fase de Construcción es desarrollado incremental e
iterativamente, obteniéndose una nueva release al final de
cada iteración.
Los artefactos 19, 20 y 21 se generarán a partir de la fase de
Construcción, con lo cual se han incluido aquí sólo para dar
una visión global de todos los artefactos que se generarán en
el proceso de desarrollo.
2.4. Evolución del Plan de Desarrollo del Software
El Plan de Desarrollo del Software se revisará semanalmente y se
refinará antes del comienzo de cada iteración.
3. Gestión del Proceso
3.1. Estimaciones del Proyecto
El presupuesto del proyecto y los recursos involucrados se adjuntan
en un documento separado.
3.2. Plan del Proyecto
En esta sección se presenta la organización en fases e iteraciones y
el calendario del proyecto.
3.2.1. Plan de las Fases
El desarrollo se llevará a cabo en base a fases con una o más
iteraciones en cada una de ellas. La siguiente tabla muestra una la
distribución de tiempos y el número de iteraciones de cada fase (para
las fases de Construcción y Transición es sólo una aproximación muy
preliminar)
Fase Nro.Iteraciones
Duración
Fase de Inicio 1 3 semanas
Fase de Elaboración 1 2 semanas
Fase de Construcción
2 7 semanas
Fase de Transición - -
Los hitos que marcan el final de cada fase se describen en la siguiente
tabla.
Descripción Hito
Fase de Inicio En esta fase desarrollará los requisitos del producto desde la perspectiva del usuario, los cuales serán establecidos en el artefacto Visión. Los principales casos de uso serán identificados y se hará un refinamiento del Plan de Desarrollo del Proyecto. La aceptación del cliente / usuario del artefacto Visión y el Plan de Desarrollo marcan el final de esta fase.
Fase de Elaboración
En esta fase se analizan los requisitos y se desarrolla un prototipo de arquitectura (incluyendo las partes más relevantes y / o críticas del sistema). Al final de esta fase, todos los casos de uso correspondientes a requisitos que serán implementados en la primera release de la fase de Construcción deben estar analizados y diseñados (en el Modelo de Análisis / Diseño). La revisión y aceptación del prototipo de la arquitectura del sistema marca el final de esta fase. En nuestro caso particular, por no incluirse las fases siguientes, la revisión y entrega de todos los artefactos hasta este punto de desarrollo también se incluye como hito. La primera iteración tendrá como objetivo la identificación y especificación de los principales casos de uso, así como su realización preliminar en el Modelo de Análisis / Diseño, también permitirá hacer una revisión general del estado de los artefactos hasta este punto y ajustar si es necesario la planificación para asegurar el cumplimiento de los objetivos. Ambas iteraciones tendrán una duración de una semana.
Fase de Construcción
Durante la fase de construcción se terminan de analizar y diseñar todos los casos de uso, refinando el Modelo de Análisis / Diseño. El producto se construye en base a 2 iteraciones, cada una produciendo una release a la cual se le aplican las pruebas y se valida con el cliente / usuario. Se comienza la elaboración de material de apoyo al usuario. El hito que marca el fin de esta fase es la versión de la release 3.0, con la capacidad operacional parcial del producto que se haya considerado como crítica, lista para ser entregada a los usuarios para pruebas beta.
Fase de Transición En esta fase se prepararán dos releases para distribución, asegurando una implantación y cambio del sistema previo de manera adecuada, incluyendo el entrenamiento de los usuarios. El hito que marca el fin de esta fase incluye, la entrega de toda la documentación del proyecto con los manuales de instalación y todo el material de apoyo al usuario, la finalización del entrenamiento de los usuarios y el empaquetamiento del producto.
3.2.2. Calendario del Proyecto
A continuación se presenta un calendario de las principales tareas
del proyecto incluyendo sólo las fases de Inicio y Elaboración. Como
se ha comentado, el proceso iterativo e incremental de RUP está
caracterizado por la realización en paralelo de todas las disciplinas
de desarrollo a lo largo del proyecto, con lo cual la mayoría de los
artefactos son generados muy tempranamente en el proyecto pero
van desarrollándose en mayor o menor grado de acuerdo a la fase e
iteración del proyecto. La siguiente figura ilustra este enfoque, en
ella lo ensombrecido marca el énfasis de cada disciplina (workflow)
en un momento determinado del desarrollo.
Para este proyecto se ha establecido el siguiente calendario. La fecha de
aprobación indica cuándo el artefacto en cuestión tiene un estado de
completitud suficiente para someterse a revisión y aprobación, pero esto no
quita la posibilidad de su posterior refinamiento y cambios.
Disciplinas / Artefactos generados o modificadosdurante la Fase de Inicio
Comienzo Aprobación
Modelado del NegocioModelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio
Semana 114/10 – 20/10
Semana 328/10 – 3/11
Requisitos
Glosario Semana 114/10 – 20/10
Semana 328/10 – 3/11
Visión Semana 221/10 – 27/10
Semana 328/10 – 3/11
Modelo de Casos de Uso Semana 328/10 – 3/11
siguiente fase
Especificación de Casos de Uso Semana 328/10 – 3/11
siguiente fase
Especificaciones Adicionales Semana 328/10 – 3/11
siguiente fase
Análisis / Diseño
Modelo de Análisis / Diseño Semana 221/10 – 27/10
siguiente fase
Modelo de Datos Semana 221/10 – 27/10
siguiente fase
Implementación
Prototipos de Interfaces de Usuario Semana 328/10 – 3/11
siguiente fase
Modelo de Implementación Semana 328/10 – 3/11
siguiente fase
Pruebas
Casos de Pruebas Funcionales Semana 328/10 – 3/11
siguiente fase
Despliegue
Modelo de Despliegue Semana 328/10 – 3/10
siguiente fase
Gestión de Cambios y Configuración Durante todo el proyectoGestión del proyecto
Plan de Desarrollo del Software en su versión 1.0 y planes de las Iteraciones
Semana 114/10 – 20/10
Semana 328/10 – 3/11
Ambiente Durante todo el proyecto
.
Disciplinas / Artefactosgenerados o modificados durante laFase de Elaboración
Comienzo Aprobación
Modelado del NegocioModelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio
Semana 114/10 – 20/10
Aprobado
Requisitos
Glosario Semana 114/10 – 20/10
Aprobado
Visión Semana 221/10 – 27/10
Aprobado
Modelo de Casos de Uso Semana 328/10 – 3/11
Semana 511/12 – 17/12
Especificación de Casos de Uso Semana 328/10 – 3/11
Semana 511/12 – 17/12
Especificaciones Adicionales Semana 328/10 – 3/11
Semana 511/12 – 17/12
Análisis / Diseño
Modelo de Análisis / Diseño Semana 221/10 – 27/10
Revisar en cada iteración
Modelo de Datos Semana 221/10 – 27/10
Revisar en cada iteración
Implementación
Prototipos de Interfaces de Usuario Semana 328/10 – 3/11
Revisar en cada iteración
Modelo de Implementación Semana 328/10 – 3/11
Revisar en cada iteración
Pruebas
Casos de Pruebas Funcionales Semana 328/10 – 3/11
Revisar en cada iteración
Despliegue
Modelo de Despliegue Semana 328/10 – 3/11
Revisar en cada iteración
Gestión de Cambios y Configuración Durante todo el proyectoGestión del proyecto
Plan de Desarrollo del Software en su versión 2.0 y planes de las Iteraciones
Semana 44/11 – 10/11
Revisar en cada iteración
Ambiente Durante todo el proyecto
3.3 Seguimiento y Control del Proyecto
Gestión de Requisitos
Los requisitos del sistema son especificados en el artefacto Visión.
Cada requisito tendrá una serie de atributos tales como importancia,
estado, iteración donde se implementa, etc. Estos atributos permitirán
realizar un efectivo seguimiento de cada requisito. Los cambios en los
requisitos serán gestionados mediante una Solicitud de Cambio, las
cuales serán evaluadas y distribuidas para asegurar la integridad del
sistema y el correcto proceso de gestión de configuración y cambios.
Control de Plazos
El calendario del proyecto tendrá un seguimiento y evaluación
semanal por el jefe de proyecto y por el Comité de Seguimiento y
Control.
Control de Calidad
Los defectos detectados en las revisiones y formalizados también en
una Solicitud de Cambio tendrán un seguimiento para asegurar la
conformidad respecto de la solución de dichas deficiencias Para la
revisión de cada artefacto y su correspondiente garantía de calidad se
utilizarán las guías de revisión y checklist (listas de verificación)
incluidas en RUP.
Gestión de Riesgos
A partir de la fase de Inicio se mantendrá una lista de riesgos
asociados al proyecto y de las acciones establecidas como estrategia
para mitigarlos o acciones de contingencia. Esta lista será evaluada al
menos una vez en cada iteración.
Gestión de Configuración
Se realizará una gestión de configuración para llevar un registro de
los artefactos generados y sus versiones. También se incluirá la
gestión de las Solicitudes de Cambio y de las modificaciones que
éstas produzcan, informando y publicando dichos cambios para que
sean accesibles a todo los participantes en el proyecto. Al final de
cada iteración se establecerá una baseline (un registro del estado de
cada artefacto, estableciendo una versión), la cual podrá ser
modificada sólo por una Solicitud de Cambio aprobada.
CAPITULO II: MODELADO DEL NEGOCIO
A continuación se presentan los modelos definidos en RUP como modelo del
negocio (modelo de casos de uso del negocio y de los objetos del negocio),
modelo de datos y modelo de análisis y diseño. También se muestran los
diagramas de componentes y diagramas de despliegue del proyecto.
1. EMPRESA DE DEPORTES
La empresa de deportes que solicitó el proyecto de desarrollo software
consta de varios departamentos centralizados, un almacén central y de
diversas sucursales de ventas repartidas en distintos distritos de Lima.
Cada sucursal de ventas dispone de un almacén que suministra los
pedidos de los clientes a los distritos, siendo el almacén central el que
abastece al resto de almacenes.
El diagrama que representa los diferentes subsistemas en los que se ha
dividido la empresa a nivel de abstracción es el siguiente:
2. MODELADO DEL NEGOCIO
El modelado del negocio se basa en dos diagramas principales, el modelo
de casos de uso del negocio, el modelo del dominio y los modelos de
objetos del negocio.
La empresa interactúa con distintos elementos externos, entre los que se
identifican el cliente externo (persona o entidad que solicita la compra de
productos a la empresa), el proveedor (persona o entidad que reabastece
de productos a la empresa) y por último la empresa de transportes, que es
una subcontrata encargada de servir los pedidos desde los distintos
almacenes a los clientes de la empresa.
Modelo de Casos de Uso del Negocio
Los modelos de objetos del dominio están asociados a cada uno de los casos
de uso del negocio. Por ser de mayor prioridad para la empresa, el caso de uso
para el cual se desarrolló el modelo de objetos fue el del caso de uso del
negocio "vender productos".
Modelo de Objetos de Vender Productos
Modelo de Objetos de Seguimiento y Consulta de Productos
Modelo de Objetos de Reponer Stock
Modelo de Objetos de Modificar Catálogo
Modelo de Objetos de Realizar Entrega
CAPITULO III: REQUISITOS
El propósito de éste capítulo es recoger, analizar y definir las necesidades de
alto nivel y las características del sistema de gestión de una empresa de
distribución de artículos deportivos. El documento se centra en la funcionalidad
requerida por los participantes en el proyecto y los usuarios finales.
Esta funcionalidad se basa principalmente en la gestión de los almacenes que
la empresa tiene repartidos por las distintas zonas en las que actúa, de forma
que dichos almacenes sean capaces de atender los distintos pedidos que les
son realizados.
Los detalles de cómo el sistema cubre los requerimientos se pueden observar
en la especificación de los casos de uso y otros documentos adicionales.
1. VISION
Comprende todas las tareas relacionadas con la determinación de las
necesidades o de las condiciones a satisfacer para el software que nos
proponemos elaborar, tomando en cuenta los diversos requisitos de las partes
interesadas, que pueden entrar en conflicto entre ellos.
1. Alcance
El documento Visión se ocupa, como ya se ha apuntado, del sistema de
gestión de una empresa dedicada a la distribución de artículos deportivos.
Dicho sistema será desarrollado por el grupo de desarrollo de software
LSI 03.
El sistema permitirá a los encargados de la empresa controlar todo lo
relativo a la distribución de los artículos (gestión de stock, gestión de
pedidos, gestión de clientes, etc.). Además, también permitirá a los
clientes realizar pedidos online, realizar un seguimiento de sus pedidos,
etc.
2. Definiciones, Acrónimos, y Abreviaciones
RUP: Son las siglas de Rational Unified Process. Se trata de una
metodología para describir el proceso de desarrollo de software.
3. Referencias
- Glosario.
- Plan de desarrollo de software.¡
- RUP (Rational Unified Process).
- Diagrama de casos de uso.
4. Posicionamiento
4.1. Oportunidad de Negocio
Este sistema permitirá a la empresa informatizar el control de todas
sus actividades (gestión de stock en cada almacén, gestión de
pedidos, etc.), lo cual supondrá un acceso rápido y sencillo a los
datos, gracias a interfaces gráficas sencillas y amigables. Además, los
datos accedidos estarán siempre actualizados, lo cual es un factor
muy importante para poder llevar un control centralizado de los
distintos almacenes.
El sistema también permite a los clientes acceder a los servicios de la
empresa a través de web, de forma rápida y sencilla y sin necesidad
de intermediarios.
4.2. Sentencia que define el problema
El problema de Controlar el stock existente en los distintos almacenes, de forma que se puedan servir los pedidos que reciben dichos almacenes.
Gestionar las órdenes de compra realizadas por los clientes.
Gestionar los pedidos realizados a los proveedores.
Gestionar la facturación de la empresa.
afecta a Departamento de logística,Jefes de almacenes,
Técnicos de almacenes,
Encargados de transporte,
Usuarios de ventas de cada región,
Departamento de contabilidad / facturación,
Departamento de recursos humanos,
Departamento de marketing.
El impacto asociado es Almacenar toda la información referente a los almacenes, pedidos y órdenes de compra recibidas, y que esta información esté al instante accesible y actualizada en lugares físicamente muy distantes es un proceso prácticamente imposible de realizar en el caso de que no esté informatizado.
Una solución adecuada sería Informatizar el proceso, usando una red local con una base de datos accesible
desde los distintos nodos de la red y generar interfaces amigables y sencillas con las que acceder a dicha base de datos.
4.3. Sentencia que define la posición del Producto
Para Departamento de logística,Jefes de almacenes,
Técnicos de almacenes,
Encargados de transporte,
Usuarios de ventas de cada región,
Departamento de contabilidad / facturación,
Departamento de recursos humanos,
Departamento de marketing.Quienes Controlan los pedidos, los almacenes
(stock), las órdenes de pedido y la facturación.
El nombre del producto Es una herramienta software.
Que Almacena la información necesaria para gestionar una empresa de distribución.
no como El sistema actual.
Nuestro producto Permite gestionar las distintas actividades de la empresa mediante una interfaz gráfica sencilla y amigable. Además proporciona un acceso rápido y actualizado a la información desde cualquier punto que tenga acceso a la base de datos.
5. Descripción de Stakeholders (Participantes en el Proyecto) y Usuarios
Para proveer de una forma efectiva productos y servicios que se ajusten a
las necesidades de los usuarios, es necesario identificar e involucrar a
todos los participantes en el proyecto como parte del proceso de modelado
de requerimientos. También es necesario identificar a los usuarios del
sistema y asegurarse de que el conjunto de participantes en el proyecto los
representa adecuadamente. Esta sección muestra un perfil de los
participantes y de los usuarios involucrados en el proyecto, así como los
problemas más importantes que éstos perciben para enfocar la solución
propuesta hacia ellos. No describe sus requisitos específicos ya que éstos
se capturan mediante otro artefacto. En lugar de esto proporciona la
justificación de por qué estos requisitos son necesarios.
5.1. Resumen de Stakeholders
Nombre Descripción Responsabilidades
Patricio Orlando Letelier Torres
Representante Global de la empresa Deportes LSI 03
El stakeholder realiza:Representa a todos los usuarios posibles del sistema.Seguimiento del desarrollo del proyecto.Aprueba requisitos y funcionalidades
5.2. Resumen de Usuarios
Nombre Descripción Stakeholder
Ingeniero de Logística
Responsable del Departamento de Logística, encargado de la gestión del almacén central, del aprovisionamiento del resto de almacenes y del contacto con los proveedores.
Logística
Jefe de Almacén
Supervisor del buen funcionamiento del almacén y de gestionar las incidencias de los pedidos, ya sea tratando con otro almacén, o bien en contacto con el Ingeniero de Logística.
Almacén
Técnico de Almacén
Encargado directo del almacén, control de stocks, preparación y despacho de pedidos.
Almacén
Representante de
Responsable de ventas del producto a los clientes, mediante visitas al domicilio del cliente.
Ventas
Ventas Informa de las ofertas y confecciona las órdenes de pedido.
Jefe de Ventas
Supervisor del Departamento de Ventas, encargado de otorgar incentivos y del control de estadísticas.
Ventas
Contable
Encargado de la facturación y cobranzas, política de cobro de los clientes.
Contabilidad / Facturación
Empleado de Maketing
Responsable de ofertas de lanzamiento, publicidad, política de ventas y otros aspectos relacionados con el marketing.
Marketing
Cliente Online
Realiza compras online, por teléfono a través de los comerciales, o tratando con éstos directamente.
Ventas
Operadora
Responsable de ventas del producto a los clientes, a través del teléfono. Informa de las ofertas y confecciona las órdenes de pedido.
Ventas
Encargado de Transporte
Responsable de consultar los envíos que se van a realizar desde un almacén. Cargar los camiones con los pedidos a enviar e introducir los datos del pedido. Una vez entregado el pedido, introducir los recibos de entrega.
Envíos
Empleado de Recursos Humanos
Responsable de realizar las entrevistas de trabajo para el nuevo personal y por tanto acceso a la base de datos de currículos. También encargado de la gestión de nóminas..
Recursos Humanos
Jefe de Recurso
Responsable de la gestión de personal, es
Recursos Humanos
s Humanos
decir, contratos y despidos, y también encargado de la redistribución de la plantilla.
5.3. Entorno de usuario
Los usuarios entrarán al sistema identificándose sobre un ordenador
con un sistema operativo Windows 2000 y tras este paso entrarán a la
parte de aplicación diseñada para cada uno según su papel en la
empresa. Este sistema es similar a cualquier aplicación Windows y
por tanto los usuarios estarán familiarizados con su entorno.
Los informes serán generados con Microsoft Word versión 2000, lo
cual también resultará familiar.
5.4. Perfil de los Stakeholders
5.4.1. Representante del área técnica y sistemas de información
Representante Patricio Orlando Letelier TorresDescripción Representante Global de la Empresa Deportes LSI 03.Tipo Experto de Sistemas.Responsabilidades
Encargado de mostrar las necesidades de cada usuario del sistema. Además, lleva a cabo un seguimiento del desarrollo del proyecto y aprobación de los requisitos y funcionalidades del sistema
Criterio de Éxito A definir por el clienteGrado de participación
Revisión de requerimientos, estructura del sistema
Comentarios Ninguno
5.5. Perfiles de Usuario
5.5.1. Ingeniero de Logística
Representante LogísticaDescripción Jefe del Departamento de Logística de la Empresa.Tipo Gurú.Responsabilidades
Responsable del Departamento de Logística, encargado
de la gestión del almacén central, del aprovisionamiento del resto de almacenes y del contacto con los proveedores. Control de estadísticas para la optimización de recursos.
Criterio de Éxito A definir por el clienteGrado de participación
A definir por el cliente
Comentarios Ninguno
5.5.2 Jefe de Almacén
Representante Almacén
Descripción Jefe del almacén de una región determinada.
Tipo Usuario casual del sistema.
Responsabilidades
Supervisor del buen funcionamiento del almacén y de gestionar las incidencias de los pedidos, ya sea tratando con otro almacén, o bien en contacto con el Ingeniero de Logística. Capacidad de toma de decisiones en cuanto a distribución de mercancías desde otro almacén y cancelación de pedidos que han sido atendidos.
Criterio de Éxito A definir por el cliente
Grado de participación
A definir por el cliente
Comentarios Ninguno.
5.5.3. Técnico de Almacén
Representante Almacén
Descripción Responsable del almacén de una región determinada.
Tipo Usuario experto.
Responsabilidades
Encargado directo del almacén, control de stocks y distribución de los productos, preparación y atención de las órdenes de pedido y solicitudes de envío al cliente. Gestión de incidencias a través del de un técnico comercial para que se ponga en contacto con el cliente, o bien por medio del jefe de almacén.
Criterio de Éxito A definir por el cliente
Grado de A definir por el cliente
participaciónComentarios Niniguno.
5.5.4 Representante de Ventas
Representante Ventas
Descripción Representante de ventas de los productos
Tipo Usuario experto.
Responsabilidades Responsable de ventas del producto a los clientes, mediante visitas al domicilio del cliente. Informa de las ofertas y confecciona las órdenes de pedido. También participa en las incidencias de pedidos poniéndose en contacto con el cliente para la resolución de los mismos. Puede cancelar pedidos en estado de elaboración.
Criterio de Éxito A definir por el cliente
Grado de participación
A definir por el cliente
Comentarios Ninguno.
5.5.5. Operadora
Representante Ventas
Descripción Operadora de ventas de los productos
Tipo Usuario experto.
Responsabilidades
Responsable de ventas del producto a los clientes a través del teléfono. Informa de las ofertas y confecciona las órdenes de pedido. También participa en las incidencias de pedidos poniéndose en contacto con el cliente para la resolución de los mismos.
Criterio de Éxito A definir por el cliente
Grado de participación
A definir por el cliente
Comentarios Ninguno.
5.5.6. Jefe de Ventas
Representante Ventas
Descripción Jefe del Departamento de Ventas de una región determinada.
Tipo Usuario experto.
Responsabilidades Supervisor del Departamento de Ventas, encargado de otorgar incentivos y del control de estadísticas.
Criterio de Éxito A definir por el cliente
Grado de participación
A definir por el cliente
Comentarios Ninguno.
5.5.7. Encargado de Transporte
Representante EnvíosDescripción Encargado de Transportes de un almacén
determinado.Tipo Usuario experto.Responsabilidades Supervisor del transporte de mercancías desde el
almacén hasta el domicilio de los clientes. Carga los pedidos en el camión, registra en el sistema los datos del envío y una vez entregado el pedido al cliente, introduce el recibo de entrega en la base de datos.
Criterio de Éxito A definir por el cliente
Grado de
participación
A definir por el cliente
Comentarios Ninguno.
5.5.8. Contable
Representante Contabilidad / Facturación
Descripción Empleado del Departamento de Contabilidad y Facturación.
Tipo Usuario experto.
Responsabilidades
Encargado de la facturación y cobranzas, política de cobro de los clientes.
Criterio de Éxito A definir por el cliente
Grado de participación
A definir por el cliente
Comentarios Niguno.
5.5.9. Empleado de Marketing
Representante Marketing
Descripción Empleado del Departamento de Marketing.
Tipo Usuario eventual.
Responsabilidades Responsable de ofertas de lanzamiento, publicidad, política de ventas y otros aspectos relacionados con el marketing.
Criterio de Éxito A definir por el cliente
Grado de participación
A definir por el cliente
Comentarios Ninguno.
5.5.10. Cliente Online
Representante Ventas
Descripción Comprador de productos.
Tipo Usuario casual.
Responsabilidades Realiza compras online y consulta del estado de pedidos como del catálogo. También puede darse de alta, darse de baja o modificar sus datos de cliente.
Criterio de Éxito A definir por el cliente
Grado de participación
A definir por el cliente
Comentarios Ninguno.
5.5.11. Empleado de Recursos Humanos
Representante Recursos Humanos
Descripción Empleado del Departamento de Recursos Humanos.
Tipo Usuario casual.
Responsabilidades
Responsable de las entrevistas de trabajo y registra los datos de las mismas, incluyendo la gestión de una base de datos de currículos de trabajadores en potencia. También realiza la gestión de contratos y nóminas del personal.
Criterio de Éxito A definir por el cliente
Grado de participación
A definir por el cliente
Comentarios Ninguno.
5.5.12. Jefe de Recursos Humanos
Representante Recursos Humanos
Descripción Empleado del Departamento de Recursos Humanos.
Tipo Usuario casual.
Responsabilidades
Responsable de la gestión de personal, es decir, gestión de contrataciones y gestión de despidos. También es responsable de la redistribución de la plantilla.
Criterio de Éxito A definir por el cliente
Grado de participación
A definir por el cliente
Comentarios Ninguno.
6. Descripción Global del Producto
6.1. Perspectiva del producto
El producto a desarrollar es un sistema global para la empresa
Deportes LSI 03, con la intención de agilizar su funcionamiento. Las
áreas a tratar por el sistema son: logística, gestión de recursos
humanos, contabilidad y marketing.
6.2. Resumen de características
A continuación se mostrará un listado con los beneficios que obtendrá
el cliente a partir del producto:
Beneficio del cliente Características que lo apoyan
Mayor agilidad en los pedidos dando la posibilidad de hacerlo vía servicios web.
Aplicación web desde la cual poder realizar los pedidos.
Gestión automatizada del stock del almacén. Sistema de optimización de del stock en el almacén y previsión de pedidos
Mayor facilidad para la gestión de los recursos humanos.
Base de datos centralizada con la información de todo el personal.
Posibilidad de cancelación de órdenes por parte del cliente dando la posibilidad de hacerlo vía servicios web.
Aplicación web desde la que poder cancelar pedidos.
Automatización de la cancelación de estas órdenes.
Sistema automatizado de anulación de órdenes.
Mayor facilidad para el control e catálogos para el área de marketing.
Base de datos con acceso remoto desde la que poder controlar ofertas y políticas de ventas.
Automatización del sistema de nóminas Sistema automático de generación de nóminas.
6.3. Suposiciones y dependencias [A definir por el cliente]
6.4. Costo y precio
[A definir por el cliente]
7. Descripción Global del Producto
7.1. Departamento de Recursos Humanos
Departamento encargado de la gestión de la plantilla y asignación de
destino de trabajo. Los trabajadores con rol de recursos humanos
tendrán acceso a un a parte del subsistema en la que se darán de alta,
de baja y se modificarán datos de la plantilla, así como a otra parte en
la que asignarán el personal adecuado a cada área.
7.2. Departamento de Marketing
Departamento responsable de la confección de catálogos d productos ,
políticas de ventas y realizar las distintas ofertas sobre los productos.
Los trabajadores con este rol tendrán acceso a una parte del sistema
conectado con la base de datos de producto de forma que puedan
controlar y aplicar las ofertas correspondientes sobre estos.
7.3. Departamento de Logística
Departamento que dirige y gestiona el almacén centralizado de la
compañía, que es el abastecimiento principal del resto de almacenes.
Este departamento dispondrá de una parte del sistema que
automatizará el proceso de reposición de stocks de los almacenes y el
reabastecimiento de los distintos almacenes, tanto el central como los
regionales mediante los proveedores de la compañía.
7.3.1. Control de estadísticas de distintos datos
Para llevar un buen control de los requerimientos de la empresa,
las necesidades de cada almacén y de cada departamento es
necesario que el sistema genere una serie de datos estadísticos
históricos que clarifiquen el excesivo volumen de datos
numéricos que se generan en la compra-venta de artículos.
7.4. Gestión de Almacén
En el subsistema de almacén se atienden los pedidos que han sido
elaborados en el departamento de ventas y que han sido pasados a la
gestión de almacenes. Los pedidos que figuran como no atendidos
pueden pasar a ser atendidos una vez que el técnico de almacén
reserva stock de productos para dichos pedidos. Durante el proceso de
atención el pedido puede sufrir diversas modificaciones en la
asignación de stock, y una vez confeccionado en su totalidad, pasa a
pedido listo para envío, y una vez en este estado pasará a ser tratado
por el subsistema de gestión de envíos.
7.4.1. Atención de las órdenes de pedido procedentes de
elaboración.
Un pedido que ha pasado del estado de elaboración al estado de
pedido no atendido figurará en el almacén en el listado de
pedidos no atendidos. El técnico de almacén podrá atender un
pedido asignándole stock del almacén. Una vez confeccionado
completamente el pedido, el técnico de almacén podrá hacer
que figure el pedido como listo para envío, de tal forma que el
encargado de transportes sepa que lo puede cargar en el
camión. En cualquier momento, el pedido podrá ser cancelado.
7.4.2 Gestión de incidencias de pedido
En caso de que en un pedido se detecte que no hay stock
suficiente para poder satisfacerlo, el técnico de almacén podrá
lanzar una incidencia de pedido, en la que figurará el o los
pedidos que no han podido completarse por falta de stock en el
almacén. Posteriormente el jefe de ventas del almacén
gestionará las incidencias de pedido y el déficit de stocks. El jefe
de almacén podrá solicitar stock de productos a otros almacenes
para reponer el déficit de stock o bien podrá solicitar al ingeniero
de logística que distribuya productos del almacén central o bien
por medio de proveedor.
7.4.3 Consulta del estado de los pedidos
En todo momento, se podrá consultar el estado de los pedidos
que se encuentran en periodo de no atención, en periodo de
atención, listos para envío y pedidos en estado de envío. La
información presentará los datos relevantes para cada estado
que se haya definido.
7.5. Gestión de Ventas
El departamento de ventas dispone de tres servicios distintos de
ventas: las ventas a domicilio del cliente mediante un representante de
ventas. Las ventas a través de una de las operadoras de la empresa,
con la que el cliente solicita sus pedidos a través del medio telefónico.
Y por último, se dispondrá de servicios web para poder hacer los
pedidos de esta forma, considerando al cliente como cliente online.
7.5.1 Información de ofertas y elaboración de pedidos
Un representante de ventas o una operadora pueden elaborar
pedidos o bien para su propios clientes (caso del representante)
o bien para cualquier cliente (caso de la operadora). Los pedidos
figurarán en estado de elaboración y eliminar a petición del
cliente o modificar las líneas del pedido, ya sea en cantidades de
productos como en los distintos productos de que consta el
pedido.
7.5.2 Gestión de los datos de los clientes
Un representante de ventas o una operadora pueden modificar
los datos de los clientes. En el caso de la operadora podrá
modificar cualquier cliente, y en el caso del representante de
ventas podrá modificar cualquiera de los clientes a los que
representa. También podrán darse de baja clientes, o darse de
alta unos nuevos. El cliente online también podrá a través de los
servicios web modificar sus datos, darse de alta o de baja.
5.5.3 Consulta de los productos del catálogo
Un representante de ventas, una operadora o un cliente online
pueden consultar en todo momento el catálogo a la hora de
elaborar su pedidos.
7.6 Gestión de Envíos
En el sistema de envíos, los pedidos se cargan en los camiones y se
refleja el estado nuevo de los pedidos en el sistema,
7.6.1 Enviar los pedidos del almacén pendientes de envío
Cuando se realiza un envío se incorporan los datos del
transportista, referencia del envío y fecha en la que se realizó el
transporte.
7.6.2. Control de los recibos de entrega
Posteriormente se lleva un control de recibos una vez que el
cliente ha recibido los pedidos en la dirección de envío
especificada. El estado de los envíos de los pedidos se podrá
consultar vía los servicios web por parte del cliente o mediante
el propio sistema por parte del personal tanto de ventas como
de almacén y transportes.
7.7. Departamento de Contabilidad y Facturación
El departamento de contabilidad y facturación tendrá acceso a todo el
subsistema de contabilidad y facturación, es decir, todo aquello que
englobe cobro de pedidos pendientes, gestión de nóminas y
comisiones, facturación a clientes según modalidad de pago, etc.
8. Restricciones
[A definir por el cliente]
9. Precedencia y Prioridad
[A definir por el cliente]
10. Otros Requisitos del Producto
10.1 Estándares Aplicables
[A definir por el cliente]
10.2 Requisitos de Sistema
[A definir por el cliente]
10.3 Requisitos de Desempeño
[A definir por el cliente]
10.4 Requisitos de Entorno
[A definir por el cliente]
11. Requisitos de Documentación
[A definir por el cliente]
11.1 Manual de Usuario
[A definir por el cliente]
11.2. Ayuda en Línea
[A definir por el cliente]
11.3. Guías de Instalación, Configuración, y Fichero Léame
[A definir por el cliente]
A. Atributos de Características
Número y nombre de la característica
Estado Beneficio Esfuerzo Riesgo Estabilidad Asignación
5.1 Depart. de Recursos Humanos
Propuesta: SíAprobada: SíIncorporada:
No
Útil Bajo [A definir por el cliente]
[A definir por el cliente] Ninguna
5.2 Depart. de Marketing
Propuesta: SíAprobada: SíIncorporada:
No
Útil Bajo [A definir por el cliente]
[A definir por el cliente] Ninguna
5.3 Depart. de Logística
Propuesta: SíAprobada: SíIncorporada:
No
Importante
Medio [A definir por el cliente]
[A definir por el cliente] Ninguna
5.3.1 Control de estadísticas de
datos
Propuesta: SíAprobada: SíIncorporada:
No
Útil Medio [A definir por el cliente]
[A definir por el cliente] Ninguna
5.4 Gestión de Almacén
Propuesta: SíAprobada: Sí
Incorporada: SíCrítica Alto [A definir por
el cliente][A definir por
el cliente]
J.A. Mocholí, Germán Mira, Miguel Mascilla
y Eduardo Bueno
5.4.1 Atención de órdenes de
pedido
Propuesta: SíAprobada: Sí
Incorporada: SíCrítica Alto [A definir por
el cliente][A definir por
el cliente]José Antonio Mocholí
5.4.2 Gestión de incidencias de
pedido
Propuesta: SíAprobada: SíIncorporada:
Útil Medio [A definir por el cliente]
[A definir por el cliente]
Ninguna
No5.4.3 Consulta
de estado de los pedidos
Propuesta: SíAprobada: Sí
Incorporada: Sí
Importante Medio [A definir por
el cliente][A definir por
el cliente]Eduardo Bueno
5.5 Gestión de Ventas
Propuesta: SíAprobada: Sí
Incorporada: SíCrítica Alto [A definir por
el cliente][A definir por
el cliente]
José Antonio Mocholí, Germán Mira y Miguel Mascilla
5.5.1 Elaborar pedidos y
ofertas
Propuesta: SíAprobada: Sí
Incorporada: SíÚtil Medio [A definir por
el cliente][A definir por
el cliente]
José Antonio Mocholí, Germán Mira y Miguel Mascilla
5.5.2 Gestión de datos de clientes
Propuesta: SíAprobada: SíIncorporada:
No
Importante
Medio [A definir por el cliente]
[A definir por el cliente] Ninguna
5.5.3 Consulta de productos del
catálogo
Propuesta: SíAprobada: SíIncorporada:
No
Importante
Medio [A definir por el cliente]
[A definir por el cliente] Ninguna
5.6 Gestión de Envíos
Propuesta: SíAprobada: SíIncorporada:
No
Importante
Medio [A definir por el cliente]
[A definir por el cliente] Ninguna
5.6.1 Enviar los pedidos del
almacén
Propuesta: SíAprobada: SíIncorporada:
No
Importante
Bajo [A definir por el cliente]
[A definir por el cliente] Ninguna
5.6.2 Control de los recibos de
entrega
Propuesta: SíAprobada: SíIncorporada:
No
Útil Bajo [A definir por el cliente]
[A definir por el cliente] Ninguna
5.7 Depart. de Contabilidad y
Facturación
Propuesta: SíAprobada: SíIncorporada:
No
Útil Medio [A definir por el cliente]
[A definir por el cliente] Ninguna
2. GLOSARIO
Este documento recoge todos y cada uno de los términos manejados a lo
largo de todo el proyecto de desarrollo de un sistema para la gestión de
artículos deportivos de la empresa Deportes LSI 03. Se trata de un
diccionario informal de datos y definiciones de la nomenclatura que se
maneja, de tal modo que se crea un estándar para todo el proyecto.
1) Propósito
El propósito de este glosario es definir con exactitud y sin ambigüedad
la terminología manejada en el proyecto de desarrollo de un sistema
para la gestión de artículos deportivos. También sirve como guía de
consulta para la clarificación de los puntos conflictivos o poco
esclarecedores del proyecto.
1.1. Alcance
El alcance del presente documento se extiende a todos los
subsistemas definidos para la empresa Deportes LSI 03. De tal
modo que la terminología empleada en el departamento de
logística, el departamento de recursos humanos, el departamento
de marketing, el departamento de contabilidad y facturación, en la
gestión de envíos, en la gestión de almacenes y en la gestión de
ventas, se refleja con claridad en este documento.
1.2. Referencias
El presente glosario hace referencia a los siguientes
documentos
Documento Plan de Desarrollo Software del Proyecto Deportes
LSI03
Documento Visión del Proyecto Deportes LSI 03
Documentos de Especificación de Casos de Uso del Proyecto
Deportes LSI 03
Documentos de Especificación de Casos de Pruebas del
Proyecto Deportes LSI 03
1.3. Organización del Glosario
El presente documento está organizado por definiciones de
términos ordenados de forma ascendente según la ordenación
alfabética tradicional del Español.
2) Definiciones
A continuación se presentan todos los términos manejados a lo largo
de todo el proyecto de desarrollo de un sistema para la gestión de
artículos deportivos en la empresa Deportes LSI 03.
2.1 Almacén
Un almacén es una de las naves pertenecientes a la empresa
Deportes LSI 03 en la que se mantiene el stock de productos que
se servirá a los clientes según pedido. Existe un almacén por cada
región definida, que es el encargado de servir los pedidos de
aquellos clientes cuya dirección de envío sea la perteneciente a
dicha región. La empresa también dispone de un almacén central
desde el cual se reabastece el stock de los distintos almacenes
regionales.
2.2.Atender pedido
El técnico del almacén de una determinada región selecciona un
pedido y asigna línea por línea una reserva de stock del producto
para dicho pedido.
2.3.Cancelar pedido atendido
Un pedido que ya ha sido atendido por un técnico de almacén
puede ser cancelado por el técnico de almacén mientras el pedido
esté en el almacén y no esté en envío, simplemente eliminándolo
de la base de datos y liberando el stock que tiene asignado. El
cliente puede cancelar un pedido que está siendo enviado, pero
con un cargo añadido por costes de transporte.
2.4 Cancelar pedido en elaboración
Un pedido que se encuentra en estado de elaboración puede ser
cancelado o bien a través de un representante de ventas o bien a
través de una operadora. El primero de ellos podrá eliminar
pedidos en elaboración de aquellos clientes a quienes represente,
mientras que la segunda puede cancelar pedidos en elaboración de
cualquier cliente. El propio cliente puede eliminar directamente sus
pedidos en elaboración si accede al sistema como cliente online y
directamente a través de la página web de elaborar pedidos online.
2.5.Cancelar pedido listo para envío
Un pedido en estado de listo para envío sólo puede ser cancelado
por el técnico de almacén que pertenezca al almacén regional que
sirve a dicho pedido. El pedido podrá ser eliminado de la lista de
pedidos listos para envío mediante la interfaz del mencionado
usuario, actualizándose la lista de pedidos listos para envío.
2.6.Cancelar pedido online
Un pedido que está en elaboración puede ser cancelado por el
cliente online simplemente seleccionando a través de la página
web el pedido que desea eliminar y suprimiéndolo. La base de
datos se actualiza con la eliminación del pedido en elaboración.
Sólo se pueden eliminar online pedidos en elaboración.
2.7.Catálogo de productos
El catálogo de productos es la colección de artículos deportivos con
los que trabaja la empresa Deportes Lsi 03. Se trata de un
compendio de toda clase de artículos, como por ejemplo, zapatillas
de deportes, camisetas, balones, raquetas, pelotas, pantalones de
deportes, chándales, bicicletas, etc. El catálogo de productos
comprende el nombre del artículo, una referencia del mismo dentro
de la catalogación de la empresa, una descripción del producto,
una fotografía del mismo y el precio de venta.
2.8.Cliente externo
El cliente externo es el cliente propiamente dicho, es decir, en la
visión que ofrece Rational Rose del modelo de casos de uso del
negocio, el cliente externo representa uno de tantos agentes
externos con los que interactúa la empresa Deportes LSI 03. Por
tanto, el cliente externo es el comprador de los artículos, que puede
ser cualquier tienda de deportes, grandes almacenes e incluso
particulares.
2.9.Cliente online
El cliente online es un determinado usuario de ventas del sistema.
El cliente online es un cliente que se conecta al sistema mediante
Internet y a través de la página web de la empresa Deportes LSI
03. El cliente online puede darse de alta como cliente nuevo, puede
darse de baja o modificar sus datos. También puede elaborar
pedidos a través de la página web.
2.10. Consultar pedidos a enviar
La consulta de los pedidos a enviar la puede realizar el encargado
de transportes mediante la interfaz gráfica que muestra la
funcionalidad principal del subsistema de gestión de envíos.
2.11. Cobro a clientes
El pago de los pedidos que realizan los clientes se realiza de
diversas maneras según el tipo de cliente. En primer lugar, una vez
que se ha entregado la mercancía en la dirección de envío que ha
especificado el cliente para la entrega de un pedido, se realiza la
formalización de un recibo que posteriormente se introducirá en el
sistema informático. En segundo lugar, una vez que el recibo ha
llegado al departamento de cobro y facturación, se determina el
tipo de pago que ha de realizar el cliente según la forma de pago
que haya solicitado (a 30 días, a 60 días, etc.). Por último, se
remite la factura al cliente una vez realizado el cobro del pedido.
2.12. Comprar a proveedor
La compra a proveedores se realiza a través del departamento de
logística, encargado de reabastecer tanto el almacén central como
los distintos almacenes regionales de la empresa. El ingeniero de
logística contacta con los distintos proveedores cuando se detecta
déficit en algún artículo o cuando se prevé un volumen de ventas
elevado. Se selecciona al proveedor que marque el precio más
competitivo de acuerdo con la política de compras que marca la
empresa.
2.13.Confeccionar catálogo
El catálogo de productos sufre constantes cambios debido a la
fluctuación de las demandas de los artículos y las diferentes modas
que se apoderan del momento. Por tanto, es responsabilidad del
departamento de marketing de la empresa la actualización del
catálogo de productos que ofrece la empresa a sus clientes.
2.14. Consultar catálogo
La consulta del catálogo se realiza mediante las interfaces que
ofrece el sistema. Tanto los representantes de ventas como las
operadoras pueden en todo momento consultar el catálogo para
informar a sus clientes de las descripciones de los productos y
precios, y para consultar las referencias de los artículos. Los
empleados del departamento de marketing también consultan el
catálogo para buscar posibles actualizaciones. También se puede
consultar el catálogo de productos a través de Internet vía la web
de la empresa, como cliente online.
2.15 Consultar pedidos no atendidos
Los pedidos que figuran como pedidos no atendidos se pueden
consultar en cualquiera de los almacenes regionales o en el
almacén central por el técnico de almacén, mediante la interfaz
gráfica correspondiente en la pestaña de “no atendidos” figura la
lista de los pedidos que aún no han pasado a ser atendidos en el
almacén. Se puede consultar no sólo el estado de los pedidos, sino
también las líneas de productos y los datos referentes al pedido.
Una vez realizada esta consulta sobre un pedido en particular, el
pedido pasa automáticamente al estado de pedido atendido.
2.16. Contable
Empleado del departamento de contabilidad y facturación.
Encargado de los cobros y facturaciones a clientes y de llevar la
contabilidad en general de la empresa.
2.17. Control de estadísticas
El control de estadísticas es un resumen general de los datos de
interés relacionado con la empresa, cada uno de los distintos
usuarios autorizados podrá acceder a diferentes visiones de las
estadísticas generadas, por ejemplo, para el ingeniero de logísticas
las estadísticas más interesantes son volúmenes de ventas,
demandas de productos, históricos de los almacenes, etc. Para el
jefe de ventas, las estadísticas interesantes son las que conciernen
a sus empleados, por ejemplo, ventas realizadas, seguimiento de
comisiones, etc.
2.18 Departamento de contabilidad y facturación
El departamento de contabilidad y facturación es el encargado del
cobro de pedidos entregados a los clientes, de facturar a los
clientes, de la asignación de remuneraciones de los distintos
empleados y de todas las características propias de la contabilidad
empresarial.
2.19 Departamento de logística
Departamento encargado de la gestión eficiente de la distribución
de productos y stock del almacén central de la empresa a los
distintos almacenes regionales. También tiene la funcionalidad de
compra de productos a proveedores para reabastecer el stock del
almacén central y de la gestión eficiente de las distintas regiones
definidas para todos los países en los que Deportes LSI 03 ofrece
sus productos.
2.20 Departamento de marketing
Este departamento está encargado de la realización de ofertas de
los distintos productos del catálogo. También están encargados de
la publicidad y promoción de artículos, determinar las distintas
políticas de ventas aplicadas, y confeccionar el catálogo cuando
sufra modificaciones según la fluctuación de oferta y demanda del
mercado.
2.21. Departamento de recursos humanos
Este departamento cumple con las siguientes funciones: la
distribución de la plantilla de la empresa, determinar el puesto de
trabajo del personal, determinar los contratos que se fijan con cada
empleado, controlar las estadísticas de rendimiento y realizar
entrevistas de trabajo. También cumple la función de despido y
contratación de los trabajadores.
2.22. Elaborar pedido online
El cliente se conecta a la página web de la empresa y puede
realizar pedidos a través de Internet de un modo bastante sencillo.
Se identifica como cliente online con un nombre de usuario y una
contraseña y abre la página de elaborar un pedido nuevo o
modificar los pedidos en elaboración que ya tuviese pendientes. El
cliente online puede añadir o modificar líneas de un pedido en
elaboración ya existente o añadir nuevas líneas a un pedido nuevo.
Una vez haya concluido puede pasar el pedido al almacén regional
correspondiente a la dirección de envío o bien guardarlo como
pedido en elaboración para posteriores modificaciones.
2.23. Elaborar pedido
El representante de ventas o la operadora reciben la petición de un
cliente para elaborar pedido. El listado de pedidos en elaboración
de dicho cliente aparece en la pantalla y el representante de ventas
o la operadora pueden modificar un pedido ya existente, borrarlo, o
bien crear uno nuevo. El representante de ventas o la operadora
pueden añadir o modificar líneas de un pedido en elaboración ya
existente o añadir nuevas líneas a un pedido nuevo. Una vez hayan
concluido pueden pasar el pedido al almacén regional
correspondiente a la dirección de envío o bien guardarlo como
pedido en elaboración para posteriores modificaciones.
2.24.Empleado de marketing
El empleado de marketing es un usuario del sistema que pertenece
al departamento de marketing. Puede confeccionar el catálogo,
cambiando cualquier dato de los productos existentes, o también
eliminando o agregando productos nuevos. Está encargado de la
política de productos, es decir, de la política de ventas que se debe
aplicar a cada artículo. También puede realizar ofertas, definiendo
precios más competitivos o ajustados a los márgenes de
beneficios.
2.25. Empleado de recursos humanos
Este empleado pertenece al departamento de recursos humanos y
es responsable de realizar las entrevistas de trabajo y genera y
modifica la nóminas de los distintos empleados de la empresa
2.26. Empresa de transportes
La empresa de transportes es la encargada de trasladar los envíos
de los distintos pedidos que estén listos para envío y se haya
decidido enviar al cliente. Este empresa es una subcontrata de
Deportes LSI 03 para realizar el trabajo de envío de pedidos, sin
embargo el encargado de transportes es un empleado de la
empresa Deportes LSI 03 y no de la subcontratada.
2.27. Encargado de transporte
Este usuario del sistema es el encargado de gestionar los pedidos
a enviar. Se encarga de cargar el camión con los pedidos que ya
están listos para enviar, y de devolver los recibos de entrega de los
pedidos. Una vez que el pedido ha sido entregado en la dirección
de envío que cada cliente había especificado para cada envío, se
genera un recibo que será introducido en el sistema por el
encargado de transportes para el control de cobros y facturación de
los pedidos enviados.
2.28. Enviar pedido
El caso de uso enviar pedido consiste en que el usuario encargado
de transportes se registra en el sistema, consulta los pedidos que
figuren como pedidos listos para envío y por último si decide
cargarlos en uno de los camiones para el próximo envío, entonces
modifica el pedido a pedido en envío, introduce el nombre del
transportista que realizará el envío y el sistema introducirá la fecha
del envío.
2.29. Facturar entrega de un pedido
Una vez que un pedido ha sido entregado en la dirección de envío
que había especificado el cliente, éste firma un recibo de entrega
que será introducido en el sistema por el encargado de transportes.
Una vez hecho esto, el pedido figura como pendiente de cobro. El
empleado del departamento de contabilidad y facturación consulta
los pedidos que quedar por facturar y genera las facturas de los
mismos, teniendo en cuenta la forma de pago especificada por
pedido y cliente.
2.30. Fecha de atención
Es la fecha que tiene asignada una orden de pedido una vez que el
técnico de almacén ha comenzado a asignarle productos del stock
del almacén. La fecha de atención es única y no se modifica en
ningún momento, puesto que se asigna la primera vez que un
pedido recibe atención. Si el pedido figura como en elaboración o
como no atendido, tendrá el campo de esta fecha vacío.
2.31. Fecha de elaboración
La fecha de elaboración figura en los pedidos que estén en estado
de elaboración. Esta fecha se asigna automáticamente cuando se
crea un pedido nuevo en la elaboración de órdenes de pedido por
parte de la operadora o por el representante de ventas. Esta fecha
no se puede modificar en ningún momento ya que se asigna por
primera vez por medio del sistema.
2.32. Fecha de envío
La fecha de envío figura como vacía en todos aquellos pedidos que
no hayan sido enviados. Si el pedido figura como pedido en envío
se mostrará la fecha en la que el encargado de transportes pasó el
pedido a envío y éste se cargó en el camión. Esta fecha no podrá
ser modificada.
2.33. Fecha de envío al almacén
Esta fecha la asigna el sistema a todos aquellos pedidos en
elaboración que son enviados al almacén por los representantes de
ventas o las operadoras. Esta fecha figurará vacía en todos
aquellos pedidos que estén en estado de elaboración.
2.34. Fecha de listo para envío
Esta fecha se asignará por el sistema a todas aquellas órdenes de
pedido que el técnico de almacén haya pasado a listas para envío.
Esta fecha figura como vacía en todos aquellos pedidos que no
estén en envío o en listos para envío. Esta fecha se eliminará de
aquellos pedidos que figuren como listos para envío y que el
técnico de almacén decida cancelar y pasar a en atención.
2.35. Gestión de almacén
La gestión de almacén es el subsistema definido como parte del
sistema principal que comprende toda la empresa Deportes LSI 03
y que trata todos aquellos aspectos del sistema que se refieren a
tratamiento de órdenes de pedido de los diferentes clientes. La
gestión de almacén se centra en la atención de órdenes de pedido,
cancelación, paso a envío, consultas, gestión de incidencias de
stock y reposición de stock. Los usuarios de este subsistema son
los técnicos de almacén y los jefes de almacén
2.36. Gestión de clientes
Gestión de clientes es un caso de uso definido dentro del
subsistema de gestión de ventas, y cuya funcionalidad está
definida por los representantes de ventas, operadoras y clientes
online. La gestión de clientes trata todos aquellos aspectos que
conciernen al tratamiento de datos de clientes, ya sea alta de
nuevos clientes, baja de clientes que ya figurasen en el sistema, ya
sea de la modificación de los datos de los clientes que figuraban
como dados de alta. Este caso de uso se puede invocar a través de
la interfaz de usuarios de ventas.
2.37. Gestión de envíos
La gestión de envíos es el subsistema definido como parte del
sistema principal que comprende toda la empresa de Deportes LSI
03 y que trata todos aquellos aspectos del sistema que se refieren
al tratamiento de órdenes de pedido que figuran como listas para
envío. La carga de las órdenes de pedido en los camiones de
reparto de mercancías se registra en el sistema mediante un
control de pedidos en envío, y tras su posterior entrega se realiza la
introducción de recibos para que pasen a la funcionalidad definida
para tal efecto en el subsistema del departamento de contabilidad y
facturación.
2.38 Gestión de nóminas
Gestión de nóminas es un caso de uso invocado por el empleado
de recursos humanos o por el jefe de recursos humanos. En la
gestión de nóminas se tienen en cuenta todos los aspectos que
conciernen a las comisiones otorgadas a los empleados de
Deportes LSI 03, los salarios fijos, las primas, datos personales de
cada empleado, etc.
2.39. Gestión de personal
Gestión de personal es un caso de uso que invoca el jefe del
departamento de recursos humanos y cuya funcionalidad define el
reparto y asignación de la plantilla y puestos de trabajo de los
distintos empleados de la empresa Deportes LSI 03. La
redistribución y asignación de tareas, etc, es la funcionalidad de
este caso de uso.
2.40. Gestión de ventas
La gestión de ventas es un subsistema definido como parte del
sistema principal que comprende toda la empresa de Deportes LSI
03 y que trata todos aquellos aspectos del sistema que se refieren
al tratamiento de ventas realizadas a los clientes, ya sea a través
de un representante de ventas o de una operadora. Este
subsistema también ofrece funcionalidad al cliente online, que
puede generar y gestionar órdenes de pedido igual que los
representantes de ventas o las operadoras aunque restringido por
supuesto a sus datos personales. La funcionalidad que recoge este
subsistema engloba todo lo que concierne a la elaboración de
nuevas órdenes de pedido, modificación de órdenes ya existentes,
cancelación de las mismas o envío al almacén para que sean
servidas.
2.41. Incidencia pedido
Incidencia pedido es un caso de uso cuya funcionalidad es
proporcionar al técnico de almacén la posibilidad de generar
incidencias de pedidos en los que se hayan dado situaciones
especiales como lo son que al asignar cantidades del stock del
almacén el sistema detecte que la cantidad a asignar deja el stock
del producto en el almacén con déficit, es decir, por debajo de una
cantidad mínima, también que no existe stock de un producto
suficiente para satisfacer las necesidades de una orden de pedido,
o que hayan pasado más de dos días desde que un pedido figura
en atención o como listo para envío. Las incidencias de pedido las
gestionará el jefe de almacén, o bien haciendo una reposición de
stock a través de otro almacén o bien trasladando la incidencia a
cargo del ingeniero de logística.
2.42. Ingeniero de logística
El ingeniero de logística es el empleado principal del departamento
de logística , encargado de la gestión de proveedores, pedidos a
los mismos, reposición de stock tanto en los distintos almacenes
regionales como en el almacén central de que dispone a la
empresa Deportes LSI 03, control de estadísticas de los distintos
almacenes regionales y previsión de almacenamiento de stock de
los distintos productos con los que trabaja la empresa.
2.43. Introducir recibos
Introducir recibos es un caso de uso que ofrece su funcionalidad al
usuario encargado de transportes, y que consiste en que cuando
un pedido se entrega en destino, el cliente firma un recibo de
entrega y éste es introducido en el sistema para que figure el
pedido como pendiente de cobro. En el recibo figura el transportista
que realizó la entrega, la fecha de envío y de entrega y el detalle de
la orden de pedido entregada.
2.44. Jefe de almacén
El empleado jefe de almacén de la empresa Deportes LSI 03
participa en el sistema dentro del subsistema de gestión de
almacén, y que hace uso de las funcionalidades definidas en los
casos de uso de reposición de stock, gestión de incidencias de
almacén y consultas de pedidos.
2.45. Jefe de recursos humanos
El empleado jefe de recursos humanos de la empresa Deportes LSI
03 participa en el sistema dentro del subsistema de departamento
de recursos humanos, y que hace uso de las funcionalidades
definidas en los casos de uso gestión de personal, redistribución de
personal y gestión de nóminas.
2.46. Jefe de ventas
El empleado jefe de ventas de la empresa Deportes LSI 03
participa en el sistema dentro del subsistema de gestión de ventas,
y que hace uso de las funcionalidades definidas en los casos de
uso de control de estadísticas, otorgan incentivos y gestión de
clientes,
2.47. Línea de pedido
La línea de pedido es uno de los componentes de la orden de
pedido, y es donde figuran los detalles de los productos a pedir. Se
corresponde una línea de pedido por producto solicitado en una
orden de pedido. Una línea de pedido se compone de la siguiente
información: código del producto del catálogo, referencia de la
orden de pedido a la que pertenece, cantidad de producto
solicitada al almacén regional, precio del producto y por último el
stock asignado en el almacén en el que se trata la orden de pedido.
2.48. Listado de pedidos en atención
El listado de pedidos en atención es una parte de la funcionalidad
que ofrece la interfaz de usuario del técnico de almacén, y en la
que se muestra la lista de órdenes de pedido que figuran en un
almacén regional pendientes de ser completados, es decir, en
estado de atención.
2.49. Listado de pedidos enviados
El listado de pedidos enviados es una parte de la funcionalidad que
ofrece la interfaz de usuario del técnico de almacén, y en la que se
muestra la lista de órdenes que figuran como enviadas desde un
almacén regional en concreto.
2.50. Listado de pedidos listos para envío
El listado de pedidos listos para envío es una parte de la
funcionalidad que ofrece la interfaz de usuario del técnico de
almacén, y en la que se muestra la lista de órdenes de pedido que
figuran en un almacén regional pendientes de ser enviadas, es
decir, en estado de listos para envío.
2.51. Listado de pedidos no atendidos
El listado de pedidos en atención es una parte de la funcionalidad
que ofrece la interfaz de usuario del técnico de almacén, y en la
que se muestra la lista de órdenes de pedido que figuran en un
almacén regional pendientes de ser atendidas, es decir, en estado
de no atendidas.
2.52. Operadora
La operadora es una empleada de la empresa de Deportes LSI 03
que hace uso de la funcionalidad definida en el subsistema de
gestión de ventas, y que se comunica con los clientes por teléfono
y elabora nuevas órdenes de pedido para éstos, modifica o cancela
otras existentes y puede acceder a gestión de clientes. Tiene la
característica especial de poder atender a cualquier cliente, a
diferencia del representante de ventas que sólo puede tratar a los
clientes a los que representa.
2.53. Orden de pedido
Una orden de pedido es una solicitud de servicio por parte de un
cliente para que la empresa Deportes LSI 03 le sirva una serie de
artículos o productos de su catálogo. Las órdenes de pedido son
generadas por los usuarios de ventas y son procesadas en los
almacenes regionales de que dispone Deportes LSI 03. Una vez
confeccionadas las órdenes de pedido, éstas son enviadas a los
clientes que las han solicitado por medio de una empresa de
transportes y son entregadas a los mismos y facturadas. Las
órdenes de pedido comprenden la siguiente información dentro del
sistema: código del pedido para identificarla de forma única, código
del cliente que ha realizado la orden, DNI del usuario de ventas que
realizó la confección de la orden, dirección de envío del pedido,
forma de pago que realizará el cliente, fecha de elaboración, fecha
de llegada al almacén, fecha de atención, fecha de listo para envío
y fecha de salida del almacén.
2.54. Otorgar incentivos
Otorgar incentivos es un caso de uso cuya funcionalidad la utiliza el
empleado jefe de ventas dentro del subsistema de gestión de
ventas y que consiste en la asignación de primas y comisiones a
los distintos empleados de ventas para incentivar su trabajo.
2.55. Pasar pedido a envío
Pasar pedido a envío es un caso de uso cuya funcionalidad la
utiliza el técnico de almacén y cuya utilidad es la de cambiar el
estado de un pedido que se encuentra en atención para que figure
como listo para envío. En caso de que las cantidades de stock
asignado en el almacén no se correspondan a las solicitadas por el
cliente se generarán los avisos y controles pertinentes.
2.56. Pedido en atención
Un pedido, o una orden de pedido, figura en estado de “en
atención” cuando esté siendo atendido por un técnico de almacén,
es decir, cuando se le estén asignando cantidades del stock que
figura en el almacén.
2.57. Pedido pendiente de cobro
Un pedido, o una orden de pedido, figura en estado de “pendiente
de cobro” cuando ya ha sido entregado en la dirección de envío y el
cliente ha firmado el recibo que posteriormente ha sido introducido
por el encargado de transportes.
2.58. Pedido en elaboración
Un pedido, o una orden de pedido, figura en estado de “en
elaboración” cuando ha sido creado por un usuario de ventas y aún
no ha sido enviado al almacén. En este estado, el pedido puede ser
modificado en líneas de pedido y dirección de envío.
2.59. Pedido en envío
Un pedido, o una orden de pedido, figura en estado de “en envío”
cuando ya haya sido cargado en un camión y esté pendiente de ser
entregado en la dirección de envío que ha especificado el cliente.
2.60. Pedido listo para envío
Un pedido, o una orden de pedido, figura en estado de “listo para
envío” cuando las cantidades de stock asignadas por el técnico de
almacén satisfacen las cantidades solicitadas por el cliente en el
pedido.
2.61. Pedido no atendido
Un pedido, o una orden de pedido, figura en estado de “no
atendido” cuando ya ha sido enviado al almacén por un usuario de
ventas y aún no ha sido atendido por ningún técnico de almacén.
2.62. Política Producto
Política producto es un caso de uso definido en el subsistema
departamento de marketing y cuya funcionalidad es ofrecer la
posibilidad al empleado de marketing de que pueda cambiar la
política de ventas aplicada a los distintos productos de la empresa
Deportes LSI 03.
2.63. Producto
Los productos con los que trabaja Deportes LSI 03 son artículos
deportivos, es decir, todos aquellos artículos que tengan que ver
con deportes, por ejemplo, balones, raquetas, ropa deportiva,
pelotas, redes, y cualquier tipo de producto relacionado con el
deporte como tiendas de campaña, sacos de dormir, bicicletas y
otros.
2.64. Proveedor
Un proveedor de Deportes LSI 03 es todo aquel proveedor que
ofrezca productos deportivos. Ejemplos de proveedores de esta
empresa son Nike, Adidas, Dunlop, Reebok, Boomerang, etc.
2.65. Reabastecer almacén
Reabastecer almacén es un caso de uso del subsistema del
departamento de logística y que consiste en que el ingeniero de
logística solicita a un proveedor o a un almacén, ya sea el central u
otro regional, que sirva artículos a uno o varios almacenes para
reponer el stock necesario para atender órdenes de pedido.
2.66. Realizar envío
Realizar envío es un caso de uso del subsistema de gestión de
envíos y cuya funcionalidad ofrece al encargado de transportes la
posibilidad de consultar los pedidos listos para envío y al cargarlos
en el camión registrar en el sistema que el pedido a pasado a estar
en envío.
2.67. Realizar oferta
Realizar oferta es un caso de uso del subsistema departamento de
marketing y cuya funcionalidad ofrece al empleado de marketing la
posibilidad de realizar ofertas de lanzamiento de distintos
productos, ofertas de venta a bajos precios u ofertas de venta a
precio de coste para captar nuevos clientes u ofrecer ventajas a los
clientes actuales.
2.68. Redistribución de personal
Redistribución de personal es un caso de uso del subsistema
departamento de recursos humanos y cuya funcionalidad ofrece al
jefe de dicho departamento la posibilidad de distribuir la plantilla o
el personal ajustando las necesidades de cada momento de la
empresa Deportes LSI 03.
2.69. Región
Las órdenes de pedido de los clientes de un país determinado que
la empresa Deportes LSI 03 al trabajar y tener delegación en todo
el mundo, ha dividido el mundo en regiones para poder gestionar
mejor a sus distintos países clientes. Existe una región central en la
que se ubican las principales instalaciones de la empresa, tales
como el departamento de logística, recursos humanos, marketing y
contabilidad / facturación. En dicha región también se ubica el
almacén central de la empresa, que servirá de abastecimiento
principal a los distintos almacenes regionales. En cada una de las
restantes regiones se localiza un departamento de gestión de
ventas y de uno de gestión del alma pertenece a una región
determinada se sirven a partir del almacén asignado a dicha
región.
2.70. Registrarse en el sistema
Cada vez que un usuario accede al sistema debe registrarse en el
mismo haciendo uso de un nombre de usuario y una contraseña
asociada al mismo. Estos datos figuran en la base de datos, y el
sistema comprueba que son correctos y ofrece la funcionalidad
determinada según el tipo de usuario que se haya registrado. Por
ejemplo, si el técnico de almacén se registra en el sistema sólo
podrá acceder a la funcionalidad de técnico de almacén y sólo
podrá trabajar con los pedidos pertenecientes a la región asignada
al almacén en que trabaja.
2.71. Reposición de stock
Reabastecer almacén es un caso de uso del subsistema de gestión
de almacén que consiste en solicitar a un almacén, ya sea el
central u otro regional, que sirva artículos a otro almacén para
reponer el stock necesario para atender órdenes de pedido.
2.72. Representante de ventas
El representante de ventas es un empleado de la empresa
Deportes LSI 03 que hace uso de la funcionalidad definida en el
subsistema de gestión de ventas, y que se comunica directamente
con los clientes en sus respectivos al que el sistema ofrece
distintas funcionalidades, entre las que se encuentra la elaboración
de nuevos pedidos, la modificación de pedidos que se encuentren
en elaboración y la cancelación de pedidos en elaboración.
También se ofrece la gestión de clientes, la consulta del catálogo
de productos, la consulta de productos enviados al almacén y la
solicitud de registro de incidencias en una orden de pedido. La
única restricción para el representante de ventas es que sólo puede
trabajar con aquellos clientes a los que representa, no tiene acceso
a ningún otro cliente que no represente.
2.73. Técnico de almacén
El técnico de almacén es un empleado de la empresa Deportes LSI
03 y que hace uso de la funcionalidad definida en el subsistema de
gestión de almacén. El técnico de almacén está encargado de
atender órdenes de pedido, reservando stock para las líneas de
pedido correspondiente a una orden de pedido, y una vez
completado éste, dispone la orden de pedido como listo para envío,
de tal modo que el encargado de transportes, posteriormente,
enviará en los camiones los pedidos que el técnico de almacén ha
confeccionado. También dispone de la funcionalidad de cancelar
pedidos atendidos y de registrar incidencias de pedido.
2.74. Usuario de ventas
El usuario de ventas es una generalización de los representantes
de ventas, operadoras y clientes online. Ofrece una visión más
general que la de sus especializaciones, y contempla en el modelo
de análisis los casos de uso comunes a representante, operadora y
cliente online, como son las funcionalidades de incidencia de
pedido y gestión de clientes.
3. ESPECIFICACIONES DE CASOS DE USO
Las especificaciones de casos de uso están divididas según el
subsistema al que pertenezcan, atendiendo a los subsistemas definidos
en el documento Visión. Tenemos los siguientes subsistemas:
A. Departamento de Contabilidad/Facturación:
Aquí encontramos las siguientes especificaciones de uso:
1) Cobro a Clientes
1.1. Descripción
Este caso de uso especifica el cobro de las facturas de los
clientes. Una vez la mercancía se ha servido satisfactoriamente
se emite una factura al cliente con el importe correspondiente al
pedido. El contable selecciona aquellos pedidos ya entregados
de los que desea emitir factura. Puede seleccionar el tipo de
cobro que desea el cliente (contrareembolso o transferencia
bancaria) y seleeciona una dirección de facturación distinta a la
usual (si el cliente dispone de más de una). Tras eso se
imprimen las facturas y quedan listas para ser enviadas por
correo.
2) Flujo de Eventos
2.1. Flujo Básico
a. La pantalla muestra una lista con los pedidos que se han
servido correctamente.
b. contable puede seleccionar aquellos que desea facturar y
tras pulsar el botón aceptar se le preguntará si desea
cambiar la dirección de facturación usual de algún cliente.
c. En caso afirmativo podrá escoger direcciones alternativas
ya grabadas en el sistema o introducir una nueva para los
clientes que desee.
d. Normalmente la aplicación tendrá predeterminado el cobro
con transferencia bancaria.
e. El contable puede modificar la forma de pago de las
facturas que desee.
f. Si el contable está conforme y no desea realizar algún
cambio más se imprimirán las facturas y los pedidos de los
clientes pasarán al estado “factura emitida”.
g. Cuando el contable tenga constancia de que la factura ha
sido pagada, ya sea viendo que se ha transferido el importe
adecuado a la cuenta o gracias al justificante de reembolso
de la agencia de envíos, podrá pasar los pedidos que
seleccione al estado “factura pagada”. Una vez alcanzado
dicho estado, el pedido no podrá ser modificado de ninguna
forma, pasando a engrosar el histórico de ventas de la
aplicación.
2.2. Flujos Alternativos
2.2.1. En el punto c.
El sistema muestra para cada cliente la dirección
“default” de facturación. Si el contable quiere cambiarla
pincha en la línea del cliente y pulsa “cambiar dirección
de facturación”. Se le muestran todas las direcciones
registradas para ese cliente. Puede seleccionar una de
ellas o pulsar “introducir nueva”. Se le pedirán los datos
de la nueva dirección y una vez pulsado “aceptar”
quedará grabada en el sistema como dirección “default”
de ese cliente.
2.2.2. En el punto e.
El contable puede seleccionar un pedido cualquier y
pulsar sobre “modificar forma de pago”. El sistema
mostrará las distintas opciones de pago para que se
seleccione una de ellas.
3) Precondiciones
3.1. El contable ha realizado correctamente el login en el sistema.
3.2. El contable ha seleccionado el botón de “Cobro a Clientes” de su
interfaz gráfica.
4) Postcondiciones
4.1. En caso de haberse dado de alta una nueva dirección de
facturación, los datos de la misma quedan almacenados en la
base de datos.
4.2. Los pedidos para los cuales se imprime factura pasan al estado
“factura emitida”.
4.3. Los pedidos para los que se ha abonado la factura pasan al estado
“factura pagada”.
B. Departamento de Logística:
Tenemos las siguientes especificaciones de uso:
1) COMPRA A PROVEEDORES
1. Descripción
El caso de uso lo inicia el actor Ingeniero de Logística. Su fin es
comprar los productos de los distintos almacenes de la
empresa. Esta adquisición se basa en la experiencia del propio
Ingeniero de Logística, que selecciona el almacén a reponer y
realiza un pedido a un proveedor de una serie de productos
según su criterio.
2. Flujo de Eventos
1.2. Flujo Básico
a. El Ingeniero de Logística accede a Compra a
Proveedores.
b. El sistema le muestra una pantalla donde llevará a
cabo las selecciones correspondientes.
c. Primero selecciona el almacén a reponer de la lista de
almacenes y pulsa siguiente.
d. La aplicación le muestra entonces una lista donde
aparecen los productos que tiene el almacén
seleccionado y su stock actual.
e. El Ingeniero de Logística puede seleccionar un
producto ya existente y pinchar en añadir al pedido.
f. El producto pasa a la lista del nuevo pedido.
g. Introduce la cantidad deseada.
h. Bien puede seleccionar un producto que no esté en el
almacén utilizando el catálogo de productos
i. Selecciona un producto del catálogo que se añadirá a
la lista del nuevo pedido
j. Introduce la cantidad deseada
k. Una vez confeccionada la lista de productos a pedir
pincha en finalizar pedido.
l. El sistema le muestra una pantalla con el pedido al
completo y le pide la confirmación.
m.Si el actor pincha en aceptar el pedido se almacenará
en el sistema y se mandará a los proveedores
correspondientes (según el artículo).
n. Si el Ingeniero pincha cancelar volverá a la pantalla
anterior.
o. El pedido se almacenará en la lista de pedidos
realizados.
3. Precondiciones
3.1.El Ingeniero de Logística ha realizado correctamente el
login en el sistema.
3.2.El Ingeniero de Logística ha seleccionado el botón “Compra
a Proveedores” de su interfaz gráfica.
4. Poscondiciones
4.1.En caso de haberse dado de alta una nueva compra, ésta
quedará grabada en el sistema.
2) Gestión de Regiones
1. Descripción
Este caso de uso lo inicia el Ingeniero de Logística. Su función es
poder gestionar las distintas regiones en las que se divide la
empresa. Cada una de estas regiones dispone de unos
almacenes a los que hacen peticiones tiendas deportivas. El
Ingeniero de Logística puede crear nuevas regiones o modificar
las actuales, asignando o borrando almacenes.
2. Flujo de Eventos
2.1 Flujo Básico
1. La pantalla muestra una lista con las regiones
actuales.
2. El Ingeniero de Logística puede pulsar sobre el botón añadir o
seleccionar una región de la lista y pinchar en el botón modificar
o eliminar.
2.1. Si pulsa sobre el botón eliminar se borrará la región si no
hay ninguna tienda o almacén asignados a ella.
2.2. Si pulsa el botón modificar, podrá cambiar los datos
relacionados a esa región así como asignar almacenes.
2.2.1. Le aparecerá una pantalla con los datos de la región
y una lista de almacenes asignados a ella.
2.2.2. Los datos se pueden modificar seleccionando uno y
rescribiendo.
2.2.3. La lista de almacenes dispone de un botón añadir y
otro eliminar.
2.2.3.1. Si pulsa el botón añadir aparecerá una
ventana donde introducir los datos del
almacén.
2.2.3.2. Si pulsa el botón eliminar, el sistema pedirá
la confirmación para borrar el almacén
seleccionado.
2.3. Si pulsa el botón añadir, podrá agregar una nueva región e
introducir sus datos.
3. Precondiciones
3.1. El Ingeniero de Logística ha realizado correctamente el registro en
el sistema.
3.2. El Ingeniero de Logística ha seleccionado el botón de “Gestión de
Regiones” de su interfaz gráfica.
4. Post condiciones
4.1. En caso de haberse dado de alta una nueva región, los datos de
la misma quedan almacenados en la base de datos.
4.2. En caso de haberse dado de alta un nuevo almacén, los datos del
mismo quedan almacenados en la base de datos.
D. Reabastecer Almacén
1. Descripción
El caso de uso lo inicia el actor Ingeniero de Logística. Especifica los
envíos desde el almacén central hacia los demás almacenes con el fin
de reponer productos sin stock. Para ello el Ingeniero dispone de una
lista con los productos que necesitan reposición y otra con los
disponibles en el almacén central. Bajo su criterio pueden realizarse
envíos hacia el resto de almacenes.
2. Flujo de Eventos
2.1 Flujo Básico
El Ingeniero de Logística accede a Reabastecer Almacén.
a. El sistema le muestra una pantalla con dos listas. En la primera
se incluyen los productos sin stock ordenados por almacén y
región. En la segunda se muestra los productos disponibles en el
almacén central.
b. Si quiere realizar un nuevo envió para reabastecer un almacén
selecciona el botón nuevo envío.
c. El sistema le muestra una lista de las regiones y los almacenes,
el Ingeniero selecciona un almacén.
d. El sistema le muestra una pantalla con dos listas, la primera con
los productos disponibles en el almacén central, la segunda la
del envío, que se encontrará vacía.
e. El Ingeniero pincha sobre un producto del almacén central y
selecciona el botón incluir en envío.
f. El sistema lo incluye en el envío y el Ingeniero modifica la
cantidad de unidades a incluir.
g. Si desea incluir más productos vuelve al paso f.
h. Si desea finalizar el reabastecimiento pincha en el botón finalizar
y se imprimirá una orden de reabastecimiento que los
empleados del almacén central se encargarán de cursar. El
envío se almacena en una lista de reabastecimientos con el
estado “en preparación”.
i. Una vez el envío esta listo para salir se notifica al sistema y el
envío pasa al estado “en envío”.
j. Cuando llega al almacén destino se grabará en el sistema como
“reabastecimiento completado”.
3. Precondiciones
3.1.El Ingeniero de Logística ha realizado correctamente el login en el
sistema.
3.2.El Ingeniero de Logística ha seleccionado el botón “Reabastecer
Almacén” de su interfaz gráfica.
4. Poscondiciones
4.1.En caso de haberse dado de alta un nuevo reabastecimiento, éste
quedará grabado en el sistema.
E. Confeccionar Catálogo
1. Descripción
El actor iniciador de este caso de uso es el Empleado de Marketing.
Mediante él mantiene el catálogo de productos de la empresa.
Actualizando productos, borrando o añadiendo nuevos. También puede
para un producto determinado modificar sus características como el
proveedor, precio, etc.
2. Flujo de Eventos
2.1 Flujo Básico
a. La pantalla muestra una lista con los productos del catálogo
actual.
b. El Empleado de Marketing dispone de un botón para añadir un
producto nuevo, otro para borrar uno existente y otro para
modificar un producto seleccionado.
c. Si pulsa el botón de añadir, el sistema le mostrará una nueva
ventana donde podrá introducir los datos del nuevo producto:
descripción, precio, etc. Para introducir un proveedor puede
seleccionar uno de los proveedores actuales con el botón
proveedor actual puede introducir uno nuevo pulsando el botón
nuevo proveedor.
d. Al seleccionar nuevo proveedor aparecerá una ventana donde
incluir sus datos: dirección, teléfono, nombre, nif
e. Si ha pulsado en proveedor actual aparecerá una lista de los
proveedores registrados. Seleccionará uno y pulsará aceptar.
f. El producto quedará registrado en el sistema debidamente.
g. Si selecciona un producto de la lista del catálogo y pulsa borrar,
el sistema le pedirá confirmación y si acepta el producto será
borrado (si no existen pedidos que estén afectados por el
mismo).
h. Si selecciona modificar producto, se abrirá una ventana con los
datos del mismo para que el Empleado de Marketing los
modifique a su gusto.
3. Precondiciones
3.1.El Empleado de Marketing ha realizado correctamente el registro
en el sistema.
3.2.El Empleado de Marketing ha seleccionado el botón de
“Confeccionar Catálogo” de su interfaz gráfica.
4. Poscondiciones
4.1.En caso de haberse dado de alta una nuevo producto o proveedor,
los datos del mismo quedan almacenados en la base de datos.
F. Política de Ventas
1. Descripción
Este caso de uso lo inicia el Empleado de Marketing. Se trata de
especificar cierta política de ventas sobre los productos de la empresa,
por ejemplo, qué productos tienen que ser más prioritarios a la hora de
vender que otros.
2. Flujo de Eventos
2.1. Flujo Básico
a. La pantalla muestra una lista con los incentivos actuales
b. EL Jefe de Ventas puede seleccionar uno de los existentes y
pulsar el botón modificar, añadir o borrar.
c. Si pulsa el botón modificar el sistema le mostrará una pantalla
donde le aparecerá una lista de personas o secciones a las que
afecta el incentivo y la cantidad del mismo.
d. Si hace doble click en el campo cantidad de una línea podrá
modificarla.
e. Si selecciona una línea y pulsa el botón borrar se borrará la
persona o sección en cuestión.
f. Si pulsa el botón añadir persona aparecerá una pantalla donde
podrá seleccionar un trabajador de la empresa según la región
e introducir la cantidad a bonificar.
g. Si pulsa el botón añadir sección aparecerá una pantalla donde
podrá seleccionar una sección de la empresa e introducir la
cantidad a bonificar.
h. Al pulsa el botón aceptar se confirmará el incentivo que será
pagado en la próxima nómina de los empleados afectados
indicándose en esta el motivo.
i. Si pulsa el botón borrar se eliminará el incentivo seleccionado.
j. Si pulsa el botón añadir aparecerá una pantalla con una lista
vacía de personas o secciones y la cantidad de bonificación a
cero.
k. Si pulsa el botón añadir persona aparecerá una pantalla donde
podrá seleccionar un trabajador de la empresa según la región
e introducir la cantidad a bonificar.
l. Si pulsa el botón añadir sección aparecerá una pantalla donde
podrá seleccionar una sección de la empresa e introducir la
cantidad a bonificar.
m.Al pulsa el botón aceptar se confirmará el incentivo que será
pagado en la próxima nómina de los empleados afectados
indicándose en esta el motivo.
n. Si hace doble click en el campo cantidad de una línea podrá
modificarla.
o. Si selecciona una línea y pulsa el botón borrar se borrará la
persona o sección en cuestión.
3. Precondiciones
3.1.El contable ha realizado correctamente el login en el sistema.
3.2.El contable ha seleccionado el botón de “Cobro a Clientes” de su
interfaz gráfica.
4. Poscondiciones
4.1.En caso de haberse dado de alta una nueva dirección de
facturación, los datos de la misma quedan almacenados en la base
de datos.
4.2.Los pedidos para los cuales se imprime factura pasan al estado
“factura emitida”.
4.3.Los pedidos para los que se ha abonado la factura pasan al estado
“factura pagada”.
G. Realizar Oferta
1. Descripción
Este caso de uso lo ejecuta el actor Empleado de Marketing. Sirve para
poner uno o varios productos en oferta a un precio determinado. El
actor consulta el catálogo de productos y selecciona aquel o aquellos a
los que desea aplicar la oferta, después, introduce el precio de la
misma y por último el periodo temporal en el que permanecerá vigente.
En este caso de uso también pueden eliminarse o modificarse ofertas
anteriores.
2. Flujo de Eventos
2.1.Flujo Básico
a. La pantalla muestra una lista con las ofertas actuales.
b. EL Empleado de Marketing puede seleccionar una de los
existentes y pulsar el botón “Modificar” o “Borrar”, o introducir
una nueva mediante el botón “Añadir Nueva”.
c. Si pulsa el botón “Modificar” el sistema le mostrará una pantalla
donde aparecerá una lista de productos a los que afecta la oferta
seleccionada. Esta lista tendrá los campos “Producto” y “Precio
de Oferta”, además de una línea adicional donde indica la fecha
de finalización de la oferta.
d. Si hace doble click en el campo “Precio de Oferta” de una línea
podrá modificarlo.
e. Si hace doble click en la línea “Fecha de Finalización” podrá
modificar la fecha en la cual la oferta dejará de ser vigente.
f. Si selecciona una línea y pulsa el botón “Borrar” se quitará de la
oferta el producto seleccionado.
g. Si pulsa el botón “Añadir Producto” aparecerá una pantalla
donde podrá seleccionar un producto del catálogo de la
empresa.
h. Al pulsa el botón “Aceptar” se confirmará la oferta.
i. Si pulsa el botón “Borrar” se eliminará la oferta seleccionada.
j. Si pulsa el botón “Añadir” aparecerá una pantalla con una lista
vacía de productos.
k. Si pulsa el botón “Añadir Producto” aparecerá una pantalla
donde podrá seleccionar un producto del catálogo de la empresa
e introducir el precio de oferta.
l. Si hace doble click en el campo “Precio de Oferta” de una línea
podrá modificarlo.
m.Si selecciona una línea y pulsa el botón “Borrar” se borrará el
producto en cuestión.
n. Al pulsa el botón “Aceptar” se confirmará la oferta.
3. Precondiciones
3.1.El Empleado de Marketing ha realizado correctamente el login en el
sistema.
3.2.El Empleado de Marketing ha seleccionado el botón de “Realizar
Oferta” de su interfaz gráfica.
4. Poscondiciones
4.1.En caso de haberse dado de alta una nueva oferta, los datos de la
misma quedan almacenados en la base de datos.
4.2.Las ofertas nuevas sólo afectan a pedidos que no estén en
preparación y a pedidos nuevos.
Departamento de Recursos Humanos:
A. Entrevista Trabajo
1. Descripción
El caso de uso lo ejecuta el actor Empleado de RRHH. Se utiliza para
realizar una entrevista de trabajo. Permite introducir los datos personales
del entrevistado y la información de la encuesta que se le realice.
También se utiliza para revisar las entrevistas que ya se han realizado e
imprimirlas.
2. Flujo de Eventos
2.2 Flujo Básico
a. La pantalla muestra una lista con las entrevistas introducidas en
el sistema. Esta lista tiene los campos “Puesto”, “Fecha”,
“Entrevistado” y “Entrevistador”.
b. El Empleado de RRHH puede pulsar en cualquiera de las
entrevistas y pulsar el botón “Ver” o “Borrar”.
c. Si pulsa el botón “Ver” se abrirá una pantalla donde podrá
visualizar los datos de la entrevista y pulsar el botón “Imprimir” si
desea obtener una copia en papel.
d. Si pulsa el botón “Borrar” el sistema, tras pedir la confirmación,
borrará la entrevista seleccionada.
e. El actor puede pulsar el botón “Nueva” para comenzar una
nueva entrevista de trabajo.
f. Se abrirá una pantalla donde podrá introducir primeramente los
datos personales del entrevistado.
g. Seguidamente tendrá una campo de texto donde podrá introducir
el contenido de la entrevista: nota que tome durante la misma,
opiniones, respuestas del entrevistado, etc.
h. Una vez finalizada la introducción de los datos si pulsa el botón
“Guardar”, la entrevista se almacenará en el sistema.
3. Precondiciones
3.1 El Empleado de RRHH ha realizado correctamente el login en el
sistema.
3.2. El Empleado de RRHH ha seleccionado el botón de “Entrevista
Trabajo” de su interfaz gráfica.
4. Poscondiciones
4.1. En caso de haberse dado de alta una nueva entrevista, los datos
de la misma quedan almacenados en la base de datos.
B. Gestión de Nóminas
1. Descripción
El caso de uso lo ejecuta el actor Empleado de RRHH. Se utiliza para
gestionar las nóminas de los empleados de la empresa. Se pueden
modificar las existentes, así como los datos de domiciliciación bancaría.
2. Flujo de Eventos
2.1 Flujo Básico
a. La pantalla muestra una lista con los distintos trabajadores de
la empresa ordenada según departamentos.
b. El Empleado de RRHH puede seleccionar una o varias
personas de un departamento (con SHIFT + Click).
c. Seguidamente y pulsando sobre el botón modificar, accede a
los datos de la o las nóminas. Puede cambiar el importe de
retribución, los datos bancarios, la fecha de pago o la
adjudicación de pagas extras.
d. Para modificar cualquiera de los datos anteriores se pincha
sobre el campo y se modifica el importe. En las pagas extras
aparecerán dos columnas, una que especifica los meses donde
se reciben y otra para el importe.
e. En los datos bancarios aparece, la entidad, el número de
cuenta y la frase a mostrar como concepto.
f. Pulsando sobre aceptar se grabarán las modificaciones en la
base de datos.
3. Precondiciones
3.1. El Empleado de RRHH ha realizado correctamente el login en el
sistema.
3.2. El Empleado de RRHH ha seleccionado el botón de “Gestión de
Nóminas” de su interfaz gráfica.
4. Poscondiciones
4.1. En caso de haberse modificado una o varias nóminas, los cambios
quedarán almacenados en la base de datos.
C.- Gestión de Personal
1. Descripción
El caso de uso lo ejecuta el actor Jefe de RRHH. Se utiliza para realizar
una entrevista de trabajo. Permite introducir los datos personales del
entrevistado y la información de la encuesta que se le realice. También
se utiliza para revisar las entrevistas que ya se han realizado e
imprimirlas.
2. Flujo de Eventos
2.1 Flujo Básico
a. La pantalla muestra una lista con las entrevistas introducidas en el
sistema. Esta lista tiene los campos “Puesto”, “Fecha”, “Entrevistado” y
“Entrevistador”.
b. El Empleado de RRHH puede pulsar en cualquiera de las entrevistas y
pulsar el botón “Ver” o “Borrar”.
c. Si pulsa el botón “Ver” se abrirá una pantalla donde podrá visualizar los
datos de la entrevista y pulsar el botón “Imprimir” si desea obtener una
copia en papel.
d. Si pulsa el botón “Borrar” el sistema, tras pedir la confirmación, borrará
la entrevista seleccionada.
e. El actor puede pulsar el botón “Nueva” para comenzar una nueva
entrevista de trabajo.
f. Se abrirá una pantalla donde podrá introducir primeramente los datos
personales del entrevistado.
g. Seguidamente tendrá una campo de texto donde podrá introducir el
contenido de la entrevista: nota que tome durante la misma, opiniones,
respuestas del entrevistado, etc.
h. Una vez finalizada la introducción de los datos si pulsa el botón
“Guardar”, la entrevista se almacenará en el sistema.
3. Precondiciones
3.1. El Empleado de RRHH ha realizado correctamente el login en el
sistema.
3.2. El Empleado de RRHH ha seleccionado el botón de “Entrevista
Trabajo” de su interfaz gráfica.
4. Poscondiciones
4.1. En caso de haberse dado de alta una nueva entrevista, los datos
de la misma quedan almacenados en la base de datos.
D.- Redistribución de Personal
1. Descripción
El caso de uso lo ejecuta el actor Jefe de RRHH. Se utiliza para
gestionar el personal de la empresa, en qué departamento está asignado
y que funciones desempeña. El actor puede hacer cambios en la plantilla
de la empresa como trasladar personal entre departamentos, cambiar
las funciones que realizan los empleados o eliminar y agregar personal.
2. Flujo de Eventos
2.1 Flujo Básico
a. La pantalla muestra una lista con los distintos trabajadores de la
empresa ordenada según departamentos.
b. El Jefe de RRHH puede seleccionar una o varias personas de un
departamento (con SHIFT + Click).
c. El actor puede pinchar en el botón modificar, añadir o eliminar.
d. Pulsando sobre el botón modificar, accede a los datos personales del
trabajador. Puede cambiar su nombre, DNI, dirección, teléfono, etc, así
como la función o el cargo que tiene y el departamento o almacén donde
trabaja.
e. Si selecciona el botón añadir, puede agregar un trabajador al
departamento seleccionado, en cuyo caso se le abrirá una pantalla con
los datos personales y de funciones para rellenar, así como un enlace a
nóminas.
f. Si pincha sobre eliminar, borrará tras una confirmación, los datos del
trabajador.
g. Al pulsar en aceptar se guardarán los cambios en la base de datos y no
se podrá volver atrás.
3. Precondiciones
3.1. El Jefe de RRHH ha realizado correctamente el login en el sistema.
3.2. El Jefe de RRHH ha seleccionado el botón de “Gestión de
Personal” de su interfaz gráfica.
4. Poscondiciones
4.1. En caso de haberse modificado, agregado o borrado uno o varios
empleados, los cambios quedarán almacenados en la base de
datos.
Gestión de Almacén:
.
A. CONSULTAR PEDIDOS NO ATENDIDOS
1. Descripción
El Técnico de Almacén selecciona el botón de Consultar en la pestaña
de “no atendidos” en su interfaz gráfica principal. El sistema muestra del
listado con los pedidos que no han sido atendidos, los detalles del
pedido que ha sido seleccionado para su consulta en una nueva interfaz.
2. Flujo de Eventos
2.1 Flujo Básico
a. El técnico selecciona la pestaña de “no atendidos” en su interfaz
grafica principal, donde se muestra un listado con los pedidos no
atendidos que hay en el sistema.
b. El técnico selecciona un pedido y pulsa el botón “consultar”.
c. El sistema muestra una interfaz gráfica en la que se detallan los
datos del pedido seleccionado
d. El técnico puede desde esta nueva interfaz atender el pedido o salir.
3. Precondiciones
3.1 El Técnico de Almacén está registrado en el sistema.
B. ATENDER PEDIDO
1. Atender Pedido
1.1 Descripción
El usuario técnico de almacén selecciona de la interfaz
correspondiente al mismo un pedido para atender, donde se
muestra una lista de pedidos no atendidos en la pestaña de “no
atendidos” o en la pestaña de pedidos “en atención”. A
continuación, el pedido seleccionado pasa al estado pedido “en
atención” en el primer caso, y en el segundo el pedido continuará
en estado de “en atención”. Se abre una nueva interfaz en la que
se muestran los detalles del pedido seleccionado.
2. Flujo de Eventos
2.1 Flujo Básico
a. El técnico de almacén selecciona un pedido la lista de pedidos
no atendidos, en la pestaña “no atendidos” o de la lista de
pedidos atendidos en la pestaña “en atención” y pulsa el botón
de “consultar” y luego el botón de “atender pedido” en el primer
caso, y en el segundo el botón “atender pedido”.
b. El sistema muestra una nueva interfaz en la que se muestran los
datos del pedido: el código del pedido, la fecha de llegada al
almacén, la fecha de atención, la dirección de envío y la lista de
las líneas de pedido que contiene la orden.
c. El técnico de almacén selecciona una línea de pedido para
editarla.
d. Para cada línea de pedido el técnico de almacén puede cambiar
la cantidad asignada del stock disponible en el almacén:
i. El técnico cambia la cantidad de stock asignada a una línea de
pedido y pulsa el botón “modificar cantidad”.
ii. El sistema comprueba que hay stock suficiente en el almacén
y que la cantidad asignada no deja el producto en déficit de
stock.
iii.Se reserva el stock del almacén.
iv.Si el técnico de almacén decide modificar otra línea de
pedido, volver al punto i.
e. El técnico puede pulsar el botón “guardar” para que se
conserven los campos o “salir” para no modificar el pedido.
También puede pulsar el botón “pasar a envío” para que el
pedido figure en la lista de pedidos en estado “listos para envío”.
2.2 Flujos Alternativos
2.2.1 En el punto 2.2
Si en el paso i. la cantidad es negativa el sistema generará
un mensaje de error.
3. Precondiciones
3.1 El técnico de almacén está dado de alta en el sistema.
3.2 El técnico de almacén ha realizado correctamente el registro en el
sistema introduciendo el nombre de usuario y la contraseña
4. Poscondiciones
4.1 El pedido queda almacenado en el sistema en la lista de pedidos
en atención.
5. Puntos de Extensión
5.1 Incidencia Pedido en el paso 4.2
Si el técnico de almacén ha introducido una cantidad que no se puede
satisfacer con el stock actual del almacén o bien la cantidad asignada
deja el producto en déficit, el sistema generará un aviso de generación
de incidencia y se podrá invocar al caso de uso Incidencia Pedido.
C. CANCELAR PEDIDO ATENDIDO
1. Cancelar Pedido Atendido
1.1 Descripción
El técnico de almacén anula un pedido ya atendido.
2. Flujo de Eventos
2.1 Flujo Básico
a. El cliente ha solicitado cancelar un pedido en estado de “no
atención”, en estado de “en atención” o en estado de “listo para
envío”.
b. El técnico de almacén selecciona el pedido cuya referencia
corresponde al pedido que el cliente desea cancelar y pulsa el
botón “cancelar pedido” en la interfaz propia del técnico, ya sea
en la pestaña de “no atendidos”, en la pestaña de “en atención”
o en la pestaña de “listos para envío”.
i. El sistema muestra un mensaje de aviso de eliminación del
pedido.Si el técnico pulsa el botón de “aceptar” se elimina el
pedido, mientras que si pulsa el botón “cancelar”, no se
modificará el pedido.
ii. Flujos Alternativos
3. Precondiciones
3.1 El técnico de almacén está dado de alta en el sistema.
3.2 El técnico de almacén ha realizado correctamente el registro en el
sistema introduciendo el nombre de usuario y la contraseña
3.3 El cliente ha solicitado anular uno de sus pedidos que ya ha sido
atendido.
4. Poscondiciones
4.1 El pedido es eliminado del sistema y se liberan los productos
reservados para atender ese pedido.
D. INCIDENCIA PEDIDO
1. Incidencia Pedido
1.1 Descripción
Este caso de uso lo ejecuta cualquier empleado que gestione
órdenes de pedido cuando por algún motivo, el pedido provoca una
situación conflictiva y requiere que se anote una incidencia. En el
caso del técnico de almacén por dejar el stock bajo mínimos, por
no poder atender una orden, etc. En cualquier caso, el empleado
que genere una incidencia de pedido debe especificar la causa de
la misma.
2. Flujo de Eventos
2.1 Flujo Básico
a. El empleado ha detectado durante la gestión de órdenes de
pedido que es necesario registrar una incidencia de pedido.
Según la interfaz en la que se encuentre podrá generar una
incidencia pulsando el botón de “incidencia pedido”.
b. El sistema muestra la interfaz de incidencias de pedido,
mostrando de forma automática el código de la incidencia, la
fecha de la misma, el código y nombre del empleado que está
registrando la incidencia y el código de la orden de pedido
asociada. También se muestra un campo para observaciones.
c. El empleado introduce en el campo de observaciones los
motivos por los que se ha generado la incidencia y puede pulsar
el botón “guardar” para almacenar la incidencia, o bien puede
pulsar “salir” para no registrar la incidencia.
2.2 Flujos Alternativos
2.2.1 En el paso b.
Si en el paso 2 el empleado no introduce ningún motivo en el
campo de observaciones y pulsa el botón “guardar”, el
sistema generará un mensaje de error indicando que no se
puede introducir una incidencia con el campo de
observaciones vacío.
3. Precondiciones
3.1 El empleado está dado de alta en el sistema.
3.2 El empleado ha realizado correctamente el registro en el sistema
introduciendo el nombre de usuario y la contraseña
4. Poscondiciones
4.1 Si el empleado ha generado la incidencia, ésta queda almacenada
en el sistema.
E. PASAR PEDIDO A ENVÍO
1. Descripción
El técnico de almacén consulta la lista de pedidos atendidos y
selecciona el pedido que quiere pasar a envío de la interfaz
correspondiente al mismo y selecciona el botón de “pasar pedido a
envío”. A continuación el sistema comprueba que la condiciones de
satisfacción de la demanda se cumplen y cambia el estado de pedido a
pedido “listo para envío”.
2. Flujo de Eventos
2.1 Flujo Básico
a. El técnico de almacén consulta la lista de pedidos atendidos y
selecciona el pedido para enviar al almacén, o directamente
desde la interfaz de atención de pedido, una vez concluida la
asignación de cantidades puede pulsar el botón de “pasar
pedido a envío”.
b. El sistema comprueba que las cantidades asignadas coinciden
con las cantidades solicitadas en todas las líneas del pedido.
c. Si no ha habido ningún error el pedido pasa al estado “listo para
envío” y figurará en el listado de pedidos de la pestaña “listos
para envío” de la interfaz gráfica principal del técnico de
almacén.
2.2 Flujos Alternativos
2.2.1 En el punto b.
Si el sistema detecta que alguna de las cantidades de stock
asignado es distinta de la cantidad que demanda la línea
de pedido, entonces se genera un mensaje de aviso de
pedido incompleto. El técnico de almacén puede pasar el
pedido a listo para envío a pesar de no estar completo el
pedido, puede cancelar el pasar el pedido a envío, o bien
puede dividir el pedido en dos: uno que pasa a listo para
envío con las cantidades asignadas al pedido y otro con las
cantidades diferencia entre las que se han asignado y las
que se demandaban. Este último pedido generado
automáticamente figurará en estado de pedido en “no
atención
3. Precondiciones
3.1 El técnico de almacén está dado de alta en el sistema.
3.2 El técnico de almacén ha realizado correctamente el registro en el
sistema introduciendo el nombre de usuario y la contraseña
4. Poscondiciones
4.1 Si se satisfacen las cantidades demandadas, el pedido cambia del
estado “en atención” a pedido “listo para envío”
4.2 Si el técnico de almacén decide enviar el pedido a envío generando
uno nuevo con las cantidades que faltaron por asignar el sistema
creará un nuevo pedido en la base de datos como pedido “no
atendido” y enviará el original a listo para envío.
F. PASAR PEDIDO A ENVÍO
1. Descripción
El técnico de almacén consulta la lista de pedidos atendidos y
selecciona el pedido que quiere pasar a envío de la interfaz
correspondiente al mismo y selecciona el botón de “pasar pedido a
envío”. A continuación el sistema comprueba que la condiciones de
satisfacción de la demanda se cumplen y cambia el estado de pedido a
pedido “listo para envío”
2. Flujo de Eventos
2.1 Flujo Básico
a. El técnico de almacén consulta la lista de pedidos atendidos y
selecciona el pedido para enviar al almacén, o directamente desde la
interfaz de atención de pedido, una vez concluida la asignación de
cantidades puede pulsar el botón de “pasar pedido a envío”.
b. El sistema comprueba que las cantidades asignadas coinciden con las
cantidades solicitadas en todas las líneas del pedido.
c. Si no ha habido ningún error el pedido pasa al estado “listo para envío” y
figurará en el listado de pedidos de la pestaña “listos para envío” de la
interfaz gráfica principal del técnico de almacén.
2.2 Flujos Alternativos
2.2.1 En el punto b.
Si el sistema detecta que alguna de las cantidades de stock
asignado es distinta de la cantidad que demanda la línea de
pedido, entonces se genera un mensaje de aviso de pedido
incompleto. El técnico de almacén puede pasar el pedido a
listo para envío a pesar de no estar completo el pedido,
puede cancelar el pasar el pedido a envío, o bien puede
dividir el pedido en dos: uno que pasa a listo para envío con
las cantidades asignadas al pedido y otro con las cantidades
diferencia entre las que se han asignado y las que se
demandaban. Este último pedido generado automáticamente
figurará en estado de pedido en “no atención”.
3. Precondiciones
3.1 El técnico de almacén está dado de alta en el sistema.
3.2 El técnico de almacén ha realizado correctamente el registro en el
sistema introduciendo el nombre de usuario y la contraseña
4. Poscondiciones
4.1 Si se satisfacen las cantidades demandadas, el pedido cambia del
estado “en atención” a pedido “listo para envío”
4.2 Si el técnico de almacén decide enviar el pedido a envío generando
uno nuevo con las cantidades que faltaron por asignar el sistema
creará un nuevo pedido en la base de datos como pedido “no
atendido” y enviará el original a listo para envío.
G. REPOSICION DE STOCK
1. Reposición Stock
1.1 Descripción
El Jefe de Almacén detecta que falta stock de cierto producto en su
almacén y se dispone a reponerlo. Puede hacer un pedido a un
proveedor o introducir productos que acaban de llegar.
2. Flujo de Eventos
2.1 Flujo Básico
a. El sistema muestra el jefe de almacén una lista de los
productos con falta de stock.
b. El Jefe de Almacén selecciona aquellos que desea reponer y
hace un pedido al proveedor con número de unidades
concreto.
c. Los productos pasan al estado “Pendiente de Reposición”.
d. Si ha llegado nuevo stock de algún producto el Jefe de
Almacén puede seleccionar de la lista el mismo e introducir el
número de unidades nuevas. El producto pierde el estado
“Pendiente de Reposición”.
a. Flujos Alternativos
a) Si en el punto 2 el Jefe de Almacén desea hacer un pedido de
algún producto que no está en el estado “Pendiente de
Reposición” puede hacerlo indicándoselo al sistema.
b) El sistema le muestra el catálogo de productos para que
seleccione el que desee e introduzca el número de unidades a
pedir al proveedor.
c) El producto pasa al estado “Pendiente de Reposición”.
3. Precondiciones
3.1 El jefe de almacén debe estar dado de alta en el sistema.
4. Postcondiciones
4.1 El producto queda en estado “Pendiente de Reposición” o queda
actualizado con el nuevo stock.
GESTIÓN DE ENVÍOS:
A. CONSULTAR PEDIDOS A ENVIAR
1. Descripción
El Encargado de Transporte obtiene una lista con los pedidos listos para
ser enviados.
2. Flujo de Eventos
2.1 Flujo Básico
a. El encargado de transporte selecciona la opción “Consultar
pedidos listos para envío”.
b. En caso de que no exista ningún pedido listo para ser enviado,
el sistema responde con un mensaje indicando dicha situación.
c. En caso de que sí existan pedidos pendientes de ser enviados,
el sistema responde con el listado correspondiente.
d. El encargado de transportes puede consultar las líneas de
pedido que conforman cualquiera de los pedidos listos para
envío.
e. El encargado de transportes puede cargar los pedidos listos
para envío en el camión de transportes e indicar al sistema el
cambio del estado de los pedidos que cargue a pedidos en
envío, mediante el caso de uso “enviar pedido”.
2.2 Flujos Alternativos
3. Precondiciones
3.1 El encargado de transporte debe estar dado de alta en el sistema.
3.2 El encargado de transporte ha realizado correctamente el registro
en el sistema introduciendo su nombre usuario y su contraseña.
B. INTRODUCIR RECIBOS
1. Descripción
El Encargado de Transporte selecciona de la interfaz correspondiente al
mismo, el botón de Introducir Recibos. A continuación introduce en el
sistema el recibo de un pedido ya entregado.
2. Flujo de Eventos
2.1 Flujo Básico
a. El encargado de transporte selecciona la opción “introducir
recibos”.
b. El sistema muestra una lista con los pedidos en estado
“enviado”.
c. El encargado de transporte selecciona uno de ellos y pulsa la
opción “aceptar”.
d. El sistema muestra el detalle del pedido y los campos fecha de
entrega y transportista.
e. El encargado de transporte introduce la fecha de entrega del
pedido y el nombre del transportista que la realizó.
f. El encargado de transporte pulsa el botón “introducir”
g. El recibo es almacenado en el sistema, y el pedido que
figuraba en estado de “enviado” pasa al estado “pendiente de
cobro”.
2.2 Flujos Alternativos
2.2.1 En el punto c.
Si el transportista se equivoca al seleccionar el pedido
puede volver atrás en cualquier momento y anular la
introducción del pedido.
2.2.2 En el punto f
Si el transportista ha introducido un nombre de transportista
que no esté en la base de datos o la fecha de entrega del
pedido es errónea, el sistema muestra un mensaje de error.
3. Precondiciones
3.1 El encargado de transportes está dado de alta en el sistema.
3.2 El encargado de transporte ha realizado correctamente el registro
en el sistema introduciendo el nombre de usuario y la contraseña
4. Poscondiciones
4.1 El pedido cambia del estado “enviado” a pedido “pendiente de
cobro”
C. REALIZAR ENVÍO
1. Descripción
El encargado de transporte hace efectivo el envío del pedido
correspondiente.
2. Flujo de Eventos
2.1. Flujo Básico
a. El encargado de transporte selecciona la opción “realizar
envío”.
b. El sistema muestra la lista de pedidos listos para ser enviados
usando el caso de uso “consultar pedidos listos para envío”.
c. El encargado de transporte selecciona un pedido de la lista.
d. El sistema registra el código de los transportistas que van a
servir el envío y la fecha y hora de salida de los camiones.
e. El contenido del pedido es cargado en el camión.
f. El pedido pasa a ser pedido “enviado” automáticamente.El
stock del almacén es actualizado automáticamente por el
sistema, eliminando de dicho stock el asignado al pedido.
2.2. Flujos Alternativos
3. Precondiciones
3.1. El pedido está marcado como “Listo para Envío”.
3.2. El encargado de transporte está dado de alta en el sistema y ha
realizado correctamente el registro en el mismo mediante su
nombre de usuario y su contraseña.
4. Poscondiciones
4.1. El pedido queda marcado como “Enviado”.
4.2. El stock de los productos del pedido queda actualizado.
GESTION DE VENTAS
A. CONTROL ESTADÍSTICAS
1. Descripción
El Jefe de Ventas o el Ingeniero de Logística inicia el caso de uso. El
sistema le muestra una pantalla donde puede crear diversas estadísticas
sobre conceptos relacionados con la empresa. Por ejemplo, ventas por
sección, ventas de los representantes, pedidos realizados a las
operadoras, beneficio de la empresa, etc. Una vez creada una
estadística puede ser imprimida o guardada en el sistema para su
consulta posterior.
2. Flujo de Eventos
2.2 Flujo Básico
a. La pantalla muestra una lista con las posibles estadísticas a
crear.
b. El actor selecciona una de ellas y pulsa el botón crear.
c. El sistema le muestra una pantalla donde puede asignar
regiones, almacenes o trabajadores afectados por la estadística.
d. Pulsando siguiente aparecerá una ventana donde se mostrarán
parámetros de control y rangos de selección de forma que pueda
amoldar la estadística a sus preferencias.
e. Pulsando siguiente aparecerán los resultados que podrá guardar
o imprimir.
Si pulsa el botón guardar el sistema le permitirá grabar los
resultados en el disco duro u otro soporte de
almacenamiento.
Su pulsa el botón imprimir se mandarán a la impresora los
resultados.
3. Precondiciones
3.1 El actor ha realizado correctamente el registro en el sistema.
3.2 El actor ha seleccionado el botón de “Control Estadísticas” de su
interfaz gráfica.
B. CONSULTAR PRODUCTOS
1. Descripción
Este caso de uso lo ejecuta el Usuario de Ventas. Presenta el catálogo
de productos de la compañía por pantalla. Se muestra una descripción
del producto, su foto y el precio de venta. Puede seleccionarse
cualquiera e introducirlo en la orden de pedido si se desea.
2. Flujo de Eventos
2.1 Flujo Básico
a. El Usuario de Ventas accede al catálogo de productos.
b. Se muestra por pantalla una clasificación de los productos con
su descripción, foto y precio.
c. El usuario puede seleccionar uno e introducirlo en la orden de
pedido.
d. El catálogo se queda en segundo plano y se muestra la orden de
pedido añadiendo el producto que se ha seleccionado.
2.2 Flujos Alternativos
3. Precondiciones
3.1 El Usuario de Ventas debe estar dado de alta en el sistema
4. Postcondiciones
C. OTORGAR INCENTIVOS
1. Descripción
Este caso de uso muestra la opción de otorgar incentivos. El actor Jefe
de Ventas inicia el caso de uso y el sistema le muestra una lista donde
se almacenan los incentivos pendientes. Si pincha en el botón añadir
incentivo la aplicación le mostrará una nueva pantalla donde puede
especificar la clase de incentivo y a los trabajadores que afectará. El
Jefe de Ventas también puede anular y modificar los incentivos ya
registrados en el sistema. Los incentivos que se han cobrado (en la
nomina mensual) por parte de los trabajadores desaparecen de la lista.
2. Flujo de Eventos
2.1 Flujo Básico
a. La pantalla muestra una lista con los incentivos pendientes
b. EL Jefe de Ventas puede seleccionar uno de los existentes y
pulsar el botón modificar, añadir o borrar.
i. Si pulsa el botón modificar el sistema le mostrará una pantalla
donde le aparecerá una lista de personas o secciones a las
que afecta el incentivo y la cantidad del mismo.
Si hace doble click en el campo cantidad de una línepodrá
modificarla.
Si selecciona una línea y pulsa el botón borrar se borrará
la persona o sección en cuestión.
Si pulsa el botón añadir persona aparecerá una pantalla
donde podrá seleccionar un trabajador de la empresa
según la región e introducir la cantidad a bonificar.
Si pulsa el botón añadir sección aparecerá una pantalla
donde podrá seleccionar una sección de la empresa e
introducir la cantidad a bonificar.
Al pulsa el botón aceptar se confirmará el incentivo que
será pagado en la próxima nómina de los empleados
afectados indicándose en esta el motivo.
ii. Si pulsa el botón borrar se eliminará el incentivo seleccionado.
iii. Si pulsa el botón añadir aparecerá una pantalla con una lista
vacía de personas o secciones y la cantidad de bonificación a
cero.
Si pulsa el botón añadir persona aparecerá una pantalla
donde podrá seleccionar un trabajador de la empresa
según la región e introducir la cantidad a bonificar.
Si pulsa el botón añadir sección aparecerá una pantalla
donde podrá seleccionar una sección de la empresa e
introducir la cantidad a bonificar.
Al pulsa el botón aceptar se confirmará el incentivo que
será pagado en la próxima nómina de los empleados
afectados indicándose en esta el motivo.
Si hace doble click en el campo cantidad de una línea
podrá modificarla.
Si selecciona una línea y pulsa el botón borrar se borrará
la persona o sección en cuestión.
3. Precondiciones
3.1 El Jefe de Ventas ha realizado correctamente el registro en el
sistema.
3.2 El Jefe de Ventas ha seleccionado el botón de “Otorgar Incentivos”
de su interfaz gráfica.
4. Poscondiciones
4.1 En caso de haberse dado de alta un nuevo incentivo este quedará
almacenado en la lista de incentivos pendientes
4.2 En caso de haberse borrado un incentivo se eliminará de la lista de
incentivos pendientes
D,. ELABORAR PEDIDO
1. Descripción
El representante de ventas o la operadora, después de registrarse en el
sistema mediante el usuario y la contraseña pueden invocar el caso de
uso elaborar pedido, aunque en el caso del representante de ventas
únicamente podrá elaborar pedidos de los clientes que tenga asignados.
Se introduce el cliente y se muestran los pedidos que tiene pendientes si
los hay. Se pueden modificar, eliminar o realizar nuevos pedidos.
2. Flujo de Eventos
1.4. Flujo Básico
1. La operadora o el representante de ventas buscan el cliente por
DNI, CIF o por código de cliente.
2. El sistema presenta los datos del cliente, según aparezcan en la
base de datos, y la lista de órdenes en elaboración y enviadas al
almacén de dicho cliente.
3. El representante de ventas o la operadora comunican al cliente
los pedidos en elaboración listados y ofrecen la posibilidad de
modificar uno ya existente, borrar uno existente, o realizar una
nueva orden de pedido. En caso de realizar una nueva orden de
pedido, ir al punto 4. En caso de solicitar una modificación de un
pedido en elaboración, pasar al punto 5. En caso de solicitar el
borrado de un pedido en elaboración se procederá al punto 6.
4. El sistema muestra una nueva interfaz gráfica en la que aparece
un campo con la fecha actual del sistema, la referencia del
pedido a modificar, la dirección de envío del pedido y un listado
de las líneas de pedido, en las que se reflejan el código de
artículo, la descripción del mismo, la cantidad solicitada, el
precio, y por último el precio total del pedido, con los datos de
las líneas de pedido que contuviera el mismo.
4.1. El representante de ventas o la operadora deben
introducir la dirección de envío del pedido especificando
dirección, número, puerta, código postal, país, provincia y
localidad.
4.2. El representante de ventas o la operadora introducen una
nueva línea de pedido mediante el botón añadir línea,
habiendo introducido la referencia del producto y la
cantidad deseada por el cliente. Conforme se introducen
las cantidades se muestra el IVA y el total del pedido por
pantalla.
4.3. En caso de querer introducir una nueva línea de pedido,
volver al punto 4.2.
4.4. Se selecciona la modalidad de pago, que aparecerá
como a crédito y al contado o bien sólo una de éstas
opciones según sea el ratio del cliente.
4.5. Por último, una vez introducidas todas las líneas de
pedido, el representante de ventas o la operadora
pueden guardar el pedido pulsando el botón “guardar”,
en cuyo caso se almacenará en la base de datos con los
datos actuales en estado de elaboración, o pueden pasar
el pedido a almacén pulsando el botón “enviar a
almacén”, en cuyo caso el pedido deja de estar en
elaboración y aparece en el listado de pedidos no
atendidos del almacén. Pasar al punto 7.
5. El sistema muestra una nueva interfaz gráfica en la que aparece
un campo con la fecha actual del sistema, la referencia del
pedido a modificar, la dirección de envío del pedido y un listado
de las líneas de pedido, en las que se reflejan el código de
artículo, la descripción del mismo, la cantidad solicitada, el
precio, y por último el precio total del pedido, con los datos de
las líneas de pedido que contuviera el mismo.
5.1. El representante de ventas o la operadora pueden
introducir una nueva línea de pedido mediante el botón
“añadir línea”, habiendo introducido la referencia del
producto y la cantidad deseada por el cliente. Conforme
se introducen las cantidades se muestra el IVA y el total
del pedido por pantalla.
5.2. El representante de ventas o la operadora pueden
modificar una línea de pedido seleccionando la línea de
pedido de la lista de líneas, modificando la cantidad y por
último pulsando el botón “añadir línea”.
5.3. En caso de introducir una nueva línea de pedido, volver al
punto 5.1.
5.4. En caso de introducir una nueva línea de pedido, volver al
punto 5.2.
5.5. Se selecciona la modalidad de pago, que aparecerá como
a crédito y al contado o bien sólo una de éstas opciones
según sea el ratio del cliente.
5.6. Por último, una vez introducidas o modificadas las líneas
de pedido, el representante de ventas o la operadora
pueden guardar el pedido pulsando el botón “guardar”, en
cuyo caso se almacenará en la base de datos con los
datos actuales en estado de elaboración, o pueden pasar
el pedido a almacén pulsando el botón “enviar a almacén”,
en cuyo caso el pedido deja de estar en elaboración y
aparece en el listado de pedidos no atendidos del
almacén. Pasar al punto 7.
6. El representante de ventas o la operadora seleccionan el pedido
en elaboración a borrar y pulsan el botón “cancelar pedido”. El
sistema mostrará una ventana de aviso de borrado y de pérdida
de los datos. El representante de ventas o la operadora pueden
confirmar el borrado pulsando el botón “aceptar”o cancelar
pulsando ”cancelar”. En el primer caso el pedido se elimina de la
base de datos, y en el segundo permanece sin cambios.
7. El representante de ventas o la operadora vuelven a la interfaz
de elaborar pedido, en la que pueden cambiar de cliente,
consultar los pedidos del cliente, tanto en elaboración como los
enviados al almacén o salir de la aplicación a la pantalla inicial
de registro en el sistema.
2.2 Flujos Alternativos
2.2.1 En el punto 1
Si en el paso 1 el cliente no está dado de alta se mostrará un
mensaje de error indicando el fracaso de la búsqueda y se
podrá invocar el caso de uso gestión de clientes para
proceder a su alta. En el caso del representante de ventas
puede ser que el problema se derive de que esté indicando
un cliente al que no representa.
2.2.2 En el punto 4.1
Si en el punto 4.1 al introducir alguno de los campos
número, puerta o código postal se ha metido un número no
estrictamente positivo, el sistema generará un mensaje de
error.
2.2.3 En el punto 4.2
Si en el paso 4.2 el representante de ventas o la operadora
introducen una referencia errónea o inexistente, el sistema
generará un aviso de error de producto no existente. En
caso de introducir una cantidad no mayor que cero el
sistema generará un aviso de error de cantidad errónea. Si
se introduce una cantidad por encima del rango máximo
razonable de pedido el sistema generará un aviso de haber
excedido esta cantidad.
2.2.4 En el punto 5.1
Si en el paso 5.1 el representante de ventas o la operadora
introducen una referencia errónea o inexistente, el sistema
generará un aviso de error de producto no existente. En
caso de introducir una cantidad no mayor que cero el
sistema generará un aviso de error de cantidad errónea. Si
se introduce una cantidad por encima del rango máximo
razonable de pedido el sistema generará un aviso de haber
excedido esta cantidad.
2.2.5 En el punto 5.2
Si en el paso 5.2 el representante de ventas o la operadora
introducen un código de artículo erróneo, el sistema
generará un aviso de error de artículo no existente. En caso
de introducir una cantidad no mayor que cero el sistema
generará un aviso de error de cantidad errónea. Si se
introduce una cantidad por encima del rango máximo
razonable de pedido el sistema generará un aviso de haber
excedido esta cantidad.
3. Precondiciones
3.1 El representante de ventas o la operadora han realizado
correctamente el registro en el sistema mediante el nombre de
usuario y la contraseña.
4. Poscondiciones
4.1 En caso de haberse realizado un nuevo pedido y seleccionado
guardar en lugar de solicitar el paso al almacén, el pedido queda
almacenado en el sistema en la lista de pedidos en elaboración.
4.2 En caso de haberse realizado un nuevo pedido y solicitado el
paso al almacén, el pedido queda almacenado en el sistema en la
lista de pedidos no atendidos del almacén.
4.3 En caso de haberse modificado un pedido en elaboración y
seleccionado en lugar de solicitar el paso al almacén, el pedido
queda almacenado con las modificaciones pertinentes en el
sistema en la lista de pedidos en elaboración.
4.4 En caso de haberse modificado un pedido en elaboración y
solicitado el paso al almacén, el pedido queda almacenado con
las modificaciones pertinentes en el sistema en la lista de pedidos
no atendidos del almacén.
4.5 En caso de haberse realizado un borrado de un pedido en
elaboración, el pedido queda eliminado del sistema y por tanto de
la lista de pedidos en elaboración.
5. Puntos de Extensión
5.1 Gestión de Clientes en el punto 1
En el paso 1, en caso de que no exista el cliente, se puede
invocar el caso de uso Gestión de Clientes para introducir un
nuevo cliente en la base de datos del sistema.
5.2 Consultar Catálogo en el punto 4.2 y 5.1
En el paso 4.2 o en el paso 5.1, en caso de que la operadora o el
representante de ventas desconozcan la referencia del producto,
pueden invocar al caso de uso Consultar Catálogo para realizar
búsquedas de productos.
E. ELABORAR PEDIDO ONLINE
1. Descripción
El cliente online puede introducir una orden de pedido accediendo a la
página de Internet de la empresa. La orden de pedido quedará
almacenada en el sistema al igual que en el caso de uso Elaborar
Pedido.
2. Flujo de Eventos
2.1 Flujo Básico
1. El sistema genera automáticamente el número de pedido y le
asigna la fecha actual.
2. El sistema presenta los datos del cliente por pantalla.
3. El cliente puede comprobar el estado de pedidos realizados con
anterioridad pulsando el botón “consultar pedidos”.
4. Si se quiere introducir un nuevo pedido, el cliente pulsa el botón
“nuevo pedido” y se le muestra una pantalla donde puede
comenzar a introducir referencias de artículos o utilizar el
catálogo de productos para seleccionarlos. Conforme se
introducen las cantidades se muestra el total del pedido por
pantalla.
5. Selecciona la modalidad de pago.
6. Si la modalidad es por transferencia o tarjeta de crédito se pide
la confirmación de los datos de la cuenta.
7. Si el cliente está conforme con los datos del pedido, puede
guardarlo como pedido en elaboración pulsando el botón
“guardar” o bien puede enviar el pedido al almacén
correspondiente a su región, pulsando el botón de “enviar a
almacén”.
8. Si el cliente no quiere guardar los datos del pedido que ha
elaborado, pulsa el botón “salir”.
2.2 Flujos Alternativos
2.2.1 En el paso 4
Si el cliente quiere anular algún pedido se le comunica si
existe la posibilidad de hacerlo y cuál sería el coste
2.2.2 En el paso 5
Si algún producto no tiene stock disponible se avisa por
pantalla.
2.2.3 En el paso 8
Si el cliente no está conforme, puede modificarse el pedido o
proceder a la anulación del mismo.
3. Precondiciones
3.1 El cliente debe estar dado de alta en el sistema de compras online.
3.2 El cliente ha introducido correctamente su nombre de usuario y su
contraseña en el sistema
4. Poscondiciones
4.1 La orden de pedido queda almacenada en el sistema si el usuario
ha seleccionado “guardar”
4.2 La orden de pedido se envía al almacén correspondiente a la
región a la que pertenece la dirección de envío si el usuario
seleccionó “enviar al almacén”
4.3 La orden de pedido no se almacena en el sistema si el usuario
seleccionó “salir”
F. GESTIÓN DE CLIENTES
1. Descripción
Este caso de uso resume la utilidad de alta, baja y modificación de los
datos registrados en la base de datos de la plantilla de clientes que tiene
la empresa. El usuario de ventas, ya sea representante de ventas,
operadora o cliente on-line, podrá acceder a los datos correspondientes
a cada uno y realizar modificaciones. Los representantes de ventas
solamente pueden modificar o eliminar clientes que estén asociados a
los mismos, y el alta asociará automáticamente al cliente con dicho
representante. Los clientes on-line solo podrán modificar datos propios,
eliminarse como clientes o darse de alta como uno nuevo sin que dé
lugar a repeticiones. Por último, la operadora podrá modificar, dar de alta
o eliminar cualquier cliente.
2. Flujo de Eventos
2.1 Flujo Básico
1. El Usuario de Ventas puede seleccionar dar de alta un nuevo
cliente, pasar al punto 2; dar de baja un cliente, pasar al punto 3;
modificar datos de un cliente, pasar al punto 4.
2. El Usuario de Ventas solicita el alta de un nuevo cliente.
2.1. El sistema muestra los campos de datos necesarios a
introducir; los campos a rellenar son: DNI/CIF, Nombre, País,
Provincia, Localidad, Dirección, Código Postal, Teléfono, E-mail
y Cuenta Bancaria.
2.2. El Usuario de Ventas pulsa el botón introducir datos. Pasar
al punto 5.
3. El Usuario de Ventas solicita la baja de un cliente.
3.1. El sistema muestra el campo DNI/CIF a introducir necesario
para la baja.
3.2. El Usuario de Ventas introduce el DNI/CIF del cliente que
desea eliminar y pulsa “entrar”.
3.3. El sistema muestra los campos de los datos del cliente que
se ha solicitado para la baja.
3.4. El Usuario de Ventas pulsa el botón borrar de su interfaz
gráfica.
3.5. El sistema genera un mensaje de aviso de borrado y
solicita la confirmación de la eliminación.
3.6. El Usuario de Ventas puede confirmar la eliminación del
cliente pulsando el botón Aceptar, o bien puede cancelar el
borrado pulsando el botón Cancelar. Pasar al punto 5.
4. El Usuario de Ventas solicita la modificación de datos de un
cliente
4.1. El sistema muestra el campo DNI/CIF a introducir necesario
para la modificación. El sistema muestra los datos del
cliente que se ha solicitado para la modificación.
4.2. El Usuario de Ventas puede modificar cualquiera de los
datos de los campos mostrados por el sistema, éstos son:
DNI/CIF, Nombre, País, Provincia, Localidad, Dirección,
Código Postal, Teléfono, E-mail y Cuenta Bancaria.
4.3. El Usuario de Ventas puede solicitar guardar los datos
modificados pulsando el botón Modificar de la interfaz
gráfica.
4.4. El sistema genera un mensaje de aviso de modificación y
solicita la confirmación de la misma.
4.5. El Usuario de Ventas puede confirmar la modificación del
cliente pulsando el botón Aceptar, o bien puede cancelar el
borrado pulsando el botón Cancelar. Pasar al punto 5.
2.2 Flujos Alternativos
2.2.1 En el punto 2.2
El sistema comprueba que los datos del nuevo cliente,
DNI/CIF no se corresponden con ningún otro cliente de la
base de datos. En caso afirmativo, generará un mensaje de
error comunicando que dicho cliente ya está dado de alta
en la base de datos. El sistema comprueba que se han
introducido todos los datos restantes, en caso de que no se
hayan introducido datos en los campos Nombre, País,
Provincia, Localidad, Dirección, Código Postal, Teléfono y
Cuenta Bancaria, el sistema generará un mensaje de error
comunicando que faltan datos del necesarios cliente.
2.2.1.1 En el punto 2.2
Si se ha generado mensaje de error, el sistema
vuelve a mostrar la interfaz gráfica de alta de
cliente.
2.2.2 En el punto 3.2
El sistema comprueba que el DNI/CIF introducido
corresponde con alguno de los registrados en la base de
datos. Si el DNI/CIF no se encuentra en la base de datos,
se generará un mensaje de error indicando que el DNI/CIF
introducido no se encuentra en la base de datos.
2.2.2.1 En el punto 3.2
Si se ha generado mensaje de error, el sistema
vuelve a mostrar la interfaz gráfica de borrar
cliente.
2.2.3 En el punto 3.6
El sistema comprueba si el cliente solicitado para la baja
tiene pedidos en elaboración, en caso afirmativo informará
al Usuario de Ventas de que se eliminarán también los
pedidos en elaboración. El sistema también comprueba
que el cliente no tiene pedidos en cualquier otro estado que
no sea el de elaboración. En caso afirmativo, el sistema
informará de la situación al Usuario de Ventas y podrá
solicitar Cancelar Pedido Atendido. En caso de no
eliminarse previamente los pedidos pendientes, el sistema
no borrará el cliente.
2.2.4 En el punto 4.1
El sistema comprueba que el DNI/CIF introducido
corresponde con alguno de los registrados en la base de
datos. Si el DNI/CIF no se encuentra en la base de datos,
se generará un mensaje de error indicando que el DNI/CIF
introducido no se encuentra en la base de datos.
2.2.4.1 En el punto 4.1
Si se ha generado mensaje de error, el sistema
vuelve a mostrar la interfaz gráfica de modificar
cliente.
2.2.5 En el punto 4.5
El sistema comprueba que los datos del nuevo cliente,
DNI/CIF no se corresponden con ningún otro cliente de la
base de datos. En caso afirmativo, generará un mensaje de
error comunicando que dicho cliente ya está dado de alta
en la base de datos. El sistema comprueba que se han
introducido todos los datos restantes, en caso de que no se
hayan introducido datos en los campos Nombre, País,
Provincia, Localidad, Dirección, Código Postal, Teléfono y
Cuenta Bancaria, el sistema generará un mensaje de error
comunicando que faltan datos del necesarios cliente.
2.2.5.1 En el punto 4.5
Si se ha generado mensaje de error, el sistema
vuelve a mostrar la interfaz gráfica de modificar
cliente.
3. Precondiciones
3.1 El Usuario de Ventas ha realizado correctamente el registro en el
sistema
3.2 El Usuario de Ventas ha seleccionado el botón de “Gestión de
Clientes” de su interfaz gráfica
4. Poscondiciones
4.1 En caso de haberse dado de alta un nuevo cliente, los datos del
cliente quedan almacenados en la base de datos
4.2 En caso de haberse realizado una modificación de los datos de un
cliente, quedan almacenados en la base de datos.
4.3 En caso de haberse realizado un borrado de un cliente, el cliente
queda eliminado del sistema y por tanto de la lista de pedidos en
elaboración de dicho cliente.
4. MODELO DE CASOS DE USO
A continuación se presentan los diagramas de casos de uso planteados para
cada uno de los subsistemas definidos para la empresa. Cabe destacar que los
casos de uso que no se incluyeron en la fase de construcción sólo figuran en
estado de propuestos, por tanto en sus primeras versiones
Gestión de Ventas
En el subsistema gestión de ventas participan tres actores para los cuales se
generan distintos casos de uso, que se muestran a continuación.
Gestión de Almacén
Gestion de Envios
Departamento de Logistica
Departamento de Marketing
Departamento de Contabilidad /Facturación
Departamento de Recursos Humanos
CAPITULO IV: ANÁLISIS / DISEÑO
A continuación se presentan los modelos definidos en RUP como modelo de datos y modelo de análisis / diseño. Constará de un diagrama de clases en el que se muestran tan sólo las clases generadas a partir de los casos de uso incorporados a la aplicación hasta la segunda iteración de la fase de construcción, y de un modelo de datos (modelo relacional) donde se muestran las entidades que participan en las relaciones definidas en el proyecto (teniendo en cuenta de nuevo que se alcanzó únicamente la segunda iteración de la fase de construcción).
1. MODELO DE ANÁLISIS/DISEÑO: DIAGRAMA DE CLASES
2. MODELO DE DATOS: MODELO RELACIONAL
CAPITULO V: IMPLEMENTACIÓN
A continuación se presentan los prototipos de interfaces gráficas de usuario
diseñadas para la aplicación final. Cabe citar que se presentan únicamente
los prototipos de interfaces de usuario que se negociaron con el cliente como
candidatos a ser incluidos hasta la segunda iteración de la fase de
construcción (en los subsistemas de gestión de almacén y gestión de ventas
respectivamente).
1. PROTOTIPO DE INTERFACE DE USUARIO
1.1. Interfaces Comunes
La aplicación de cualquier subsistema de la empresa dispone de una
primera ventana de identificación del usuario. Sólo usuarios registrados
en la base de datos pueden acceder al sistema. Para la demo
descargable se puede utilizar el usuario operadora cuyo nombre de
usuario es "maria" y cuyo password es "nike".
Interfaz que se presenta en la identificación
En caso de seleccionar incidencia pedido, la interfaz gráfica que se
mostrará será la siguiente
En la consulta de incidencias se podrá ver una lista de las incidencias
registradas en el sistema.
En las siguientes iteraciones de construcción se implementarán casos
de uso como el de gestión de clientes (botón que aparece en la
pantalla de los datos del cliente pero que no tiene ninguna
funcionalidad asociada).
El interfaz es el siguiente:
Para consultar los detalles de una incidencia el prototipo de interfaz
gráfica es el siguiente:
2. GESTIÓN DE VENTAS
Para el subsistema de ventas el prototipo de interfaz gráfica es el de
elaborar pedido. Para la aplicación demo se puede introducir por ejemplo
en nombre "jaime" y pulsar el botón "buscar". Aparecerán los datos de este
cliente.
El prototipo de interfaz gráfica es el siguiente:
El usuario de ventas puede generar un pedido nuevo para un cliente,
modificar un pedido que esté en elaboración, consultar pedidos en
elaboración, cancelar pedidos o consultar el detalle de pedidos ya enviados
al almacén.
En el caso de elaborar un pedido nuevo o de modificar uno existente la
interfaz gráfica que se presentará será la siguiente:
3. GESTIÓN DE ALMACÉN
Para la gestión de almacén el prototipo de interfaz gráfica es el siguiente,
en el que se pueden observar cuatro pestañas principales, una para no
atendidos (pedidos en estado de no atención), otra para en atención
(pedidos para los cuales ha sido reservado stock)
En la pestaña de no atendidos el técnico de almacén puede realizar las
operaciones de consulta de detalles de un pedido, puede atender
directamente el pedido seleccionado, puede cancelar el pedido
seleccionado o salir de nuevo a la interfaz de identificación.
Para ver la interfaz gráfica principal de técnico de almacén en no
atendidos es la siguiente:
En la pestaña de atención el técnico de almacén dispone de las siguientes
opciones en su interfaz gráfica: atender el pedido seleccionado, cancelar el
pedido seleccionado, pasar un pedido determinado tanto si está completo
como si está completo a envío, y salir a la interfaz de identificación.
El enlace para la interfaz de en atención es el siguiente:
En la pestaña de listos para envío, el técnico de almacén dispone de las
siguientes opciones en su interfaz gráfica: consultar los detalles del pedido
seleccionado, cancelar el pedido seleccionado o salir a la interfaz de
identificación.
El enlace para la interfaz de listos para envío es el siguiente:
Dentro de la interfaz en de la consulta de pedidos no atendidos que se
puede realizar desde la pestaña de no atendidos, se observa la siguiente
interfaz gráfica:
Al atender, tanto si es la primera atención como si se trata de una
modificación posterior de un pedido, se observa la siguiente interfaz
gráfica, que dispone de las opciones siguientes: asignar cantidad al hacer
doble clic sobre una línea de pedido, guardar los cambios realizados
pulsando el botón guardar, pasar el pedido a envíos, generar una
incidencia respecto a este envío o volver a la interfaz anterior pulsando el
botón salir.
El interfaz de atender pedido es el siguiente
Por último, al hacer doble clic sobre una línea de pedido, la interfaz
gráfica que surge es:
4. COMPONENTES Y DESPLIEGUE
A continuación se presentan los modelos definidos en RUP como diagrama
de componentes y diagrama de despliegue del proyecto. En el primero de
ellos se muestra la disposición de las partes integrantes de la aplicación y
las dependencias entre los distintos módulos de la aplicación. En el
segundo se muestra la representación de los distintos nodos repartidos en
distintos países que forman parte del sistema completo.
Se puede ver el código fuente en Visual Basic haciendo clic sobre
cualquiera de los componentes que se pretenda consultar.
4.1. Diagrama Global de Paquetes
4.2. Diagrama de Componentes Comunes
4.3. Diagrama de Componentes Almacén
4.4. Diagrama de Componentes Ventas
4.5. Diagrama de Despliegue
CAPITULO VI: PRUEBAS
1. PRUEBAS FUNCIONALES
A continuación se muestran los casos de pruebas funcionales de los casos
de uso incluidos en el proyecto de desarrollo software hasta la segunda
iteración de la fase de construcción, como se indica en el plan de desarrollo
software.
1.1. Especificaciones de Casos de Prueba
Las especificaciones de casos de uso están divididas según el
subsistema al que pertenezcan, atendiendo a los subsistemas definidos
en el documento Visión.
A. BASE DE DATOS DE PRUEBA
Estos son Imprescindible para ver los datos utilizados en los casos de
1. Orden pedidoCódig
o pedid
o
Fecha Estado Cliente
Usuario Ventas
C.P. enví
o
País envío
Prov. envío
Loc. envío
Pta enví
o
Nº enví
o
Calle envío
Forma pago
Fecha elab.
Fecha lleg. Alm.
Fecha aten.
Fecha
lista enví
o
Fecha sal. Alm.
1 07/09/2002
En elaboració
n
1 48265791-L
46985
España
Valencia
Manises 25 3 C/ Melia
s
Contado
07/09/2002
2 25/10/2002
En elaboració
n
2 26359874-J
46758
España
Valencia
Xativa 12 6 C/ Azori
n
Contado
25/10/2002
3 10/11/2002
No atendido
1 48265791-L
46985
España
Valencia
Manises 25 3 C/ Melia
s
Crédito 10/11/2002
10/11/2002
4 21/11/2002
En elaboració
n
1 48265791-L
46985
España
Valencia
Manises 25 3 C/ Melia
s
Contado
21/11/2002
5 02/12/2002
No atendido
1 48265791-L
46970
España
Valencia
Burjassot
14 5 C/ San
Justo
Crédito 02/12/2002
05/12/2002
6 07/12/2002
En atención
2 48265791-L
46758
España
Valencia
Xativa 12 6 C/ Azorí
n
Contado
07/12/2002
10/12/2002
11/12/2002
7 15/12/2002
En atención
2 48265791-L
46758
España
Valencia
Xativa 12 6 C/ Azorí
Contad 15/12/200 18/12/200 19/12/200
n o 2 2 2
8 04/01/2003
En atención
2 48265791-L
46758
España
Valencia
Xativa 12 6 C/ Azorí
n
Contado
04/01/2003
07/01/2003
09/01/2003
2. Empleado
NIF Usuario Contraseña Nombre Teléfono Cargo
22596826-F Pepe adidas José Martínez Muñoz 962468597 Técnico almacén
26359874-J Luis reebok Luis Fernández Vila 961387596 Representante de Ventas
48265791-L Maria nike Maria López Escudero 963478952 Operadora
26485963-M Toni puma Antonio Milla López 963474565 Técnico almacén
3. Producto
Referencia Precio(€) Nombre Descripción Proveedor Max_razonable
1 67 Zapatillas Zapatillas illas 456 200
2 34 Mochila Mochila ilas 456 100
3 28 Sudadera Sudadera eras 456 350
4 42 Raqueta Raquetas etas 456 100
5 30 Calentadores Calentadores ores 456 1000
4. Línea pedido
5. Producto-Almacén
Código pedido Referencia Cantidad Precio(€) Cantidad Asig.
1 1 1 67 0
1 2 1 34 0
1 3 2 56 0
2 1 1 67 0
2 4 2 84 0
3 2 2 68 0
4 5 3 90 0
4 4 2 84 0
5 3 5 140 0
5 1 2 134 0
6 2 2 68 2
6 1 1 67 1
7 4 2 84 1
8 4 1 42 0
8 5 2 60 1
Referencia Almacén Stock Stock Asig.
1 VAL 1000 1
2 VAL 500 2
3 VAL 6 0
4 VAL 600 1
5 VAL 3000 1
6. Almacén
Código Nombre Dirección Teléfono País Fax Email Cod_reg Técnico
VAL Virso C/ Colón, 15-78
963479862 España 963479860 [email protected] E 26485963-M
7. Región
Código Nombre
E Europa
8. País
Nombre Región
España E
9. Proveedor
NIF Código Nombre Teléfono Dirección Nº Pta Localidad
Provincia CP Pais Fax Email
26789536-D 456 Juan Navarro
Luna
963471263 C/ Jesús 48 101 Benaixida Valencia 46078 España 963471260 [email protected]
10.Cliente
Codigo
NIF/CIF Usuario
Contra señ
a
Nombre
Pta Nº Calle Teléfono
Loc. Prov. C.P. C.C.C País Email Es-empresa
Pers_conta
cto
Tlf_pers_contacto
Ratio
conf.
Repre
sentante
Fax
1 48315682-N
JaimeMonzónGarcía
25 3 C/ Melia
s
961385396
Manises
Valencia
46985 95-264895-000635268
9
España
Jaime75
@ono.com
Excelente
26359874-J
2 22496359-P
javi kelme
Javier Soria
Garrido
12 6 C/ Azori
n
962359684
Xativa Valencia
46758 48-59682-000845489
5
España
m
Regular
26359874-J
11. I ncidencias
Cod_incidencia Cod_pedido Fecha Nif_creador Creador Observaciones
1 6 11/12/2002 26485963M Antonio Milla López
Reponer stock, producto 1 por debajo
del mínimo2 7 21/12/2002 26485963M Antonio Milla
LópezPedido en atención
más de 2 días
2. GESTION DE ALMACEN
A. Consultar Pedidos no Atendidos
1. Descripción
Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de
Uso “Consultar Pedidos no Atendidos”. La única prueba que se puede
realizar a este caso de uso es comprobar que la consulta funciona
correctamente. El entorno del cual partiremos para realizar la prueba
será el formulario de entrada de la aplicación.
2. Comprobar que la consulta funciona correctamente
2.1. Descripción
Nos introducimos en el sistema como técnico de almacén, accediendo a
su funcionalidad y solicitamos consultar pedidos no atendidos, el sistema
nos mostrara una lista con los pedidos no atendidos que haya
almacenados en el sistema.
2.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el
usuario técnico de almacén “toni” está dado de alta en la base de
datos de empleado y su clave correspondiente. Consultar la Base
de Datos de Pruebas para ver toda la especificación completa de
los datos.
2.3. Entrada
Introducimos ‘pepe’ en el campo usuario
Introducimos ‘adidas’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia del técnico de almacén, donde
pulsaremos la pestaña de “No Atendidos”.
Seleccionamos uno de los pedidos en estado de no atención.
Pulsamos el botón “consultar” y el sistema muestra los detalles
de las líneas del pedido. Al salir, el pedido figurará en el estado
de “En Atención”.
2.4. Resultado esperado
El sistema nos muestra una interfaz que consistirá en una lista
con las líneas de pedido del pedido solicitado.
2.5. Evaluación de la Prueba
Prueba superada con éxito
B. Casos de Prueba de Atender Pedido
Descripción
Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de
Uso “Atender Pedido”.
La pruebas realizadas a este caso de uso son:
Atender pedido después de consultar dicho pedido.
Atender un pedido de la lista de pedidos no atendidos.
Atender pedido asignando cantidades negativas o mayores a las
disponibles.
Atender pedido asignando cantidades mayores a las solicitadas.
Atender pedido sin asignar cantidades.
El entorno del cual partiremos para realizar la prueba será el formulario
de entrada de la aplicación
1) Atender pedido después de consultar dicho pedido
1.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos no
atendidos, el sistema nos mostrara una lista con los pedidos no
atendidos que haya almacenados en el sistema. Seleccionaremos
un pedido y lo consultaremos eligiendo posteriormente la opción de
atender dicho pedido.
1.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el
usuario técnico de almacén “Toni” está dado de alta en la base de
datos de empleado y su clave correspondiente. Consultar la Base
de Datos de Pruebas para ver toda la especificación completa de
los datos.
1.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
El técnico selecciona de la lista de pedidos no atendidos el pedido
de código ‘3’ y pulsa el botón ‘Consultar’.
Una vez consultado pulsa el botón ‘Atender Pedido’.
Para cada línea de pedido:
o Comprueba que hay stock disponible.
o Selecciona la línea haciendo doble clic para que aparezca la
interfaz que nos permite modificar la cantidad asignada, allí
se actualizan automáticamente los datos código y nombre
del artículo.
o Introduce la cantidad solicitada.
o Pulsa el botón ‘Asignar Cantidad’.
o Se actualiza línea de pedido.
o El técnico pulsa el botón ‘Guardar’.
1.4. Resultado esperado
El pedido queda almacenado en el sistema como en atención y el
stock se reduce en las cantidades asignadas.
1.5. Evaluación de la Prueba
Prueba superada con éxito.
2) Atender un pedido de la lista de pedidos no atendidos
2.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos no
atendidos, el sistema nos mostrara una lista con los pedidos no
atendidos que haya almacenados en el sistema. Seleccionaremos
un pedido y elegiremos la opción atender pedido.
2.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el
usuario técnico de almacén “Toni” está dado de alta en la base de
datos de empleado y su clave correspondiente. Consultar la Base
de Datos de Pruebas para ver toda la especificación completa de
los datos.
2.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
El técnico selecciona de la lista de pedidos no atendidos el pedido
de código ‘5’ y pulsa el botón ‘Atender Pedido’.
Para cada línea de pedido:
o Comprueba que hay stock disponible.
o Selecciona la línea haciendo doble clic para que aparezca
la interfaz que nos permite modificar la cantidad asignada,
allí se actualizan automáticamente los datos código y
nombre del artículo.
o Introduce la cantidad solicitada.
o Pulsa el botón ‘Asignar Cantidad’.
o Se actualiza línea de pedido.
El técnico pulsa el botón ‘Guardar’.
2.2. Resultado esperado
El pedido queda almacenado en el sistema como en atención y el
stock se reduce en las cantidades asignadas.
2.3. Evaluación de la Prueba
Prueba superada con éxito.
3. Atender pedido asignando cantidades negativas
3.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos no
atendidos, el sistema nos mostrara una lista con los pedidos no
atendidos que haya almacenados en el sistema. Seleccionaremos
un pedido, elegiremos la opción atender pedido y asignaremos
cantidades negativas para observar como responde el sistema.
3.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “Toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos
de Pruebas para ver toda la especificación completa de los datos.
3.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
El técnico selecciona de la lista de pedidos no atendidos el
pedido de código ‘1’ y pulsa el botón ‘Atender Pedido’.
Selecciona la línea de pedido del articulo ‘2’ haciendo doble clic.
Aparece la interfaz que nos permite modificar la cantidad
asignada, se actualizan automáticamente los datos código y
nombre del artículo.
Introduce la cantidad ‘-2’.
Pulsa el botón ‘Asignar Cantidad’.
3.4. Resultado esperado
El sistema nos muestra un mensaje de error advirtiéndonos de que
no es posible introducir cantidades negativas.
3.5. Evaluación de la Prueba
Prueba superada con éxito.
4. Atender pedido asignando cantidades mayores a las disponibles
4.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos no
atendidos, el sistema nos mostrara una lista con los pedidos no
atendidos que haya almacenados en el sistema. Seleccionaremos
un pedido, elegiremos la opción atender pedido y asignaremos
cantidades mayores al stock disponible para observar como
responde el sistema.
4.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “Toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos
de Pruebas para ver toda la especificación completa de los datos.
4.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
El técnico selecciona de la lista de pedidos no atendidos el pedido
de código ‘1’ y pulsa el botón ‘Atender Pedido’.
Selecciona la línea de pedido del articulo ‘3’ haciendo doble clic.
Aparece la interfaz que nos permite modificar la cantidad
asignada, se actualizan automáticamente los datos código y
nombre del artículo.
Introduce la cantidad ‘2’.
Pulsa el botón ‘Asignar Cantidad’.
4.4. Resultado esperado
El sistema nos muestra un mensaje de error advirtiéndonos de que
no hay stock disponible para poder asignar esa cantidad .
4.5. Evaluación de la Prueba
Prueba superada con éxito.
5. Atender pedido asignando cantidades mayores a las solicitadas
5.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos no
atendidos, el sistema nos mostrara una lista con los pedidos no
atendidos que haya almacenados en el sistema. Seleccionaremos
un pedido, elegiremos la opción atender pedido y asignaremos
cantidades mayores a las solicitadas para observar como responde
el sistema.
5.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “Toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos
de Pruebas para ver toda la especificación completa de los datos.
5.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
El técnico selecciona de la lista de pedidos no atendidos el pedido de
código ‘1’ y pulsa el botón ‘Atender Pedido’.
Selecciona la línea de pedido del articulo ‘2’ haciendo doble clic.
Aparece la interfaz que nos permite modificar la cantidad
asignada, se actualizan automáticamente los datos código y
nombre del artículo.
Introduce la cantidad ‘2’.
Pulsa el botón ‘Asignar Cantidad’.
5.4. Resultado esperado
El sistema nos muestra un mensaje de error advirtiéndonos de que
la cantidad introducida es superior a la cantidad solicitada.
5.5. Evaluación de la Prueba
Prueba superada con éxito.
6. Atender pedido sin asignar cantidades
6.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos no
atendidos, el sistema nos mostrara una lista con los pedidos no
atendidos que haya almacenados en el sistema. Seleccionaremos
un pedido, elegiremos la opción atender pedido y no realizaremos
ninguna modificación.
6.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “Toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos
de Pruebas para ver toda la especificación completa de los datos.
6.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
El técnico selecciona de la lista de pedidos no atendidos el pedido
de código ‘1’ y pulsa el botón ‘Atender Pedido’.
Sin hacer ninguna modificación el técnico pulsa el botón
‘Guardar’.
6.4. Resultado esperado
El pedido no se modificada por esta acción y continua estando en
estado no atendido.
6.5. Evaluación de la Prueba
Prueba superada con éxito.
C. Cancelar Pedido Atendido
Descripción
Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de
Uso “Cancelar Pedido Atendido”.
Realizaremos únicamente dos pruebas que consistirán en la elección de
cada una de las opciones de confirmación de la cancelación del pedido.
El entorno del cual partiremos para realizar la prueba será el formulario de
entrada de la aplicación.
1. Elegir opción CANCELAR en la confirmación de la cancelación de
pedido
1.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos en
atención, el sistema nos mostrara una lista con los pedidos en
atención que haya almacenados en el sistema. Elegiremos el pedido
que el cliente nos solicite y cancelaremos dicho pedido respondiendo
a la confirmación negativamente.
1.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “Toni” está dado de alta en la base de datos de
empleado y su clave correspondiente y que el cliente Jaime con DNI
48315682-N también figure en la base de datos. Consultar la Base
de Datos de Pruebas para ver toda la especificación completa de los
datos.
1.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
El cliente ‘Jaime’ con DNI ‘48315682N’ contacta con el técnico de
almacén y solicita la cancelación del pedido en atención con
código ‘5’.
El técnico de almacén selecciona de la lista de pedidos en
atención el pedido en cuestión y pulsa el botón ‘Cancelar Pedido’.
Nos aparece un mensaje de confirmación de la cancelación del
pedido.
El cliente decide finalmente no cancelar el pedido.
El técnico pulsa el botón ‘Cancelar’.
1.4. Resultado esperado
El pedido seleccionado sigue almacenado en el sistema sin ninguna
modificación.
1.5. Evaluación de la Prueba
Prueba superada con éxito.
2. Elegir opción ACEPTAR en la confirmación de la cancelación de
pedido
2.1. Descripción
Nos introducimos en el sistema como técnico de almacén, accediendo
a su funcionalidad y solicitamos consultar pedidos en atención, el
sistema nos mostrara una lista con los pedidos en atención que haya
almacenados en el sistema. Elegiremos el pedido que el cliente nos
solicite y cancelaremos dicho pedido respondiendo a la confirmación
afirmativamente.
2.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “Toni” está dado de alta en la base de datos de
empleado y su clave correspondiente y que el cliente Jaime con DNI
48315682-N también figure en la base de datos. Consultar la Base de
Datos de Pruebas para ver toda la especificación completa de los
datos.
2.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
El cliente ‘Jaime’ con DNI ‘48315682N’ contacta con el técnico de
almacén y solicita la cancelación del pedido en atención con
código ‘5’.
El técnico de almacén selecciona de la lista de pedidos en
atención el pedido en cuestión y pulsa el botón ‘Cancelar Pedido’.
Nos aparece un mensaje de confirmación de la cancelación del
pedido.
El cliente decide finalmente cancelar el pedido.
El técnico pulsa el botón ‘Aceptar’ .
2.4. Resultado esperado
El pedido es eliminado del sistema y se libera el stock asociado a las
líneas de pedido pasando de nuevo al stock disponible.
2.5. Evaluación de la Prueba
Prueba superada con éxito.
D. Incidencia de Pedido
Descripción
Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de
Uso “Incidencia Pedido”.
La pruebas realizadas a este caso de uso son:
Crear una incidencia normal en Almacén.
Crear una incidencia vacía en Almacén.
Consultar incidencias en Almacén.
Crear una incidencia normal en Ventas.
Crear una incidencia vacía en Ventas.
Consultar incidencias en Ventas.
El entorno del cual partiremos para realizar la prueba será el formulario de
entrada de la aplicación
1. Crear una incidencia normal en Almacén
1.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad. Ante cualquier incidencia que nos
ocurra mientras estemos atendiendo un pedido, tendremos la
oportunidad de crear un parte de incidencia que dejara reflejado en el
sistema cualquier problema que nos haya surgido durante la atención
de ese pedido.
1.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos de
Pruebas para ver toda la especificación completa de los datos.
1.3. Entrada
Introducimos ‘toni’ en el campo usuario.
Introducimos ‘puma’ en el campo contraseña.
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
Seleccionamos de la lista de pedidos no atendidos el pedido de
código ‘1’.
Pulsamos el botón ‘Atender Pedido’.
Nos aparece la interfaz para atender un pedido.
Pulsamos el botón ‘Incidencia’.
Nos aparece la interfaz de nueva incidencia.
Introducimos un comentario y pulsamos ‘Guardar’.
Pulsamos ‘Guardar’ o ‘Salir’ en la interfaz atender pedido.
1.4. Resultado esperado
La incidencia se almacena en el sistema.
1.5. Evaluación de la Prueba
Prueba superada con éxito.
2. Crear una incidencia vacía en Almacén
2.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad. Ante cualquier incidencia que nos
ocurra mientras estemos atendiendo un pedido, tendremos la
oportunidad de crear un parte de incidencia que dejara reflejado en el
sistema cualquier problema que nos haya surgido durante la atención
de ese pedido. En este caso, probaremos a crear una incidencia
vacía para ver como responde el sistema.
2.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos de
Pruebas para ver toda la especificación completa de los datos.
2.3. Entrada
Introducimos ‘toni’ en el campo usuario.
Introducimos ‘puma’ en el campo contraseña.
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
Seleccionamos de la lista de pedidos no atendidos el pedido de
código ‘1’.
Pulsamos el botón ‘Atender Pedido’.
Nos aparece la interfaz para atender un pedido.
Pulsamos el botón ‘Incidencia’.
Nos aparece la interfaz de nueva incidencia.
Pulsamos ‘Guardar’ sin haber introducido ningún comentario.
2.4. Resultado esperado
El sistema nos muestra un mensaje de error que nos indica que el
campo observaciones no puede ser vacío.
2.5. Evaluación de la Prueba
Prueba superada con éxito.
3. Consultar incidencias en Almacén
3.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad. Ante cualquier incidencia que nos
ocurra mientras estemos atendiendo un pedido, tendremos la
oportunidad de crear un parte de incidencia que dejara reflejado en el
sistema cualquier problema que nos haya surgido durante la atención
de ese pedido. En este caso, consultaremos la lista de incidencias
almacenadas en el sistema.
3.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos de
Pruebas para ver toda la especificación completa de los datos.
3.3. Entrada
Introducimos ‘toni’ en el campo usuario.
Introducimos ‘puma’ en el campo contraseña.
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
Seleccionamos de la lista de pedidos no atendidos el pedido de
código ‘1’.
Pulsamos el botón ‘Atender Pedido’.
Nos aparece la interfaz para atender un pedido.
Pulsamos el botón ‘Incidencia’.
Nos aparece la interfaz de nueva incidencia.
Pulsamos ‘Consultar Incidencias’.
3.4. Resultado esperado
El sistema nos muestra una nueva interfaz donde se listan todas las
incidencias almacenadas.
3.5. Evaluación de la Prueba
Prueba superada con éxito.
4. Crear una incidencia normal en Ventas
4.1. Descripción
Nos introducimos en el sistema como operadora, accediendo a su
funcionalidad. Ante cualquier incidencia que nos ocurra mientras
estemos elaborando un pedido, tendremos la oportunidad de crear
un parte de incidencia que dejara reflejado en el sistema cualquier
problema que nos haya surgido durante la elaboración de ese
pedido.
4.2. Condiciones de Ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
operadora “maria” está dado de alta en la base de datos de
empleado y su clave correspondiente y que el cliente Jaime con DNI
48315682-N también figure en la base de datos. Consultar la Base
de Datos de Pruebas para ver toda la especificación completa de los
datos.
4.3. Entrada
Introducimos ‘maria’ en el campo usuario
Introducimos ‘nike’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un operador.
El cliente ‘Jaime’ con código ‘1’ llama a la operadora.
La operadora introduce el código del cliente apareciendo en el
formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita hacer modificaciones al pedido ‘4’.
La operadora selecciona el pedido en cuestión y pulsa el botón
“modificar”, aparece la interfaz de modificar pedido.
La operadora observa que hay anomalías y procede a la creación
de una incidencia.
Pulsamos el botón ‘Incidencia’.
Nos aparece la interfaz de nueva incidencia.
Introducimos un comentario y pulsamos ‘Guardar’.
Pulsamos ‘Guardar’ o ‘Salir’ en la interfaz modificar pedido.
4.4. Resultado Esperado
La incidencia se almacena en el sistema.
4.5. Evaluación
Prueba superada con éxito.
5. Crear una incidencia vacía en Ventas
5.1. Descripción
Nos introducimos en el sistema como operadora, accediendo a su
funcionalidad. Ante cualquier incidencia que nos ocurra mientras
estemos elaborando un pedido, tendremos la oportunidad de crear
un parte de incidencia que dejara reflejado en el sistema cualquier
problema que nos haya surgido durante la elaboración de ese
pedido. En este caso, probaremos a crear una incidencia vacía para
ver como responde el sistema.
5.2. Condiciones de Ejecución
as condiciones de ejecución del caso de prueba son que el usuario
operadora “maria” está dado de alta en la base de datos de
empleado y su clave correspondiente y que el cliente Jaime con DNI
48315682-N también figure en la base de datos. Consultar la Base de
Datos de Pruebas para ver toda la especificación completa de los
datos.
5.3. Entrada
Introducimos ‘maria’ en el campo usuario
Introducimos ‘nike’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un operador.
El cliente ‘Jaime’ con código ‘1’ llama a la operadora.
La operadora introduce el código del cliente apareciendo en el
formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita hacer modificaciones al pedido ‘4’.
La operadora selecciona el pedido en cuestión y pulsa el botón
“modificar”, aparece la interfaz de modificar pedido.
La operadora observa que hay anomalías y procede a la creación
de una incidencia.
Pulsamos el botón ‘Incidencia’.
Nos aparece la interfaz de nueva incidencia.
Pulsamos ‘Guardar’ sin haber introducido ningún comentario.
5.4. Resultado Esperado
El sistema nos muestra un mensaje de error que nos indica que el
campo observaciones no puede ser vacío.
5.5. Evaluación
Prueba superada con éxito.
6. Consultar incidencias en Ventas
6.1. Descripción
Nos introducimos en el sistema como operadora, accediendo a su
funcionalidad. Ante cualquier incidencia que nos ocurra mientras
estemos elaborando un pedido, tendremos la oportunidad de crear un
parte de incidencia que dejara reflejado en el sistema cualquier
problema que nos haya surgido durante la elaboración de ese
pedido. En este caso, consultaremos la lista de incidencias
almacenadas en el sistema.
6.2. Condiciones de Ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
operadora “maria” está dado de alta en la base de datos de
empleado y su clave correspondiente y que el cliente Jaime con DNI
48315682-N también figure en la base de datos. Consultar la Base de
Datos de Pruebas para ver toda la especificación completa de los
datos.
6.3. Entrada
Introducimos ‘maria’ en el campo usuario
Introducimos ‘nike’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un operador.
El cliente ‘Jaime’ con código ‘1’ llama a la operadora.
La operadora introduce el código del cliente apareciendo en el
formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita hacer modificaciones al pedido ‘
La operadora selecciona el pedido en cuestión y pulsa el botón
“modificar”, aparece la interfaz de modificar pedido.
La operadora consulta las incidencias por si el pedido en cuestión
tubo alguna.
Pulsamos el botón ‘Incidencia’.
Nos aparece la interfaz de nueva incidencia.
Pulsamos ‘Consultar Incidencias’.
6.4. Resultado Esperado
El sistema nos muestra una nueva interfaz donde se listan todas las
incidencias almacenadas.
6.5. Evaluación
Prueba superada con éxito.
E. Caso de Pruebas de Pasar Pedido a Envío
Descripción
Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso
“Pasar Pedido a Envío”.
La pruebas realizadas a este caso de uso son:
Pasar pedido a envío desde la lista de pedidos en atención.
Pasar pedido a envío desde atender pedido.
Cancelar al pasar un pedido incompleto a envío.
Pasar a envío un pedido incompleto generando un pedido con las
cantidades restantes.
Pasar a envío un pedido incompleto sin generar un pedido con las
cantidades restantes.
El entorno del cual partiremos para realizar la prueba será el formulario
de entrada de la aplicación
1. Pasar pedido completo a envío desde la lista de pedidos en atención
1.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos en
atención, el sistema nos mostrara una lista con los pedidos en
atención que haya almacenados en el sistema. Seleccionaremos un
pedido y lo pasaremos a envío.
1.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “Toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos de
Pruebas para ver toda la especificación completa de los datos.
1.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
Seleccionamos de la lista de pedidos en atención el pedido de
código ‘3’.
Pulsamos el botón ‘Pasar a listo para envío’.
1.4. Resultado esperado
El pedido queda almacenado en el sistema como listo para envío.
1.5. Evaluación de la Prueba
Prueba superada con éxito.
2. Pasar pedido completo a envío desde atender pedido
2.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos en
atención, el sistema nos mostrara una lista con los pedidos en
atención que haya almacenados en el sistema. Seleccionaremos un
pedido y después de comprobar desde la opción atender pedido que
tiene todas las cantidades asignadas lo pasaremos a envío.
2.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “Toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos de
Pruebas para ver toda la especificación completa de los datos.
2.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
El técnico selecciona de la lista de pedidos en atención el pedido
de código ‘6’ y pulsa el botón ‘Atender Pedido’.
Una vez comprobado que tiene todas las cantidades asignadas
pulsa el botón ‘Pasar a Envíos’.
2.4. Resultado esperado
El pedido queda almacenado en el sistema como listo para envío.
2.5. Evaluación de la Prueba
Prueba superada con éxito.
3. Cancelar al pasar un pedido incompleto a envío
3.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos en
atención, el sistema nos mostrara una lista con los pedidos en
atención que haya almacenados en el sistema. Seleccionaremos un
pedido incompleto y lo pasaremos a envío, cancelando seguidamente
dicha decisión.
3.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “Toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos de
Pruebas para ver toda la especificación completa de los datos.
3.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
Seleccionamos de la lista de pedidos en atención el pedido de
código ‘7’.
Pulsamos el botón ‘Pasar a listo para envío’.
Nos aparece un mensaje de confirmación que nos indica que el
pedido esta incompleto.
Elegimos la opción ‘Cancelar’.
3.4. Resultado esperado
El pedido no se modifica por dicha acción y sigue almacenado en el
sistema con estado en atención.
3.5. Evaluación de la Prueba
Prueba superada con éxito.
4. Pasar a envío un pedido incompleto generando un pedido con las
cantidades restantes
4.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos en
atención, el sistema nos mostrara una lista con los pedidos en
atención que haya almacenados en el sistema. Seleccionaremos un
pedido incompleto y lo pasaremos a envío, responderemos
afirmativamente a la confirmación de paso de envío y responderemos
afirmativamente a la creación de un pedido con las cantidades
restantes.
4.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “Toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos de
Pruebas para ver toda la especificación completa de los datos.
4.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
Seleccionamos de la lista de pedidos en atención el pedido de
código ‘7’.
Pulsamos el botón ‘Pasar a listo para envío’.
Nos aparece un mensaje de confirmación que nos indica que el
pedido esta incompleto.
Elegimos la opción ‘Aceptar’.
Nos aparece un mensaje de confirmación sobre la creación de un
pedido con las cantidades restantes.
Elegimos la opción ‘Aceptar’.
4.4. Resultado esperado
El pedido se almacena en el sistema con estado listo para envío y se
almacena un nuevo pedido en el sistema con las cantidades que
restaron del anterior con estado en elaboración.
4.5. Evaluación de la Prueba
Prueba superada con éxito.
5. Pasar a envío un pedido incompleto sin generar un pedido con las
cantidades restantes
5.1. Descripción
Nos introducimos en el sistema como técnico de almacén,
accediendo a su funcionalidad y solicitamos consultar pedidos en
atención, el sistema nos mostrara una lista con los pedidos en
atención que haya almacenados en el sistema. Seleccionaremos un
pedido incompleto y lo pasaremos a envío, responderemos
afirmativamente a la confirmación de paso de envío y responderemos
negativamente a la creación de un pedido con las cantidades
restantes.
5.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
técnico de almacén “Toni” está dado de alta en la base de datos de
empleado y su clave correspondiente. Consultar la Base de Datos de
Pruebas para ver toda la especificación completa de los datos.
5.3. Entrada
Introducimos ‘toni’ en el campo usuario
Introducimos ‘puma’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un técnico de almacén.
Seleccionamos de la lista de pedidos en atención el pedido de
código ‘8’.
Pulsamos el botón ‘Pasar a listo para envío’.
Nos aparece un mensaje de confirmación que nos indica que el
pedido esta incompleto.
Elegimos la opción ‘Aceptar’.
Nos aparece un mensaje de confirmación sobre la creación de un
pedido con las cantidades restantes.
Elegimos la opción ‘Cancelar’
5.4. Resultado esperado
El pedido se almacena en el sistema con estado listo para envío.
5.5. Evaluación de la Prueba
Prueba superada con éxito.
GESTION DE VENTAS
A. Caso de Pruebas de Elaborar Pedido
I. Descripción
Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de
Uso “Elaborar Pedido”.
La pruebas realizadas a este caso de uso son:
Elaborar pedido y enviar a almacén.
Elaborar pedido y guardar.
Elaborar pedido vacío y guardar.
Elaborar pedido vacío y enviar al almacén.
Modificar pedido resultando dos líneas con el mismo producto.
Modificar pedido añadiendo una línea de cantidad fuera de rango.
Modificar pedido añadiendo un producto inexistente.
Modificar pedido, añadiendo / eliminando una línea de pedido, y enviar
a almacén.
Modificar pedido, añadiendo / eliminando una línea de pedido, y guardar.
Modificar dirección de correo del pedido.
Modificar pedido eliminando todas sus líneas.
Eliminar pedido.
El entorno del cual partiremos para realizar la prueba será el formulario de
entrada de la aplicación.
1. Elaborar pedido y enviar a almacén
1.1. Descripción
Nos introducimos en el sistema como empleado, accediendo a su
funcionalidad y solicitamos elaborar un pedido, el sistema nos
mostrara una interfaz para que llevemos a cabo la elaboración de
dicho pedido. Una vez elaborado escogeremos la opción enviar a
almacén.
1.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
operadora “maria” está dado de alta en la base de datos de
empleado y su clave correspondiente y que el cliente Jaime con DNI
48315682-N también figure en la base de datos. Consultar la Base
de Datos de Pruebas para ver toda la especificación completa de los
datos.
1.3. Entrada
Introducimos ‘maria’ en el campo usuario
Introducimos ‘nike’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de una operadora.
El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operadora.
La operadora introduce el DNI del cliente apareciendo en el
formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita hacer un nuevo pedido.
La operadora pulsa nuevo y aparece el formulario de nuevo
pedido
El cliente solicita comprar un par de raquetas.
La operadora introduce una línea de pedido:
o Introduce ‘ 4’ en código artículo
o Se rellenan automáticamente los campos nombre y precio.
o Introduce ‘2’ en cantidad
o Pulsa el botón “añadir línea”
o Se actualiza automáticamente el precio total
El cliente solicita a la operadora finalizar el pedido escogiendo la
opción pasar pedido a almacén
La operadora pulsa el botón “pasar a almacén”.
El pedido aparece en el listado de pedidos enviados al almacén.
1.4. Resultado esperado
El sistema almacena el nuevo pedido con estado “No atendido”.
1.5. Evaluación de la Prueba
Prueba superada con éxito
2. Elaborar pedido y guardar
2.1. Descripción
Nos introducimos en el sistema como empleado, accediendo a su
funcionalidad y solicitamos elaborar un pedido, el sistema nos
mostrara una interfaz para que llevemos a cabo la elaboración de
dicho pedido. Una vez elaborado escogeremos la opción guardar.
2.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
operadora “maria” está dado de alta en la base de datos de
empleado y su clave correspondiente y que el cliente Jaime con DNI
48315682-N también figure en la base de datos. Consultar la Base
de Datos de Pruebas para ver toda la especificación completa de los
datos.
2.3. Entrada
Introducimos ‘maria’ en el campo usuario
Introducimos ‘nike’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un operador.
El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operadora.
La operadora introduce el DNI del cliente apareciendo en el
formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita hacer un nuevo pedido.
La operadora pulsa el botón “nuevo”.
El sistema muestra la interfaz propia de la modificación de un
pedido.
El cliente solicita comprar un par de raquetas.
La operadora introduce una línea de pedido:
o Introduce ‘4’ en código artículo
o Se rellena automáticamente los campos nombre y precio.
o Introduce ‘2’ en cantidad
o Pulsa el botón “añadir línea”
o Se actualiza automáticamente el precio total
El cliente solicita a la operadora finalizar el pedido escogiendo la
opción guardar pedido.
La operadora pulsa el botón “guardar”.
2.4. Resultado esperado
El sistema almacena el nuevo pedido con estado “No atendido”.
2.5. Evaluación de la Prueba
Prueba superada con éxito
3. Elaborar pedido vacío y guardar
3.1. Descripción
Nos introducimos en el sistema como usuario representante de
ventas, accediendo a su funcionalidad y solicitamos elaborar un
pedido, el sistema nos mostrara una interfaz para que llevemos a
cabo la elaboración de dicho pedido. Una vez dentro intentaremos
guardar o enviar la orden sin haber añadido ninguna línea de pedido
para observar cómo responde el sistema.
3.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
representante de ventas “luis”, representante de ventas está dado de
alta en la base de datos de empleado y su clave correspondiente y
que el cliente Jaime con DNI 48315682-N también figure en la base
de datos. Consultar la Base de Datos de Pruebas para ver toda la
especificación completa de los datos.
3.3. Entrada
Introducimos ‘luis’ en el campo usuario
Introducimos ‘reebok’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un representante de ventas.
El cliente ‘Javier’ con DNI ‘22496359P’ contacta con el
representante de ventas.
El representante de ventas introduce el DNI del cliente
apareciendo en el formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita hacer un nuevo pedido.
El representante de ventas pulsa el botón “nuevo”.
El sistema muestra la interfaz propia de la elaborar un nuevo
pedido.
El representante de ventas pulsa el botón guardar.
3.4. Resultado esperado
El sistema muestra un mensaje de error avisando al cliente de que
no es posible almacenar en el sistema un pedido vacío.
3.5. Evaluación de la Prueba
Prueba superada con éxito
4. Elaborar pedido vacío y enviar al almacén
4.1. Descripción
Nos introducimos en el sistema como usuario representante de
ventas, accediendo a su funcionalidad y solicitamos elaborar un
pedido, el sistema nos mostrara una interfaz para que llevemos a
cabo la elaboración de dicho pedido. Una vez dentro intentaremos
guardar o enviar la orden sin haber añadido ninguna línea de pedido
para observar como responde el sistema.
4.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
representante de ventas “luis”, representante de ventas está dado de
alta en la base de datos de empleado y su clave correspondiente y
que el cliente Jaime con DNI 48315682-N también figure en la base
de datos. Consultar la Base de Datos de Pruebas para ver toda la
especificación completa de los datos.
4.3. Entrada
Introducimos ‘luis’ en el campo usuario
Introducimos ‘reebok’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un representante de ventas.
El cliente ‘Jaime’ con DNI ‘48315682N’ contacta con el
representante de ventas.
El representante de ventas introduce el DNI del cliente
apareciendo en el formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita hacer un nuevo pedido.
El representante de ventas pulsa el botón “nuevo”.
El sistema muestra la interfaz propia de la elaborar un nuevo
pedido.
El representante de ventas pulsa el botón enviar a almacén
4.4. Resultado esperado
El sistema muestra un mensaje de error avisando al cliente de que
no es posible almacenar en el sistema un pedido vacío.
4.5. Evaluación de la Prueba
Prueba superada con éxito
5. Modificar pedido resultando dos líneas con el mismo producto
5.1. Descripción
Nos introducimos en el sistema como usuario representante de
ventas, el sistema nos mostrara una interfaz para que llevemos a
cabo la elaboración de dicho pedido. Aparece una lista de pedidos
solicitados por el cliente que están en proceso de elaboración.
Seleccionaremos uno de ellos y lo editaremos para poder añadir una
línea de pedido asociada a un producto ya incluido en el pedido.
5.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
representante de ventas “luis”, representante de ventas está dado de
alta en la base de datos de empleado y su clave correspondiente y
que el cliente Jaime con DNI 48315682-N también figure en la base
de datos. Consultar la Base de Datos de Pruebas para ver toda la
especificación completa de los datos.
5.3. Entrada
Introducimos ‘luis’ en el campo usuario
Introducimos ‘reebok’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un representante de ventas.
El cliente ‘Javier’ con DNI ‘22496359P’ contacta con el
representante de ventas.
El representante de ventas introduce el DNI del cliente
apareciendo en el formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El representante de ventas selecciona el pedido con código “2” y
pulsa el botón “modificar”.
El sistema muestra la interfaz propia de la modificación de un
pedido.
El cliente solicita añadir un producto al pedido.
Introduce una nueva línea de pedido:
o Introduce ‘ 4’ en código artículo
o Se rellena automáticamente los campos nombre y precio.
o Introduce ‘1’ en cantidad
o Pulsa el botón “añadir línea”
5.4. Resultado esperado
El sistema nos muestra un mensaje de aviso informándonos de que
en ese pedido ya existe una línea asociada a ese código de artículo y
pregunta si desea sobrescribirla o cancelar.
5.5. Evaluación de la Prueba
Prueba superada con éxito
6. Modificar pedido añadiendo una línea de cantidad fuera de rango
6.1. Descripción
Nos introducimos en el sistema como usuario representante de
ventas, el sistema nos mostrara una interfaz para que llevemos a
cabo la elaboración de dicho pedido. Aparece una lista de pedidos
solicitados por el cliente que están en proceso de elaboración.
Seleccionaremos uno de ellos y lo editaremos para poder añadir una
línea de pedido, probaremos a introducir una cantidad de producto
que esté fuera del rango permitido, probaremos una inferior al
mínimo y otra superior al máximo.
6.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
representante de ventas “luis”, representante de ventas está dado de
alta en la base de datos de empleado y su clave correspondiente y
que el cliente Jaime con DNI 48315682-N también figure en la base
de datos. Consultar la Base de Datos de Pruebas para ver toda la
especificación completa de los datos.
6.3. Entrada
Introducimos ‘luis’ en el campo usuario
Introducimos ‘reebok’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un representante de ventas.
El cliente ‘Javier’ con DNI ‘22496359P’ contacta con el
representante de ventas.
El representante de ventas introduce el DNI del cliente
apareciendo en el formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El representante de ventas selecciona el pedido con código “2” y
pulsa el botón “modificar”.
El sistema muestra la interfaz propia de la modificación de un
pedido.
El cliente solicita añadir un producto al pedido.
Introduce una nueva línea de pedido:
o Introduce ‘3’ en código artículo
o Se rellena automáticamente los campos nombre y precio.
o Introduce ‘0’ en cantidad
o Introduce ‘10000’ en cantid
6.4. Resultado esperado
El sistema nos muestra para cada una de las cantidades introducidas
un mensaje de error indicándonos que estamos introduciendo una
cantidad errónea ya que está fuera del rango permitido.
6.5. Evaluación de la Prueba
Prueba superada con éxito.
7. Modificar un pedido añadiendo un producto inexistente
7.1. Descripción
Nos introducimos en el sistema como usuario representante de
ventas, el sistema nos mostrara una interfaz para que llevemos a
cabo la elaboración de dicho pedido. Aparece una lista de pedidos
solicitados por el cliente que están en proceso de elaboración.
Seleccionaremos uno de ellos y lo editaremos para poder añadir una
línea de pedido asociada a un producto ya incluido en el pedido y
añadir un producto inexistente.
7.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
representante de ventas “luis”, representante de ventas está dado de
alta en la base de datos de empleado y su clave correspondiente y
que el cliente Jaime con DNI 48315682-N también figure en la base
de datos. Consultar la Base de Datos de Pruebas para ver toda la
especificación completa de los datos.
7.3. Entrada
Introducimos ‘luis’ en el campo usuario
Introducimos ‘reebok’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un representante de ventas.
El cliente ‘Javier’ con DNI ‘22496359P’ contacta con el
representante de ventas.
El representante de ventas introduce el DNI del cliente
apareciendo en el formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El representante de ventas selecciona el pedido con código “2” y
pulsa el botón “modificar”.
El sistema muestra la interfaz propia de la modificación de un
pedido.
El cliente solicita añadir un producto al pedido.
Introduce una nueva línea de pedido:
o Introduce ‘7’ en código artículo
o Pulsa el botón “añadir línea”
7.4. Resultado esperado
El sistema nos muestra un mensaje de error informándonos de que el
artículo introducido no existe.
7.5. Evaluación de la Prueba
Prueba superada con éxito.
8. Modificar pedido añadiendo / eliminando una línea de pedido y enviar
a almacén
8.1. Descripción
Nos introducimos en el sistema como empleado, accediendo a su
funcionalidad y solicitamos elaborar un pedido, el sistema nos
mostrara una interfaz para que llevemos a cabo la elaboración de
dicho pedido, que consistirá en añadir una nueva línea de pedido y
eliminar una de las existentes de un pedido en elaboración. Una vez
elaborado escogeremos la opción enviar a almacén.
8.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
operadora “maria” está dado de alta en la base de datos de
empleado y su clave correspondiente y que el cliente Jaime con DNI
48315682-N también figure en la base de datos. Consultar la Base
de Datos de Pruebas para ver toda la especificación completa de los
datos.
8.3. Entrada
Introducimos ‘maria’ en el campo usuario
Introducimos ‘nike’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un operador.
El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operadora.
La operadora introduce el DNI del cliente apareciendo en el
formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita hacer modificaciones al pedido ‘1’.
La operadora selecciona el pedido en cuestión y pulsa el botón
modificar, aparece el formulario del pedido.
El cliente solicita añadir un par de raquetas al pedido.
La operadora introduce una línea de pedido:
o Introduce ‘ 4’ en código artículo
o Se rellena automáticamente los campos descripción y
precio.
o Introduce ‘2’ en cantidad
o Pulsa el botón “añadir línea”
o Se actualiza automáticamente el precio total
El cliente solicita eliminar el par de zapatillas incluidas en el
pedido.
La operadora elimina la línea de pedido correspondiente al
producto que se desea eliminar.
El cliente solicita a la operadora finalizar el pedido escogiendo la
opción enviar a almacén.
La operadora pulsa el botón enviar a almacén
8.4. Resultado esperado
El sistema almacena las nuevas modificaciones del pedido
seleccionado.
8.5. Evaluación de la Prueba
Prueba superada con éxito
9. Modificar pedido añadiendo / eliminando una línea de pedido y
guardar
9.1. Descripción
Nos introducimos en el sistema como empleado, accediendo a su
funcionalidad y solicitamos elaborar un pedido, el sistema nos
mostrara una interfaz para que llevemos a cabo la elaboración de
dicho pedido, que consistirá en añadir una nueva línea de pedido y
eliminar una existente de un pedido en elaboración. Una vez
elaborado escogeremos la opción enviar a almacén.
9.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
representante de ventas “luis”, representante de ventas está dado de
alta en la base de datos de empleado y su clave correspondiente y
que el cliente Jaime con DNI 48315682-N también figure en la base
de datos. Consultar la Base de Datos de Pruebas para ver toda la
especificación completa de los datos.
9.3. Entrada
Introducimos ‘luis’ en el campo usuario
Introducimos ‘reebok’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia del un representante de ventas.
El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operador.
El operador introduce el DNI del cliente apareciendo en el
formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita hacer modificaciones al pedido ‘4’.
El representante de ventas selecciona el pedido en cuestión y
pulsa el botón “modificar”, aparece la interfaz de modificar pedido.
El cliente solicita añadir un par de zapatillas al pedido.
El operador introduce una línea de pedido:
o Introduce ‘ 1’ en código artículo
o Se rellena automáticamente los campos nombre y precio.
o Introduce ‘1’ en cantidad
o Pulsa el botón “añadir línea”
o Se actualiza automáticamente el precio total
El cliente solicita eliminar el par de raquetas del pedido.
El representante de ventas elimina la línea de pedido
correspondiente al producto que se desea eliminar.
El cliente solicita al representante de ventas finalizar el pedido
escogiendo la opción guardar.
El operador pulsa el botón “guardar”.
9.4. Resultado esperado
El sistema almacena las nuevas modificaciones del pedido
seleccionado.
9.5. Evaluación de la Prueba
Prueba superada con éxito
10. .Modificar dirección de envío del pedido
10.1. Descripción
Nos introducimos en el sistema como empleado, accediendo a su
funcionalidad y solicitamos elaborar un pedido, el sistema nos
mostrara una interfaz para que llevemos a cabo la elaboración de
dicho pedido, que consistirá en modificar la dirección de envío de un
pedido en elaboración.
10.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
representante de ventas “luis”, representante de ventas está dado de
alta en la base de datos de empleado y su clave correspondiente y
que el cliente Jaime con DNI 48315682-N también figure en la base
de datos. Consultar la Base de Datos de Pruebas para ver toda la
especificación completa de los datos.
10.3. Entrada
Introducimos ‘luis’ en el campo usuario
Introducimos ‘reebok’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia del un representante de ventas.
El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operador.
El operador introduce el DNI del cliente apareciendo en el
formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita modificar la dirección de envío del pedido ‘4’.
El representante de ventas selecciona el pedido en cuestión y
pulsa el botón modificar, aparece el formulario de modificar
pedido.
El cliente da la nueva dirección de envío al operador.
El representante de ventas introduce la nueva dirección :
o Introduce ‘C/ Bailén’ en el campo Calle
o Introduce ‘2’ en el campo Nº
o Introduce ‘23’ en el campo Pta
El representante de ventas pulsa el botón guardar
10.4. Resultado esperado
El sistema modifica la dirección de envío del pedido seleccionado.
10.5. Evaluación de la Prueba
Prueba superada con éxito
11. Modificar pedido eliminando todas sus líneas
11.1. Descripción
Nos introducimos en el sistema como empleado, accediendo a su
funcionalidad y solicitamos elaborar un pedido, el sistema nos
mostrara una interfaz para que llevemos a cabo la elaboración de
dicho pedido, que consistirá en modificar la dirección de envío de
un pedido en elaboración.
11.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el
usuario operadora “luis” está dado de alta en la base de datos de
empleado y su clave correspondiente y que el cliente Jaime con
DNI 48315682-N también figure en la base de datos. Consultar la
Base de Datos de Pruebas para ver toda la especificación
completa de los datos.
11.3. Entrada
Introducimos ‘luis’ en el campo usuario
Introducimos ‘reebok’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un operador.
El cliente ‘Javier’ con DNI ‘22496359P’ llama a la operadora.
La operadora introduce el DNI del cliente apareciendo en el
formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
La operadora selecciona el pedido ‘2’ y pulsa el botón
“modificar” y aparece la interfaz de modificar pedido.
La operadora elimina las dos líneas de pedido que componen
el pedido, pulsando sucesivamente el botón “eliminar línea”.
11.4. Resultado esperado
El sistema muestra un mensaje de error que nos informa de que no
es posible eliminar todas las líneas de pedido de un cierto pedido.
11.5. Evaluación de la Prueba
Prueba superada con éxito
12. Eliminar pedido
12.1. Descripción
Nos introducimos en el sistema como empleado, accediendo a su
funcionalidad y solicitamos elaborar un pedido, el sistema nos
mostrara una interfaz para que llevemos a cabo la elaboración de
dicho pedido, que consistirá en eliminar un pedido.
12.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el usuario
operadora “maria” está dado de alta en la base de datos de
empleado y su clave correspondiente y que el cliente Jaime con DNI
48315682-N también figure en la base de datos. Consultar la Base
de Datos de Pruebas para ver toda la especificación completa de los
datos.
12.3. Entrada
Introducimos ‘maria’ en el campo usuario
Introducimos ‘nike’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un operador.
El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operadora.
La operadora introduce el DNI del cliente apareciendo en el
formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita eliminar el pedido ‘10’.
La operadora selecciona el pedido en cuestión y pulsa el botón
“cancelar pedido”.
El sistema muestra un mensaje de aviso de borrado y solicita la
confirmación. La operadora confirma la eliminación del pedido al
cliente pulsando el botón “aceptar”.
12.4. Resultado esperado
El pedido seleccionado es eliminado del sistema.
12.5. Evaluación de la Prueba
Prueba superada con éxito.
13. Comprobar ratio de pago del cliente
13.1. Descripción
Nos introducimos en el sistema como empleado, accediendo a su
funcionalidad y solicitamos elaborar un pedido, el sistema nos
mostrara una interfaz para que llevemos a cabo la elaboración de
dicho pedido, que consistirá en elegir una modalidad de pago que
no corresponde con el ratio de pago del cliente.
13.2. Condiciones de ejecución
Las condiciones de ejecución del caso de prueba son que el
usuario operadora “maria” está dado de alta en la base de datos de
empleado y su clave correspondiente y que el cliente Javier con
DNI 22496359-P también figure en la base de datos. Consultar la
Base de Datos de Pruebas para ver toda la especificación completa
de los datos.
13.3. Entrada
Introducimos ‘maria’ en el campo usuario
Introducimos ‘nike’ en el campo contraseña
Pulsamos entrar o el botón “aceptar” de la aplicación.
Nos aparece la interfaz propia de un operador.
El cliente ‘Javier’ con DNI ‘22496359-P’ llama a la operadora.
La operadora introduce el DNI del cliente apareciendo en el
formulario los datos completos del cliente.
Aparece una lista con los pedidos en elaboración que tiene el
cliente en el sistema y los que ya ha enviado al almacén.
El cliente solicita hacer un nuevo pedido.
La operadora pulsa el botón “nuevo”.
El sistema muestra la interfaz propia de la realización de un
pedido.
El cliente solicita comprar un par de sudaderas.
La operadora introduce una línea de pedido:
o Introduce ‘3’ en código artículo
o Se rellena automáticamente los campos nombre y precio.
o Introduce ‘2’ en cantidad
o Pulsa el botón “añadir línea”
o Se actualiza automáticamente el precio total
El cliente solicita a la operadora pago a crédito.
La operadora pincha en el desplegable forma de pago
13.4. Resultado esperado
No es posible escoger la opción a crédito porque el ratio del cliente solo
permite al contado.
13.5. Evaluación de la Prueba
Prueba superada con éxito
CONCLUSIONES Y RECOMENDACIONES
A. CONCLUSIONES
Al culminar el proyecto sobre el diseño e implementación de un sistema
informático para mejorar el proceso de ventas en la Empresa Comercial
de Artículos Deportivos se puede afirmar que los objetivos planteados al
inicio del desarrollo del proyecto fueron cumplidos de manera
satisfactoria.
El diseño modular que tiene el sistema facilita la administración
entendimiento del mismo haciendo más fácil la integración de otros
módulos o componentes para su crecimiento con ello también cabe
recalcar que el diseño multiplataforma que se integre fácilmente a
cualquier plataforma de hardware y software.
Como en toda empresa se hace necesario seguir los estándares de
desarrollo de sistemas los cuales ayudan a llevar de manera más
organizada la información; poder especificar los contenidos que se
necesitan visualizar en el sistema y lograr que los beneficiarios se acoplen
sin mayor dificultad en su manejo.
La presente tesis se basan en la revisión constante de los avances lo cual
resulta beneficioso para lograr el éxito, cabe recalcar que los
contratiempos encontrados en la ejecución de la investigación, se dieron a
múltiples inconvenientes que se han suscitado en la empresa, los mismos
que han sido reconocidos y remediados de manera justa y equitativa para
la satisfacción de la institución beneficiaria.
El uso de la metodología de desarrollo RUP, conjuntamente con el
lenguaje UML y el manejo de los conceptos de la programación
orientadas a objetos, propiciaron que el desarrollo del sistema sea
entendible, sostenible. Incremental.
B. RECOMENDACIONES
Se recomienda tener en cuenta el uso del software como alternativa de
desarrollo del sistema, para así beneficiamos de sus ventajas en cuanto a
conceptos de independencia, costo y facilidad de desarrollo e
implementación, puesto que las herramientas que provee el software libre
están muy maduras y capaz de satisfacer las necesidades del
desarrollador.
Para que el sistema crezca hasta un nivel gerencial y estratégico,
deberán tener en cuenta en proyectos de desarrollos de módulos de
gestión, que estos emitan reportes que sea capaz de hacer ver cómo va
el giro del negocio, tenencias y además ayude a tomar decisiones a nivel
estratégico.
Los requerimientos de hardware que se pide, según la sección técnica de
análisis de factibilidad y el diagrama de despliegue, son mínimos; pero se
recomienda que mientras más capacidad tenga el servidor mejor
performance tendrá el funcionamiento del sistema.
Realizar una continua actualización de información y preparación en el
manejo del Sistema, por parte de los usuarios pertenecientes a la
Empresa.
REFERENCIA BIBIOGRÁFICA
A. Bibliografía Física
1) ALVAREZ GENDIN, SABINO (2000). “TEORÍA Y PRÁCTICA DE LO
CONTENCIOSO DE PROCESOS DE VENTAS”. Editorial Bosch. Págs.
220. Barcelona-España
2) KENDALL KENNETH E(2007) “Informática de Sistemas” Última edición;
editorial ra-ma; Lima-Perú; uned.
3) MC CONNELL STEVE (1996). “DESARROLLO Y GESTIÓN DE
PROYECTOS INFORMÁTICOS “Gestión de Riesgo, editorial mc. Graw
Hill. 691 p primera edición, aravaca (Madrid). Isbn: 84-481-1229-6.
4) MICROSOFT SQL SERVER INTEGRATION SERVICES (2005) –
MICROSOFT press. "manual de programador visual Basic 6.0" editorial
mc. Graw-hill. 2005.
5) LLACCHUA GUTIERRES, Melquiades (2007)“Diseño de un Sistema de
Comercialización para el supermercado mini market tito’s”
6) BALLOU, R. (2004). “Logística administración de la cadena de
suministro”. Editorial. Pearson. México DF.
7) BOWERSOX, D. Y OTROS (2007). “Administración y Logística de la
Cadena de Suministro”. Editorial. Mc Graw-Hill Interamericano. México
DF.
8) SEBASTIÁN ANTONIO GUZMÁN SILVA (2008) “Diseño y Optimización
del Proceso de Gestión y Ejecución de la Venta Mayorista para una
Empresa Tipo Homeimprovement”.
9) VÁSQUEZ RÍOS, Danny (2008) “Análisis y Diseño de un Sistema
Informático para el Control de los Procesos de Comercialización de la
Empresa Grupo Selva S.A.C. de Tarapoto – Perú.”
B. Bibliografía Virtual
http://www.elprisma.com/apuntes/administracion_de_empresas/procesoadminis
trativo/
http://www.ra-ma.es/libros/SISTEMAS-INFORMATICOS-CFGS/32651/978-84-
9964-099-0
http://es.wikipedia.org/wiki/Visual_Basic
http://www.monografias.com-administracion.htm
.
http://www.itba.edu.ar/archivos/secciones/gomez_tesisprocesosventas.pdf
http://www.geoogle.com/organizacion/
elementosbasicosdelosprocesosdeventas/segunalgunosautores.htm
http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
http://www.monografias.com-procesosventas.htm
http://www-01.ibm.com/software/rational/uml/
http://www.mcgraw-hill.es/bcv/guide/capitulo/8448169204.pdf
http://www.taringa.net/posts/info/1442455/Tesis-Ingenieria-informatica.html
B. ANEXOS
PLANIFICACION DEL PROYECTO
Disciplinas / Artefactos generados o
modificados
durante la Fase de Inicio
Comienzo Aprobación
Modelado del Negocio
Modelo de Casos de Uso del Negocio y Modelo de
Objetos del Negocio
Semana
14/10/02 -
20/10/02
Semana
28/10/02 -
3/11/02
Requisitos
Glosario
Semana
14/10/02 -
20/10/02
Semana
28/10/02 -
3/11/02
Visión
Semana
21/10/02 -
27/10/02
Semana
28/10/02 -
3/11/02
Modelo de Casos de Uso
Semana
28/10/02 -
3/11/02
Siguiente fase
Especificación de Casos de Uso
Semana
28/10/02 -
3/11/02
Siguiente fase
Especificaciones Adicionales
Semana
28/10/02 -
3/11/02
Siguiente fase
Análisis / Diseño
Modelo de Análisis / Diseño
Semana
21/10/02 -
27/10/02
Siguiente fase
Modelo de Datos Semana Siguiente fase
21/10/02 -
27/10/02
Implementación
Prototipos de Interfaces de Usuario
Semana
28/10/02 -
3/11/02
Siguiente fase
Modelo de Implementación
Semana
28/10/02 -
3/11/02
Siguiente fase
Pruebas
Casos de Pruebas Funcionales
Semana
28/10/02 -
3/11/02
Siguiente fase
Despliegue
Modelo de Despliegue
Semana
28/10/02 -
3/10/02
Siguiente fase
Gestión de Cambios y ConfiguraciónDurante todo el
proyecto
Durante todo el
proyecto
Gestión del proyecto
Plan de Desarrollo del Software en su versión 1.0 y
planes de las Iteraciones
Semana
14/10/02 -
20/10/02
Semana
28/10/02 -
3/11/02
AmbienteDurante todo el
proyecto
Durante todo el
proyecto
Disciplinas / Artefactos generados o modificados
durante la Fase de ElaboraciónComienzo Aprobación
Modelado del Negocio
Modelo de Casos de Uso del Negocio y Modelo de Objetos
del Negocio
Semana 14/10/02 -
20/10/02Aprobado
Requisitos
GlosarioSemana 14/10/02 -
20/10/02Aprobado
VisiónSemana 21/10/02 -
27/10/02Aprobado
Modelo de Casos de UsoSemana 28/10/02 -
3/11/02
Semana 11/12/02 -
17/12/02
Especificación de Casos de UsoSemana 28/10/02 -
3/11/02
Semana 11/12/02 -
17/12/02
Especificaciones AdicionalesSemana 28/10/02 -
3/11/02
Semana 11/12/02 -
17/12/02
Análisis / Diseño
Modelo de Análisis / DiseñoSemana 21/10/02 -
27/10/02
Revisar en cada
iteración
Modelo de DatosSemana 21/10/02 -
27/10/02
Revisar en cada
iteración
Implementación
Prototipos de Interfaces de UsuarioSemana 28/10/02 -
3/11/02
Revisar en cada
iteración
Modelo de ImplementaciónSemana 28/10/02 -
3/11/02
Revisar en cada
iteración
Pruebas
Casos de Pruebas FuncionalesSemana 28/10/02 -
3/11/02
Revisar en cada
iteración
Despliegue
Modelo de DespliegueSemana 28/10/02 -
3/10/02
Revisar en cada
iteración
Gestión de Cambios y ConfiguraciónDurante todo el
proyecto
Durante todo el
proyecto
Gestión del proyecto
Plan de Desarrollo del Software en su versión 2.0 y planes de
las Iteraciones
Semana 14/10/02 -
20/10/02
Revisar en cada
iteración
AmbienteDurante todo el
proyecto
Durante todo el
proyecto
Disciplinas / Artefactos generados o modificados durante la Fase de Construcción (Iteración 2)
Comienzo Aprobación
Casos de Uso negociados para la Primera Release
Elaborar Pedido (Gestión de Ventas)19/11/2002 Aprobado
Disciplinas / Artefactos generados o modificados durante la Fase de Construcción (Iteración 1)
Comienzo Aprobación
Casos de Uso negociados para la Primera Release
Elaborar Pedido (Gestión de Ventas)19/11/2002 12/12/2002
Consultar Pedidos no Atendidos (Gestión de Almacén)23/11/2002 12/12/2002
Consultar Pedidos no Atendidos (Gestión de Almacén)23/11/2002 Aprobado
Casos de Uso negociados para la Segunda Release
Atender Pedido (Gestión de Almacén)13/01/2003 17/01/2003
Cancelar Pedido Atendido (Gestión de Almacén)16/12/2002 17/01/2003
Pasar Pedido a Envío (Gestión de Almacén)13/01/2003 17/01/2003
Incidencia de Pedidos (Gestión de Almacén y Ventas)13/01/2003 17/01/2003
Diario de Ejecución
Día
Actividad desarrollada
Dedicación estimada (en horas
de trabajo)
03/09/2002 Reunión de los miembros del grupo. Puesta en marcha del proyecto. Organización del equipo.
3,5
07/10/2002 Reunión con el Stakeholder de la empresa cliente. Descripción general del sistema. Captura inicial de requisitos.
1
10/10/2002 Reunión con dos de los integrantes del grupo no asistentes a la anterior reunión. Explicación de la presentación del proyecto.
4
14/10/2002Elaboración del primer documento con la captura de requisitos inicial para exponer al resto del grupo. 1
17/10/2002Reunión del grupo de trabajo. Aclaración de los requisitos iniciales del sistema. 3
18/10/2002Segunda reunión con el Stakeholder para la aclaración de dudas anteriores, y para el inicio del documento Visión y Plan de Desarrollo Software.
1
21/10/2002 Reunión del Jefe Proyecto y Arquitecto de Software para la planificación de tareas. Comienzo de la fase de Análisis.
3,5
22/10/2002Reunión del Jefe de Proyecto, Arquitecto de Software y dos Programadores para identificar subsistemas, actores y algunos casos de uso generales. Primeros esbozos en Rational Rose.
3
23/10/2002Tercera reunión con el Stakeholder. Aclaración de las características del sistema y sus atributos. Definición de los perfiles de usuario.
1,5
24/10/2002Presentación de la versión 1.0 del documento Visión. Cuarta reunión con el Stakeholder. Casos de uso generales y glosario encaminados. Algunos posibles casos de prueba.
3
29/10/2002 Realización del documento Visión versión 1.0 completa. 3
31/10/2002 Presentación del artefacto Plan de Desarrollo Software y del Modelo de Casos de Uso del Negocio y de Objetos del Negocio.
1
01/11/2002 Generación del Diagrama de Clases. 3
04/11/2002Creación de las Plantillas de Especificación de Casos de Uso y revisión de otros artefactos. 5,5
05/11/2002Reunión del todo el equipo para revisar cada artefacto y asegurar que todos los miembros del grupo están al tanto del proyecto, y de la labor de cada uno.
2,5
06/11/2002 Realización de la Especificación de los Casos de Uso. 7,5
07/11/2002Preparación de las especificaciones de algunos casos de uso, a falta de corroborar con el usuario. Búsqueda de más información con la herramienta Rational Rose.
2
07/11/2002 Quinta reunión con el Stakeholder de la empresa para aprobar el modelo de casos de uso del negocio, el modelo de objetos del
1,5
negocio, y revisar los casos de uso y el modelo de datos.
10/11/2002Elaboración casos de uso y estudio de ejemplos de Casos de Prueba por parte del Tester. Elaboración de la documentación con Requisite Pro.
7,5
11/11/2002 Elaboración de plantillas de casos de uso, cada uno de los miembros del grupo tiene asignadas una o dos plantillas.
7
12/11/2002 Realización de la primera versión del modelo de la Base de Datos, Especificación Casos de Uso y Diagrama de Clases
7,5
13/11/2002
Sexta reunión con el Stakeholder, revisión de las plantillas de los casos de uso negociados para la primera release: Elaborar Pedido y Consultar Pedidos no Atendidos. Elaboración de los Prototipos de Interfaces y Casos de Prueba asociados a los mismos.
9,5
14/11/2002
Aprobación de la Arquitectura del Software. Entrega de prototipos de interfaces gráficas y modelos de casos de pruebas. Se ratifican los casos de uso que se incorporarán en la 1ª release. Presentación del modelo Rational Rose (diagrama de casos de uso, especificación de casos de uso, modelo de negocio, diagrama de clases), del modelo de la base de datos, de los casos de prueba y de las interfaces gráficas. Refinamiento del modelo de la base de datos, con lo que obtenemos la segunda versión del mismo.
7
16/11/2002Mejora de las Interfaces Gráficas, también revisión de las plantillas de las especificaciones de Casos de Uso de Elaborar Pedido y Consultar Pedidos no Atendidos y los Casos de Pruebas asociados.
6
17/11/2002 Elaboración nuevos Casos de Prueba detectados. 1,5
18/11/2002Séptima reunión con el Stakeholder. Revisión de las interfaces de los casos de uso incorporados en la 1ª release y de los casos de pruebas.
1,5
19/11/2002
Elaboración informe reunión. Integración del modelo de la base de datos en el sistema de gestión de bases de datos Oracle. Realización de la segunda versión de las interfaces gráficas, de acuerdo con los requerimientos del cliente.
3
20/11/2002 Comienzo de la elaboración de la documentación y requisitos con el RequisitePro. Revisión Casos de Uso.
9,5
21/11/2002
Octava reunión con el Stakeholder. Revisión del Visión y del Plan de Desarrollo Software. Continuación del desarrollo del proyecto y documentación en RequisitePro. Elaboración de nuevos Casos de Prueba.
9
21/11/2002Inicio de la implementación del primer frame de la aplicación, correspondiente a la identificación de los usuarios. Conexión a la Base de Datos.
6,5
23/11/2002 Elaboración de Casos de Prueba. Elaboración de la documentación con Requisite Pro.
5,5
24/11/2002 Elaboración de Casos de Prueba. 3
25/11/2002Reunión de equipo para revisión de las tareas asignadas. Elaboración de la documentación con Requisite Pro. 5
25/11/2002 Novena reunión con el Stakeholder para la revisión de Interfaces Gráficas y Modelo de Pruebas.
1,5
25/11/2002Revisión del modelo en Rational Rose en el RequisitePro y los módulos de programación para que todo sea consistente. 3
25/11/2002Finaliza la implementación del primer frame. Se inicia la implementación del frame correspondiente a “Elaborar Pedido” por parte de un representante.
4,5
26/11/2002 Elaboración de la documentación con Requisite Pro. 5
26/11/2002Creación Modelo de Objetos del Negocio, Diagrama de Despliegue y Diagrama de Componentes. Reunión con los Implementadores. Elaboración de Casos de Prueba por parte del Tester.
8,5
26/11/2002Elaboración de la documentación con Requisite Pro. Avanza la implementación del frame “Elaborar Pedido”. 7,5
27/11/2002Décima reunión con el Stakeholder para resolver dudas puntuales y algunos detalles. Reunión posterior del grupo para aclarar esfuerzos individuales.
2,5
28/11/2002 Elaboración de Casos de Prueba de la 2ª Release. 1
30/11/2002 Modificación Base de Datos de pruebas. 2
02/12/2002Reunión del grupo para aclarar la dinámica de trabajo, esfuerzos individuales y planificar nuevas tareas. Continúa la implementación y depuración de “Elaborar pedido”.
7,5
03/12/2002Ajustes del Modelo de Rational Rose y depuración de “Elaborar pedido”. Elaboración de la documentación con Requisite Pro. 8,5
05/12/2002 Modificación Base de Datos de pruebas y continuación de la depuración de "Elaborar Pedido".
5,5
09/12/2002Reunión del grupo. Realización Pruebas diseñadas por el Tester y otras pruebas funcionales no documentadas. Depuración del código generado.
9
10/12/2002 Creación de nuevos Diagramas y Casos de Uso. Continúa la realización de Pruebas.
6
11/12/2002Modificación Base de Datos de pruebas, revisión de las pruebas realizadas. Realización de Pruebas por parte del Usuario. 4,5
12/12/2002 Exposición de la 1ª Release 0,5
14/12/2002 Estudio de nuevos Prototipos de Interfaces Gráficas. Elaboración de la documentación con Requisite Pro.
2
16/12/2002 Reunión con el Stakeholder de la empresa cliente. Revisión de Prototipos y Casos de Prueba asociados.
5,5
17/12/2002 Creación de nuevos Diagramas y estudio Caso de Pruebas. 6
19/12/2002 Reunión del grupo para aclarar la dinámica de trabajo, esfuerzos individuales y objetivos comunes.
2
19/12/2002 Reunión con el cliente con el fin de negociar los casos de uso que se implementarán para la 2ª Release.
1,5
21/12/2002 Implementación de los Casos de Uso pactados. Realización casos prueba 2ª Release.
7,5
22/12/2002 Creación de nuevos Casos de Uso. Implementación del caso de uso “Pasar a listo para envío”.
7,5
23/12/2002 Implementación de los Casos de Uso pactados para la 2ª Release. 7,5
26/12/2002 Creación de nuevos casos de uso 3
26/12/2002 Realización casos prueba 2ª Release. 3,5
27/12/2002 Implementación de los Casos de Uso pactados para la 2ª Release. 8,5
28/12/2002 Implementación de los Casos de Uso pactados para la 2ª Release. 9
29/12/2002 Realización de Casos de Prueba 2ª Release y modificación Base de Datos de prueba.
5,5
03/01/2003 Creación de nuevos Diagramas de Actividad. Realización de los Casos de Prueba 2ª Release.
6,5
05/01/2003 Realización casos prueba 2ª Release y modificación Base de Datos de prueba.
4
06/01/2003 Modificación de documentos del Requisite Pro. 5
08/01/2003Modificación de los Casos de Pruebas. Elaboración de la documentación con Requisite Pro. 5,5
10/01/2003 Revisión de los Diagramas de Acitividad. Elaboración de la documentación con Requisite Pro.
4,5
15/01/2003 Reunión del grupo para la confirmación de todos los entregables de la 2ª Release.
6,5
15/01/2003Presentación de la 2ª Release al cliente, entrega de lo convenido hasta la fecha. Revisión del Usuario y Fin del Proyecto. 1
Total de horas dedicadas al proyecto:271,5 horas
Nota: en los casos de reuniones de grupo se han computado solamente las horas dedicadas a la reunión en total, no las horas
de cada miembro del equipo en la reunión. En el resto de casos las horas computadas son la suma de las dedicadas por los integrantes del equipo en suma del día