Proyecto final victor by Victor Ibarra

PROYECTO FINAL PROYECTO FINAL Sistema para Gesti贸n de Art铆culos Deportivos

Sistema para Gesti贸n de Art铆culos Deportivos

SKY BLUE, S.A de C.V. SKY BLUE, S.A de C.V.

SKY BLUE S.A DE C.V. VICTOR HUGO IBARRA ORTIZ. INGENIERIA DEL SOFTWARE.

CD. OBREGON, SONORA A 12 DE JUNIO DE 2013

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

INTRODUCCIÓN

La empresa Sky Blue, S.A. de C.V. solicitó el proyecto de desarrollo software consta de varios departamentos centralizados, un almacén central y de diversas sucursales de ventas repartidas en distintos países. Cada sucursal de ventas dispone de un almacén regional que suministra los pedidos de los clientes a los países que conforman una región determinada, 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:

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

1. GESTIÓN DEL PROYECTO. SWEBOK La gestión de la Ingeniería del Software puede definirse como la aplicación de actividades administrativas – planeación, coordinación, medición, monitorización, control y reporte- para asegurar que el desarrollo y el mantenimiento de software sean sistemáticos, disciplinados y cuantificables. (IEEE610.12-90). PRESSMAN Gestión de Proyectos. La gestión de proyectos implica la planificación, supervisión, y control del personal, del proceso y de los eventos que ocurren mientras evoluciona el software desde la fase preliminar a la implementación operacional. Planificación. El propósito principal de la planificación es establecer un conjunto detallado de directrices que permita al equipo de trabajo saber exactamente: Qué tiene que hacerse, Cuándo tiene que hacerse y Qué recursos tienen que estar disponibles. Elementos de una Planificación Hitos. Son actividades que no tienen duración pero que marcan fechas clave del proyecto y objetivos parciales del mismo. Reuniones: Son hitos que corresponden a reuniones internas o con el cliente, que deben estar programadas lo antes posible. • Tareas: Son las actividades a realizar en el proyecto para obtener los resultados esperados •

Personas: Encargadas de realizar cada una de las actividades

• Entregables: Elementos tangibles que se irán entregando a lo largo del ciclo de vida del proyecto.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Calendarización de proyectos. Cada proyecto de software presenta distintos problemas en su desarrollo, los cuales involucran personas, equipo, usuarios del software y ambiente de la aplicación. Por estas razones, cada proyecto debe resolver el problema de la producción del software. Calendarización Es una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del proyecto, al asignar el esfuerzo a tareas específicas de ingeniería del software. Gestión de riesgos Gestión de riesgos = serie de pasos que ayudan a comprender y manejar la incertidumbre que implica el desarrollo de todo proyecto. Identificación de riesgos • Grupos de riegos Genéricos: Son comunes a todos los proyectos, son una amenaza potencial para todo el proyecto de software. • Específicos: Implican un conocimiento profundo del proyecto. Se identifican examinando el plan del proyecto y la declaración del ámbito del software Categorías Relacionados con el tamaño del producto Impacto en la organización Tipo de cliente Definición del proceso de producción Entorno de desarrollo Tecnología Experiencia y tamaño del equipo.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Plan de Desarrollo Software Versión 3.0 Sistema para Gestión de Artículos Deportivos

Versión:

3.0

Plan de Desarrollo Software

Fecha:

20/05/2013

Nombre Empresa: Sky blue, S.A de C.V.

2. Modelado de Negocio. El modelado de negocios es de gran ayuda en la etapa de análisis de desarrollo de software, ya que tener un buen modelo permite lograr comprender el ámbito de la información además de identificar las actividades y procesos que se realizan dentro de la organización para lograr una correcta operación y así lograr una buena comprensión del negocio para automatizar procesos al crear sistemas computacionales que se ajusten a la medida de una organización. De esta manera, si los requerimientos son tomados con base en el modelado del negocio, las probabilidades de que el sistema que se realice se adapte a las operaciones a realizarse dentro de la organización, son muy altas. Existen varias ventajas para basar los sistemas de información en un mismo modelo básico de negocio (León y Asato, 2009): • Los sistemas de información se vuelven una parte integral del negocio global, soportando las operaciones, fortaleciendo el trabajo y la obtención de resultados. • Los sistemas se integran fácilmente unos con otros y pueden compartir o intercambiar información. Un modelo de proceso de negocio típicamente define los siguientes elementos (León y Asato, 2009): • El Objetivo o motivo del proceso. • Las Entradas específicas. • Las Salidas específicas. • Los Recursos consumidos.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

• La secuencia de las Actividades. • Los Eventos que dirigen el proceso. Estos elementos se irán analizando a lo largo de esta asignatura, para comprender su funcionamiento dentro de la organización, así como su modelado.

Modelo de Casos de Uso 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 regionales a los clientes de la empresa.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

2.1

Modelo de Dominio.

Representación de los conceptos (objetos) significativos en el domino del problema. Incluye: – Clases de objetos – Asociaciones entre clases de objetos – Atributos de las clases de objetos

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

2.2

Modelo de objeto.

Objeto: – Entidad que existe en el mundo real – Tienen identidad y son distinguibles entre sí. Clase de objeto • Agrupa un conjunto de objetos por tener: – las mismas propiedades – un mismo comportamiento – la misma relación con otros objetos – una misma semántica Abstracción: – Ocultación de los detalles/características menos importantes para poder observar aspectos comunes • Los objetos de una clase tienen las mismas propiedades y los mismos patrones de comportamiento.

Modelo de Objetos de Vender Productos 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".

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Historial de Revisiones Fecha

Versión

Descripción

20/05/2013

0.9

Versión preliminar como propuesta de desarrollo.

22/06/2013

1.0

Versión propuesta para aprobación al final de la fase de inicio.

20/07/2013

1.9

Versión lista para ser revisada al final de la fase de elaboración.

23/08/2013

2.0

Versión revisada por el Stakeholder al final de la fase de elaboración.

20/09/2013

2.1

Versión revisada en la primera iteración de la fase de construcción

22/10/2013

2.9

Versión revisada en la segunda iteración de la fase de construcción, pendiente de revisión del Stakeholder

24/11/2013

3.0

Versión revisada en la segunda iteración de la fase de construcción, pendiente de aprobación del Stakeholder

Autor

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Introducción.......................................................................................................................................................12 1.1

Propósito .....................................................................................................................................................12

1.2

Alcance ........................................................................................................................................................13

1.3

Resumen.......................................................................................................................................................13

Vista General del Proyecto ............................................................................................................................... 13 2.1

Propósito, Alcance y Objetivos....................................................................................................................13

2.2

Suposiciones y Restricciones .......................................................................................................................15

2.3

Entregables del proyecto ............................................................................................................................. 15

2.4

Evolución del Plan de Desarrollo del Software .......................................................................................... 19

Organización del Proyecto................................................................................................................................ 19 3.1

Participantes en el Proyecto........................................................................................................................19

3.2

Interfaces Externas ......................................................................................................................................20

3.3

Roles y Responsabilidades........................................................................................................................... 20

Gestión del Proceso............................................................................................................................................21 4.1

Estimaciones del Proyecto........................................................................................................................... 21

4.2 Plan del Proyecto ........................................................................................................................................22 4.2.1 Plan de las Fases ..................................................................................................................................22 4.2.2 Calendario del Proyecto.......................................................................................................................24 4.3 5.

Seguimiento y Control del Proyecto ............................................................................................................29

Referencias .........................................................................................................................................................30

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Plan de Desarrollo de Software 1.

Introducción Este Plan de Desarrollo del Software es una versión preliminar preparada para ser incluida en la propuesta elaborada como respuesta al proyecto final de la asignatura de Ingeniería de Software de la Universidad del Desarrollo Profesional. Este documento provee una visión global del enfoque de desarrollo propuesto. El proyecto ha sido basado en una 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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

1.3

Resumen Después de esta introducción, el resto del documento está organizado en las siguientes secciones: Vista General del Proyecto — proporciona una descripción del propósito, alcance y objetivos del proyecto, estableciendo los entragbles que serán producidos y utilizados durante el proyecto.. Organización del Proyecto — describe la estructura organizacional del equipo de desarrollo. Gestión del Proceso — explica los costos y planificación estimada, define las fases e hitos del proyecto y describe cómo se realizará su seguimiento. Planes y Guías de aplicación — proporciona una vista global del proceso de desarrollo de software, incluyendo métodos, herramientas y técnicas que serán utilizadas.

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Deportes SKY BLUE, S.A DE C.V 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 esta firma conllevará una previsible adaptación a los nuevos sistemas de información y a la evolución tecnológica. Por ello, Deportes SKY BLUE, S.A DE C.V 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.

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.

Gestión de Envíos, incluyendo: 

Gestión de Pedidos para envío.



Gestión de recibos.

c) Departamento de Recursos Humanos. d) Departamento de Marketing. e) Departamento de Logística. f) Contabilidad y Facturación.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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. c) 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 SKY BLUE, S.A DE C.V . d) Como es natural, la lista de suposiciones y restricciones se incrementará durante el desarrollo del proyecto, particularmente una vez establecido el artefacto “Visión”. 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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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-

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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. 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. 8) 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. 9) 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. 10)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.) .

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

11)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). 12)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. 13)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. 14)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. 15)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.

16)Evaluación de Iteración

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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. 17)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. 18)Manual de Instalación Este documento incluye las instrucciones para realizar la instalación del producto. 19)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 20)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.3

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.

Organización del Proyecto

3.1

Participantes en el Proyecto De momento no se incluye el personal que designará Deportes SKY BLUE, S.A DE C.V como Responsable del Proyecto, Comité de Control y Seguimiento, otros participantes que se estimen convenientes para proporcionar los requisitos y validar el sistema.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

El resto del personal del proyecto (por la parte del la empresa adjudicataria), considerando las fases de Inicio, Elaboración y dos iteraciones de la fase de Construcción, estará formado por los siguientes puestos de trabajo y personal asociado: Jefe de Proyecto. Labor de VICTOR HUGO IBARRA ORTIZ, alumno de la carrera de Ingeniería de software de la universidad de desarrollo profesional. Con una experiencia modesta en metodologías de desarrollo, herramientas CASE y notaciones, en particular la notación UML y el proceso de desarrollo RUP. Analista de Sistemas. El perfil establecido es: Ingeniero en sistemas computacionales con conocimientos de UML, uno de ellos al menos con experiencia en sistemas afines a la línea del proyecto, labor que llevará a cabo VICTOR HUGO IBARRA ORTIZ. 4 Analistas - Programadores. Con experiencia en el entorno de desarrollo del proyecto, con el fin de que los prototipos puedan ser lo más cercanos posibles al producto final. Este trabajo ha sido encomendado a JESUS ISIDRO GONZALEZ ESPINOZA. Ingeniero de Software. El perfil establecido es: Ingeniero en sistemas computacionales, realizando labores de gestión de requisitos, gestión de configuración, documentación y diseño de datos. Encargado de las pruebas funcionales del sistema, realizará la labor de JESUS ISIDRO GONZALEZ ESPINOZA. Los Currículos Vitae del personal del proyecto que ya ha comprometido su participación se adjuntan por separado. 3.2

Interfaces Externas Deportes SKY BLUE, S.A DE C.V definirá los participantes del proyecto que proporcionarán los requisitos del sistema, y entre ellos quiénes serán los encargados de evaluar los artefactos de acuerdo a cada subsistema y según el plan establecido.

El equipo de desarrollo interactuará activamente con los participantes de Deportes SKY BLUE, S.A DE C.V para especificación y validación de los artefactos generados. 3.3

Roles y Responsabilidades A continuación se describen las principales responsabilidades de cada uno de los puestos en el equipo de desarrollo durante las fases de Inicio y Elaboración, de acuerdo con los roles que desempeñan en RUP.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Puesto

Responsabilidad

El jefe de proyecto asigna los recursos, gestiona las prioridades, coordina las interacciones con los clientes y usuarios, y mantiene al equipo del proyecto enfocado en los objetivos. El jefe de proyecto también establece un conjunto de Jefe de Proyecto prácticas que aseguran la integridad y calidad de los artefactos del proyecto. Además, el jefe de proyecto se encargará de supervisar el establecimiento de la arquitectura del sistema. Gestión de riesgos. Planificación y control del proyecto.

Analista Sistemas

Programador

Ingeniero Software

4. 4.1

Captura, especificación y validación de requisitos, interactuando con el cliente y los usuarios mediante de entrevistas. Elaboración del Modelo de Análisis y Diseño. Colaboración en la elaboración de las pruebas funcionales y el modelo de datos. Construcción de prototipos. Colaboración en la elaboración de las pruebas funcionales, modelo de datos y en las validaciones con el usuario Gestión de requisitos, gestión de configuración y cambios, elaboración del modelo de datos, de preparación de las pruebas funcionales, elaboración de la documentación. Elaborar modelos de implementación y despliegue.

Gestión del Proceso

Estimaciones del Proyecto El presupuesto del proyecto y los recursos involucrados se adjuntan en un documento separado.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

4.2

Plan del Proyecto En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto.

4.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) Nro. Fase

Duración Iteraciones

Fase de Inicio

3 semanas

Fase de Elaboración

2 semanas

Fase de Construcción

7 semanas

Fase Transición

Los hitos que marcan el final de cada fase se describen en la siguiente tabla.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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,

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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 / modificados

Artefactos

generados

o Comienzo

Aprobación

Semana 1

Semana 3

durante la Fase de Inicio Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio

13/05 19/05

– 27/05 3/06

–

Requisitos Semana 1 Glosario

13/05 19/05

Visión

Semana 2

Semana 3 – 27/05 3/06 Semana 3

–

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

20/05 26/05

– 27/05 3/06

Semana 3 Modelo de Casos de Uso

28/05 3/05

siguiente – fase

Semana 3 Especificación de Casos de Uso

28/05 3/05

siguiente – fase

Semana 3 Especificaciones Adicionales

28/05 3/06

siguiente – fase

Análisis / Diseño Semana 2 Modelo de Análisis / Diseño

21/05 27/05

siguiente – fase

Semana 2 Modelo de Datos

21/05 27/05

siguiente – fase

Implementación Semana 3 Prototipos de Interfaces de Usuario

28/05 3/06

siguiente – fase

Semana 3 Modelo de Implementación

28/05 3/06

siguiente – fase

Pruebas Casos de Pruebas Funcionales

Semana 3

–

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

28/05 3/06

– fase

Despliegue Semana 3 Modelo de Despliegue

Gestión de Cambios y Configuración

siguiente – fase

28/05 3/06

Durante todo el proyecto

Gestión del proyecto Semana 1 Plan de Desarrollo del Software en su versión 1.0 y planes de las Iteraciones Ambiente

14/05 20/06

Semana 3 – 28/05 3/06

Durante todo el proyecto

Disciplinas / Artefactos generados o modificados durante la

Comienzo

Aprobación

Fase de Elaboración Modelado del Negocio Semana 1 Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio

–

14/05 20/05

– aprobado

Requisitos Semana 1 Glosario

14/05 20/05

Visión

Semana 2

– aprobado

aprobado

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

21/05 27/05

–

Semana 3 Modelo de Casos de Uso

28/05 3/06

Semana 5 –

Semana 3 Especificación de Casos de Uso

28/05 3/06

Semana 5 –

Semana 3 Especificaciones Adicionales

28/05 3/06

11/06 – 17/06

Semana 5 –

11/06 – 17/06

Análisis / Diseño Semana 2 Modelo de Análisis / Diseño

21/05 27/05

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

Semana 2 Modelo de Datos

21/05 27/05

Implementación Semana 3 Prototipos de Interfaces de Usuario

28/05 3/06 Semana 3

Modelo de Implementación

28/05 3/06

Pruebas Casos de Pruebas Funcionales

Semana 3

Revisar en cada iteración

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

28/05 3/06

–

Despliegue Semana 3 Modelo de Despliegue

Gestión de Cambios y Configuración

28/05 3/06

–

Revisar en cada iteración

Durante todo el proyecto

Gestión del proyecto Semana 4 Plan de Desarrollo del Software en su versión 2.0 y planes de las Iteraciones Ambiente

4/06 10/06

–

Revisar en cada iteración

Durante todo el proyecto

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

Referencias 

Pliego de Cláusulas Técnicas para la Definición y Análisis de los Procedimientos del ES-NIC.



Desarrollo de una aplicación informática para el cálculo del personal necesario para la fabricación de carrocerías, utilizando la metodología RUP. – P.F.C. de Ponz Lillo, Daniel.



Visual Modeling with Rational Rose and UML, Terry Quatrani. - AddisonWesley.



Documentación de Rational Unified Process, manuals de ayuda, tutoriales, etc.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3. Requisitos Definición de requerimiento Cuando el cliente solicita que se desarrolle un sistema tiene algunas nociones de lo que debe hacer. Por esta razón cada sistema basado en el software tiene un propósito, usualmente expresado con algo que el sistema debe hacer. Un requerimiento “es una característica del sistema o una descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito del sistema”

3.1 Visión

Historial de Revisiones Fecha

Versión

Descripción

20/05/2013

0.9

Propuesta inicial del documento Visión con las primeras capturas de requisitos funcionales del sistema.

20/06/2013

1.0

Versión 1.0 en estado de complementación para su aprobación.

20/07/2013

1.0

Versión 1.0 para la aprobación al final de la fase de inicio

20/08/2013

1.0

Versión 1.0 para la aprobación al final de la fase de inicio

20/09/2013

2.0

Versión 2.0 tras el fin de la fase de elaboración a falta de revisión por el stakeholder

20/10/2013

2.1

Versión 2.0 modificada en la primera iteración de construcción. Pendiente de revisión por el Stakeholder.

20/11/2013

2.9

Versión modificada en la segunda iteración de construcción. Pendiente de revisión por el Stakeholder.

20/12/2013

3.0

Versión revisada para la segunda iteración de construcción. Pendiente de validación por el Stakeholder

20/01/2014

3.0

Versión revisada para la segunda iteración de construcción. Pendiente de validación por el Stakeholder

Autor

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Introducción

1.1 1.2 1.3 1.4

5 5 5 5

Propósito Alcance Definiciones, Acrónimos, y Abreviaciones Referencias

Posicionamiento

2.1 2.2 2.3

6 6 7

Oportunidad de Negocio Sentencia que define el problema Sentencia que define la posición del Producto

Descripción de Stakeholders (Participantes en el Proyecto) y Usuarios

3.1 3.2 3.3 3.4

Resumen de Stakeholders Resumen de Usuarios Entorno de usuario Perfil de los Stakeholders 3.4.1 Representante del área técnica y sistemas de información 3.5 Perfiles de Usuario 3.5.1 Ingeniero de Logística 3.5.2 Jefe de Almacén 3.5.3 Técnico de Almacén 3.5.4 Representante de Ventas 3.5.5 Operadora 3.5.6 Jefe de Ventas 3.5.7 Encargado de Transporte 3.5.8 Contable 3.5.9 Empleado de Marketing 3.5.10 Cliente Online 3.5.11 Empleado de Recursos Humanos 3.5.12 Jefe de Recursos Humanos

8 8 9 9 9 10 10 10 11 11 12 12 13 13 14 14 15 15

Descripción Global del Producto

4.1 4.2 4.3 4.4

16 16 16 16

Perspectiva del producto Resumen de características Suposiciones y dependencias Costo y precio

