Modelado Del Negocio de La Empresa de Deportes

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


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


Implementación

Prototipos de Interfaces de Usuario Semana 328/10 – 3/11


Modelo de Implementación Semana 328/10 – 3/11


Pruebas

Casos de Pruebas Funcionales Semana 328/10 – 3/11


Despliegue

Modelo de Despliegue Semana 328/10 – 3/11


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


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


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.


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


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.





5.5.5. Operadora


Descripción Operadora de ventas de los productos


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.





5.5.6. Jefe de Ventas


Descripción Jefe del Departamento de Ventas de una región determinada.


Responsabilidades Supervisor del Departamento de Ventas, encargado de otorgar incentivos y del control de estadísticas.





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.


Grado de

participación



5.5.8. Contable

Representante Contabilidad / Facturación

Descripción Empleado del Departamento de Contabilidad y Facturación.


Responsabilidades

Encargado de la facturación y cobranzas, política de cobro de los clientes.




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.





5.5.10. Cliente Online


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.





5.5.11. Empleado de Recursos Humanos

Representante Recursos Humanos

Descripción Empleado del Departamento de Recursos Humanos.


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.





5.5.12. Jefe de Recursos Humanos

Representante Recursos Humanos

Descripción Empleado del Departamento de Recursos Humanos.


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.





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


9. Precedencia y Prioridad


10. Otros Requisitos del Producto

10.1 Estándares Aplicables


10.2 Requisitos de Sistema


10.3 Requisitos de Desempeño


10.4 Requisitos de Entorno


11. Requisitos de Documentación


11.1 Manual de Usuario


11.2. Ayuda en Línea


11.3. Guías de Instalación, Configuración, y Fichero Léame


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


No



5.3 Depart. de Logística


No

Importante

Medio [A definir por el cliente]


5.3.1 Control de estadísticas de

datos


No

Útil Medio [A definir por el cliente]


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




el cliente]José Antonio Mocholí

5.4.2 Gestión de incidencias de

pedido




Ninguna

No5.4.3 Consulta

de estado de los pedidos


Incorporada: Sí

Importante Medio [A definir por


el cliente]Eduardo Bueno

5.5 Gestión de Ventas




el cliente]

José Antonio Mocholí, Germán Mira y Miguel Mascilla

5.5.1 Elaborar pedidos y

ofertas


Incorporada: SíÚtil Medio [A definir por


el cliente]

José Antonio Mocholí, Germán Mira y Miguel Mascilla

5.5.2 Gestión de datos de clientes


No

Importante



5.5.3 Consulta de productos del

catálogo


No

Importante



5.6 Gestión de Envíos


No

Importante



5.6.1 Enviar los pedidos del

almacén


No

Importante

Bajo [A definir por el cliente]


5.6.2 Control de los recibos de

entrega


No



5.7 Depart. de Contabilidad y

Facturación


No



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.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.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.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




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.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




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”.


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.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.


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.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.


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.


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.



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





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



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.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.



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.


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


vuelve a mostrar la interfaz gráfica de borrar

cliente.


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.


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


vuelve a mostrar la interfaz gráfica de modificar

cliente.


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


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


s

Crédito 10/11/2002

10/11/2002

4 21/11/2002

En elaboració

n

1 48265791-L

46985

España

Valencia


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


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


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

[email protected]

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


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.



usuario técnico de almacén “Toni” está dado de alta en la base de



los datos.

1.3. Entrada

Introducimos ‘toni’ en el campo usuario

Introducimos ‘puma’ en el campo contraseña


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’.


El pedido queda almacenado en el sistema como en atención y el

stock se reduce en las cantidades asignadas.


Prueba superada con éxito.

2) Atender un pedido de la lista de pedidos no atendidos

2.1. Descripción





un pedido y elegiremos la opción atender pedido.



usuario técnico de almacén “Toni” está dado de alta en la base de



los datos.

2.3. Entrada






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’.


El pedido queda almacenado en el sistema como en atención y el

stock se reduce en las cantidades asignadas.



3. Atender pedido asignando cantidades negativas

3.1. Descripción





un pedido, elegiremos la opción atender pedido y asignaremos

cantidades negativas para observar como responde el sistema.


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





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


Introduce la cantidad ‘-2’.

Pulsa el botón ‘Asignar Cantidad’.


El sistema nos muestra un mensaje de error advirtiéndonos de que

no es posible introducir cantidades negativas.



4. Atender pedido asignando cantidades mayores a las disponibles

4.1. Descripción






cantidades mayores al stock disponible para observar como

responde el sistema.






4.3. Entrada











Introduce la cantidad ‘2’.




no hay stock disponible para poder asignar esa cantidad .



5. Atender pedido asignando cantidades mayores a las solicitadas

5.1. Descripción






cantidades mayores a las solicitadas para observar como responde

el sistema.






5.3. Entrada





El técnico selecciona de la lista de pedidos no atendidos el pedido de

código ‘1’ y pulsa el botón ‘Atender Pedido’.





Introduce la cantidad ‘2’.