Descripción Global del Producto

5.1 5.2 5.3 5.4 5.5 5.6 5.7

17 17 17 17 18 18 19

Departamento de Recursos Humanos Departamento de Marketing Departamento de Logística Gestión de Almacén Gestión de Ventas Gestión de Envíos Departamento de Contabilidad y Facturación

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Restricciones

Precedencia y Prioridad

Otros Requisitos del Producto

8.1 8.2 8.3 8.4

19 19 19 19

Estándares Aplicables Requisitos de Sistema Requisitos de Desempeño Requisitos de Entorno

Requisitos de Documentación

9.1 9.2 9.3

19 19 19

Manual de Usuario Ayuda en Línea Guías de Instalación, Configuración, y Fichero Léame

Atributos de Características

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Visión 1. Introducción

1.1 Propósito

El propósito de éste documento 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.2 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. 1.3 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. 1.4 Referencias

Glosario. Plan de desarrollo de software. RUP (Rational Unified Process). Diagrama de casos de uso.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

2.3 Sentencia que define la posición del Producto

Para

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.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3.1 Resumen de Stakeholders

Nombre

Descripción

Responsabilidades

Agustín Duarte Preciado.

Representante Global de la empresa Deportes de Sky Blue s.a. de c.v.

El stakeholder realiza: Representa a todos los usuarios posibles del sistema. Seguimiento del desarrollo del proyecto. Aprueba requisitos y funcionalidades

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

Responsable de ventas del producto a los clientes, mediante visitas al domicilio del cliente. Informa de las ofertas y confecciona las órdenes de pedido.

Ventas

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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 Recursos Humanos

Responsable de la gestión de personal, es decir, contratos y despidos, y también encargado de la redistribución de la plantilla.

Recursos Humanos

3.3 Entorno de usuario

Los usuarios entrarán al sistema identificándose sobre un ordenador con un sistema operativo Windows 8 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 2013, lo cual también resultará familiar.

3.4 Perfil de los Stakeholders 3.4.1 Representante del área técnica y sistemas de información

Representante

Patricio Orlando Letelier Torres

Descripción

Representante Global de la Empresa Deportes Sky Blue s.a. de c.v.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tipo

Experto de Sistemas.

Responsabilidade s

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 cliente

Grado de participación

Revisión de requerimientos, estructura del sistema

Comentarios

Ninguno

3.5 Perfiles de Usuario 3.5.1 Ingeniero

Logística

Representante

Agustin Duarte Preciado.

Descripción

Jefe del Departamento de Logística de la Empresa.

Tipo

Gurú.

Responsabilidade s

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 cliente

Grado de participación

A definir por el cliente

Comentarios

Ninguno

3.5.2 Jefe

Representante

Luis Newman

Descripción

Jefe del almacén de una región determinada.

Tipo

Usuario casual del sistema.

Almacén

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Responsabilidade s

Supervisor del buen funcionamiento del almacén y de gestionar las incidencias de los pedidos, ya sea tratando con otro almacén, o bien en contacto con el Ingeniero de Logística. Capacidad de toma de decisiones en cuanto a distribución de mercancías desde otro almacén y cancelación de pedidos que han sido atendidos.

Criterio de Éxito

A definir por el cliente

Grado de participación

A definir por el cliente

Comentarios

Ninguno.

3.5.3 Técnico

Almacén

Representante

Juan Jose

Descripción

Responsable del almacén de una región determinada.

Tipo

Usuario experto.

Responsabilidade s

Encargado directo del almacén, control de stocks y distribución de los productos, preparación y atención de las órdenes de pedido y solicitudes de envío al cliente. Gestión de incidencias a través del de un técnico comercial para que se ponga en contacto con el cliente, o bien por medio del jefe de almacén.

Criterio de Éxito

A definir por el cliente

Grado de participación

A definir por el cliente

Comentarios

Niniguno.

3.5.4 Representante

Ventas

Representante

Eli

Descripción

Representante de ventas de los productos

Tipo

Usuario experto.

Responsabilidade

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

participa en las incidencias de pedidos poniéndose en contacto con el cliente para la resolución de los mismos. Puede cancelar pedidos en estado de elaboración.

Criterio de Éxito

A definir por el cliente

Grado de participación

A definir por el cliente

Comentarios

Ninguno.

3.5.5 Operadora

Representante

Oscar Holguin.

Descripción

Operadora de ventas de los productos

Tipo

Usuario experto.

Responsabilidade s

Responsable de ventas del producto a los clientes a través del teléfono. Informa de las ofertas y confecciona las órdenes de pedido. También participa en las incidencias de pedidos poniéndose en contacto con el cliente para la resolución de los mismos.

Criterio de Éxito

A definir por el cliente

Grado de participación

A definir por el cliente

Comentarios

Ninguno.

3.5.6 Jefe de Ventas

Representante

Edgar Rascon.

Descripción

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

Tipo

Usuario experto.

Responsabilidade s

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Criterio de Éxito

A definir por el cliente

Grado de participación

A definir por el cliente

Comentarios

Ninguno.

3.5.7 Encargado de Transporte

Representante

Josefina Vazquez Mota.

Descripción

Encargado de Transportes de un almacén determinado.

Tipo

Usuario experto.

Responsabilidade s

Supervisor del transporte de mercancías desde el almacén hasta el domicilio de los clientes. Carga los pedidos en el camión, registra en el sistema los datos del envío y una vez entregado el pedido al cliente, introduce el recibo de entrega en la base de datos.

Criterio de Éxito

A definir por el cliente

Grado de participación

A definir por el cliente

Comentarios

Ninguno.

3.5.8 Contable

Representante

Benny Franco.

Descripción

Empleado del Departamento de Contabilidad y Facturación.

Tipo

Usuario experto.

Responsabilidade s

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

Criterio de Éxito

A definir por el cliente

Grado de

A definir por el cliente

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

participación Comentarios

Niguno.

3.5.9 Empleado

Marketing

Representante

Tomas Beltran.

Descripción

Empleado del Departamento de Marketing.

Tipo

Usuario eventual.

Responsabilidade s

Responsable de ofertas de lanzamiento, publicidad, política de ventas y otros aspectos relacionados con el marketing.

Criterio de Éxito

A definir por el cliente

Grado de participación

A definir por el cliente

Comentarios

Ninguno.

3.5.10 Cliente

Online

Representante

Ventas

Descripción

Comprador de productos.

Tipo

Usuario casual.

Responsabilidade s

Realiza compras online y consulta del estado de pedidos como del catálogo. También puede darse de alta, darse de baja o modificar sus datos de cliente.

Criterio de Éxito

A definir por el cliente

Grado de participación

A definir por el cliente

Comentarios

Ninguno.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3.5.11 Empleado

Recursos

Humanos

Representante

Recursos Humanos

Descripción

Empleado del Departamento de Recursos Humanos.

Tipo

Usuario casual.

Responsabilidade s

Responsable de las entrevistas de trabajo y registra los datos de las mismas, incluyendo la gestión de una base de datos de currículos de trabajadores en potencia. También realiza la gestión de contratos y nóminas del personal.

Criterio de Éxito

A definir por el cliente

Grado de participación

A definir por el cliente

Comentarios

Ninguno.

3.5.12 Jefe

Recursos

Humanos

Representante

Recursos Humanos

Descripción

Empleado del Departamento de Recursos Humanos.

Tipo

Usuario casual.

Responsabilidade s

Responsable de la gestión de personal, es decir, gestión de contrataciones y gestión de despidos. También es responsable de la redistribución de la plantilla.

Criterio de Éxito

A definir por el cliente

Grado de participación

A definir por el cliente

Comentarios

Ninguno.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

4. Descripción Global del Producto 4.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. 4.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 Base de datos centralizada con la información humanos. de todo el personal. Posibilidad de cancelación de órdenes por parte del cliente dando la posibilidad de hacerlo vía servicios web. Automatización de la cancelación de estas órdenes.

Aplicación web desde la que poder cancelar pedidos. Sistema automatizado de anulación de órdenes.

Mayor facilidad para el control e catálogos Base de datos con acceso remoto desde la que para el área de marketing. poder controlar ofertas y políticas de ventas. Automatización del sistema de nóminas

4.3 Suposiciones y dependencias [A definir por el cliente] 4.4 Costo y precio [A definir por el cliente]

Sistema automático nóminas.

generación

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

5. Descripción Global del Producto

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

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

5.4.2

Gestión de incidencias de pedido

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

6. Restricciones [A definir por el cliente]

7. Precedencia y Prioridad [A definir por el cliente]

8. Otros Requisitos del Producto 8.1 Estándares Aplicables [A definir por el cliente] 8.2 Requisitos de Sistema [A definir por el cliente]

8.3 Requisitos de Desempeño [A definir por el cliente]

8.4 Requisitos de Entorno [A definir por el cliente]

9. Requisitos de Documentación [A definir por el cliente] 9.1 Manual de Usuario [A definir por el cliente]

9.2 Ayuda en Línea [A definir por el cliente]

9.3 Guías de Instalación, Configuración, y Fichero Léame [A definir por el cliente]

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Atributos de Características

Número y nombre de la característica

Estado

Beneficio

Esfuerzo

Riesgo

Estabilidad

Asignación

Útil

Bajo

[A definir por [A definir por el cliente] el cliente]

Ninguna

Útil

Bajo

[A definir por [A definir por el cliente] el cliente]

Ninguna

Important e

Medio

[A definir por [A definir por el cliente] el cliente]

Ninguna

Útil

Medio

[A definir por [A definir por el cliente] el cliente]

Ninguna

Crítica

Alto

[A definir por [A definir por Mira, Miguel Mascilla el cliente] el cliente] y Eduardo Bueno

Crítica

Alto

[A definir por [A definir por José Antonio Mocholí el cliente] el cliente]

Propuesta: Sí 5.1 Depart. de Recursos Humanos

Aprobada: Sí Incorporada: No Propuesta: Sí

5.2 Depart. de Marketing

Aprobada: Sí Incorporada: No Propuesta: Sí

5.3 Depart. de Logística

Aprobada: Sí Incorporada: No Propuesta: Sí

5.3.1 Control de estadísticas de datos

Aprobada: Sí Incorporada: No Propuesta: Sí

5.4 Gestión de Almacén

Aprobada: Sí Incorporada: Sí

5.4.1 Atención de órdenes de pedido

Propuesta: Sí Aprobada: Sí

J.A. Mocholí, Germán

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Incorporada: Sí Propuesta: Sí 5.4.2 Gestión de incidencias de pedido

Aprobada: Sí

Útil

Medio

[A definir por [A definir por el cliente] el cliente]

Ninguna

Important e

Medio

[A definir por [A definir por el cliente] el cliente]

Eduardo Bueno

Crítica

Alto

[A definir por [A definir por el cliente] el cliente]

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

Útil

Medio

[A definir por [A definir por el cliente] el cliente]

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

Important e

Medio

[A definir por [A definir por el cliente] el cliente]

Ninguna

Important e

Medio

[A definir por [A definir por el cliente] el cliente]

Ninguna

Important e

Medio

[A definir por [A definir por el cliente] el cliente]

Ninguna

Incorporada: No Propuesta: Sí

5.4.3 Consulta de estado de los pedidos

Aprobada: Sí Incorporada: Sí Propuesta: Sí

5.5 Gestión de Ventas

Aprobada: Sí Incorporada: Sí Propuesta: Sí

5.5.1 Elaborar pedidos y ofertas

Aprobada: Sí Incorporada: Sí Propuesta: Sí

5.5.2 Gestión de datos de clientes

Aprobada: Sí Incorporada: No Propuesta: Sí

5.5.3 Consulta de productos del catálogo

Aprobada: Sí Incorporada: No Propuesta: Sí

5.6 Gestión de Envíos

Aprobada: Sí Incorporada:

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

No Propuesta: Sí 5.6.1 Enviar los pedidos del almacén

Aprobada: Sí Incorporada: No

Important e

Bajo

[A definir por [A definir por el cliente] el cliente]

Ninguna

Útil

Bajo

[A definir por [A definir por el cliente] el cliente]

Ninguna

Útil

Medio

[A definir por [A definir por el cliente] el cliente]

Ninguna

Propuesta: Sí 5.6.2 Control de los recibos de entrega

Aprobada: Sí Incorporada: No Propuesta: Sí

5.7 Depart. de Contabilidad y Facturación

Aprobada: Sí Incorporada: No

3.2. Glosario.

Historial de Revisiones Fecha

Versión

Descripción

20/05/2013

0.8

Versión preliminar del glosario, a falta de completar con próximas reuniones

20/06/2013

0.9

Versión para ser aprobada el día 24/11

20/07/2013

1.0

Versión aprobada por el Stakeholder

20/08/2013

2.0

Versión modificada con la incorporación de nueva terminología derivada de modificaciones en los requisitos

20/09/2013

2.1

Versión revisada en la primera iteración de construcción. Términos actualizados

20/10/2013

2.9

Versión para ser aprobada por el Stakeholder en la segunda iteración de la fase de construcción

20/11/2013

3.0

Versión revisada para la segunda iteración, pendiente de ser validad por el Stakeholder.

Autor

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Introducción

1.1 1.2 1.3 1.4

25 25 25 25

Propósito Alcance Referencias Organización del Glosario

Definiciones

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 2.24 2.25 2.26 2.27 2.28 2.29 2.30 2.31 2.32 2.33 2.34 2.35 2.36 2.37 2.38 2.39 2.40

25 25 26 26 26 26 26 26 26 27 27 27 27 27 27 28 28 28 28 28 29 29 29 29 29 29 30 30 30 30 30 31 31 31 31 31 32 32 32 32

Almacén Atender pedido Cancelar pedido atendido Cancelar pedido en elaboración Cancelar pedido listo para envío Cancelar pedido online Catálogo de productos Cliente externo Cliente online Consultar pedidos a enviar Cobro a clientes Comprar a proveedor Confeccionar catálogo Consultar catálogo Consultar pedidos no atendidos Contable Control de estadísticas Departamento de contabilidad y facturación Departamento de logística Departamento de marketing Departamento de recursos humanos Elaborar pedido online Elaborar pedido Empleado de marketing Empleado de recursos humanos Empresa de transportes Encargado de transporte Enviar pedido Facturar entrega de un pedido Fecha de atención Fecha de elaboración Fecha de envío Fecha de envío al almacén Fecha de listo para envío Gestión de almacén Gestión de clientes Gestión de envíos Gestión de nóminas Gestión de personal Gestión de ventas

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

2.41 2.42 2.43 2.44 2.45 2.46 2.47 2.48 2.49 2.50 2.51 2.52 2.53 2.54 2.55 2.56 2.57 2.58 2.59 2.60 2.61 2.62 2.63 2.64 2.65 2.66 2.67 2.68 2.69 2.70 2.71 2.72 2.73 2.74 3.

Incidencia pedido Ingeniero de logística Introducir recibos Jefe de almacén Jefe de recursos humanos Jefe de ventas Línea de pedido Listado de pedidos en atención Listado de pedidos enviados Listado de pedidos listos para envío Listado de pedidos no atendidos Operadora Orden de pedido Otorgar incentivos Pasar pedido a envío Pedido en atención Pedido pendiente de cobro Pedido en elaboración Pedido en envío Pedido listo para envío Pedido no atendido Política Producto Producto Proveedor Reabastecer almacén Realizar envío Realizar oferta Redistribución de personal Región Registrarse en el sistema Reposición de stock Representante de ventas Técnico de almacén Usuario de ventas

Estereotipos UML

32 33 33 33 33 33 34 34 34 34 34 34 35 35 35 35 35 35 36 36 36 36 36 36 36 37 37 37 37 37 37 38 38 38 38

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Glosario 10. Introducción 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. 10.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. 10.2 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. 10.3 Referencias El presente glosario hace referencia a los siguientes documentos: -

Documento Plan de Desarrollo Software del Proyecto Deportes LSI 03

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

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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.

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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.

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

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

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

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

11.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, otorgar incentivos y gestión de clientes.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

11.69 Región 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 almacén regional. Las órdenes de pedido de los clientes de un país determinado que pertenece a una región determinada se sirven a partir del almacén asignado a dicha región.

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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.

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

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

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

12. Estereotipos UML [This section contains or references specifications of Unified Modeling Language (UML) stereotypes and their semantic implications—a textual description of the meaning and significance of the stereotype and any limitations on its use—for stereotypes already known or discovered to be important for the system being modeled. The use of these stereotypes may be simply recommended or perhaps even made mandatory; for example, when their use is required by an imposed standard or when it is felt that their use makes models significantly easier to understand. This section may be empty if no additional stereotypes, other than those predefined by the UML and the Rational Unified Process, are considered necessary.]

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3.3. Casos de Usos de Rational Rose. 3.3.1. Especificaciones de caso de uso. Especificaciones de atender el pedido.

Historia de Revisiones Fecha

Versión

Descripción

20/05/2013

0.9

Plantilla del caso de uso para revisar con el Stakeholder

20/06/2013

1.0

Plantilla revisada por el Stakeholder el día 13/11/2002

20/07/2013

2.0

Versión modificada por los cambios aplicados por el Stakeholder en una reunión previa.

20/08/2013

2.1

Plantilla revisada por el Stakeholder y que incluye las modificaciones de usuario para la segunda iteración de construcción

20/09/2013

3.0

Plantilla revisada para la segunda iteración de construcción

Autor

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Atender Pedido

1.1

Descripción

Flujo de Eventos

2.1 2.2

41 41 41

Flujo Básico Flujos Alternativos 2.2.1 En el punto 2.2

Precondiciones

3.1

El técnico de almacén está dado de alta en el sistema.

42 42

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

Poscondiciones

4.1

El pedido queda almacenado en el sistema en la lista de pedidos en atención.

Puntos de Extensión

5.1

Incidencia Pedido en el paso 4.2

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

13. Atender Pedido 13.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.

14. Flujo de Eventos 14.1 Flujo Básico

1. 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”. 2. 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. 3. El técnico de almacén selecciona una línea de pedido para editarla. 4. Para cada línea de pedido el técnico de almacén puede cambiar la cantidad asignada del stock disponible en el almacén: 4.1. El técnico cambia la cantidad de stock asignada a una línea de pedido y pulsa el botón “modificar cantidad”. 4.2. 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. 4.3. Se reserva el stock del almacén. 4.4. Si el técnico de almacén decide modificar otra línea de pedido, volver al punto 4.1 5. 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”. 14.2 Flujos Alternativos 14.2.1 En el punto 2.2 Si en el paso 4.1 la cantidad es negativa el sistema generará un mensaje de error.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

15. Precondiciones 16. El técnico de almacén está dado de alta en el sistema. 17. El técnico de almacén ha realizado correctamente el registro en el sistema introduciendo el nombre de usuario y la contraseña 18. Poscondiciones 18.1 El pedido queda almacenado en el sistema en la lista de pedidos en atención.

19. Puntos de Extensión 19.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.

Especificaciones de cancelar pedido.

Historia de Revisiones Fecha

Versión

Descripción

Autor

20/05/2013

0.9

Plantilla del caso de uso para revisar con el Stakeholder

José Luis Martínez

25/05/2013

1.0

Plantilla revisada por el Stakeholder el día 13/11/2002

César López Rodríguez

10/06/2013

2.0

Plantilla revisada en la primera iteración de la fase de construcción

César López Rodríguez

11/06/2013

2.1

Plantilla revisada por el Stakeholder y que incluye las modificaciones de usuario para la segunda iteración de construcción

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Cancelar Pedido Atendido

1.1

Descripción

Flujo de Eventos

2.1 2.2

44 44

Flujo Básico Flujos Alternativos

Precondiciones

3.1 El técnico de almacén está dado de alta en el sistema. 3.2 El técnico de almacén ha realizado correctamente el registro en el sistema introduciendo el nombre de usuario y la contraseña 3.3 El cliente ha solicitado anular uno de sus pedidos que ya ha sido atendido.

Poscondiciones

4.1 El pedido es eliminado del sistema y se liberan los productos reservados para atender ese pedido.

44 44

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

20. Cancelar Pedido Atendido 20.1 Descripción El técnico de almacén anula un pedido ya atendido.

21. Flujo de Eventos 21.1 Flujo Básico

1. 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”. 2. 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”. 2.1. El sistema muestra un mensaje de aviso de eliminación del pedido. 2.2. 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. 21.2 Flujos Alternativos

22. Precondiciones 22.1 El técnico de almacén está dado de alta en el sistema. 22.2 El técnico de almacén ha realizado correctamente el registro en el sistema introduciendo el nombre de usuario y la contraseña 22.3 El cliente ha solicitado anular uno de sus pedidos que ya ha sido atendido.

23. Poscondiciones 23.1 El pedido es eliminado del sistema y se liberan los productos atender ese pedido.

reservados para

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Especificaciones de cobro a cliente. Historia de Revisiones Fecha 20/05/2013

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

Tabla de Contenidos 1.

Cobro a Clientes

1.1

Descripción

Flujo de Eventos

2.1 2.2

46 46 46

Flujo Básico Flujos Alternativos 2.2.1 En el punto 2.1

Precondiciones

3.1. 3.2.

47 47

El contable ha realizado correctamente el login en el sistema. El contable ha seleccionado el botón de “Cobro a Clientes” de su interfaz gráfica.

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

47 47 47

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

1. Cobro a Clientes 23.2 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 23.3 2.1

Flujo Básico

24. La pantalla muestra una lista con los pedidos que se han servido correctamente. 25. El 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. 25.1 En caso afirmativo podrá escoger direcciones alternativas ya grabadas en el sistema o introducir una nueva para los clientes que desee. 26. Normalmente la aplicación tendrá predeterminado el cobro con transferencia bancaria. 26.1 El contable puede modificar la forma de pago de las facturas que desee. 27. 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”. 28. 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.

28.1 2.2

Flujos Alternativos

28.1.1 2.2.1 En el punto 2.1 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. 28.1.1.1 2.2.2 En el punto 3.1

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

Especificaciones de Compra de Provedores.

Historia de Revisiones Fecha 20/05/2013

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Compra a Proveedores

1.1

Descripción

Flujo de Eventos

2.1

Flujo Básico

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.

Poscondiciones

4.1.

En caso de haberse dado de alta una nueva compra, ésta quedará grabada en el sistema.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

5. Compra a Proveedores 28.2 1.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.

6. Flujo de Eventos 28.3 2.1

Flujo Básico

29. 30. 31. 32.

El Ingeniero de Logística accede a Compra a Proveedores. El sistema le muestra una pantalla donde llevará a cabo las selecciones correspondientes. Primero selecciona el almacén a reponer de la lista de almacenes y pulsa siguiente. La aplicación le muestra entonces una lista donde aparecen los productos que tiene el almacén seleccionado y su stock actual. 32.1 El Ingeniero de Logística puede seleccionar un producto ya existente y pinchar en añadir al pedido. 32.1.1 El producto pasa a la lista del nuevo pedido. 32.1.2 Introduce la cantidad deseada. 32.2 O bien puede seleccionar un producto que no esté en el almacén utilizando el catálogo de productos 32.2.1 Selecciona un producto del catálogo que se añadirá a la lista del nuevo pedido 32.2.2 Introduce la cantidad deseada 33. Una vez confeccionada la lista de productos a pedir pincha en finalizar pedido. 34. El sistema le muestra una pantalla con el pedido al completo y le pide la confirmación. 34.1 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). 34.2 Si el Ingeniero pincha cancelar volverá a la pantalla anterior. 35. El pedido se almacenará en la lista de pedidos realizados.

7. Precondiciones 7.1. El Ingeniero de Logística ha realizado correctamente el login en el sistema. 7.2. El Ingeniero de Logística ha seleccionado el botón “Compra a Proveedores” de su interfaz gráfica.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

8. Poscondiciones 8.1. En caso de haberse dado de alta una nueva compra, ésta quedará grabada en el sistema.

Especificación de Confeccionar Catalogo.

Historia de Revisiones Fecha 20/05/2013

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Confeccionar Catálogo

1.1

Descripción

Flujo de Eventos

2.1

Flujo Básico

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.

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

9. Confeccionar Catálogo 35.1 1.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.

10. Flujo de Eventos 35.2 2.1

Flujo Básico

36. La pantalla muestra una lista con los productos del catálogo actual. 37. 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. 37.1 Si pulsa el botón de añadir, el sistema le mostrará una nueva ventana donde podrá introducir los datos del nuevo producto: descripcció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. 37.1.1 Al seleccionar nuevo proveedor aparecerá una ventana donde incluir sus datos: dirección, teléfono, nombre, nif. 37.1.2 Si ha pulsado en proveedor actual aparecerá una lista de los proveedores registrados. Seleccionará uno y pulsará aceptar. 37.1.3 El producto quedará registrado en el sistema debidamente. 37.2 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). 37.3 Si selecciona modificar producto, se abrirá una ventana con los datos del mismo para que el Empleado de Marketing los modifique a su gusto.

11. Precondiciones 11.1.

El Empleado de Marketing ha realizado correctamente el registro en el sistema.

11.2. El Empleado de Marketing ha seleccionado el botón de “Confeccionar Catálogo” de su interfaz gráfica.

12. Poscondiciones 12.1. En caso de haberse dado de alta una nuevo producto o proveedor, los datos del mismo quedan almacenados en la base de datos.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Especificación de Consultar Pedidos y Enviar.

Historia de Revisiones Fecha 20/06/2013

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Confeccionar Catálogo

1.1

Descripción

Flujo de Eventos

2.1

Flujo Básico

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.

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

13. Confeccionar Catálogo 37.4 1.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.

14. Flujo de Eventos 37.5 2.1

Flujo Básico

38. La pantalla muestra una lista con los productos del catálogo actual. 39. 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. 39.1 Si pulsa el botón de añadir, el sistema le mostrará una nueva ventana donde podrá introducir los datos del nuevo producto: descripcció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. 39.1.1 Al seleccionar nuevo proveedor aparecerá una ventana donde incluir sus datos: dirección, teléfono, nombre, nif. 39.1.2 Si ha pulsado en proveedor actual aparecerá una lista de los proveedores registrados. Seleccionará uno y pulsará aceptar. 39.1.3 El producto quedará registrado en el sistema debidamente. 39.2 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). 39.3 Si selecciona modificar producto, se abrirá una ventana con los datos del mismo para que el Empleado de Marketing los modifique a su gusto.

15. Precondiciones 15.1.

El Empleado de Marketing ha realizado correctamente el registro en el sistema.

15.2. El Empleado de Marketing ha seleccionado el botón de “Confeccionar Catálogo” de su interfaz gráfica.

16. Poscondiciones 16.1. En caso de haberse dado de alta una nuevo producto o proveedor, los datos del mismo quedan almacenados en la base de datos.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Especifiaciones de Consultar Pedidos No Atendidos.

Historia de Revisiones Fecha

Versión

Descripción

Autor

20/05/2013

0.9

Plantilla para revisión con el Stakeholder

Jose Antonio Mocholí

25/05/2013

1.0

Plantilla revisada el día 13/11/2002 por el Stakeholder

César López Rodríguez

10/06/2013

2.0

Plantilla adaptada a la primera iteración de la fase de construcción

César López Rodríguez

17/06/2013

3.0

Plantilla adaptada a la segunda iteración de la fase de construcción

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Consultar Pedidos no Atendidos

1.1

Descripción

Flujo de Eventos

2.1

Flujo Básico

Precondiciones

3.1

El Técnico de Almacén está registrado en el sistema.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

40. Consultar Pedidos no Atendidos 40.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.

41. Flujo de Eventos 41.1 Flujo Básico

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.

El técnico selecciona un pedido y pulsa el botón “consultar”.

El sistema muestra una interfaz gráfica en la que se detallan los datos del pedido seleccionado

El técnico puede desde esta nueva interfaz atender el pedido o salir.

42. Precondiciones El Técnico de Almacén está registrado en el sistema.

Especificación de Control de Estadística.

Historia de Revisiones Fecha 20/05/2013

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Control Estadísticas

¡Error! Marcador no definido.

1.1. Descripción

Flujo de Eventos

2.1.

Flujo Básico

2.2.

Flujos Alternativos

Precondiciones

Postcondiciones

60 ¡Error! Marcador no definido.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

17. Control Estadísticas 42.1 1.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.

18. Flujo de Eventos 42.2 2.2

Flujo Básico

43. La pantalla muestra una lista con las posibles estadísticas a crear. 44. El actor selecciona una de ellas y pulsa el botón crear. 45. El sistema le muestra una pantalla donde puede asignar regiones, almacenes o trabajadores afectados por la estadística. 46. 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. 47. Pulsando siguiente aparecerán los resultados que podrá guardar o imprimir. 47.1 Si pulsa el botón guardar el sistema le permitirá grabar los resultados en el disco duro u otro soporte de almacenamiento. 47.2 Su pulsa el botón imprimir se mandarán a la impresora los resultados.

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

Especificación de Consultar Consulta.

Historia de Revisiones Fecha

Versión

Descripción

Autor

20/05/2013

0.9

Plantilla del caso de uso para revisar con el Stakeholder

José Luis Martínez

25/05/2013

1.0

Plantilla revisada por el Stakeholder el día 13/11/2002

César López Rodríguez

10/06/2013

2.0

Plantilla revisada en la primera iteración de la fase de construcción

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Consultar Productos 1.1

Descripción

¡Error! Marcador no definido. 62

Flujo de Eventos

2.1 2.2

62 62

Flujo Básico Flujos Alternativos

Precondiciones

Postcondiciones

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

48. Consultar Productos 48.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.

49. Flujo de Eventos 49.1 Flujo Básico

3. El Usuario de Ventas accede al catálogo de productos. 4. Se muestra por pantalla una clasificación de los productos con su descripcción, foto y precio. 5. El usuario puede seleccionar uno e introducirlo en la orden de pedido. 6. El catálogo se queda en segundo plano y se muestra la orden de pedido añadiendo el producto que se ha seleccionado. 49.2 Flujos Alternativos

50. Precondiciones 3.1 El Usuario de Ventas debe estar dado de alta en el sistema

51. Postcondiciones

Especificaciones de Elaborar Pedidos On-line.

Historia de Revisiones Fecha

Versión

Descripción

Autor

20/05/2013

0.9

Plantilla del caso de uso para revisar con el Stakeholder

José Luis Martínez

25/05/2013

1.0

Plantilla revisada por el Stakeholder el día 13/11/2002

César López Rodríguez

10/06/2013

2.0

Plantilla revisada en la primera iteración de la fase de construcción

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Elaborar Pedido Online

1.1

Descripción

Flujo de Eventos

2.1 2.2

64 64 64 64 64

Flujo Básico Flujos Alternativos 2.2.1 En el paso 4 2.2.2 En el paso 5 2.2.3 En el paso 8

Precondiciones

3.1 3.2

64 64

El cliente debe estar dado de alta en el sistema de compras online. El cliente ha introducido correctamente su nombre de usuario y su contraseña en el sistema

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”

65 65 65

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

52. Elaborar Pedido Online 52.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.

53. Flujo de Eventos 53.1 Flujo Básico

7. El sistema genera automáticamente el número de pedido y le asigna la fecha actual. 8. El sistema presenta los datos del cliente por pantalla. 9. El cliente puede comprobar el estado de pedidos realizados con anterioridad pulsando el botón “consultar pedidos”. 10.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. 11.Selecciona la modalidad de pago. 12.Si la modalidad es por transferencia o tarjeta de crédito se pide la confirmación de los datos de la cuenta. 13.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”. 14.Si el cliente no quiere guardar los datos del pedido que ha elaborado, pulsa el botón “salir”. 53.2 Flujos Alternativos 53.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 53.2.2 En el paso 5

Si algún producto no tiene stock disponible se avisa por pantalla.

53.2.3 En el paso 8

Si el cliente no está conforme, puede modificarse el pedido o proceder a la anulación del mismo.

54. Precondiciones 54.1 El cliente debe estar dado de alta en el sistema de compras online. 54.2 El cliente ha introducido correctamente su nombre de usuario y su contraseña en el sistema

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

55. Poscondiciones 55.1 La orden de pedido queda almacenada en el sistema si el usuario ha seleccionado “guardar” 55.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” 55.3 La orden de pedido no se almacena en el sistema si el usuario seleccionó “salir”

Especificación de Elaborar Pedido.

Historia de Revisiones Fecha

Versión

Descripción

Autor

20/05/2013

0.9

Plantilla del caso de uso para revisar con el Stakeholder

José Luis Martínez

25/05/2013

1.0

Plantilla revisada por el Stakeholder el día 13/11/2002

César López Rodríguez

10/06/2013

2.0

Plantilla revisada en la primera iteración de la fase de construcción

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Elaborar Pedido

1.1

Descripción

Flujo de Eventos

2.1 2.2

67 68 68 68 68 68 69

Flujo Básico Flujos Alternativos 2.2.1 En el punto 1 2.2.2 En el punto 4.1 2.2.3 En el punto 4.2 2.2.4 En el punto 5.1 2.2.5 En el punto 5.2

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.

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.

69 69

Puntos de Extensión

5.1 5.2

69 69

Gestión de Clientes en el punto 1 Consultar Catálogo en el punto 4.2 y 5.1

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Especificación de caso de uso: Elaborar Pedido 56. Elaborar Pedido 56.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.

57. Flujo de Eventos 57.1 Flujo Básico

15.La operadora o el representante de ventas buscan el cliente por DNI, CIF o por código de cliente. 16.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. 17.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. 18.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. 18.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. 18.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. 18.3. En caso de querer introducir una nueva línea de pedido, volver al punto 4.2. 18.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. 18.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. 19.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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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. 19.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. 19.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”. 19.3. En caso de introducir una nueva línea de pedido, volver al punto 5.1. 19.4. En caso de introducir una nueva línea de pedido, volver al punto 5.2. 19.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. 19.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. 20.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. 21.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. 57.2 Flujos Alternativos 57.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. 57.2.2 En el punto 4.1 Si en el punto 4.1 al introducir alguno de los campos número, puerta o código postal se ha metido un número no estrictamente positivo, el sistema generará un mensaje de error. 57.2.3 En el punto 4.2 Si en el paso 4.2 el representante de ventas o la operadora introducen una referencia errónea o inexistente, el sistema generará un aviso de error de producto no existente. En caso de introducir una cantidad no mayor que cero el sistema generará un aviso de error de cantidad errónea. Si se introduce una cantidad por encima del rango máximo razonable de pedido el sistema generará un aviso de haber excedido esta cantidad. 57.2.4 En el punto 5.1 Si en el paso 5.1 el representante de ventas o la operadora introducen una referencia errónea o inexistente, el sistema generará un aviso de error de producto no existente. En caso de introducir una cantidad no mayor que cero el sistema

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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. 57.2.5 En el punto 5.2 Si en el paso 5.2 el representante de ventas o la operadora introducen un código de artículo erróneo, el sistema generará un aviso de error de artículo no existente. En caso de introducir una cantidad no mayor que cero el sistema generará un aviso de error de cantidad errónea. Si se introduce una cantidad por encima del rango máximo razonable de pedido el sistema generará un aviso de haber excedido esta cantidad.

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

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

60. Puntos de Extensión 60.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. 60.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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Especificación de Entrevista de Trabajo.

Historia de Revisiones Fecha 20/05/2013

Versión 1.0

Descripción Versión preliminar lista para ser revisada por el Stakeholder

Autor

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Entrevista Trabajo

1.1

Descripción

Flujo de Eventos

2.2

Flujo Básico

Precondiciones

3.1. 3.2.

72 72

El Empleado de RRHH ha realizado correctamente el login en el sistema. El Empleado de RRHH ha seleccionado el botón de “Entrevista Trabajo” de su interfaz gráfica.

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

20. Entrevista Trabajo 60.3 1.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.

21. Flujo de Eventos 2.2 Flujo Básico

61. La pantalla muestra una lista con las entrevistas introducidas en el sistema. Esta lista tiene los campos “Puesto”, “Fecha”, “Entrevistado” y “Entrevistador”. 62. El Empleado de RRHH puede pulsar en cualquiera de las entrevistas y pulsar el botón “Ver” o “Borrar”. 62.1 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. 62.2 Si pulsa el botón “Borrar” el sistema, tras pedir la confirmación, borrará la entrevista seleccionada. 63. El actor puede pulsar el botón “Nueva” para comenzar una nueva entrevista de trabajo. 63.1 Se abrirá una pantalla donde podrá introducir primeramente los datos personales del entrevistado. 63.2 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. 63.3 Una vez finalizada la introducción de los datos si pulsa el botón “Guardar”, la entrevista se almacenará en el sistema.

22. Precondiciones 22.1.

El Empleado de RRHH ha realizado correctamente el login en el sistema.

22.2. El Empleado de RRHH ha seleccionado el botón de “Entrevista Trabajo” de su interfaz gráfica.

23. Poscondiciones En caso de haberse dado de alta una nueva entrevista, los datos de la misma quedan almacenados en la base de datos.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Especificación de Gestión de Clientes.

Historia de Revisiones Fecha

Versión

Descripción

Autor

20/05/2013

0.9

Plantilla para revisar por el Stakeholder el día 13/11/2002

César López Rodríguez

24/05/2013

1.0

Plantilla revisada por el Stakeholder el día 13/11/2002

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Gestión de Clientes

1.1

Descripción

Flujo de Eventos

2.1 2.2

75 76 76 76 76 76 77

Flujo Básico Flujos Alternativos 2.2.1 En el punto 2.2 2.2.2 En el punto 3.2 2.2.3 En el punto 3.6 2.2.4 En el punto 4.1 2.2.5 En el punto 4.5

Precondiciones

3.1 3.2

77 77

El Usuario de Ventas ha realizado correctamente el login en el sistema El Usuario de Ventas ha seleccionado el botón de “Gestión de Clientes” de su interfaz gráfica

Postcondiciones

¡Error! Marcador no definido.

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.

77 77 77

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Especificación de caso de uso: Gestión de Clientes 64. Gestión de Clientes 64.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.

65. Flujo de Eventos 65.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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