la cantidad introducida es superior a la cantidad solicitada.



6. Atender pedido sin asignar cantidades

6.1. Descripción





un pedido, elegiremos la opción atender pedido y no realizaremos

ninguna modificación.






6.3. Entrada







Sin hacer ninguna modificación el técnico pulsa el botón

‘Guardar’.


El pedido no se modificada por esta acción y continua estando en

estado no atendido.



C. Cancelar Pedido Atendido

Descripción


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


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.




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





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’.


El pedido seleccionado sigue almacenado en el sistema sin ninguna

modificación.



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.





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





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’ .


El pedido es eliminado del sistema y se libera el stock asociado a las

líneas de pedido pasando de nuevo al stock disponible.



D. Incidencia de Pedido

Descripción


Uso “Incidencia Pedido”.


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.


entrada de la aplicación

1. Crear una incidencia normal en Almacén

1.1. Descripció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.



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.



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.


La incidencia se almacena en el sistema.



2. Crear una incidencia vacía en Almacén

2.1. Descripción






de ese pedido. En este caso, probaremos a crear una incidencia

vacía para ver como responde el sistema.






2.3. Entrada






código ‘1’.





Pulsamos ‘Guardar’ sin haber introducido ningún comentario.


El sistema nos muestra un mensaje de error que nos indica que el

campo observaciones no puede ser vacío.



3. Consultar incidencias en Almacén

3.1. Descripción






de ese pedido. En este caso, consultaremos la lista de incidencias

almacenadas en el sistema.






3.3. Entrada






código ‘1’.





Pulsamos ‘Consultar Incidencias’.


El sistema nos muestra una nueva interfaz donde se listan todas las

incidencias almacenadas.



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


operadora “maria” está dado de alta en la base de datos de




datos.

4.3. Entrada

Introducimos ‘maria’ en el campo usuario

Introducimos ‘nike’ en el campo contraseña


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.



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


5. Crear una incidencia vacía en Ventas

5.1. Descripción



estemos elaborando un pedido, tendremos la oportunidad de crear

un parte de incidencia que dejara reflejado en el sistema cualquier


pedido. En este caso, probaremos a crear una incidencia vacía para

ver como responde el sistema.


as condiciones de ejecución del caso de prueba son que el usuario





datos.

5.3. Entrada













La operadora observa que hay anomalías y procede a la creación

de una incidencia.



Pulsamos ‘Guardar’ sin haber introducido ningún comentario.


El sistema nos muestra un mensaje de error que nos indica que el

campo observaciones no puede ser vacío.

5.5. Evaluación


6. Consultar incidencias en Ventas

6.1. Descripción



estemos elaborando un pedido, tendremos la oportunidad de crear un

parte de incidencia que dejara reflejado en el sistema cualquier


pedido. En este caso, consultaremos la lista de incidencias

almacenadas en el sistema.







datos.

6.3. Entrada










El cliente solicita hacer modificaciones al pedido ‘



La operadora consulta las incidencias por si el pedido en cuestión

tubo alguna.



Pulsamos ‘Consultar Incidencias’.


El sistema nos muestra una nueva interfaz donde se listan todas las

incidencias almacenadas.

6.5. Evaluación


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”.


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




atención que haya almacenados en el sistema. Seleccionaremos un

pedido y lo pasaremos a envío.






1.3. Entrada





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’.


El pedido queda almacenado en el sistema como listo para envío.



2. Pasar pedido completo a envío desde atender pedido

2.1. Descripción





pedido y después de comprobar desde la opción atender pedido que

tiene todas las cantidades asignadas lo pasaremos a envío.






2.3. Entrada





El técnico selecciona de la lista de pedidos en atención el pedido


Una vez comprobado que tiene todas las cantidades asignadas

pulsa el botón ‘Pasar a Envíos’.


El pedido queda almacenado en el sistema como listo para envío.



3. Cancelar al pasar un pedido incompleto a envío

3.1. Descripción





pedido incompleto y lo pasaremos a envío, cancelando seguidamente

dicha decisión.






3.3. Entrada






código ‘7’.


Nos aparece un mensaje de confirmación que nos indica que el

pedido esta incompleto.

Elegimos la opción ‘Cancelar’.


El pedido no se modifica por dicha acción y sigue almacenado en el

sistema con estado en atención.



4. Pasar a envío un pedido incompleto generando un pedido con las

cantidades restantes

4.1. Descripción





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.3. Entrada






código ‘7’.




Elegimos la opción ‘Aceptar’.

Nos aparece un mensaje de confirmación sobre la creación de un

pedido con las cantidades restantes.



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.



5. Pasar a envío un pedido incompleto sin generar un pedido con las

cantidades restantes

5.1. Descripción





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.3. Entrada






código ‘8’.





Nos aparece un mensaje de confirmación sobre la creación de un

pedido con las cantidades restantes.

Elegimos la opción ‘Cancelar’


El pedido se almacena en el sistema con estado listo para envío.



GESTION DE VENTAS

A. Caso de Pruebas de Elaborar Pedido

I. Descripción