65.2 Flujos Alternativos 65.2.1 En el punto 2.2 El sistema comprueba que los datos del nuevo cliente, DNI/CIF no se corresponden con ningún otro cliente de la base de datos. En caso afirmativo, generará un mensaje de error comunicando que dicho cliente ya está dado de alta en la base de datos. El sistema comprueba que se han introducido todos los datos restantes, en caso de que no se hayan introducido datos en los campos Nombre, País, Provincia, Localidad, Dirección, Código Postal, Teléfono y Cuenta Bancaria, el sistema generará un mensaje de error comunicando que faltan datos del necesarios cliente. 65.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. 65.2.2 En el punto 3.2 El sistema comprueba que el DNI/CIF introducido corresponde con alguno de los registrados en la base de datos. Si el DNI/CIF no se encuentra en la base de datos, se generará un mensaje de error indicando que el DNI/CIF introducido no se encuentra en la base de datos. 65.2.2.1 En el punto 3.2

Si se ha generado mensaje de error, el sistema vuelve a mostrar la interfaz gráfica de borrar cliente.

65.2.3 En el punto 3.6 El sistema comprueba si el cliente solicitado para la baja tiene pedidos en elaboración, en caso afirmativo informará al Usuario de Ventas de que se eliminarán también los pedidos en elaboración. El sistema también comprueba que el cliente no tiene pedidos en cualquier otro estado que no sea el de elaboración. En caso afirmativo, el sistema informará de la situación al Usuario de Ventas y podrá solicitar Cancelar Pedido Atendido. En caso de no eliminarse previamente los pedidos pendientes, el sistema no borrará el cliente. 65.2.4 En el punto 4.1 El sistema comprueba que el DNI/CIF introducido corresponde con alguno de los registrados en la base de datos. Si el DNI/CIF no se encuentra en la base de datos, se generará un mensaje de error indicando que el DNI/CIF introducido no se encuentra en la base de datos.

65.2.4.1 En el punto 4.1

Si se ha generado mensaje de error, el sistema vuelve a mostrar la interfaz gráfica de modificar cliente.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

65.2.5 En el punto 4.5

El sistema comprueba que los datos del nuevo cliente, DNI/CIF no se corresponden con ningún otro cliente de la base de datos. En caso afirmativo, generará un mensaje de error comunicando que dicho cliente ya está dado de alta en la base de datos. El sistema comprueba que se han introducido todos los datos restantes, en caso de que no se hayan introducido datos en los campos Nombre, País, Provincia, Localidad, Dirección, Código Postal, Teléfono y Cuenta Bancaria, el sistema generará un mensaje de error comunicando que faltan datos del necesarios cliente.

65.2.5.1 En el punto 4.5 Si se ha generado mensaje de error, el sistema vuelve a mostrar la interfaz gráfica de modificar cliente.

66. Precondiciones 66.1 El Usuario de Ventas ha realizado correctamente el registro en el sistema 66.2 El Usuario de Ventas ha seleccionado el botón de “Gestión de Clientes” de su interfaz gráfica

67. Poscondiciones 67.1 En caso de haberse dado de alta un nuevo cliente, los datos del cliente quedan almacenados en la base de datos 67.2 En caso de haberse realizado una modificación de los datos de un cliente, quedan almacenados en la base de datos. 67.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.

Especificación de Gestión de Nominas.

Historia de Revisiones Fecha 29/05/2013

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Gestión de Nóminas

1.1

Descripción

Flujo de Eventos

2.1

Flujo Básico

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.

Poscondiciones

4.1. En caso de haberse modificado una o varias nóminas, los cambios quedarán almacenados en la base de datos. 79 1.2 ¡Error! Marcador no definido.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

24. Gestión de Nóminas 67.4 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.

25. Flujo de Eventos 2.1

Flujo Básico

67.5 La pantalla muestra una lista con los distintos trabajadores de la empresa ordenada según departamentos. 67.6 El Empleado de RRHH puede seleccionar una o varias personas de un departamento (con SHIFT + Click). 67.7 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. 67.8 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. 67.9 En los datos bancarios aparece, la entidad, el número de cuenta y la frase a mostrar como concepto. 67.10 Pulsando sobre aceptar se grabarán las modificaciones en la base de datos.

26. Precondiciones 26.1.

El Empleado de RRHH ha realizado correctamente el login en el sistema.

26.2. El Empleado de RRHH ha seleccionado el botón de “Gestión de Nóminas” de su interfaz gráfica.

27. Poscondiciones 27.1. En caso de haberse modificado una o varias nóminas, los cambios quedarán almacenados en la base de datos.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Especificación de Gestión de Regiones.

Historia de Revisiones Fecha 20/05/2013

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Gestión de Regiones

1.1

Descripción

Flujo de Eventos

2.1

Flujo Básico

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.

Poscondiciones

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.

83 83

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

28. Gestión de Regiones 67.11 1.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.

29. Flujo de Eventos 67.12 2.1

Flujo Básico

68. La pantalla muestra una lista con las regiones actuales. 69. 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. 69.1 Si pulsa sobre el botón eliminar se borrará la región si no hay ninguna tienda o almacén asignados a ella. 69.2 Si pulsa el botón modificar, podrá cambiar los datos relacionados a esa región así como asignar almacenes. 69.2.1 Le aparecerá una pantalla con los datos de la región y una lista de almacenes asignados a ella. 69.2.2 Los datos se pueden modificar seleccionando uno y rescribiendo. 69.2.3 La lista de almacenes dispone de un botón añadir y otro eliminar. 69.2.3.1 Si pulsa el botón añadir aparecerá una ventana donde introducir los datos del almacén. 69.2.3.2 Si pulsa el botón eliminar, el sistema pedirá la confirmación para borrar el almacén seleccionado. 69.3 Si pulsa el botón añadir, podrá agregar una nueva región e introducir sus datos.

30. Precondiciones 30.1.

El Ingeniero de Logística ha realizado correctamente el registro en el sistema.

30.2. El Ingeniero de Logística ha seleccionado el botón de “Gestión de Regiones” de su interfaz gráfica.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

31. Poscondiciones 31.1. En caso de haberse dado de alta una nueva región, los datos de la misma quedan almacenados en la base de datos. 31.2. En caso de haberse dado de alta un nuevo almacén, los datos del mismo quedan almacenados en la base de datos.

Especificacion de Incidencia Pedido

Historia de Revisiones Fecha

Versión

Descripción

Autor

20/05/2002

1.0

Versión preliminar lista para ser revisada por el Stakeholder

César López Rodríguez

22/05/2002

2.0

Versión revisada para la primera iteración de la fase de construcción

César López Rodríguez

23/05/2013

2.1

Plantilla revisada por el Stakeholder y que incluye las modificaciones de usuario para la segunda iteración de construcción

César López Rodríguez

03/06/2013

3.0

Versión revisada en la segunda iteración de la fase de construcción. Pendiente de revisión por el Stakeholer

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Incidencia Pedido

1.1

Flujo de Eventos

2.1 2.2

3. 3.1

Descripción

Flujo Básico

Flujos Alternativos 2.2.1 En el paso 2

85 85

Precondiciones El empleado está dado de alta en el sistema.

85 85

3.2 El empleado ha realizado correctamente el registro en el sistema introduciendo el nombre de usuario y la contraseña

4.1

Poscondiciones Si el empleado ha generado la incidencia, ésta queda almacenada en el sistema.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

70. Incidencia Pedido 70.1 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.

71. Flujo de Eventos 2.1 Flujo Básico 1. 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”. 2. 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. 3. 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.

71.1 2.2

Flujos Alternativos

71.1.1 2.2.1

En el paso 2

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

73. Poscondiciones 4.1

Si el empleado ha generado la incidencia, ésta queda almacenada en el sistema.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Especificacion de Introducir Recibos.

Historia de Revisiones Fecha

Versión

Descripción

Autor

20/05/2013

0.9

Plantilla del caso de uso para revisar con el Stakeholder

José Luis Martínez

25/05/2013

1.0

Plantilla revisada por el Stakeholder el día 13/11/2002

César López Rodríguez

21/06/2013

2.0

Plantilla revisada en la primera iteración de la fase de construcción

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Introducir Recibos

1.1

Descripción

Flujo de Eventos

2.1 2.2

88 88 88 88

Flujo Básico Flujos Alternativos 2.2.1 En el punto 3 2.2.2 En el punto 6

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

Poscondiciones

4.1

El pedido cambia del estado “enviado” a pedido “pendiente de cobro”

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

74. Introducir Recibos 74.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.

75. Flujo de Eventos 75.1 Flujo Básico

22.El encargado de transporte selecciona la opción “introducir recibos”. 23.El sistema muestra una lista con los pedidos en estado “enviado”. 24.El encargado de transporte selecciona uno de ellos y pulsa la opción “aceptar”. 25.El sistema muestra el detalle del pedido y los campos fecha de entrega y transportista. 26.El encargado de transporte introduce la fecha de entrega del pedido y el nombre del transportista que la realizó. 27.El encargado de transporte pulsa el botón “introducir” 28.El recibo es almacenado en el sistema, y el pedido que figuraba en estado de “enviado” pasa al estado “pendiente de cobro”.

75.2 Flujos Alternativos 75.2.1 En el punto 3 Si el transportista se equivoca al seleccionar el pedido puede volver atrás en cualquier momento y anular la introducción del pedido.

75.2.2 En el punto 6 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.

76. Precondiciones 76.1 El encargado de transportes está dado de alta en el sistema. 76.2 El encargado de transporte ha realizado correctamente el registro en el sistema introduciendo el nombre de usuario y la contraseña

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

77. Poscondiciones 77.1 El pedido cambia del estado “enviado” a pedido “pendiente de cobro”

Especificacion de Otorgar Incentivos.

Historia de Revisiones Fecha 20/05/2013

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Otorgar Incentivos

1.1

Descripción

Flujo de Eventos

2.1

Flujo Básico

Precondiciones

3.1 3.2

92 92

El Jefe de Ventas ha realizado correctamente el registro en el sistema. El Jefe de Ventas ha seleccionado el botón de “Otorgar Incentivos” de su interfaz gráfica.

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

92 92

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

78. Otorgar Incentivos 78.1 1.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.

79. Flujo de Eventos 79.1 2.1

Flujo Básico

80. La pantalla muestra una lista con los incentivos pendientes 81. EL Jefe de Ventas puede seleccionar uno de los existentes y pulsar el botón modificar, añadir o borrar. 81.1 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. 81.1.1 Si hace doble click en el campo cantidad de una línea podrá modificarla. 81.1.2 Si selecciona una línea y pulsa el botón borrar se borrará la persona o sección en cuestión. 81.1.3 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. 81.1.4 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. 81.1.5 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. 81.2 Si pulsa el botón borrar se eliminará el incentivo seleccionado. 81.3 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. 81.3.1 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. 81.3.2 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. 81.3.3 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. 81.3.4 Si hace doble click en el campo cantidad de una línea podrá modificarla. 81.3.5 Si selecciona una línea y pulsa el botón borrar se borrará la persona o sección en cuestión.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

82. Precondiciones 82.1 3.1

El Jefe de Ventas ha realizado correctamente el registro en el sistema.

82.2 3.2 El Jefe de Ventas ha seleccionado el botón de “Otorgar Incentivos” de su interfaz gráfica.

83. Poscondiciones 83.1 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

Especificacion de Pasar Pedido a Envio.

Historia de Revisiones Fecha

Versión

Descripción

Autor

20/05/2013

1.0

Plantilla de versión preliminar del caso de uso Pasar Pedido a Envío

César López Rodríguez

21/06/2013

1.9

Versión lista para ser revisada por el Stakeholder

César López Rodríguez

20/07/2013

2.0

Versión revisada en la primera iteración de construcción

César López Rodríguez

21/08/2013

2.1

Plantilla revisada por el Stakeholder y que incluye las modificaciones de usuario para la segunda iteración de construcción

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

3. 3.1

Pasar Pedido a Envío

1.1

Descripción

Flujo de Eventos

2.1 2.2

94 94 94

Flujo Básico Flujos Alternativos 2.2.1 En el punto 2

Precondiciones El técnico de almacén está dado de alta en el sistema.

94 94

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

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

84. Pasar Pedido a Envío 84.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”.

85. Flujo de Eventos 85.1 Flujo Básico

1. 2. 3.

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”. El sistema comprueba que las cantidades asignadas coinciden con las cantidades solicitadas en todas las líneas del pedido. 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.

85.2 Flujos Alternativos 85.2.1 En el punto 2 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”.

86. Precondiciones 87. El técnico de almacén está dado de alta en el sistema. 88. El técnico de almacén ha realizado correctamente el registro en el sistema introduciendo el nombre de usuario y la contraseña

89. Poscondiciones 89.1 Si se satisfacen las cantidades demandadas, el pedido cambia del estado

“en

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

atención” a pedido “listo para envío”

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.

Especificación de Política de Ventas.

Historia de Revisiones Fecha 20/12/2013

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Política de Ventas

1.1

Descripción

Flujo de Eventos

2.1

Flujo Básico

Precondiciones

3.1. 3.2.

98 98

El contable ha realizado correctamente el login en el sistema. El contable ha seleccionado el botón de “Cobro a Clientes” de su interfaz gráfica.

Poscondiciones

98 98 98

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

32. Política de Ventas 89.2 1.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.

33. Flujo de Eventos 89.3 2.1

Flujo Básico

90. La pantalla muestra una lista con los incentivos actuales 91. EL Jefe de Ventas puede seleccionar uno de los existentes y pulsar el botón modificar, añadir o borrar. 91.1 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. 91.1.1 Si hace doble click en el campo cantidad de una línea podrá modificarla. 91.1.2 Si selecciona una línea y pulsa el botón borrar se borrará la persona o sección en cuestión. 91.1.3 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. 91.1.4 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. 91.1.5 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. 91.2 Si pulsa el botón borrar se eliminará el incentivo seleccionado. 91.3 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. 91.3.1 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. 91.3.2 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. 91.3.3 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. 91.3.4 Si hace doble click en el campo cantidad de una línea podrá modificarla. 91.3.5 Si selecciona una línea y pulsa el botón borrar se borrará la persona o sección en cuestión.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

34. Precondiciones 34.1.

El contable ha realizado correctamente el login en el sistema.

34.2.

El contable ha seleccionado el botón de “Cobro a Clientes” de su interfaz gráfica.

35. Poscondiciones 35.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. 35.2. Los pedidos para los cuales se imprime factura pasan al estado “factura emitida”.

Los pedidos para los que se ha abonado la factura pasan al estado “factura pagada”.

Especificación de Reabastecer Almacen.

Historia de Revisiones Fecha 18/12/2013

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Reabastecer Almacén

100

1.1

100

Descripción

Flujo de Eventos

100

2.1

100

Flujo Básico

Precondiciones

101

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.

101

Poscondiciones

101

4.1. En caso de haberse dado de alta un nuevo reabastecimiento, éste quedará grabado en el sistema.

101

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

36. Reabastecer Almacén 91.4 1.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.

37. Flujo de Eventos 91.5 2.1

Flujo Básico

92. El Ingeniero de Logística accede a Reabastecer Almacén. 93. 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. 94. Si quiere realizar un nuevo envió para reabastecer un almacén selecciona el botón nuevo envío. 95. El sistema le muestra una lista de las regiones y los almacenes, el Ingeniero selecciona un almacén. 96. 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. 97. El Ingeniero pincha sobre un producto del almacén central y selecciona el botón incluir en envío. 98. El sistema lo incluye en el envío y el Ingeniero modifica la cantidad de unidades a incluir. 99. Si desea incluir más productos vuelve al paso 6. 100. 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”. 101. Una vez el envío esta listo para salir se notifica al sistema y el envío pasa al estado “en envío”. 102. Cuando llega al almacén destino se grabará en el sistema como “reabastecimiento completado”.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

38. Precondiciones 38.1.

El Ingeniero de Logística ha realizado correctamente el login en el sistema.

38.2. El Ingeniero de Logística ha seleccionado el botón “Reabastecer Almacén” de su interfaz gráfica.

39. Poscondiciones En caso de haberse dado de alta un nuevo reabastecimiento, éste quedará grabado en el sistema.

Especificacion de Realizar Envio.

Historia de Revisiones Fecha

Versión

Descripción

Autor

8/11/2013

1.0

Versión preliminar lista para ser revisada por el Stakeholder

César López Rodríguez

10/12/2013

2.0

Plantilla revisada en la primera iteración de la fase de construcción

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1. 1.1. 2.

Realizar Envío

103

Descripción

103

Flujo de Eventos

103

2.1.

Flujo Básico

103

2.2.

Flujos Alternativos

103

3. 3.1.

Precondiciones El pedido está marcado como “Listo para Envío”.

103 103

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.

103

Poscondiciones

4.1.

El pedido queda marcado como “Enviado”.

103

4.2.

El stock de los productos del pedido queda actualizado.

103

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

40. Realizar Envío 40.1.

Descripción

El encargado de transporte hace efectivo el envío del pedido correspondiente.

41. Flujo de Eventos 41.1.

Flujo Básico

29.El encargado de transporte selecciona la opción “realizar envío”. 30.El sistema muestra la lista de pedidos listos para ser enviados usando el caso de uso “consultar pedidos listos para envío”. 31.El encargado de transporte selecciona un pedido de la lista. 32.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. 33.El contenido del pedido es cargado en el camión. 34.El pedido pasa a ser pedido “enviado” automáticamente. 35.El stock del almacén es actualizado automáticamente por el sistema, eliminando de dicho stock el asignado al pedido.

41.2.

Flujos Alternativos

42. Precondiciones 42.1.

El pedido está marcado como “Listo para Envío”.

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

43. Poscondiciones 43.1.

El pedido queda marcado como “Enviado”.

El stock de los productos del pedido queda actualizado.

Especificacion de Realizar Oferta.

Historia de Revisiones Fecha 29/10/2013

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Realizar Oferta

105

1.1

105

Descripción

Flujo de Eventos

105

2.1

105

Flujo Básico

Precondiciones

105

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.

105

Poscondiciones

106

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.

106 106

105

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

44. Realizar Oferta 102.1 1.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.

45. Flujo de Eventos 2.1 Flujo Básico

103. La pantalla muestra una lista con las ofertas actuales. 104. 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”. 104.1 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. 104.1.1 Si hace doble click en el campo “Precio de Oferta” de una línea podrá modificarlo. 104.1.2 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. 104.1.3 Si selecciona una línea y pulsa el botón “Borrar” se quitará de la oferta el producto seleccionado. 104.1.4 Si pulsa el botón “Añadir Producto” aparecerá una pantalla donde podrá seleccionar un producto del catálogo de la empresa. 104.1.5 Al pulsa el botón “Aceptar” se confirmará la oferta. 104.2 Si pulsa el botón “Borrar” se eliminará la oferta seleccionada. 104.3 Si pulsa el botón “Añadir” aparecerá una pantalla con una lista vacía de productos. 104.3.1 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. 104.3.2 Si hace doble click en el campo “Precio de Oferta” de una línea podrá modificarlo. 104.3.3 Si selecciona una línea y pulsa el botón “Borrar” se borrará el producto en cuestión. 104.3.4 Al pulsa el botón “Aceptar” se confirmará la oferta.

46. Precondiciones 46.1.

El Empleado de Marketing ha realizado correctamente el login en el sistema.

46.2. El Empleado de Marketing ha seleccionado el botón de “Realizar Oferta” de su interfaz gráfica.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

47. Poscondiciones 47.1. En caso de haberse dado de alta una nueva oferta, los datos de la misma quedan almacenados en la base de datos.

Las ofertas nuevas sólo afectan a pedidos que no estén en preparación y a pedidos nuevos.

Especificación de Redistribución de Personal.