Uso “Elaborar Pedido”.


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.


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.







datos.

1.3. Entrada




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




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.


El sistema almacena el nuevo pedido con estado “No atendido”.



2. Elaborar pedido y guardar

2.1. Descripción




dicho pedido. Una vez elaborado escogeremos la opción guardar.







datos.

2.3. Entrada











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.


o Introduce ‘4’ en código artículo

o Se rellena automáticamente los campos nombre y precio.





opción guardar pedido.

La operadora pulsa el botón “guardar”.


El sistema almacena el nuevo pedido con estado “No atendido”.



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.



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


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.




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.


El sistema muestra un mensaje de error avisando al cliente de que

no es posible almacenar en el sistema un pedido vacío.



4. Elaborar pedido vacío y enviar al almacén

4.1. Descripción


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.3. Entrada





El cliente ‘Jaime’ con DNI ‘48315682N’ contacta con el







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


El sistema muestra un mensaje de error avisando al cliente de que

no es posible almacenar en el sistema un pedido vacío.



5. Modificar pedido resultando dos líneas con el mismo producto

5.1. Descripción


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.3. Entrada











El representante de ventas selecciona el pedido con código “2” y

pulsa el botón “modificar”.


pedido.

El cliente solicita añadir un producto al pedido.

Introduce una nueva línea de pedido:






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.



6. Modificar pedido añadiendo una línea de cantidad fuera de rango

6.1. Descripción






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.3. Entrada














pedido.






o Introduce ‘10000’ en cantid


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.



7. Modificar un pedido añadiendo un producto inexistente

7.1. Descripción






línea de pedido asociada a un producto ya incluido en el pedido y

añadir un producto inexistente.








7.3. Entrada














pedido.






El sistema nos muestra un mensaje de error informándonos de que el

artículo introducido no existe.



8. Modificar pedido añadiendo / eliminando una línea de pedido y enviar

a almacén

8.1. Descripción




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.







datos.

8.3. Entrada












modificar, aparece el formulario del pedido.

El cliente solicita añadir un par de raquetas al pedido.



o Se rellena automáticamente los campos descripción y

precio.




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.


opción enviar a almacén.

La operadora pulsa el botón enviar a almacén


El sistema almacena las nuevas modificaciones del pedido

seleccionado.



9. Modificar pedido añadiendo / eliminando una línea de pedido y

guardar

9.1. Descripción




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.3. Entrada




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





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:






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”.


El sistema almacena las nuevas modificaciones del pedido

seleccionado.



10. .Modificar dirección de envío del pedido

10.1. Descripción




dicho pedido, que consistirá en modificar la dirección de envío de un

pedido en elaboración.








10.3. Entrada




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




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


El sistema modifica la dirección de envío del pedido seleccionado.



11. Modificar pedido eliminando todas sus líneas

11.1. Descripción




dicho pedido, que consistirá en modificar la dirección de envío de

un pedido en elaboración.



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





El cliente ‘Javier’ con DNI ‘22496359P’ llama a la operadora.





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”.


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.



12. Eliminar pedido

12.1. Descripción




dicho pedido, que consistirá en eliminar un pedido.







datos.

12.3. Entrada










El cliente solicita eliminar el pedido ‘10’.


“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”.


El pedido seleccionado es eliminado del sistema.



13. Comprobar ratio de pago del cliente

13.1. Descripción




dicho pedido, que consistirá en elegir una modalidad de pago que

no corresponde con el ratio de pago del cliente.



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





El cliente ‘Javier’ con DNI ‘22496359-P’ llama a la operadora.






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.







El cliente solicita a la operadora pago a crédito.

La operadora pincha en el desplegable forma de pago


No es posible escoger la opción a crédito porque el ratio del cliente solo

permite al contado.



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.monografias.com-procesosventas.htm/

http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

http://www.geoogle.com/organizacion/elementosbasicosdelosprocesosdeventas/segunalgunosautores.htm

http://www.geoogle.com/organizacion/elementosbasicosdelosprocesosdeventas/segunalgunosautores.htm

http://www.itba.edu.ar/archivos/secciones/gomez_tesisprocesosventas.pdf

http://www.monografias.com-administracion.htm/

http://es.wikipedia.org/wiki/Visual_Basic

http://www.ra-ma.es/libros/SISTEMAS-INFORMATICOS-CFGS/32651/978-84-9964-099-0

http://www.ra-ma.es/libros/SISTEMAS-INFORMATICOS-CFGS/32651/978-84-9964-099-0

http://www.elprisma.com/apuntes/administracion_de_empresas/procesoadministrativo/

http://www.elprisma.com/apuntes/administracion_de_empresas/procesoadministrativo/

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


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

http://www.taringa.net/posts/info/1442455/Tesis-Ingenieria-informatica.html

http://www.mcgraw-hill.es/bcv/guide/capitulo/8448169204.pdf

http://www-01.ibm.com/software/rational/uml/

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)


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)


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

Modelado Del Negocio de La Empresa de Deportes

Documents

Transcript of Modelado Del Negocio de La Empresa de Deportes