Historia de Revisiones Fecha 29/12/2002

Versión 1.0

Descripción

Autor

Versión preliminar lista para ser revisada por el Stakeholder

José Luis Martínez Herrero

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Redistribución de Personal

108

1.1

108

Descripción

Flujo de Eventos

108

2.1

108

Flujo Básico

Precondiciones

108

3.1. 3.2.

108 108

El Jefe de RRHH ha realizado correctamente el login en el sistema. El Jefe de RRHH ha seleccionado el botón de “Gestión de Personal” de su interfaz gráfica.

Poscondiciones

108

4.1. En caso de haberse modificado, agregado o borrado uno o varios empleados, los cambios quedarán almacenados en la base de datos.

108

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

48. Redistribución de Personal 104.4 1.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.

49. Flujo de Eventos 104.5 2.1

Flujo Básico

104.6 La pantalla muestra una lista con los distintos trabajadores de la empresa ordenada según departamentos. 104.7 El Jefe de RRHH puede seleccionar una o varias personas de un departamento (con SHIFT + Click). 104.8 El actor puede pinchar en el botón modificar, añadir o eliminar. 104.8.1 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. 104.8.2 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. 104.8.3 Si pincha sobre eliminar, borrará tras una confirmación, los datos del trabajador. 104.9 Al pulsar en aceptar se guardarán los cambios en la base de datos y no se podrá volver atrás.

50. Precondiciones 50.1.

El Jefe de RRHH ha realizado correctamente el login en el sistema.

50.2. El Jefe de RRHH ha seleccionado el botón de “Gestión de Personal” de su interfaz gráfica.

51. Poscondiciones En caso de haberse modificado, agregado o borrado uno o varios empleados, los cambios quedarán almacenados en la base de datos.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3.4. Gestión de requisitos con RequisitePro. Requisitos pro. es un requisitos y el uso de herramientas de gestión de casos para los equipos de proyecto.Los equipos pueden crear y compartir sus necesidades utilizando métodos basados en documentos familiares, durante el uso de las capacidades de base de datos como la trazabilidad y el análisis de impacto. Esto puede mejorar la comunicación y la gestión de requisitos, aumentar la calidad y el tiempo de salida al mercado. Rational RequisitePro es una herramienta fácil de usar que le ayuda a: 

Evite el retrabajo y la duplicación con la avanzada integración en tiempo real con Microsoft ® Word.



Gestione la complejidad con trazabilidad detalladas vistas que muestran relaciones padre / hijo.



Mejorar la colaboración de equipos geográficamente distribuidos a través de pleno funcionamiento, la interfaz web escalable y foros de discusión.



Capturar y analizar los requisitos de información con la personalización de atributos detallado y filtrado.



Aumentar la productividad mediante cambios de localización utilizando comparaciones versión del proyecto con las líneas de base de los proyectos basados en XML.



Alinear las metas y objetivos de negocio con los resultados del proyecto , aunque la integración con múltiples herramientas en el desarrollo de software de IBM Rational y la plataforma de entrega.

mantiene los equipos de proyectos al día gracias a la creación, análisis y gestión de los requisitos de aplicaciones y casos de uso. Ya que el desarrollo de software es una tarea de equipo, es crítico que los miembros que implementen la solución comprendan los objetivos y entregables apropiados. ¿Cómo puede un equipo entregar la solución adecuada si sus miembros no tienen acceso a la visión del proyecto, sus metas, especificaciones y otros requerimientos que detallan lo que la solución final debe hacer?

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3.4.1. Stakaholders Stakeholders: Los representantes de los usuarios y portavoces de las necesidades de la empresa son los stakeholders. En este proyecto solamente se ha tratado con un stakeholder como representante de los usuaros y necesidades de la empresa, sin embargo se han dividido representativamente según los distintos departamentos. La matriz de atributos de los stakeholders es la siguiente:

Stakeholders: La matriz de trazabilidad de los stakeholders relaciona a éstos con las características de software de tal manera que se puede conocer qué stakeholder propuso qué característica.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3.4.2.

actores

Actores: Se define este requerimiento para listar los usuarios potenciales del sistema, en este proyecto se han definido los siguientes actores: Ingeniero de Logística, Jefe de Almacén, Técnico de Almacén, Jefe de Ventas, Representante de Ventas, Contable, Empleado de Marketing, Cliente Online, Operadora, Encargado de Transporte, Jefe de Recursos Humanos y Empleado de Recursos Humanos. La Matriz de Atributos para los actores es la siguiente:

Actores: La matriz de trazabilidad de los actores relaciona a éstos con los casos de uso de tal manera que se puede conocer qué actor utiliza qué caso de uso

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3.4.3. Características del software Características de Software: Las características software son las necesidades de los usuarios propuestas por los stakeholders de la empresa, son los requisitos que debe cumplir el sistema para satisfacer las necesidades de los trabajadores y de la empresa. Las características definidas son las que aparecen en la matriz de atributos, siendo las indicadas como subcaracterísticas las derivadas según una clasificación jerárquicas.

3.4.4. caso de uso. Casos de Uso: derivados de las características software, son el resultado del análisis de las necesidades de los usuarios, cuyas especificaciones están recogidas en el paquete Especificaciones de Casos de Uso definido en Requisite Pro. La matriz de atributos es la siguiente:

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Casos de Uso: La matriz de trazabilidad de los casos de uso relaciona a éstos con las clases de tal manera que se puede conocer qué clase deriva de qué caso de uso. También se ha definido una segunda matriz de trazabilidad para saber los casos de uso que se relacionan con los casos de pruebas.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Casos de Uso: derivados de las características software, son el resultado del análisis de las necesidades de los usuarios, cuyas especificaciones están recogidas en el paquete Especificaciones de Casos de Uso definido en Requisite Pro. La matriz de atributos es la siguiente:

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

PROYECTO FINAL Sistema para Gesti贸n de Art铆culos Deportivos

SKY BLUE, S.A de C.V.

PROYECTO FINAL Sistema para Gesti贸n de Art铆culos Deportivos

SKY BLUE, S.A de C.V.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3.4.5. Clases. Clases: Las clases son requerimientos derivados de los casos de uso como necesidad de representación del modelo de datos. La matriz de atributos de las clases es la siguiente:

Características de Software: La matriz de trazabilidad de las características de software relaciona a éstas con los casos de uso de tal manera que se puede conocer qué caso de uso deriva de qué característica.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Historial de Revisiones Fecha

Versión

Descripción

20/05/2013

0.9

Versión preliminar como propuesta de desarrollo.

22/06/2013

1.0

Versión propuesta para aprobación al final de la fase de inicio.

20/07/2013

1.9

Versión lista para ser revisada al final de la fase de elaboración.

23/08/2013

2.0

Versión revisada por el Stakeholder al final de la fase de elaboración.

20/09/2013

2.1

Versión revisada en la primera iteración de la fase de construcción

22/10/2013

2.9

Versión revisada en la segunda iteración de la fase de construcción, pendiente de revisión del Stakeholder

24/11/2013

3.0

Versión revisada en la segunda iteración de la fase de construcción, pendiente de aprobación del Stakeholder

Autor

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Introducción ...................................................................................................................................................... 121 1.1 Propósito ................................................................................................................................................... 121 1.2 Alcance ..................................................................................................................................................... 122 1.3 Resumen.................................................................................................................................................... 123

Vista General del Proyecto ............................................................................................................................... 123 2.1 2.2 2.3 2.4

Propósito, Alcance y Objetivos................................................................................................................. 123 Suposiciones y Restricciones .................................................................................................................... 124 Entregables del proyecto ........................................................................................................................... 126 Evolución del Plan de Desarrollo del Software......................................................................................... 131

Organización del Proyecto ................................................................................................................................ 131 3.1 Participantes en el Proyecto ...................................................................................................................... 131 3.2 Interfaces Externas.................................................................................................................................... 132 3.3 Roles y Responsabilidades........................................................................................................................ 132

Gestión del Proceso .......................................................................................................................................... 133 4.1 Estimaciones del Proyecto ........................................................................................................................ 133 4.2 Plan del Proyecto ...................................................................................................................................... 133 4.2.1 Plan de las Fases........................................................................................................................... 133 4.2.2 Calendario del Proyecto ............................................................................................................... 136 4.3 Seguimiento y Control del Proyecto ......................................................................................................... 144

Referencias........................................................................................................................................................ 145

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Plan de Desarrollo de Software 105. Introducción Este Plan de Desarrollo del Software es una versión preliminar preparada para ser incluida en la propuesta elaborada como respuesta al proyecto final de la asignatura de Ingeniería de Software de la Universidad del Desarrollo Profesional. Este documento provee una visión global del enfoque de desarrollo propuesto. El proyecto ha sido basado en una 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. 105.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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

105.3 Resumen

Después de esta introducción, el resto del documento está organizado en las siguientes secciones: Vista General del Proyecto — proporciona una descripción del propósito, alcance y objetivos del proyecto, estableciendo los entragbles que serán producidos y utilizados durante el proyecto.. Organización del Proyecto — describe la estructura organizacional del equipo de desarrollo. Gestión del Proceso — explica los costos y planificación estimada, define las fases e hitos del proyecto y describe cómo se realizará su seguimiento. Planes y Guías de aplicación — proporciona una vista global del proceso de desarrollo de software, incluyendo métodos, herramientas y técnicas que serán utilizadas. 106. Vista General del Proyecto 106.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. Deportes the runners 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 esta firma conllevará una previsible adaptación a los nuevos sistemas de información y a la evolución tecnológica. Por ello, Deportes the runners 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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.



Procedimiento de venta mediante la atención de comerciales a domicilio del cliente.



Procedimiento de venta mediante el sistema online, vía web.

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.

|Gestión de Envíos, incluyendo: 

Gestión de Pedidos para envío.



Gestión de recibos.

c) Departamento de Recursos Humanos. d) Departamento de Marketing. e) Departamento de Logística. f) Contabilidad y Facturación.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

gráficamente las entidades del sistema y sus relaciones, Actividad para mostrar los flujos de trabajo.

4) Glosario Es un documento que define los principales términos proyecto. Permite establecer una terminología consensuada. .

y Diagramas de

usados en el

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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.

106.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. 107. Organización del Proyecto 107.1 Participantes en el Proyecto

De momento no se incluye el personal que designará Deportes the runners como Responsable del Proyecto, Comité de Control y Seguimiento, otros participantes que se estimen convenientes para proporcionar los requisitos y validar el sistema. El resto del personal del proyecto (por la parte del la empresa adjudicataria), considerando las fases de Inicio, Elaboración y dos iteraciones de la fase de Construcción, estará formado por los siguientes puestos de trabajo y personal asociado: Jefe de Proyecto. Labor de luis newman flores, alumno de la carrera de Ingeniería de software de la universidad de desarrollo profesional. Con una experiencia modesta en metodologías de desarrollo, herramientas CASE y notaciones, en particular la notación UML y el proceso de desarrollo RUP. Analista de Sistemas. El perfil establecido es: Ingeniero en sistemas computacionales con conocimientos de UML, uno de ellos al menos con experiencia en sistemas afines a la línea del proyecto, labor que llevará a cabo Agustín Duarte Preciado 4 Analistas - Programadores. Con experiencia en el entorno de desarrollo del proyecto, con el fin de que los prototipos puedan ser lo más cercanos posibles al producto final. Este trabajo ha sido encomendado a Agustín Duarte Preciado

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Ingeniero de Software. El perfil establecido es: Ingeniero en sistemas computacionales, realizando labores de gestión de requisitos, gestión de configuración, documentación y diseño de datos. Encargado de las pruebas funcionales del sistema, realizará la labor de José Elí Sandoval Los Currículos Vitae del personal del proyecto que ya ha comprometido su participación se adjuntan por separado. 107.2 Interfaces Externas

Deportes the runners definirá los participantes del proyecto que proporcionarán los requisitos del sistema, y entre ellos quiénes serán los encargados de evaluar los artefactos de acuerdo a cada subsistema y según el plan establecido. El equipo de desarrollo interactuará activamente con los participantes de Deportes the runners para especificación y validación de los artefactos generados. 107.3 Roles y Responsabilidades

A continuación se describen las principales responsabilidades de cada uno de los puestos en el equipo de desarrollo durante las fases de Inicio y Elaboración, de acuerdo con los roles que desempeñan en RUP.

Puesto

Responsabilidad

El jefe de proyecto asigna los recursos, gestiona las prioridades, coordina las interacciones con los clientes y usuarios, y mantiene al equipo del proyecto enfocado en los objetivos. El jefe de proyecto también establece un conjunto de prácticas que aseguran la Jefe de Proyecto integridad y calidad de los artefactos del proyecto. Además, el jefe de proyecto se encargará de supervisar el establecimiento de la arquitectura del sistema. Gestión de riesgos. Planificación y control del proyecto. Analista Sistemas

de Captura, especificación y validación de requisitos, interactuando con el cliente y los usuarios mediante entrevistas. Elaboración del Modelo de Análisis y

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Diseño. Colaboración en la elaboración de las pruebas funcionales y el modelo de datos.

Programador

Ingeniero Software

Construcción de prototipos. Colaboración en la elaboración de las pruebas funcionales, modelo de datos y en las validaciones con el usuario Gestión de requisitos, gestión de configuración y cambios, elaboración del modelo de datos, de preparación de las pruebas funcionales, elaboración de la documentación. Elaborar modelos de implementación y despliegue.

108. Gestión del Proceso 108.1 Estimaciones del Proyecto

El presupuesto del proyecto y los recursos involucrados se adjuntan en un documento separado. 108.2 Plan del Proyecto

En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto. 108.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)

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V. Nro.

Fase

Duración Iteraciones

Fase de Inicio

3 semanas

Fase de Elaboración

2 semanas

Fase de Construcción

7 semanas

Fase Transición

Los hitos que marcan el final de cada fase se describen en la siguiente tabla. Descripción

Hito

Fase de Inicio

Fase de Elaboración

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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.

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

PROYECTO FINAL Sistema para Gesti贸n de Art铆culos Deportivos

SKY BLUE, S.A de C.V.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Disciplinas / modificados

Artefactos

generados

o Comienzo

Aprobación

Semana 1

Semana 3

durante la Fase de Inicio Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio

14/10 20/10

– 28/10 3/11

–

Requisitos Semana 1 Glosario

14/10 20/10

Semana 3 – 28/10 3/11

Semana 2 Visión

21/10 27/10

Semana 3 – 28/10 3/11

Semana 3 Modelo de Casos de Uso

Especificación de Casos de Uso

28/10 3/11

siguiente – fase

Semana 3 28/10

–

siguiente fase

–

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3/11 Semana 3 Especificaciones Adicionales

28/10 3/11

siguiente – fase

Análisis / Diseño Semana 2 Modelo de Análisis / Diseño

21/10 27/10

siguiente – fase

Semana 2 Modelo de Datos

21/10 27/10

siguiente – fase

Implementación Semana 3 Prototipos de Interfaces de Usuario

28/10 3/11

siguiente – fase

Semana 3 Modelo de Implementación

28/10 3/11

siguiente – fase

Pruebas Semana 3 Casos de Pruebas Funcionales

28/10 3/11

siguiente – fase

Despliegue Modelo de Despliegue

Semana 3 28/10

–

siguiente fase

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3/10 Gestión de Cambios y Configuración

Durante todo el proyecto

Gestión del proyecto Semana 1 Plan de Desarrollo del Software en su versión 1.0 y planes de las Iteraciones Ambiente

14/10 20/10

Semana 3 – 28/10 3/11

Durante todo el proyecto

Disciplinas / Artefactos generados o modificados durante la

Comienzo

Aprobación

Fase de Elaboración Modelado del Negocio Semana 1 Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio

14/10 20/10

– aprobado

Requisitos Semana 1 Glosario

14/10 20/10

– aprobado

Semana 2 Visión

Modelo de Casos de Uso

–

21/10 27/10

– aprobado

Semana 3 28/10

Semana 5 –

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3/11

11/12 – 17/12

Semana 3 Especificación de Casos de Uso

28/10 3/11

Semana 5 –

Semana 3 Especificaciones Adicionales

28/10 3/11

11/12 – 17/12

Semana 5 –

11/12 – 17/12

Análisis / Diseño Semana 2 Modelo de Análisis / Diseño

21/10 27/10

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

Semana 2 Modelo de Datos

21/10 27/10

Implementación Semana 3 Prototipos de Interfaces de Usuario

28/10 3/11 Semana 3

Modelo de Implementación

28/10 3/11

Pruebas Semana 3 Casos de Pruebas Funcionales

28/10 3/11

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Disciplinas / Artefactos generados o modificados durante la

Comienzo

Aprobación

Fase de Elaboración Modelado del Negocio Semana 1 Modelo de Casos de Uso del Negocio y 14/10 – aprobado Modelo de Objetos del Negocio 20/10 Requisitos Semana 1 Glosario

14/10 20/10

– aprobado

Semana 2 Visión

21/10 27/10

– aprobado

Semana 3 Modelo de Casos de Uso

28/10 3/11

–

Semana 5 11/12 – 17/12

–

Semana 5 11/12 – 17/12

–

Semana 5 11/12 – 17/12

Semana 3 Especificación de Casos de Uso

28/10 3/11 Semana 3

Especificaciones Adicionales

Análisis / Diseño

28/10 3/11

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Semana 2 Modelo de Análisis / Diseño

21/10 27/10

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

Semana 2 Modelo de Datos

21/10 27/10

Implementación Semana 3 Prototipos de Interfaces de Usuario

28/10 3/11 Semana 3

Modelo de Implementación

28/10 3/11

Pruebas Semana 3 Casos de Pruebas Funcionales

28/10 3/11

Despliegue Semana 3 Modelo de Despliegue

Gestión de Cambios y Configuración

28/10 3/11

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 4 4/11

Revisar en – cada iteración

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

10/11 Ambiente

Durante todo el proyecto

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

109. Referencias 

Pliego de Cláusulas Técnicas para la Definición y Análisis de los Procedimientos del ES-NIC.



Desarrollo de una aplicación informática para el cálculo del personal necesario para la fabricación de carrocerías, utilizando la metodología RUP. – P.F.C. de Ponz Lillo, Daniel.



Visual Modeling with Rational Rose and UML, Terry Quatrani. - AddisonWesley.



Documentación de Rational Unified Process, manuals de ayuda, tutoriales, etc.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

4.0. Análisis y Diseño. El análisis del sistema es una atapa de la fase de planificación y en ella se realiza una descripción del entorno, software que se quiere obtener y se define los recursos humanos para su desarrollo, el coste y el calendario estimado.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

En concreto, el análisis del sistema presenta los siguientes objetivos:     

Identificar las necesidades del cliente. Realizar un análisis técnico y económico del sistema. Establecer restricciones de costo y tiempo. Evaluar la viabilidad del sistema. Asignar funciones al software, a la gente, a las bases de datos y otros elementos del sistema.  Definir el sistema.

Análisis del Sistema: Define los flujos de información, las estructuras primarias de datos, las características funcionales del sistema, los requerimientos de rendimiento y las restricciones impuestas por el cliente. Así mismo, se incorporarán los criterios globales de validación que se utilizarán para probar que los requisitos señalados han sido implementados.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Modelo de Análisis/Diseño: Diagrama de Clases

PROYECTO FINAL Sistema para Gesti贸n de Art铆culos Deportivos

SKY BLUE, S.A de C.V.

Modelo de Datos: Modelo Relacional

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

5.0. Implementación. La fase de implementación de un sistema es la fase más costosa y que consume más tiempo, se dice que es costosa por que muchas personas, herramientas y recursos, están involucrados en el proceso y consume mucho tiempo porque se completa todo el trabajo realizado previamente durante las demás fases. En esta fase se instala el nuevo sistema de información para que empiece a trabajar y se capacita a sus usuarios para que puedan utilizarlo. La instalación puede realizarse según 4 métodos: 1. Directo 2. Paralelo 3. piloto y 4. en Fase. MÉTODO DIRECTO Se abandona el sistema antiguo y se adopta inmediatamente el nuevo. Esto puede ser sumamente riesgoso porque si algo marcha mal, es imposible volver al sistema anterior, las correcciones deberán hacerse bajo la marcha. Regularmente con un sistema nuevo suelen surgir problemas de pequeña y gran escala. Si se trata de grandes sistemas, un problema puede significar una catástrofe, perjudicando o retrasando el desempeño entero de la organización. MÉTODO PARALELO Los sistemas de información antiguo y nuevo operan juntos hasta que el nuevo demuestra ser confiable. Este método es de bajo riesgo. Si el sistema nuevo falla, la organización puede mantener sus actividades con el personal y equipo para laborar con los dos sistemas, por lo que este método se reserva específicamente para casos en los que el costo de una falla sería considerable. MÉTODO DE FASES La implementación del sistema se divide en partes o fases, que se van realizando a lo largo de un período de tiempo, sucesivamente. Una vez iniciada la primera fase, la segunda no se inicia hasta que la primera se completado con éxito. Así se continúa hasta que se finaliza con la última fase. Es costoso porque se hace más lenta la implementación, pero sin duda tiene menor riesgo.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

PROTOTIPO DE INTERFACES DE USUARIO 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. La interfaz que se presenta en la identificación se puede ver en el siguiente imagen

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Para consultar los detalles de una incidencia el prototipo de interfaz gráfica es el siguiente:

Gestión de Ventas Para el subsistema de ventas el prototipo de interfaz gráfica es el de elaborar pedido.

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

En la pestaña de en 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.

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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:

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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Por último, al hacer doble clic sobre una línea de pedido, la interfaz gráfica que surge es

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Historial de Revisiones Fecha

Versión

Descripción

20/05/2013

0.9

Versión preliminar como propuesta de desarrollo.

22/06/2013

1.0

Versión propuesta para aprobación al final de la fase de inicio.

20/07/2013

1.9

Versión lista para ser revisada al final de la fase de elaboración.

23/08/2013

2.0

Versión revisada por el Stakeholder al final de la fase de elaboración.

20/09/2013

2.1

Versión revisada en la primera iteración de la fase de construcción

22/10/2013

2.9

Versión revisada en la segunda iteración de la fase de construcción, pendiente de revisión del Stakeholder

24/11/2013

3.0

Versión revisada en la segunda iteración de la fase de construcción, pendiente de aprobación del Stakeholder

Autor

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Introducción.......................................................................................................................................................121 1.1 Propósito....................................................................................................................................................121 1.2 Alcance ......................................................................................................................................................122 1.3 Resumen ....................................................................................................................................................123

Vista General del Proyecto ................................................................................................................................ 123 2.1 2.2 2.3 2.4

Propósito, Alcance y Objetivos .................................................................................................................123 Suposiciones y Restricciones.....................................................................................................................124 Entregables del proyecto ........................................................................................................................... 126 Evolución del Plan de Desarrollo del Software .........................................................................................131

Organización del Proyecto ................................................................................................................................ 131 3.1 Participantes en el Proyecto.......................................................................................................................131 3.2 Interfaces Externas ....................................................................................................................................132 3.3 Roles y Responsabilidades ........................................................................................................................132

Gestión del Proceso ...........................................................................................................................................133 4.1 Estimaciones del Proyecto.........................................................................................................................133 4.2 Plan del Proyecto .......................................................................................................................................133 4.2.1 Plan de las Fases ........................................................................................................................... 133 4.2.2 Calendario del Proyecto ................................................................................................................136 4.3 Seguimiento y Control del Proyecto..........................................................................................................144

Referencias ........................................................................................................................................................145

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Plan de Desarrollo de Software 110.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

110.3 Resumen Después de esta introducción, el resto del documento está organizado en las siguientes secciones: Vista General del Proyecto — proporciona una descripción del propósito, alcance y objetivos del proyecto, estableciendo los entragbles que serán producidos y utilizados durante el proyecto.. Organización del Proyecto — describe la estructura organizacional del equipo de desarrollo. Gestión del Proceso — explica los costos y planificación estimada, define las fases e hitos del proyecto y describe cómo se realizará su seguimiento. Planes y Guías de aplicación — proporciona una vista global del proceso de desarrollo de software, incluyendo métodos, herramientas y técnicas que serán utilizadas. 111.

Vista General del Proyecto

111.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. Deportes the runners 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 esta firma conllevará una previsible adaptación a los nuevos sistemas de información y a la evolución tecnológica. Por ello, Deportes the runners 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: b) 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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

 b)

Procedimiento de venta mediante el sistema online, vía web. 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.

Gestión de Envíos, incluyendo: 

Gestión de Pedidos para envío.



Gestión de recibos.

g) Departamento de Recursos Humanos. h) Departamento de Marketing. i) Departamento de Logística. j) Contabilidad y Facturación.

111.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: d) 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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

f) 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 the runners Como es natural, la lista de suposiciones y restricciones se incrementará durante el desarrollo del proyecto, particularmente una vez establecido el artefacto “Visión”. 111.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.

22)Plan de Desarrollo del Software Es el presente documento.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

25)Glosario Es un documento que define los principales términos usados en el proyecto. Permite establecer una terminología consensuada. .

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

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

28)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 nofuncionales 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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

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

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

40)Manual de Instalación Este documento incluye las instrucciones para realizar la instalación del producto.

41)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

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

Organización del Proyecto

112.1 Participantes en el Proyecto De momento no se incluye el personal que designará Deportes the runners como Responsable del Proyecto, Comité de Control y Seguimiento, otros participantes que se estimen convenientes para proporcionar los requisitos y validar el sistema. El resto del personal del proyecto (por la parte del la empresa adjudicataria), considerando las fases de Inicio, Elaboración y dos iteraciones de la fase de Construcción, estará formado por los siguientes puestos de trabajo y personal asociado: Jefe de Proyecto. Labor de luis newman flores, alumno de la carrera de Ingeniería de software de la universidad de desarrollo profesional. Con una experiencia modesta en metodologías de desarrollo, herramientas CASE y notaciones, en particular la notación UML y el proceso de desarrollo RUP. Analista de Sistemas. El perfil establecido es: Ingeniero en sistemas computacionales con conocimientos de UML, uno de ellos al menos con experiencia en sistemas afines a la línea del proyecto, labor que llevará a cabo Agustín Duarte Preciado 4 Analistas - Programadores. Con experiencia en el entorno de desarrollo del proyecto, con el fin de que los prototipos puedan ser lo más cercanos posibles al producto final. Este trabajo ha sido encomendado a Agustín Duarte Preciado Ingeniero de Software. El perfil establecido es: Ingeniero en sistemas computacionales, realizando labores de gestión de requisitos, gestión de configuración, documentación y diseño de datos. Encargado de las pruebas funcionales del sistema, realizará la labor de José Elí Sandoval

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Los Currículos Vitae del personal del proyecto que ya ha comprometido su participación se adjuntan por separado. 112.2 Interfaces Externas Deportes the runners definirá los participantes del proyecto que proporcionarán los requisitos del sistema, y entre ellos quiénes serán los encargados de evaluar los artefactos de acuerdo a cada subsistema y según el plan establecido. El equipo de desarrollo interactuará activamente con los participantes de Deportes the runners para especificación y validación de los artefactos generados. 112.3 Roles y Responsabilidades A continuación se describen las principales responsabilidades de cada uno de los puestos en el equipo de desarrollo durante las fases de Inicio y Elaboración, de acuerdo con los roles que desempeñan en RUP.

Puesto

Responsabilidad

Analista Sistemas

Programador

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

datos y en las validaciones con el usuario

Ingeniero Software

113.

Gestión de requisitos, gestión de configuración y cambios, elaboración del modelo de datos, de preparación de las pruebas funcionales, elaboración de la documentación. Elaborar modelos de implementación y despliegue.

Gestión del Proceso

113.1 Estimaciones del Proyecto El presupuesto del proyecto y los recursos involucrados se adjuntan en un documento separado. 113.2 Plan del Proyecto En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto. 113.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) Nro. Fase

Duración Iteraciones

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Fase de Inicio

3 semanas

Fase de Elaboración

2 semanas

Fase de Construcción

7 semanas

Fase Transición

Los hitos que marcan el final de cada fase se describen en la siguiente tabla. Descripción

Hito

Fase de Inicio

Fase de Elaboración

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

Fase de Transición

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Disciplinas / modificados

Artefactos

generados

o Comienzo

Aprobación

Semana 1

Semana 3

durante la Fase de Inicio Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio

14/10 20/10

– 28/10 3/11

–

Requisitos Semana 1 Glosario

14/10 20/10 Semana 2

Visión

21/10 27/10

Semana 3 – 28/10 3/11 Semana 3 – 28/10 3/11

Semana 3 Modelo de Casos de Uso

28/10 3/11

siguiente – fase

Semana 3 Especificación de Casos de Uso

28/10 3/11

–

siguiente – fase

–

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Semana 3 Especificaciones Adicionales

28/10 3/11

siguiente – fase

Análisis / Diseño Semana 2 Modelo de Análisis / Diseño

21/10 27/10

siguiente – fase

Semana 2 Modelo de Datos

21/10 27/10

siguiente – fase

Implementación Semana 3 Prototipos de Interfaces de Usuario

28/10 3/11

siguiente – fase

Semana 3 Modelo de Implementación

28/10 3/11

siguiente – fase

Pruebas Semana 3 Casos de Pruebas Funcionales

28/10 3/11

siguiente – fase

Despliegue Semana 3 Modelo de Despliegue

Gestión de Cambios y Configuración

28/10 3/10

siguiente – fase

Durante todo el proyecto

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Gestión del proyecto Semana 1 Plan de Desarrollo del Software en su versión 1.0 y planes de las Iteraciones Ambiente

14/10 20/10

Semana 3 – 28/10 3/11

–

Durante todo el proyecto

Disciplinas / Artefactos generados o modificados durante la

Comienzo

Aprobación

Fase de Elaboración Modelado del Negocio Semana 1 Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio

14/10 20/10

– aprobado

Requisitos Semana 1 Glosario

14/10 20/10

– aprobado

Semana 2 Visión

21/10 27/10

– aprobado

Semana 3 Modelo de Casos de Uso

Especificación de Casos de Uso

28/10 3/11 Semana 3 28/10

Semana 5 –

11/12 – 17/12 Semana 5

– 11/12 – 17/12

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

3/11 Semana 3 Especificaciones Adicionales

28/10 3/11

Semana 5 –

11/12 – 17/12

Análisis / Diseño Semana 2 Modelo de Análisis / Diseño

21/10 27/10

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

Semana 2 Modelo de Datos

21/10 27/10

Implementación Semana 3 Prototipos de Interfaces de Usuario

28/10 3/11 Semana 3

Modelo de Implementación

28/10 3/11

Pruebas Semana 3 Casos de Pruebas Funcionales

28/10 3/11

Disciplinas / Artefactos generados o modificados durante la Fase de Elaboración

Comienzo

Aprobación

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Modelado del Negocio Semana 1 Modelo de Casos de Uso del Negocio y 14/10 – aprobado Modelo de Objetos del Negocio 20/10 Requisitos Semana 1 Glosario

14/10 20/10

– aprobado

Semana 2 Visión

21/10 27/10

– aprobado

Semana 3 Modelo de Casos de Uso

–

Semana 5 11/12 – 17/12

–

Semana 5 11/12 – 17/12

–

Semana 5 11/12 – 17/12

21/10 27/10

–

Revisar en cada iteración

Semana 2

Revisar en – cada iteración

28/10 3/11 Semana 3

Especificación de Casos de Uso

28/10 3/11 Semana 3

Especificaciones Adicionales

28/10 3/11

Análisis / Diseño Semana 2 Modelo de Análisis / Diseño

Modelo de Datos

21/10

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

27/10 Implementación Semana 3 Prototipos de Interfaces de Usuario

28/10 3/11

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

–

Revisar en cada iteración

Semana 3 Modelo de Implementación

28/10 3/11

Pruebas Semana 3 Casos de Pruebas Funcionales

28/10 3/11

Despliegue Semana 3 Modelo de Despliegue

Gestión de Cambios y Configuración

28/10 3/11

Durante todo el proyecto

Gestión del proyecto Semana 4 Plan de Desarrollo del Software en su versión 2.0 y planes de las Iteraciones Ambiente

4/11 10/11

–

Revisar en cada iteración

Durante todo el proyecto

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

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

Referencias 

Pliego de Cláusulas Técnicas para la Definición y Análisis de los Procedimientos del ES-NIC.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.



Desarrollo de una aplicación informática para el cálculo del personal necesario para la fabricación de carrocerías, utilizando la metodología RUP. – P.F.C. de Ponz Lillo, Daniel.



Visual Modeling with Rational Rose and UML, Terry Quatrani. - AddisonWesley.



Documentación de Rational Unified Process, manuals de ayuda, tutoriales, etc.

FASE 6. PRUEBAS DE IMPLEMENTACION.

Historial de Revisiones Fecha

Versión

Descripción

Autor

8/11/2002

0.9

Versión preliminar a falta de aprobación del Stakeholder

Rosa María Ogallar

14/11/2002

1.0

Versión revisada por el Stakeholder

Rosa María Ogallar

26/11/2002

1.9

Versión con diversas modificaciones no revisadas por el Stakeholder

Rosa María Ogallar

09/12/2002

2.0

Versión con detalles y ajustes a la aplicación en desarrollo.

César López Rodríguez

15/12/2002

2.9

Versión generada en la segunda release con evaluación de las pruebas actualizados.

Rosa María Ogallar

21/12/2002

3.0

Versión generada en la segunda release con nuevas pruebas a falta de aprobación por le Stakeholder

Rosa María Ogallar

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Descripción

Elaborar pedido y enviar a almacén 2.1 2.2 2.3 2.4 2.5

Elaborar pedido y guardar 3.1 3.2 3.3 3.4 3.5

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

185 185 185 185 185 186 186 186

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

186 186 186 187 187

Elaborar pedido vacío y guardar

187

4.1 4.2 4.3 4.4 4.5

187 187 188 188 188

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Elaborar pedido vacío y enviar al almacén

188

5.1 5.2 5.3 5.4 5.5

188 188 189 189 189

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Modificar pedido resultando dos líneas con el mismo producto

189

6.1 6.2 6.3 6.4 6.5

189 189 190 190 190

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

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

190

7.1 7.2 7.3 7.4 7.5

190 191 191 191 191

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Modificar un pedido añadiendo un producto inexistente

191

8.1

191

Descripción

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

8.2 8.3 8.4 8.5 9.

Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

192 192 192 192

Modificar pedido añadiendo / eliminando una línea de pedido y enviar a almacén

193

9.1 9.2 9.3 9.4 9.5

193 193 193 193 194

10.

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba Modificar pedido añadiendo / eliminando una línea de pedido y guardar

10.1 10.2 10.3 10.4 10.5 11.

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba .Modificar dirección de envío del pedido

11.1 11.2 11.3 11.4 11.5 12.

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba Modificar pedido eliminando todas sus líneas

12.1 12.2 12.3 12.4 12.5 13.

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba Eliminar pedido

13.1 13.2 13.3 13.4 13.5 14.

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba Comprobar ratio de pago del cliente

14.1 14.2 14.3 14.4 14.5

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

194 194 194 194 195 195 195 195 195 195 196 196 196 196 196 196 197 197 197 197 197 197 198 198 198 198 198 198 199 199

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

115. 1.

Descripción

Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso “Elaborar Pedido”. La pruebas realizadas a este caso de uso son:            

Elaborar pedido y enviar a almacén. Elaborar pedido y guardar. Elaborar pedido vacío y guardar. Elaborar pedido vacío y enviar al almacén. Modificar pedido resultando dos líneas con el mismo producto. Modificar pedido añadiendo una línea de cantidad fuera de rango. Modificar pedido añadiendo un producto inexistente. Modificar pedido, añadiendo / eliminando una línea de pedido, y enviar a almacén. Modificar pedido, añadiendo / eliminando una línea de pedido, y guardar. Modificar dirección de correo del pedido. Modificar pedido eliminando todas sus líneas. Eliminar pedido.

El entorno del cual partiremos para realizar la prueba será el formulario de entrada de la aplicación.

116. 2.

Elaborar pedido y enviar a almacén

117. 2.1

Descripción

Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamos elaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración de dicho pedido. Una vez elaborado escogeremos la opción enviar a almacén. 118. 2.2

Condiciones de ejecución

Las condiciones de ejecución del caso de prueba son que el usuario operadora “maria” está dado de alta en la base de datos de empleado y su clave correspondiente y que el cliente Jaime con DNI 48315682-N también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver toda la especificación completa de los datos. 119. 2.3

Entrada       

Introducimos ‘maria’ en el campo usuario Introducimos ‘nike’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de una operadora. El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operadora. La operadora introduce el DNI del cliente apareciendo en el formulario los datos completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que ya ha enviado al almacén.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

   

   120. 2.4

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

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

Evaluación de la Prueba

Prueba superada con éxito

122. 3.

Elaborar pedido y guardar

123. 3.1

Descripción

Condiciones de ejecución

125. 3.3

Entrada     

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

      

  126. 3.4

La operadora introduce el DNI del cliente apareciendo en el formulario los datos completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que ya ha enviado al almacén. El cliente solicita hacer un nuevo pedido. La operadora pulsa el botón “nuevo”. El sistema muestra la interfaz propia de la modificación de un pedido. El cliente solicita comprar un par de raquetas. La operadora introduce una línea de pedido: o Introduce ‘4’ en código artículo o Se rellena automáticamente los campos nombre y precio. o Introduce ‘2’ en cantidad o Pulsa el botón “añadir línea” o Se actualiza automáticamente el precio total El cliente solicita a la operadora finalizar el pedido escogiendo la opción guardar pedido. La operadora pulsa el botón “guardar”. Resultado esperado

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

Evaluación de la Prueba

Prueba superada con éxito

128. 4.

Elaborar pedido vacío y guardar

129. 4.1

Descripción

Nos introducimos en el sistema como usuario representante de ventas, accediendo a su funcionalidad y solicitamos elaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración de dicho pedido. Una vez dentro intentaremos guardar o enviar la orden sin haber añadido ninguna línea de pedido para observar como responde el sistema. 130. 4.2

Condiciones de ejecución

Las condiciones de ejecución del caso de prueba son que el usuario representante de ventas “luis”, representante de ventas está dado de alta en la base de datos de empleado y su clave correspondiente y que el cliente Jaime con DNI 48315682-N también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver toda la especificación completa de los datos.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

131. 4.3

Entrada           

132. 4.4

Introducimos ‘luis’ en el campo usuario Introducimos ‘reebok’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un representante de ventas. El cliente ‘Javier’ con DNI ‘22496359P’ contacta con el representante de ventas. El representante de ventas introduce el DNI del cliente apareciendo en el formulario los datos completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que ya ha enviado al almacén. El cliente solicita hacer un nuevo pedido. El representante de ventas pulsa el botón “nuevo”. El sistema muestra la interfaz propia de la elaborar un nuevo pedido. El representante de ventas pulsa el botón guardar. Resultado esperado

El sistema muestra un mensaje de error avisando al cliente de que no es posible almacenar en el sistema un pedido vacío. 133. 4.5

Evaluación de la Prueba

Prueba superada con éxito

134. 5.

Elaborar pedido vacío y enviar al almacén

135. 5.1

Descripción

Condiciones de ejecución

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

137. 5.3

Entrada           

138. 5.4

Introducimos ‘luis’ en el campo usuario Introducimos ‘reebok’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un representante de ventas. El cliente ‘Jaime’ con DNI ‘48315682N’ contacta con el representante de ventas. El representante de ventas introduce el DNI del cliente apareciendo en el formulario los datos completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que ya ha enviado al almacén. El cliente solicita hacer un nuevo pedido. El representante de ventas pulsa el botón “nuevo”. El sistema muestra la interfaz propia de la elaborar un nuevo pedido. El representante de ventas pulsa el botón enviar a almacén Resultado esperado

El sistema muestra un mensaje de error avisando al cliente de que no es posible almacenar en el sistema un pedido vacío. 139. 5.5

Evaluación de la Prueba

Prueba superada con éxito

140. 6.

Modificar pedido resultando dos líneas con el mismo producto

141. 6.1

Descripción

Nos introducimos en el sistema como usuario representante de ventas, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración de dicho pedido. Aparece una lista de pedidos solicitados por el cliente que están en proceso de elaboración. Seleccionaremos uno de ellos y lo editaremos para poder añadir una línea de pedido asociada a un producto ya incluido en el pedido. 142. 6.2

Condiciones de ejecución

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

143. 6.3

Entrada           

144. 6.4

Introducimos ‘luis’ en el campo usuario Introducimos ‘reebok’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un representante de ventas. El cliente ‘Javier’ con DNI ‘22496359P’ contacta con el representante de ventas. El representante de ventas introduce el DNI del cliente apareciendo en el formulario los datos completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que ya ha enviado al almacén. El representante de ventas selecciona el pedido con código “2” y pulsa el botón “modificar”. El sistema muestra la interfaz propia de la modificación de un pedido. El cliente solicita añadir un producto al pedido. Introduce una nueva línea de pedido: o Introduce ‘ 4’ en código artículo o Se rellena automáticamente los campos nombre y precio. o Introduce ‘1’ en cantidad o Pulsa el botón “añadir línea” Resultado esperado

El sistema nos muestra un mensaje de aviso informándonos de que en ese pedido ya existe una línea asociada a ese código de artículo y pregunta si desea sobrescribirla o cancelar. 145. 6.5

Evaluación de la Prueba

Prueba superada con éxito

146. 7.

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

rango 147. 7.1

Descripción

Nos introducimos en el sistema como usuario representante de ventas, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración de dicho pedido. Aparece una lista de pedidos solicitados por el cliente que están en proceso de elaboración. Seleccionaremos uno de ellos y lo editaremos para poder añadir una línea de pedido, 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.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

148. 7.2

Condiciones de ejecución

Entrada           

150. 7.4

Introducimos ‘luis’ en el campo usuario Introducimos ‘reebok’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un representante de ventas. El cliente ‘Javier’ con DNI ‘22496359P’ contacta con el representante de ventas. El representante de ventas introduce el DNI del cliente apareciendo en el formulario los datos completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que ya ha enviado al almacén. El representante de ventas selecciona el pedido con código “2” y pulsa el botón “modificar”. El sistema muestra la interfaz propia de la modificación de un pedido. El cliente solicita añadir un producto al pedido. Introduce una nueva línea de pedido: o Introduce ‘3’ en código artículo o Se rellena automáticamente los campos nombre y precio. o Introduce ‘0’ en cantidad o Introduce ‘10000’ en cantidad Resultado esperado

El sistema nos muestra para cada una de las cantidades introducidas un mensaje de error indicándonos que estamos introduciendo una cantidad errónea ya que está fuera del rango permitido. 151. 7.5

Evaluación de la Prueba

Prueba superada con éxito.

152. 8.

Modificar un pedido añadiendo un producto inexistente

153. 8.1

Descripción

Nos introducimos en el sistema como usuario representante de ventas, el sistema nos mostrara una

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

interfaz para que llevemos a cabo la elaboración de dicho pedido. Aparece una lista de pedidos solicitados por el cliente que están en proceso de elaboración. Seleccionaremos uno de ellos y lo editaremos para poder añadir una línea de pedido asociada a un producto ya incluido en el pedido y añadir un producto inexistente. 154. 8.2

Condiciones de ejecución

Entrada           

156. 8.4

Introducimos ‘luis’ en el campo usuario Introducimos ‘reebok’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un representante de ventas. El cliente ‘Javier’ con DNI ‘22496359P’ contacta con el representante de ventas. El representante de ventas introduce el DNI del cliente apareciendo en el formulario los datos completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que ya ha enviado al almacén. El representante de ventas selecciona el pedido con código “2” y pulsa el botón “modificar”. El sistema muestra la interfaz propia de la modificación de un pedido. El cliente solicita añadir un producto al pedido. Introduce una nueva línea de pedido: o Introduce ‘7’ en código artículo o Pulsa el botón “añadir línea” Resultado esperado

El sistema nos muestra un mensaje de error informándonos de que el artículo introducido no existe. 157. 8.5

Evaluación de la Prueba

Prueba superada con éxito.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

158. 9.

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

enviar a almacén 159. 9.1

Descripción

Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamos elaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración de dicho pedido, que consistirá en añadir una nueva línea de pedido y eliminar una de las existentes de un pedido en elaboración. Una vez elaborado escogeremos la opción enviar a almacén.

160. 9.2

Condiciones de ejecución

Entrada           

    162. 9.4

Introducimos ‘maria’ en el campo usuario Introducimos ‘nike’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un operador. El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operadora. La operadora introduce el DNI del cliente apareciendo en el formulario los datos completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que ya ha enviado al almacén. El cliente solicita hacer modificaciones al pedido ‘1’. La operadora selecciona el pedido en cuestión y pulsa el botón modificar, aparece el formulario del pedido. El cliente solicita añadir un par de raquetas al pedido. La operadora introduce una línea de pedido: o Introduce ‘ 4’ en código artículo o Se rellena automáticamente los campos descripción y precio. o Introduce ‘2’ en cantidad o Pulsa el botón “añadir línea” o Se actualiza automáticamente el precio total El cliente solicita eliminar el par de zapatillas incluidas en el pedido. La operadora elimina la línea de pedido correspondiente al producto que se desea eliminar. El cliente solicita a la operadora finalizar el pedido escogiendo la opción enviar a almacén. La operadora pulsa el botón enviar a almacén Resultado esperado

El sistema almacena las nuevas modificaciones del pedido seleccionado.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

163. 9.5

Evaluación de la Prueba

Prueba superada con éxito

10.

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

164. 10.1

Descripción

Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamos elaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración de dicho pedido, que consistirá en 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. 165. 10.2

Condiciones de ejecución

166. 10.3

Entrada           

Introducimos ‘luis’ en el campo usuario Introducimos ‘reebok’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia del un representante de ventas. El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operador. El operador introduce el DNI del cliente apareciendo en el formulario los datos completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que ya ha enviado al almacén. El cliente solicita hacer modificaciones al pedido ‘4’. El representante de ventas selecciona el pedido en cuestión y pulsa el botón “modificar”, aparece la interfaz de modificar pedido. El cliente solicita añadir un par de zapatillas al pedido. El operador introduce una línea de pedido: o Introduce ‘ 1’ en código artículo o Se rellena automáticamente los campos nombre y precio. o Introduce ‘1’ en cantidad o Pulsa el botón “añadir línea” o Se actualiza automáticamente el precio total

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

    167. 10.4

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

El sistema almacena las nuevas modificaciones del pedido seleccionado. 168. 10.5

Evaluación de la Prueba

Prueba superada con éxito 169. 170.

171. 11.

.Modificar dirección de envío del pedido

172. 11.1

Descripción

Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamos elaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración de dicho pedido, que consistirá en modificar la dirección de envío de un pedido en elaboración. 173. 11.2

Condiciones de ejecución

Entrada       

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

   

 175. 11.4

ya ha enviado al almacén. El cliente solicita modificar la dirección de envío del pedido ‘4’. El representante de ventas selecciona el pedido en cuestión y pulsa el botón modificar, aparece el formulario de modificar pedido. El cliente da la nueva dirección de envío al operador. El representante de ventas introduce la nueva dirección : o Introduce ‘C/ Bailén’ en el campo Calle o Introduce ‘2’ en el campo Nº o Introduce ‘23’ en el campo Pta El representante de ventas pulsa el botón guardar Resultado esperado

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

Evaluación de la Prueba

Prueba superada con éxito

177. 12.

Modificar pedido eliminando todas sus líneas

178. 12.1

Descripción

Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamos elaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración de dicho pedido, que consistirá en modificar la dirección de envío de un pedido en elaboración. 179. 12.2

Condiciones de ejecución

Las condiciones de ejecución del caso de prueba son que el usuario operadora “luis” está dado de alta en la base de datos de empleado y su clave correspondiente y que el cliente Jaime con DNI 48315682-N también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver toda la especificación completa de los datos. 180. 12.3

Entrada       

Introducimos ‘luis’ en el campo usuario Introducimos ‘reebok’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un operador. El cliente ‘Javier’ con DNI ‘22496359P’ llama a la operadora. La operadora introduce el DNI del cliente apareciendo en el formulario los datos completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

 

181. 12.4

ya ha enviado al almacén. La operadora selecciona el pedido ‘2’ y pulsa el botón “modificar” y aparece la interfaz de modificar pedido. La operadora elimina las dos líneas de pedido que componen el pedido, pulsando sucesivamente el botón “eliminar línea”. Resultado esperado

El sistema muestra un mensaje de error que nos informa de que no es posible eliminar todas las líneas de pedido de un cierto pedido. 182. 12.5

Evaluación de la Prueba

Prueba superada con éxito

183. 13.

Eliminar pedido

184. 13.1

Descripción

Condiciones de ejecución

Entrada       

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

  

El cliente solicita eliminar el pedido ‘10’. La operadora selecciona el pedido en cuestión y pulsa el botón “cancelar pedido”. El sistema muestra un mensaje de aviso de borrado y solicita la confirmación. La operadora confirma la eliminación del pedido al cliente pulsando el botón “aceptar”.

187. 188. 13.4

Resultado esperado

El pedido seleccionado es eliminado del sistema. 189. 13.5

Evaluación de la Prueba

Prueba superada con éxito.

14.

Comprobar ratio de pago del cliente

15. 14.1

Descripción

Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamos elaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración de dicho pedido, que consistirá en elegir una modalidad de pago que no corresponde con el ratio de pago del cliente. 16. 14.2

Condiciones de ejecución

Las condiciones de ejecución del caso de prueba son que el usuario operadora “maria” está dado de alta en la base de datos de empleado y su clave correspondiente y que el cliente Javier con DNI 22496359-P también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver toda la especificación completa de los datos. 17. 14.3

Entrada        

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

   

  18. 14.4

La operadora pulsa el botón “nuevo”. El sistema muestra la interfaz propia de la realización de un pedido. El cliente solicita comprar un par de sudaderas. La operadora introduce una línea de pedido: o Introduce ‘3’ en código artículo o Se rellena automáticamente los campos nombre y precio. o Introduce ‘2’ en cantidad o Pulsa el botón “añadir línea” o Se actualiza automáticamente el precio total El cliente solicita a la operadora pago a crédito. La operadora pincha en el desplegable forma de pago Resultado esperado

No es posible escoger la opción a crédito porque el ratio del cliente solo permite al contado. 19. 14.5

Evaluación de la Prueba

Prueba superada con éxito

Historial de Revisiones Fecha

Versión

Descripción

Autor

03/01/2003

0.9

Versión preliminar a falta de aprobación del Stakeholder

Rosa María Ogallar

07/01/2003

1.0

Versión con ajustes respecto a las interfaces

Rosa María Ogallar

10/01/2003

2.0

Versión lista Stakeholder

Rosa María Ogallar

15/01/2003

3.0

Versión preparada para la segunda iteración de la fase de construcción

para

revisión

con

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Descripción

201

Pasar pedido completo a envío desde la lista de pedidos en atención

201

2.1 2.2 2.3 2.4 2.5

201 201 201 201 201

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Pasar pedido completo a envío desde atender pedido

202

3.1 3.2 3.3 3.4 3.5

202 202 202 202 202

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Cancelar al pasar un pedido incompleto a envío

202

4.1 4.2 4.3 4.4 4.5

202 203 203 203 203

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Pasar a envío un pedido incompleto generando un pedido con las cantidades restantes

203

5.1 5.2 5.3 5.4 5.5

203 203 204 204 204

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Pasar a envío un pedido incompleto sin generar un pedido con las cantidades restantes

204

6.1 6.2 6.3 6.4 6.5

204 204 205 205 205

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

20.

Descripción Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso “Pasar Pedido a Envío”. La pruebas realizadas a este caso de uso son:     

Pasar pedido a envío desde la lista de pedidos en atención. Pasar pedido a envío desde atender pedido. Cancelar al pasar un pedido incompleto a envío. Pasar a envío un pedido incompleto generando un pedido con las cantidades restantes. Pasar a envío un pedido incompleto sin generar un pedido con las cantidades restantes.

El entorno del cual partiremos para realizar la prueba será el formulario de entrada de la aplicación

21.

Pasar pedido completo a envío desde la lista de pedidos en atención

21.1

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

21.3

Entrada      

21.4

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

21.5

Evaluación de la Prueba

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Prueba superada con éxito.

22.

Pasar pedido completo a envío desde atender pedido

22.1

Descripción Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad y solicitamos consultar pedidos en atención, el sistema nos mostrara una lista con los pedidos en atención que haya almacenados en el sistema. Seleccionaremos un pedido y después de comprobar desde la opción atender pedido que tiene todas las cantidades asignadas lo pasaremos a envío.

22.2

22.3

Entrada      

22.4

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

22.5

Evaluación de la Prueba Prueba superada con éxito.

23.

Cancelar al pasar un pedido incompleto a envío

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

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

atención que haya almacenados en el sistema. Seleccionaremos un pedido incompleto y lo pasaremos a envío, cancelando seguidamente dicha decisión. 23.2

23.3

Entrada        

23.4

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. Seleccionamos de la lista de pedidos en atención el pedido de código ‘7’. Pulsamos el botón ‘Pasar a listo para envío’. Nos aparece un mensaje de confirmación que nos indica que el pedido esta incompleto. Elegimos la opción ‘Cancelar’.

Resultado esperado El pedido no se modifica por dicha acción y sigue almacenado en el sistema con estado en atención.

23.5

Evaluación de la Prueba Prueba superada con éxito.

24.

Pasar a envío un pedido incompleto generando un pedido con las cantidades restantes

24.1

Descripción Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad y solicitamos consultar pedidos en atención, el sistema nos mostrara una lista con los pedidos en atención que haya almacenados en el sistema. Seleccionaremos un pedido incompleto y lo pasaremos a envío, responderemos afirmativamente a la confirmación de paso de envío y responderemos afirmativamente a la creación de un pedido con las cantidades restantes.

24.2

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

24.3

Entrada          

24.4

Resultado esperado El pedido se almacena en el sistema con estado listo para envío y se almacena un nuevo pedido en el sistema con las cantidades que restaron del anterior con estado en elaboración.

24.5

Evaluación de la Prueba Prueba superada con éxito.

25.

Pasar a envío un pedido incompleto sin generar un pedido con las cantidades restantes

25.1

Descripción Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad y solicitamos consultar pedidos en atención, el sistema nos mostrara una lista con los pedidos en atención que haya almacenados en el sistema. Seleccionaremos un pedido incompleto y lo pasaremos a envío, responderemos afirmativamente a la confirmación de paso de envío y responderemos negativamente a la creación de un pedido con las cantidades restantes.

25.2

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

25.3

Entrada          

25.4

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. Seleccionamos de la lista de pedidos en atención el pedido de código ‘8’. Pulsamos el botón ‘Pasar a listo para envío’. Nos aparece un mensaje de confirmación que nos indica que el pedido esta incompleto. Elegimos la opción ‘Aceptar’. Nos aparece un mensaje de confirmación sobre la creación de un pedido con las cantidades restantes. Elegimos la opción ‘Cancelar’.

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

25.5

Evaluación de la Prueba Prueba superada con éxito.

Historial de Revisiones Fecha

Versión

Descripción

Autor

11/01/2003

0.9

Versión preliminar a falta de aprobación del Stakeholder

Rosa María Ogallar

07/01/2003

1.0

Versión con ajustes respecto a las interfaces

Rosa María Ogallar

10/01/2003

2.0

Versión lista Stakeholder

Rosa María Ogallar

15/01/2003

2.9

Versión preparada para la segunda iteración de la fase de construcción

César López Rodríguez

16/01/2003

3.0

Versión con nuevas pruebas

Rosa María Ogallar

para

revisión

con

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Descripción

207

Crear una incidencia normal en Almacén

207

2.1 2.2 2.3 2.4 2.5

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

207 207 207 208 208

Crear una incidencia vacía en Almacén

208

3.1 3.2 3.3 3.4 3.5

208 208 208 208 209

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Consultar incidencias en Almacén

209

4.1 4.2 4.3 4.4 4.5

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

209 209 209 209 209

Crear una incidencia normal en Ventas

210

5.1 5.2 5.3 5.4 5.5

210 210 210 210 210

Descripción Condiciones de Ejecución Entrada Resultado Esperado Evaluación

Crear una incidencia vacía en Ventas

211

6.1 6.2 6.3 6.4 6.5

211 211 211 211 211

Descripción Condiciones de Ejecución Entrada Resultado Esperado Evaluación

Consultar incidencias en Ventas

212

7.1 7.2 7.3 7.4 7.5

212 212 212 212 212

Descripción Condiciones de Ejecución Entrada Resultado Esperado Evaluación

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

26.

Descripción Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso “Incidencia Pedido”. La pruebas realizadas a este caso de uso son:      

Crear una incidencia normal en Almacén. Crear una incidencia vacía en Almacén. Consultar incidencias en Almacén. Crear una incidencia normal en Ventas. Crear una incidencia vacía en Ventas. Consultar incidencias en Ventas.

El entorno del cual partiremos para realizar la prueba será el formulario de entrada de la aplicación

27.

Crear una incidencia normal en Almacén

27.1

Descripción Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad. Ante cualquier incidencia que nos ocurra mientras estemos atendiendo un pedido, tendremos la oportunidad de crear un parte de incidencia que dejara reflejado en el sistema cualquier problema que nos haya surgido durante la atención de ese pedido.

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

27.3

Entrada           

Introducimos ‘toni’ en el campo usuario. Introducimos ‘puma’ en el campo contraseña. Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. Seleccionamos de la lista de pedidos no atendidos el pedido de código ‘1’. Pulsamos el botón ‘Atender Pedido’. Nos aparece la interfaz para atender un pedido. Pulsamos el botón ‘Incidencia’. Nos aparece la interfaz de nueva incidencia. Introducimos un comentario y pulsamos ‘Guardar’. Pulsamos ‘Guardar’ o ‘Salir’ en la interfaz atender pedido.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

27.4

Resultado esperado La incidencia se almacena en el sistema.

27.5

Evaluación de la Prueba Prueba superada con éxito.

28.

Crear una incidencia vacía en Almacén

28.1

28.2

28.3

Entrada          

28.4

Introducimos ‘toni’ en el campo usuario. Introducimos ‘puma’ en el campo contraseña. Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. Seleccionamos de la lista de pedidos no atendidos el pedido de código ‘1’. Pulsamos el botón ‘Atender Pedido’. Nos aparece la interfaz para atender un pedido. Pulsamos el botón ‘Incidencia’. Nos aparece la interfaz de nueva incidencia. Pulsamos ‘Guardar’ sin haber introducido ningún comentario.

Resultado esperado El sistema nos muestra un mensaje de error que nos indica que el campo observaciones no puede ser vacío.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

28.5

Evaluación de la Prueba Prueba superada con éxito.

29.

Consultar incidencias en Almacén

29.1

29.2

29.3

Entrada          

29.4

Resultado esperado El sistema nos muestra una nueva interfaz donde se listan todas las incidencias almacenadas.

29.5

Evaluación de la Prueba Prueba superada con éxito.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

30.

Crear una incidencia normal en Ventas

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

30.2

Condiciones de Ejecución Las condiciones de ejecución del caso de prueba son que el usuario operadora “maria” está dado de alta en la base de datos de empleado y su clave correspondiente y que el cliente Jaime con DNI 48315682-N también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver toda la especificación completa de los datos.

30.3

Entrada              

30.4

Introducimos ‘maria’ en el campo usuario Introducimos ‘nike’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un operador. El cliente ‘Jaime’ con código ‘1’ llama a la operadora. La operadora introduce el código del cliente apareciendo en el formulario los datos completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que ya ha enviado al almacén. El cliente solicita hacer modificaciones al pedido ‘4’. La operadora selecciona el pedido en cuestión y pulsa el botón “modificar”, aparece la interfaz de modificar pedido. La operadora observa que hay anomalías y procede a la creación de una incidencia. Pulsamos el botón ‘Incidencia’. Nos aparece la interfaz de nueva incidencia. Introducimos un comentario y pulsamos ‘Guardar’. Pulsamos ‘Guardar’ o ‘Salir’ en la interfaz modificar pedido.

Resultado Esperado La incidencia se almacena en el sistema.

30.5

Evaluación Prueba superada con éxito.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

31.

Crear una incidencia vacía en Ventas

31.1

31.2

31.3

Entrada             

31.4

Resultado Esperado El sistema nos muestra un mensaje de error que nos indica que el campo observaciones no puede ser vacío.

31.5

Evaluación Prueba superada con éxito.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

32.

Consultar incidencias en Ventas

32.1

32.2

32.3

Entrada             

32.4

Resultado Esperado El sistema nos muestra una nueva interfaz donde se listan todas las incidencias almacenadas.

32.5

Evaluación Prueba superada con éxito.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Historial de Revisiones Fecha

Versión

Descripción

Autor

26/11/2002

0.9

Versión preliminar a falta de aprobación del Stakeholder

Rosa María Ogallar

07/01/2003

1.0

Versión con ajustes respecto a las interfaces

Rosa María Ogallar

10/01/2003

2.0

Versión lista Stakeholder

Rosa María Ogallar

15/01/2003

3.0

Versión preparada para la segunda iteración de la fase de construcción

para

revisión

con

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Descripción

215

Elegir opción CANCELAR en la confirmación de la cancelación de pedido

215

2.1 2.2 2.3 2.4 2.5

215 215 215 215 216

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Elegir opción ACEPTAR en la confirmación de la cancelación de pedido

216

3.1 3.2 3.3 3.4 3.5

216 216 216 216 216

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

33.

Descripción Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso “Cancelar Pedido Atendido”. Realizaremos únicamente dos pruebas que consistirán en la elección de cada una de las opciones de confirmación de la cancelación del pedido. El entorno del cual partiremos para realizar la prueba será el formulario de entrada de la aplicación.

34.

Elegir opción CANCELAR en la confirmación de la cancelación de pedido

34.1

Descripción Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad y solicitamos consultar pedidos en atención, el sistema nos mostrara una lista con los pedidos en atención que haya almacenados en el sistema. Elegiremos el pedido que el cliente nos solicite y cancelaremos dicho pedido respondiendo a la confirmación negativamente.

34.2

Condiciones de ejecución Las condiciones de ejecución del caso de prueba son que el usuario técnico de almacén “Toni” está dado de alta en la base de datos de empleado y su clave correspondiente y que el cliente Jaime con DNI 48315682-N también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver toda la especificación completa de los datos.

34.3

Entrada         

34.4

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. El cliente ‘Jaime’ con DNI ‘48315682N’ contacta con el técnico de almacén y solicita la cancelación del pedido en atención con código ‘5’. El técnico de almacén selecciona de la lista de pedidos en atención el pedido en cuestión y pulsa el botón ‘Cancelar Pedido’. Nos aparece un mensaje de confirmación de la cancelación del pedido. El cliente decide finalmente no cancelar el pedido. El técnico pulsa el botón ‘Cancelar’ .

Resultado esperado El pedido seleccionado sigue almacenado en el sistema sin ninguna modificación.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

34.5

Evaluación de la Prueba Prueba superada con éxito.

35.

Elegir opción ACEPTAR en la confirmación de la cancelación de pedido

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

35.2

Condiciones de ejecución Las condiciones de ejecución del caso de prueba son que el usuario técnico de almacén “Toni” está dado de alta en la base de datos de empleado y su clave correspondiente y que el cliente Jaime con DNI 48315682-N también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver toda la especificación completa de los datos.

35.3

Entrada         

35.4

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. El cliente ‘Jaime’ con DNI ‘48315682N’ contacta con el técnico de almacén y solicita la cancelación del pedido en atención con código ‘5’. El técnico de almacén selecciona de la lista de pedidos en atención el pedido en cuestión y pulsa el botón ‘Cancelar Pedido’. Nos aparece un mensaje de confirmación de la cancelación del pedido. El cliente decide finalmente cancelar el pedido. El técnico pulsa el botón ‘Aceptar’ .

Resultado esperado El pedido es eliminado del sistema y se libera el stock asociado a las líneas de pedido pasando de nuevo al stock disponible.

35.5

Evaluación de la Prueba Prueba superada con éxito.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Historial de Revisiones Fecha

Versión

Descripción

Autor

29/12/2002

0.9

Versión preliminar a falta de aprobación del Stakeholder

Rosa María Ogallar

07/01/2003

1.0

Versión con ajustes respecto a las interfaces

Rosa María Ogallar

10/01/2003

2.0

Versión lista Stakeholder

Rosa María Ogallar

15/01/2003

3.0

Versión preparada para la segunda iteración de la fase de construcción

para

revisión

con

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Descripción

219

Atender pedido después de consultar dicho pedido

219

2.1 2.2 2.3 2.4 2.5

219 219 219 220 220

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Atender un pedido de la lista de pedidos no atendidos

220

3.1 3.2 3.3 3.4 3.5

220 220 220 221 221

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Atender pedido asignando cantidades negativas

221

4.1 4.2 4.3 4.4 4.5

221 221 221 221 222

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Atender pedido asignando cantidades mayores a las disponibles

222

5.1 5.2 5.3 5.4 5.5

222 222 222 222 222

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Atender pedido asignando cantidades mayores a las solicitadas

223

6.1 6.2 6.3 6.4 6.5

223 223 223 223 223

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

Atender pedido sin asignar cantidades

224

7.1 7.2 7.3 7.4 7.5

224 224 224 224 224

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Descripción Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso “Atender Pedido”. La pruebas realizadas a este caso de uso son:     

Atender pedido después de consultar dicho pedido. Atender un pedido de la lista de pedidos no atendidos. Atender pedido asignando cantidades negativas o mayores a las disponibles. Atender pedido asignando cantidades mayores a las solicitadas. Atender pedido sin asignar cantidades.

El entorno del cual partiremos para realizar la prueba será el formulario de entrada de la aplicación

36.

Atender pedido después de consultar dicho pedido

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

36.2

36.3

Entrada       



Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. El técnico selecciona de la lista de pedidos no atendidos el pedido de código ‘3’ y pulsa el botón ‘Consultar’. Una vez consultado pulsa el botón ‘Atender Pedido’ . Para cada línea de pedido: o Comprueba que hay stock disponible. o Selecciona la línea haciendo doble clic para que aparezca la interfaz que nos permite modificar la cantidad asignada, allí se actualizan automáticamente los datos código y nombre del artículo. o Introduce la cantidad solicitada. o Pulsa el botón ‘Asignar Cantidad’. o Se actualiza línea de pedido. El técnico pulsa el botón ‘Guardar’.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

36.4

Resultado esperado El pedido queda almacenado en el sistema como en atención y el stock se reduce en las cantidades asignadas.

36.5

Evaluación de la Prueba Prueba superada con éxito.

37.

Atender un pedido de la lista de pedidos no atendidos

37.1

37.2

37.3

Entrada      



Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. El técnico selecciona de la lista de pedidos no atendidos el pedido de código ‘5’ y pulsa el botón ‘Atender Pedido’. Para cada línea de pedido: o Comprueba que hay stock disponible. o Selecciona la línea haciendo doble clic para que aparezca la interfaz que nos permite modificar la cantidad asignada, allí se actualizan automáticamente los datos código y nombre del artículo. o Introduce la cantidad solicitada. o Pulsa el botón ‘Asignar Cantidad’. o Se actualiza línea de pedido. El técnico pulsa el botón ‘Guardar’.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

37.4

Resultado esperado El pedido queda almacenado en el sistema como en atención y el stock se reduce en las cantidades asignadas.

37.5

Evaluación de la Prueba Prueba superada con éxito.

38.

Atender pedido asignando cantidades negativas

38.1

Descripción Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad y solicitamos consultar pedidos no atendidos, el sistema nos mostrara una lista con los pedidos no atendidos que haya almacenados en el sistema. Seleccionaremos un pedido, elegiremos la opción atender pedido y asignaremos cantidades negativas para observar como responde el sistema.

38.2

38.3

Entrada         

38.4

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. El técnico selecciona de la lista de pedidos no atendidos el pedido de código ‘1’ y pulsa el botón ‘Atender Pedido’. Selecciona la línea de pedido del articulo ‘2’ haciendo doble clic. Aparece la interfaz que nos permite modificar la cantidad asignada, se actualizan automáticamente los datos código y nombre del artículo. Introduce la cantidad ‘-2’. Pulsa el botón ‘Asignar Cantidad’.

Resultado esperado El sistema nos muestra un mensaje de error advirtiéndonos de que no es posible introducir cantidades negativas.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

38.5

Evaluación de la Prueba Prueba superada con éxito.

39.

Atender pedido asignando cantidades mayores a las disponibles

39.1

Descripción Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad y solicitamos consultar pedidos no atendidos, el sistema nos mostrara una lista con los pedidos no atendidos que haya almacenados en el sistema. Seleccionaremos un pedido, elegiremos la opción atender pedido y asignaremos cantidades mayores al stock disponible para observar como responde el sistema.

39.2

39.3

Entrada         

39.4

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. El técnico selecciona de la lista de pedidos no atendidos el pedido de código ‘1’ y pulsa el botón ‘Atender Pedido’. Selecciona la línea de pedido del articulo ‘3’ haciendo doble clic. Aparece la interfaz que nos permite modificar la cantidad asignada, se actualizan automáticamente los datos código y nombre del artículo. Introduce la cantidad ‘2’. Pulsa el botón ‘Asignar Cantidad’.

Resultado esperado El sistema nos muestra un mensaje de error advirtiéndonos de que no hay stock disponible para poder asignar esa cantidad .

39.5

Evaluación de la Prueba Prueba superada con éxito.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

40.

Atender pedido asignando cantidades mayores a las solicitadas

40.1

Descripción Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad y solicitamos consultar pedidos no atendidos, el sistema nos mostrara una lista con los pedidos no atendidos que haya almacenados en el sistema. Seleccionaremos un pedido, elegiremos la opción atender pedido y asignaremos cantidades mayores a las solicitadas para observar como responde el sistema.

40.2

40.3

Entrada         

40.4

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. El técnico selecciona de la lista de pedidos no atendidos el pedido de código ‘1’ y pulsa el botón ‘Atender Pedido’. Selecciona la línea de pedido del articulo ‘2’ haciendo doble clic. Aparece la interfaz que nos permite modificar la cantidad asignada, se actualizan automáticamente los datos código y nombre del artículo. Introduce la cantidad ‘2’. Pulsa el botón ‘Asignar Cantidad’.

Resultado esperado El sistema nos muestra un mensaje de error advirtiéndonos de que la cantidad introducida es superior a la cantidad solicitada .

40.5

Evaluación de la Prueba Prueba superada con éxito.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

41.

Atender pedido sin asignar cantidades

41.1

Descripción Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad y solicitamos consultar pedidos no atendidos, el sistema nos mostrara una lista con los pedidos no atendidos que haya almacenados en el sistema. Seleccionaremos un pedido, elegiremos la opción atender pedido y no realizaremos ninguna modificación .

41.2

41.3

Entrada      

41.4

Resultado esperado El pedido no se modificada por esta acción y continua estando en estado no atendido.

41.5

Evaluación de la Prueba Prueba superada con éxito.

Historial de Revisiones Fecha

Versión

Descripción

Autor

8/11/2002

0.9

Versión preliminar a falta de aprobación del Stakeholder

Rosa María Ogallar

14/11/2002

1.0

Versión revisada por el Stakeholder

Rosa María Ogallar

09/12/2002

2.0

Versión lista para pasar el test

César López Rodríguez

15/12/2002

2.9

Versión con evaluación de las pruebas

Rosa María Ogallar

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V. actualizados.

15/01/2003

3.0

Versión preparada para la segunda iteración de la fase de construcción

César López Rodríguez

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Tabla de Contenidos 1.

Descripción

227

Comprobar que la consulta funciona correctamente

227

2.1 2.2 2.3 2.4 2.5

227 227 227 227 227

Descripción Condiciones de ejecución Entrada Resultado esperado Evaluación de la Prueba

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

42.

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.

43.

Comprobar que la consulta funciona correctamente

43.1

43.2

43.3

Entrada      

43.4

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

Resultado esperado El sistema nos muestra una interfaz que consistirá en una lista con las líneas de pedido del pedido solicitado.

43.5

Evaluación de la Prueba Prueba superada con éxito

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Orden pedido Código pedido

Fecha

Estado

Cliente

Usuario Ventas

07/09/2002

25/10/2002

10/11/2002

21/11/2002

02/12/2002

07/12/2002

15/12/2002

04/01/2003

En elaboración En elaboración No atendido En elaboración No atendido En atención En atención En atención

48265791L 26359874J 48265791L 48265791L 48265791L 48265791L 48265791L 48265791L

2 1 1 1 2 2 2

C.P. envío

País envío

Prov. envío

Loc. envío

Pta Nº Calle envío envío envío

46985 España Valencia Manises

46758 España Valencia

46985 España Valencia Manises

Xativa

46985 España Valencia Manises

46970 España Valencia Burjassot

46758 España Valencia

Xativa

46758 España Valencia

Xativa

46758 España Valencia

Xativa

C/ Melias C/ Azorin C/ Melias C/ Melias C/ San Justo C/ Azorín C/ Azorín C/ Azorín

Forma pago

Fecha elab.

Usuario pepe luis

Contraseña adidas reebok

Nombre José Martínez Muñoz Luis Fernández Vila

Teléfono 962468597 961387596

48265791-L 26485963-M

maria toni

nike puma

Maria López Escudero Antonio Milla López

963478952 963474565

Fecha aten.

Contado 07/09/2002 Contado 25/10/2002 Crédito 10/11/2002 10/11/2002 Contado 21/11/2002 Crédito 02/12/2002 05/12/2002 Contado 07/12/2002 10/12/2002 11/12/2002 Contado 15/12/2002 18/12/2002 19/12/2002 Contado 04/01/2003 07/01/2003 09/01/2003

Empleado NIF 22596826-F 26359874-J

Fecha lleg. Alm.

Cargo Técnico almacén Representante de Ventas Operadora Técnico almacén

Fecha Fecha lista sal. envío Alm.

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Producto-Almacén Referencia 1 2 3 4 5

Almacén VAL VAL VAL VAL VAL

Stock 1000 500 6 600 3000

Stock Asig. 1 2 0 1 1

Almacén Código Nombre Dirección Teléfono País Fax Email Cod_reg Técnico VAL Virso C/ Colón, 15- 963479862 España 963479860 virso@ono.com E 26485963-M 78 Región Código E

Nombre Europa

Nombre

Región

España

País

Proveedor NIF 26789536-D

Código Nombre 456

Teléfono Dirección

Nº

Pta

Localidad Provincia

Juan 963471263 C/ Jesús Navarro Luna

101

Benaixida Valencia

46078

Pais

Fax

España 963471260 junalu@ono.com

PROYECTO FINAL Sistema para Gestión de Artículos Deportivos

SKY BLUE, S.A de C.V.

Producto Referencia 1 2 3 4 5

Precio(€) 67 34 28 42 30

Nombre Zapatillas Mochila Sudadera Raqueta Calentadores

Descripción Zapatillas illas Mochila ilas Sudadera eras Raquetas etas Calentadores ores

Proveedor 456 456 456 456 456

Max_razonable 200 100 350 100 1000

Línea pedido Código pedido 1 1 1 2 2 3 4 4 5 5 6 6 7 8 8

Referencia 1 2 3 1 4 2 5 4 3 1 2 1 4 4 5

Cantidad 1 1 2 1 2 2 3 2 5 2 2 1 2 1 2

Precio(€) 67 34 56 67 84 68 90 84 140 134 68 67 84 42 60

Cantidad Asig. 0 0 0 0 0 0 0 0 0 0 2 1 1 0 1

Cliente Codig o

NIF/CIF

Usu Con Nombre ario tra seña

Pta

Nº

Calle

48315682N

22496359- javi P

Jaime Monzón García

C/ 9613853 Manises Valencia 46985 Melias 96

95-2648950006352689

Javier Soria Garrido

C/ 9623596 Azorin 84

48-596820008454895

kel me

Teléfon o

Loc.

Xativa

Prov.

C.P.

Valencia 46758

C.C.C

País

Es- Pers_ Tlf_ Rati Repre emp contac pers o sentan resa to _co conf te ntac . to Españ Jaime Exc 26359 a 75 elen 874-J @ono. te com Españ Javier Reg 26359 a 32@o ular 874-J no.co m

Incidencias Cod_incidencia 1

Cod_pedido 6

Fecha 11/12/2002

Nif_creador 26485963M

21/12/2002

26485963M

Creador Observaciones Antonio Milla López Reponer stock, producto 1 por debajo del mínimo Antonio Milla López Pedido en atención más de 2 días

Fax