Proyecto final victor

PROYECTO FINALSistema para Gestión de Artículos Deportivos

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



INTRODUCCIÓN

La empresa Sky Blue, S.A. de C.V. solicitó el proyecto de desarrollo softwareconsta de varios departamentos centralizados, un almacén central y de diversassucursales de ventas repartidas en distintos países. Cada sucursal de ventasdispone de un almacén regional que suministra los pedidos de los clientes a lospaíses que conforman una región determinada, siendo el almacén central el queabastece al resto de almacenes.

El diagrama que representa los diferentes subsistemas en los que se ha dividido laempresa a nivel de abstracción es el siguiente:



1. GESTIÓN DEL PROYECTO.

SWEBOK

La gestión de la Ingeniería del Software puede definirse como la aplicación deactividades administrativas – planeación, coordinación, medición, monitorización,control y reporte- para asegurar que el desarrollo y el mantenimiento de softwaresean 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 lafase preliminar a la implementación operacional.

Planificación.

El propósito principal de la planificación es establecer un conjunto detallado dedirectrices que permita al equipo de trabajo saber exactamente: Qué tiene quehacerse, 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 delproyecto y objetivos parciales del mismo. Reuniones: Son hitos que correspondena reuniones internas o con el cliente, que deben estar programadas lo antesposible.

• Tareas: Son las actividades a realizar en el proyecto para obtener losresultados esperados

• Personas: Encargadas de realizar cada una de las actividades

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



Calendarización de proyectos.

Cada proyecto de software presenta distintos problemas en su desarrollo, loscuales involucran personas, equipo, usuarios del software y ambiente de laaplicación. Por estas razones, cada proyecto debe resolver el problema de laproducción del software.

Calendarización Es una actividad que distribuye estimaciones de esfuerzo a travésde la duración planificada del proyecto, al asignar el esfuerzo a tareas específicasde ingeniería del software.

Gestión de riesgos

Gestión de riesgos = serie de pasos que ayudan a comprender y manejar laincertidumbre que implica el desarrollo de todo proyecto.

Identificación de riesgos

• Grupos de riegos Genéricos: Son comunes a todos los proyectos, son unaamenaza potencial para todo el proyecto de software.

• Específicos: Implican un conocimiento profundo del proyecto. Se identificanexaminando el plan del proyecto y la declaración del ámbito del softwareCategorías Relacionados con el tamaño del producto Impacto en la organizaciónTipo de cliente Definición del proceso de producción Entorno de desarrolloTecnología Experiencia y tamaño del equipo.



Plan de Desarrollo SoftwareVersión 3.0Sistema 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, yaque tener un buen modelo permite lograr comprender el ámbito de la información además deidentificar las actividades y procesos que se realizan dentro de la organización para lograr unacorrecta operación y así lograr una buena comprensión del negocio para automatizar procesos alcrear 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, lasprobabilidades de que el sistema que se realice se adapte a las operaciones a realizarse dentro dela organización, son muy altas.

Existen varias ventajas para basar los sistemas de información en un mismo modelo básico denegocio (León y Asato, 2009):

• Los sistemas de información se vuelven una parte integral del negocio global, soportandolas operaciones, fortaleciendo el trabajo y la obtención de resultados.

• Los sistemas se integran fácilmente unos con otros y pueden compartir o intercambiarinformació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.



• 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 sufuncionamiento 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 delnegocio, 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 clienteexterno (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 detransportes, que es una subcontrata encargada de servir los pedidos desde los distintos almacenesregionales a los clientes de la empresa.



2.1 Modelo de Dominio.

Representación de los conceptos (objetos) significativos en el domino delproblema.

Incluye:

– Clases de objetos– Asociaciones entre clases de objetos– Atributos de las clases de objetos



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ánticaAbstracción:– Ocultación de los detalles/características menos importantes para poder observaraspectos comunes• Los objetos de una clase tienen las mismas propiedades y los mismos patrones decomportamiento.

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 deobjetos fue el del caso de uso del negocio "vender productos".



Modelo de Objetos de Seguimiento y Consulta de Productos

Modelo de Objetos de Reponer Stock

Modelo de Objetos de Modificar Catálogo

Modelo de Objetos de Realizar Entrega



Historial de Revisiones

Fecha Versión Descripción Autor

20/05/2013 0.9 Versión preliminar como propuesta dedesarrollo.

22/06/2013 1.0 Versión propuesta para aprobación alfinal de la fase de inicio.

20/07/2013 1.9 Versión lista para ser revisada al finalde la fase de elaboración.

23/08/2013 2.0 Versión revisada por el Stakeholder alfinal de la fase de elaboración.

20/09/2013 2.1 Versión revisada en la primera iteraciónde la fase de construcción

22/10/2013 2.9 Versión revisada en la segundaiteración de la fase de construcción,pendiente de revisión del Stakeholder

24/11/2013 3.0 Versión revisada en la segundaiteración de la fase de construcción,pendiente de aprobación delStakeholder



Tabla de Contenidos1. Introducción.......................................................................................................................................................12

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

1.2 Alcance ........................................................................................................................................................13

1.3 Resumen.......................................................................................................................................................13

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

3. Organización del Proyecto................................................................................................................................19

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

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

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

4. Gestión del Proceso............................................................................................................................................21

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

4.2 Plan del Proyecto ........................................................................................................................................224.2.1 Plan de las Fases ..................................................................................................................................224.2.2 Calendario del Proyecto.......................................................................................................................24

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

5. Referencias .........................................................................................................................................................30



Plan de Desarrollo de Software

1. IntroducciónEste Plan de Desarrollo del Software es una versión preliminar preparadapara ser incluida en la propuesta elaborada como respuesta al proyectofinal de la asignatura de Ingeniería de Software de la Universidad delDesarrollo Profesional. Este documento provee una visión global delenfoque de desarrollo propuesto.El proyecto ha sido basado en una metodología de Rational Unified Processen la que únicamente se procederá a cumplir con las tres primeras fasesque marca la metodología, constando únicamente en la tercera fase de dositeraciones. Es importante destacar esto puesto que utilizaremos laterminología RUP en este documento. Se incluirá el detalle para las fasesde Inicio y Elaboración y adicionalmente se esbozarán las fases posterioresde Construcción y Transición para dar una visión global de todo proceso.El enfoque desarrollo propuesto constituye una configuración del procesoRUP de acuerdo a las características del proyecto, seleccionando los rolesde los participantes, las actividades a realizar y los artefactos (entregables)que serán generados. Este documento es a su vez uno de los artefactos deRUP.

1.1 PropósitoEl propósito del Plan de Desarrollo de Software es proporcionar lainformación necesaria para controlar el proyecto. En él se describe elenfoque de desarrollo del software.Los usuarios del Plan de Desarrollo del Software son:

El jefe del proyecto lo utiliza para organizar la agenda y necesidadesde recursos, y para realizar su seguimiento.

Los miembros del equipo de desarrollo lo usan para entender loqué deben hacer, cuándo deben hacerlo y qué otras actividadesdependen de ello.



1.2 AlcanceEl Plan de Desarrollo del Software describe el plan global usado para eldesarrollo del “Sistema para Gestión de Artículos Deportivos”. El detalle delas iteraciones individuales se describe en los planes de cada iteración,documentos que se aportan en forma separada. Durante el proceso dedesarrollo en el artefacto “Visión” se definen las características del productoa desarrollar, lo cual constituye la base para la planificación de lasiteraciones. Para la versión 1.0 del Plan de Desarrollo del Software, noshemos basado en la captura de requisitos por medio del stakeholderrepresentante de la empresa para hacer una estimación aproximada, unavez comenzado el proyecto y durante la fase de Inicio se generará laprimera versión del artefacto “Visión”, el cual se utilizará para refinar estedocumento. Posteriormente, el avance del proyecto y el seguimiento encada una de las iteraciones ocasionará el ajuste de este documentoproduciendo nuevas versiones actualizadas.

1.3 ResumenDespués de esta introducción, el resto del documento está organizado enlas siguientes secciones:Vista General del Proyecto — proporciona una descripción del propósito,alcance y objetivos del proyecto, estableciendo los entragbles que seránproducidos y utilizados durante el proyecto..Organización del Proyecto — describe la estructura organizacional delequipo de desarrollo.Gestión del Proceso — explica los costos y planificación estimada, definelas 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 procesode desarrollo de software, incluyendo métodos, herramientas y técnicas queserán utilizadas.

2. Vista General del Proyecto2.1 Propósito, Alcance y Objetivos

La información que a continuación se incluye ha sido extraída de lasdiferentes reuniones que se han celebrado con el stakeholder de laempresa desde el inicio del proyecto.



Deportes SKY BLUE, S.A DE C.V lleva a cabo la venta al por mayor deartículos deportivos a nivel internacional. La entrada en un mercadocompetitivo como en el que encuentra inmersa esta firma conllevará unaprevisible adaptación a los nuevos sistemas de información y a la evolucióntecnológica. Por ello, Deportes SKY BLUE, S.A DE C.V consideranecesario el desarrollo de un nuevo sistema de gestión de los artículosdeportivos que forman parte de sus catálogos, así como las bases de datosque recogen datos tanto estadísticos, empresariales como de nóminas,plantillas de personal, etc., por tanto los solicitantes demandan una gestiónmás rápida, automática y segura de las gestiones de almacén y bases dedatos de los distintos departamentos.”El proyecto debe proporcionar una propuesta para el desarrollo de todos lossubsistemas implicados en la gestión de artículos deportivos y bases dedatos departamentales”. Estos subsistemas se pueden diferenciar en sietegrandes 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 adomicilio del cliente.

Procedimiento de venta mediante el sistema online, vía web.b) Gestión de Almacenes, incluyendo:

Gestión de nuevos pedidos.

Reserva de stock para la preparación de pedidos.

Gestión de incidencias de stock.

Gestión de pedidos para envío.

Gestión de consultas de estado de pedidos

Cancelación de pedidos solicitado por el cliente.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.



2.2 Suposiciones y RestriccionesLas suposiciones y restricciones respecto del sistema, y que se derivandirectamente 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 lastrasmisiones de datos (PKI), etc.

Gestión de flujos de trabajo, seguridad de transacciones eintercambio de información

Adaptación a la normativa de Protección de Datosb) 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ónreferente a los dominios de tercer nivel.

c) El subsistema “Gestión de Almacenes” debe diseñarse como móduloindependiente para ser utilizado posteriormente en otras regiones de losdistintos almacenes no centralizados encargados de proveer a cadaregió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 establecidoel artefacto “Visión”.

Entregables del proyecto

A continuación se indican y describen cada uno de los artefactos que serángenerados y utilizados por el proyecto y que constituyen los entregables.Esta lista constituye la configuración de RUP desde la perspectiva deartefactos, y que proponemos para este proyecto.

Es preciso destacar que de acuerdo a la filosofía de RUP (y de todoproceso iterativo e incremental), todos los artefactos son objeto demodificaciones a lo largo del proceso de desarrollo, con lo cual, sólo altérmino del proceso podríamos tener una versión definitiva y completa decada uno de ellos. Sin embargo, el resultado de cada iteración y los hitosdel proyecto están enfocados a conseguir un cierto grado de completitud yestabilidad de los artefactos. Esto será indicado más adelante cuando sepresenten los objetivos de cada iteración.


SKY BLUE, S.A de C.V.1) Plan de Desarrollo del Software

Es el presente documento.

2) Modelo de Casos de Uso del NegocioEs un modelo de las funciones de negocio vistas desde la perspectiva

de los actores externos (Agentes de registro, solicitantes finales, otrossistemas etc.). Permite situar al sistema en el contexto organizacionalhaciendo énfasis en los objetivos en este ámbito. Este modelo serepresenta con un Diagrama de Casos de Uso usando estereotiposespecíficos para este modelo.

3) Modelo de Objetos del NegocioEs un modelo que describe la realización de cada caso de uso del

negocio, estableciendo los actores internos, la información que en términosgenerales manipulan y los flujos de trabajo (workflows) asociados al casode uso del negocio. Para la representación de este modelo se utilizanDiagramas de Colaboración (para mostrar actores externos, internos y lasentidades (información) que manipulan, un Diagrama de Clases paramostrar gráficamente las entidades del sistema y sus relaciones, yDiagramas de Actividad para mostrar los flujos de trabajo.

4) GlosarioEs un documento que define los principales términos usados en el

proyecto. Permite establecer una terminología consensuada.

5) Modelo de Casos de UsoEl modelo de Casos de Uso presenta las funciones del sistema y los

actores que hacen uso de ellas. Se representa mediante Diagramas deCasos de Uso.

6) VisiónEste 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 UsoPara los casos de uso que lo requieran (cuya funcionalidad no sea

evidente o que no baste con una simple descripción narrativa) se realizauna descripción detallada utilizando una plantilla de documento, donde seincluyen: precondiciones, post-condiciones, flujo de eventos, requisitos no-


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áficamediante un Diagrama de Actividad.

Especificaciones Adicionales

Este documento capturará todos los requisitos que no han sido incluidoscomo parte de los casos de uso y se refieren requisitos no-funcionalesglobales. Dichos requisitos incluyen: requisitos legales o normas, aplicaciónde estándares, requisitos de calidad del producto, tales como: confiabilidad,desempeño, etc., u otros requisitos de ambiente, tales como: sistemaoperativo, requisitos de compatibilidad, etc.

8) Prototipos de Interfaces de UsuarioSe trata de prototipos que permiten al usuario hacerse una idea más o

menos precisa de las interfaces que proveerá el sistema y así, conseguirretroalimentación de su parte respecto a los requisitos del sistema. Estosprototipos se realizarán como: dibujos a mano en papel, dibujos con algunaherramienta gráfica o prototipos ejecutables interactivos, siguiendo eseorden de acuerdo al avance del proyecto. Sólo los de este último tipo seránentregados 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 lamedida que el resultado de las iteraciones vayan desarrollando el productofinal.

9) Modelo de Análisis y DiseñoEste 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 incluiraspectos de implementación) hacia una de diseño (incluyendo unaorientación hacia el entorno de implementación), de acuerdo al avance delproyecto.

10)Modelo de DatosPreviendo que la persistencia de la información del sistema será

soportada por una base de datos relacional, este modelo describe larepresentación lógica de los datos persistentes, de acuerdo con el enfoquepara modelado relacional de datos. Para expresar este modelo se utiliza unDiagrama de Clases (donde se utiliza un profile UML para Modelado deDatos, para conseguir la representación de tablas, claves, etc.) .


SKY BLUE, S.A de C.V.11)Modelo de Implementación

Este modelo es una colección de componentes y los subsistemas quelos contienen. Estos componentes incluyen: ficheros ejecutables, ficherosde código fuente, y todo otro tipo de ficheros necesarios para laimplantación y despliegue del sistema. (Este modelo es sólo una versiónpreliminar al final de la fase de Elaboración, posteriormente tiene bastanterefinamiento).

12)Modelo de DespliegueEste 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 PruebaCada prueba es especificada mediante un documento que establece las

condiciones de ejecución, las entradas de la prueba, y los resultadosesperados. Estos casos de prueba son aplicados como pruebas deregresión en cada iteración. Cada caso de prueba llevará asociado unprocedimiento de prueba con las instrucciones para realizar la prueba, ydependiendo del tipo de prueba dicho procedimiento podrá serautomatizable mediante un script de prueba.

14)Solicitud de CambioLos cambios propuestos para los artefactos se formalizan mediante este

documento. Mediante este documento se hace un seguimiento de losdefectos detectados, solicitud de mejoras o cambios en los requisitos delproducto. Así se provee un registro de decisiones de cambios, de suevaluación e impacto, y se asegura que éstos sean conocidos por el equipode desarrollo. Los cambios se establecen respecto de la última baseline (elestado del conjunto de los artefactos en un momento determinado delproyecto) establecida. En nuestro caso al final de cada iteración seestablecerá una baseline.

15)Plan de IteraciónEs un conjunto de actividades y tareas ordenadas temporalmente, con

recursos asignados, dependencias entre ellas. Se realiza para cadaiteración, y para todas las fases.

16)Evaluación de Iteración


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 RiesgosEste documento incluye una lista de los riesgos conocidos y vigentes en

el proyecto, ordenados en orden decreciente de importancia y con accionesespecíficas de contingencia o para su mitigación.

18)Manual de InstalaciónEste documento incluye las instrucciones para realizar la instalación del

producto.

19)Material de Apoyo al Usuario FinalCorresponde a un conjunto de documentos y facilidades de uso del

sistema, incluyendo: Guías del Usuario, Guías de Operación, Guías deMantenimiento y Sistema de Ayuda en Línea

20)ProductoLos ficheros del producto empaquetados y almacenadas en un CD con

los mecanismos apropiados para facilitar su instalación. El producto, a partirde la primera iteración de la fase de Construcción es desarrolladoincremental e iterativamente, obteniéndose una nueva release al final decada iteración.

Los artefactos 19, 20 y 21 se generarán a partir de la fase deConstrucción, con lo cual se han incluido aquí sólo para dar una visiónglobal de todos los artefactos que se generarán en el proceso de desarrollo.

2.3 Evolución del Plan de Desarrollo del SoftwareEl Plan de Desarrollo del Software se revisará semanalmente y se

refinará antes del comienzo de cada iteración.

3. Organización del Proyecto

3.1 Participantes en el ProyectoDe momento no se incluye el personal que designará Deportes SKY

BLUE, S.A DE C.V como Responsable del Proyecto, Comité de Control ySeguimiento, otros participantes que se estimen convenientes paraproporcionar los requisitos y validar el sistema.


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 dositeraciones de la fase de Construcción, estará formado por los siguientespuestos de trabajo y personal asociado:Jefe de Proyecto. Labor de VICTOR HUGO IBARRA ORTIZ, alumno de lacarrera de Ingeniería de software de la universidad de desarrolloprofesional. Con una experiencia modesta en metodologías de desarrollo,herramientas CASE y notaciones, en particular la notación UML y elproceso de desarrollo RUP.Analista de Sistemas. El perfil establecido es: Ingeniero en sistemascomputacionales con conocimientos de UML, uno de ellos al menos conexperiencia en sistemas afines a la línea del proyecto, labor que llevará acabo VICTOR HUGO IBARRA ORTIZ.4 Analistas - Programadores. Con experiencia en el entorno de desarrollodel proyecto, con el fin de que los prototipos puedan ser lo más cercanosposibles al producto final. Este trabajo ha sido encomendado a JESUSISIDRO GONZALEZ ESPINOZA.Ingeniero de Software. El perfil establecido es: Ingeniero en sistemas

computacionales, realizando labores de gestión de requisitos, gestión deconfiguración, documentación y diseño de datos. Encargado de las pruebasfuncionales del sistema, realizará la labor de JESUS ISIDRO GONZALEZESPINOZA.Los Currículos Vitae del personal del proyecto que ya ha comprometido suparticipación se adjuntan por separado.

3.2 Interfaces ExternasDeportes SKY BLUE, S.A DE C.V definirá los participantes del proyectoque proporcionarán los requisitos del sistema, y entre ellos quiénes seránlos encargados de evaluar los artefactos de acuerdo a cada subsistema ysegún el plan establecido.

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

3.3 Roles y ResponsabilidadesA continuación se describen las principales responsabilidades de cada unode los puestos en el equipo de desarrollo durante las fases de Inicio yElaboración, de acuerdo con los roles que desempeñan en RUP.


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

Jefe de Proyecto

El jefe de proyecto asigna los recursos, gestiona lasprioridades, coordina las interacciones con losclientes y usuarios, y mantiene al equipo delproyecto enfocado en los objetivos. El jefe deproyecto también establece un conjunto deprácticas que aseguran la integridad y calidad delos artefactos del proyecto. Además, el jefe deproyecto se encargará de supervisar elestablecimiento de la arquitectura del sistema.Gestión de riesgos. Planificación y control delproyecto.

Analista deSistemas

Captura, especificación y validación de requisitos,interactuando con el cliente y los usuarios medianteentrevistas. Elaboración del Modelo de Análisis yDiseño. Colaboración en la elaboración de laspruebas funcionales y el modelo de datos.

ProgramadorConstrucción de prototipos. Colaboración en laelaboración de las pruebas funcionales, modelo dedatos y en las validaciones con el usuario

Ingeniero deSoftware

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

4. Gestión del Proceso

4.1 Estimaciones del ProyectoEl presupuesto del proyecto y los recursos involucrados se adjuntan en un

documento separado.



4.2 Plan del ProyectoEn esta sección se presenta la organización en fases e iteraciones y elcalendario del proyecto.

4.2.1 Plan de las Fases

El desarrollo se llevará a cabo en base a fases con una o más iteracionesen cada una de ellas. La siguiente tabla muestra una la distribución detiempos y el número de iteraciones de cada fase (para las fases deConstrucción y Transición es sólo una aproximación muy preliminar)

FaseNro.

IteracionesDuración

Fase de Inicio 1 3semanas

Fase deElaboración

1 2semanas

Fase deConstrucción

2 7semanas

Fase deTransición

- -

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


SKY BLUE, S.A de C.V.Descripción Hito

Fase de Inicio En esta fase desarrollará los requisitos del productodesde la perspectiva del usuario, los cuales seránestablecidos en el artefacto Visión. Los principalescasos de uso serán identificados y se hará unrefinamiento del Plan de Desarrollo del Proyecto. Laaceptación del cliente / usuario del artefacto Visión yel Plan de Desarrollo marcan el final de esta fase.

Fase deElaboración

En esta fase se analizan los requisitos y sedesarrolla un prototipo de arquitectura (incluyendolas partes más relevantes y / o críticas del sistema).Al final de esta fase, todos los casos de usocorrespondientes a requisitos que seránimplementados en la primera release de la fase deConstrucción deben estar analizados y diseñados(en el Modelo de Análisis / Diseño). La revisión yaceptación del prototipo de la arquitectura delsistema marca el final de esta fase. En nuestro casoparticular, por no incluirse las fases siguientes, larevisión y entrega de todos los artefactos hasta estepunto de desarrollo también se incluye como hito. Laprimera iteración tendrá como objetivo laidentificación y especificación de los principalescasos de uso, así como su realización preliminar enel Modelo de Análisis / Diseño, también permitiráhacer una revisión general del estado de losartefactos hasta este punto y ajustar si es necesariola planificación para asegurar el cumplimiento de losobjetivos. Ambas iteraciones tendrán una duraciónde una semana.


Durante la fase de construcción se terminan deanalizar y diseñar todos los casos de uso,


SKY BLUE, S.A de C.V.refinando el Modelo de Análisis / Diseño. Elproducto se construye en base a 2 iteraciones,cada una produciendo una release a la cual se leaplican las pruebas y se valida con el cliente /usuario. Se comienza la elaboración de material deapoyo al usuario. El hito que marca el fin de estafase es la versión de la release 3.0, con lacapacidad operacional parcial del producto que sehaya considerado como crítica, lista para serentregada a los usuarios para pruebas beta.

Fase deTransición

En esta fase se prepararán dos releases paradistribución, asegurando una implantación ycambio del sistema previo de manera adecuada,incluyendo el entrenamiento de los usuarios. Elhito que marca el fin de esta fase incluye, laentrega de toda la documentación del proyecto conlos manuales de instalación y todo el material deapoyo al usuario, la finalización del entrenamientode los usuarios y el empaquetamiento delproducto.

4.2.2 Calendario del ProyectoA continuación se presenta un calendario de las principales tareas delproyecto incluyendo sólo las fases de Inicio y Elaboración. Como se hacomentado, el proceso iterativo e incremental de RUP está caracterizadopor la realización en paralelo de todas las disciplinas de desarrollo a lo largodel proyecto, con lo cual la mayoría de los artefactos son generados muytempranamente en el proyecto pero van desarrollándose en mayor o menorgrado de acuerdo a la fase e iteración del proyecto. La siguiente figurailustra este enfoque, en ella lo ensombrecido marca el énfasis de cadadisciplina (workflow) en un momento determinado del desarrollo.



Para este proyecto se ha establecido el siguiente calendario. La fecha deaprobación indica cuándo el artefacto en cuestión tiene un estado decompletitud suficiente para someterse a revisión y aprobación, pero esto noquita la posibilidad de su posterior refinamiento y cambios.

Disciplinas / Artefactos generados omodificados

durante la Fase de InicioComienzo Aprobación

Modelado del Negocio

Modelo de Casos de Uso del Negocio yModelo de Objetos del Negocio

Semana 1

13/05 –19/05

Semana 3

27/05 –3/06

Requisitos

GlosarioSemana 1

13/05 –19/05

Semana 3

27/05 –3/06

Visión Semana 2 Semana 3


SKY BLUE, S.A de C.V.20/05 –26/05

27/05 –3/06

Modelo de Casos de UsoSemana 3

28/05 –3/05

siguientefase

Especificación de Casos de UsoSemana 3

28/05 –3/05

siguientefase

Especificaciones AdicionalesSemana 3

28/05 –3/06

siguientefase

Análisis / Diseño

Modelo de Análisis / DiseñoSemana 2

21/05 –27/05

siguientefase

Modelo de DatosSemana 2

21/05 –27/05

siguientefase

Implementación

Prototipos de Interfaces de UsuarioSemana 3

28/05 –3/06

siguientefase

Modelo de ImplementaciónSemana 3

28/05 –3/06

siguientefase

Pruebas

Casos de Pruebas Funcionales Semana 3 siguiente


SKY BLUE, S.A de C.V.28/05 –3/06

fase

Despliegue

Modelo de DespliegueSemana 3

28/05 –3/06

siguientefase

Gestión de Cambios y Configuración Durante todo el proyecto

Gestión del proyecto

Plan de Desarrollo del Software en suversión 1.0 y planes de las Iteraciones

Semana 1

14/05 –20/06

Semana 3

28/05 –3/06

Ambiente Durante todo el proyecto

Disciplinas / Artefactos

generados o modificados durante la

Fase de Elaboración

Comienzo Aprobación



Semana 1

14/05 –20/05

aprobado

Requisitos

GlosarioSemana 1

14/05 –20/05

aprobado

Visión Semana 2 aprobado


SKY BLUE, S.A de C.V.21/05 –27/05


28/05 –3/06

Semana 5

11/06 – 17/06


28/05 –3/06

Semana 5

11/06 – 17/06


28/05 –3/06

Semana 5

11/06 – 17/06

Análisis / Diseño


21/05 –27/05

Revisar encada iteración


21/05 –27/05


Implementación


28/05 –3/06



28/05 –3/06


Pruebas

Casos de Pruebas Funcionales Semana 3 Revisar encada iteración


SKY BLUE, S.A de C.V.28/05 –3/06

Despliegue


28/05 –3/06





Semana 4

4/06 –10/06



Seguimiento y Control del Proyecto

Gestión de RequisitosLos requisitos del sistema son especificados en el artefacto Visión. Cadarequisito tendrá una serie de atributos tales como importancia, estado,iteración donde se implementa, etc. Estos atributos permitirán realizar unefectivo seguimiento de cada requisito. Los cambios en los requisitos serángestionados mediante una Solicitud de Cambio, las cuales serán evaluadasy distribuidas para asegurar la integridad del sistema y el correcto procesode gestión de configuración y cambios.Control de PlazosEl calendario del proyecto tendrá un seguimiento y evaluación semanal porel jefe de proyecto y por el Comité de Seguimiento y Control.


SKY BLUE, S.A de C.V.Control de CalidadLos defectos detectados en las revisiones y formalizados también en unaSolicitud de Cambio tendrán un seguimiento para asegurar la conformidadrespecto de la solución de dichas deficiencias Para la revisión de cadaartefacto y su correspondiente garantía de calidad se utilizarán las guías derevisión y checklist (listas de verificación) incluidas en RUP.Gestión de RiesgosA partir de la fase de Inicio se mantendrá una lista de riesgos asociados alproyecto y de las acciones establecidas como estrategia para mitigarlos oacciones de contingencia. Esta lista será evaluada al menos una vez encada iteración.Gestión de ConfiguraciónSe realizará una gestión de configuración para llevar un registro de losartefactos generados y sus versiones. También se incluirá la gestión de lasSolicitudes de Cambio y de las modificaciones que éstas produzcan,informando y publicando dichos cambios para que sean accesibles a todolos participantes en el proyecto. Al final de cada iteración se estableceráuna baseline (un registro del estado de cada artefacto, estableciendo unaversión), la cual podrá ser modificada sólo por una Solicitud de Cambioaprobada.

5. Referencias

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

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

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

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



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 algoque el sistema debe hacer.

Un requerimiento “es una característica del sistema o una descripción de algo que el sistema es capazde hacer con el objeto de satisfacer el propósito del sistema”

3.1 Visión

Historial de RevisionesFecha Versión Descripción Autor

20/05/2013 0.9 Propuesta inicial del documento Visión conlas primeras capturas de requisitosfuncionales del sistema.

20/06/2013 1.0 Versión 1.0 en estado de complementaciónpara su aprobación.

20/07/2013 1.0 Versión 1.0 para la aprobación al final de lafase de inicio

20/08/2013 1.0 Versión 1.0 para la aprobación al final de lafase de inicio

20/09/2013 2.0 Versión 2.0 tras el fin de la fase deelaboración a falta de revisión por elstakeholder

20/10/2013 2.1 Versión 2.0 modificada en la primeraiteración de construcción. Pendiente derevisión por el Stakeholder.

20/11/2013 2.9 Versión modificada en la segunda iteraciónde construcción. Pendiente de revisión porel Stakeholder.

20/12/2013 3.0 Versión revisada para la segunda iteraciónde construcción. Pendiente de validaciónpor el Stakeholder

20/01/2014 3.0 Versión revisada para la segunda iteraciónde construcción. Pendiente de validaciónpor el Stakeholder



Tabla de Contenidos1. Introducción 5

1.1 Propósito 51.2 Alcance 51.3 Definiciones, Acrónimos, y Abreviaciones 51.4 Referencias 5

2. Posicionamiento 6

2.1 Oportunidad de Negocio 62.2 Sentencia que define el problema 62.3 Sentencia que define la posición del Producto 7

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

3.1 Resumen de Stakeholders 83.2 Resumen de Usuarios 83.3 Entorno de usuario 93.4 Perfil de los Stakeholders 9

3.4.1 Representante del área técnica y sistemas de información 93.5 Perfiles de Usuario 10

3.5.1 Ingeniero de Logística 103.5.2 Jefe de Almacén 103.5.3 Técnico de Almacén 113.5.4 Representante de Ventas 113.5.5 Operadora 123.5.6 Jefe de Ventas 123.5.7 Encargado de Transporte 133.5.8 Contable 133.5.9 Empleado de Marketing 143.5.10 Cliente Online 143.5.11 Empleado de Recursos Humanos 153.5.12 Jefe de Recursos Humanos 15

4. Descripción Global del Producto 16

4.1 Perspectiva del producto 164.2 Resumen de características 164.3 Suposiciones y dependencias 164.4 Costo y precio 16

5. Descripción Global del Producto 17

5.1 Departamento de Recursos Humanos 175.2 Departamento de Marketing 175.3 Departamento de Logística 175.4 Gestión de Almacén 175.5 Gestión de Ventas 185.6 Gestión de Envíos 185.7 Departamento de Contabilidad y Facturación 19



6. Restricciones 19

7. Precedencia y Prioridad 19

8. Otros Requisitos del Producto 19

8.1 Estándares Aplicables 198.2 Requisitos de Sistema 198.3 Requisitos de Desempeño 198.4 Requisitos de Entorno 19

9. Requisitos de Documentación 19

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

A. Atributos de Características 20



Visión1. Introducción

1.1 Propósito

El propósito de éste documento es recoger, analizar y definir las necesidades de alto nivel y lascaracterísticas del sistema de gestión de una empresa de distribución de artículos deportivos. El documentose 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 repartidospor las distintas zonas en las que actúa, de forma que dichos almacenes sean capaces de atender losdistintos pedidos que les son realizados.

Los detalles de cómo el sistema cubre los requerimientos se pueden observar en la especificación de loscasos 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 empresadedicada a la distribución de artículos deportivos. Dicho sistema será desarrollado por el grupode desarrollo de software LSI 03.

El sistema permitirá a los encargados de la empresa controlar todo lo relativo a la distribuciónde 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 elproceso de desarrollo de software.

1.4 Referencias

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



2. Posicionamiento2.1 Oportunidad de Negocio

Este sistema permitirá a la empresa informatizar el control de todas sus actividades (gestión destock en cada almacén, gestión de pedidos, etc.), lo cual supondrá un acceso rápido y sencillo alos datos, gracias a interfaces gráficas sencillas y amigables. Además, los datos accedidos estaránsiempre actualizados, lo cual es un factor muy importante para poder llevar un controlcentralizado 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 problemaEl problema de Controlar el stock existente en los distintos almacenes, de

forma que se puedan servir los pedidos que reciben dichosalmacenes.

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 estainformación esté al instante accesible y actualizada en lugaresfísicamente muy distantes es un proceso prácticamenteimposible 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 dedatos accesible desde los distintos nodos de la red y generarinterfaces amigables y sencillas con las que acceder a dichabase de datos.



2.3 Sentencia que define la posición del Producto

Para Departamento de logística,

Jefes de almacenes,

Técnicos de almacenes,

Encargados de transporte,

Usuarios de ventas de cada región,

Departamento de contabilidad / facturación,

Departamento de recursos humanos,

Departamento de marketing.

Quienes Controlan los pedidos, los almacenes (stock), las órdenes depedido y la facturación.

El nombre del producto Es una herramienta software.

Que Almacena la información necesaria para gestionar una empresade distribución.

no como El sistema actual.

Nuestro producto Permite gestionar las distintas actividades de la empresamediante una interfaz gráfica sencilla y amigable. Ademásproporciona un acceso rápido y actualizado a la informacióndesde 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 demodelado de requerimientos. También es necesario identificar a los usuarios del sistema y asegurarse deque el conjunto de participantes en el proyecto los representa adecuadamente. Esta sección muestra unperfil de los participantes y de los usuarios involucrados en el proyecto, así como los problemas másimportantes que éstos perciben para enfocar la solución propuesta hacia ellos. No describe sus requisitosespecíficos ya que éstos se capturan mediante otro artefacto. En lugar de esto proporciona la justificaciónde por qué estos requisitos son necesarios.



3.1 Resumen de Stakeholders

Nombre Descripción Responsabilidades

Agustín DuartePreciado.

Representante Global de laempresa Deportes de SkyBlue s.a. de c.v.

El stakeholder realiza:

Representa a todos los usuarios posibles delsistema.

Seguimiento del desarrollo del proyecto.

Aprueba requisitos y funcionalidades

3.2 Resumen de Usuarios

Nombre Descripción Stakeholder

Ingeniero deLogística

Responsable del Departamento deLogística, encargado de la gestión delalmacén central, del aprovisionamiento delresto de almacenes y del contacto con losproveedores.

Logística

Jefe de Almacén Supervisor del buen funcionamiento delalmacén y de gestionar las incidencias delos pedidos, ya sea tratando con otroalmacén, o bien en contacto con elIngeniero de Logística.

Almacén

Técnico deAlmacén

Encargado directo del almacén, control destocks, preparación y despacho de pedidos.

Almacén

Representante deVentas

Responsable de ventas del producto a losclientes, mediante visitas al domicilio delcliente. Informa de las ofertas yconfecciona las órdenes de pedido.

Ventas

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

Ventas

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

Contabilidad / Facturación

Empleado deMaketing

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

Marketing



Cliente Online Realiza compras online, por teléfono através de los comerciales, o tratando conéstos directamente.

Ventas

Operadora Responsable de ventas del producto a losclientes, a través del teléfono. Informa delas ofertas y confecciona las órdenes depedido.

Ventas

Encargado deTransporte

Responsable de consultar los envíos que sevan a realizar desde un almacén. Cargarlos camiones con los pedidos a enviar eintroducir los datos del pedido. Una vezentregado el pedido, introducir los recibosde entrega.

Envíos

Empleado deRecursos Humanos

Responsable de realizar las entrevistas detrabajo para el nuevo personal y por tantoacceso a la base de datos de currículos.También encargado de la gestión denóminas..

Recursos Humanos

Jefe de RecursosHumanos

Responsable de la gestión de personal, esdecir, contratos y despidos, y tambiénencargado de la redistribución de laplantilla.

Recursos Humanos

3.3 Entorno de usuario

Los usuarios entrarán al sistema identificándose sobre un ordenador con un sistema operativo Windows 8 ytras este paso entrarán a la parte de aplicación diseñada para cada uno según su papel en la empresa. Estesistema es similar a cualquier aplicación Windows y por tanto los usuarios estarán familiarizados con suentorno.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.



Tipo Experto de Sistemas.

Responsabilidades

Encargado de mostrar las necesidades de cada usuario del sistema. Además, lleva acabo un seguimiento del desarrollo del proyecto y aprobación de los requisitos yfuncionalidades del sistema

Criterio de Éxito A definir por el cliente

Grado departicipación

Revisión de requerimientos, estructura del sistema

Comentarios Ninguno

3.5 Perfiles de Usuario

3.5.1 Ingeniero de Logística

Representante Agustin Duarte Preciado.

Descripción Jefe del Departamento de Logística de la Empresa.

Tipo Gurú.

Responsabilidades

Responsable del Departamento de Logística, encargado de la gestión del almacéncentral, del aprovisionamiento del resto de almacenes y del contacto con losproveedores. Control de estadísticas para la optimización de recursos.



A definir por el cliente

Comentarios Ninguno

3.5.2 Jefe de Almacén

Representante Luis Newman

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

Tipo Usuario casual del sistema.



Responsabilidades

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




Comentarios Ninguno.

3.5.3 Técnico de Almacén

Representante Juan Jose

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

Tipo Usuario experto.

Responsabilidades

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




Comentarios Niniguno.

3.5.4 Representante de Ventas

Representante Eli

Descripción Representante de ventas de los productos


Responsabilidade Responsable de ventas del producto a los clientes, mediante visitas al domicilio delcliente. Informa de las ofertas y confecciona las órdenes de pedido. También



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





3.5.5 Operadora

Representante Oscar Holguin.

Descripción Operadora de ventas de los productos


Responsabilidades

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





3.5.6 Jefe de Ventas

Representante Edgar Rascon.

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


Responsabilidades

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







3.5.7 Encargado de Transporte

Representante Josefina Vazquez Mota.

Descripción Encargado de Transportes de un almacén determinado.


Responsabilidades

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





3.5.8 Contable

Representante Benny Franco.

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


Responsabilidades

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


Grado de A definir por el cliente



participación

Comentarios Niguno.

3.5.9 Empleado de Marketing

Representante Tomas Beltran.

Descripción Empleado del Departamento de Marketing.

Tipo Usuario eventual.

Responsabilidades

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





3.5.10 Cliente Online

Representante Ventas

Descripción Comprador de productos.

Tipo Usuario casual.

Responsabilidades

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







3.5.11 Empleado de Recursos Humanos

Representante Recursos Humanos

Descripción Empleado del Departamento de Recursos Humanos.


Responsabilidades

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





3.5.12 Jefe de Recursos Humanos

Representante Recursos Humanos

Descripción Empleado del Departamento de Recursos Humanos.


Responsabilidades

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







4. Descripción Global del Producto4.1 Perspectiva del productoEl producto a desarrollar es un sistema global para la empresa Deportes LSI 03, con la intención de agilizarsu funcionamiento. Las áreas a tratar por el sistema son: logística, gestión de recursos humanos,contabilidad y marketing.

4.2 Resumen de característicasA 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 laposibilidad de hacerlo vía servicios web.

Aplicación web desde la cual poder realizar lospedidos.

Gestión automatizada del stock del almacén. Sistema de optimización de del stock en elalmacén y previsión de pedidos

Mayor facilidad para la gestión de los recursoshumanos.

Base de datos centralizada con la informaciónde todo el personal.

Posibilidad de cancelación de órdenes porparte del cliente dando la posibilidad dehacerlo vía servicios web.

Aplicación web desde la que poder cancelarpedidos.

Automatización de la cancelación de estasórdenes.

Sistema automatizado de anulación deórdenes.

Mayor facilidad para el control e catálogospara el área de marketing.

Base de datos con acceso remoto desde la quepoder controlar ofertas y políticas de ventas.

Automatización del sistema de nóminas Sistema automático de generación denóminas.

4.3 Suposiciones y dependencias[A definir por el cliente]

4.4 Costo y precio[A definir por el cliente]



5. Descripción Global del Producto

5.1 Departamento de Recursos HumanosDepartamento encargado de la gestión de la plantilla y asignación de destino de trabajo. Los trabajadorescon rol de recursos humanos tendrán acceso a un a parte del subsistema en la que se darán de alta, de baja yse 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 MarketingDepartamento responsable de la confección de catálogos d productos , políticas de ventas y realizar lasdistintas ofertas sobre los productos. Los trabajadores con este rol tendrán acceso a una parte del sistemaconectado con la base de datos de producto de forma que puedan controlar y aplicar las ofertascorrespondientes sobre estos.

5.3 Departamento de LogísticaDepartamento que dirige y gestiona el almacén centralizado de la compañía, que es el abastecimientoprincipal del resto de almacenes. Este departamento dispondrá de una parte del sistema que automatizará elproceso de reposición de stocks de los almacenes y el reabastecimiento de los distintos almacenes, tanto elcentral 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 cadadepartamento es necesario que el sistema genere una serie de datos estadísticos históricos que clarifiquen elexcesivo volumen de datos numéricos que se generan en la compra-venta de artículos.

5.4 Gestión de AlmacénEn el subsistema de almacén se atienden los pedidos que han sido elaborados en el departamento de ventasy que han sido pasados a la gestión de almacenes. Los pedidos que figuran como no atendidos pueden pasara ser atendidos una vez que el técnico de almacén reserva stock de productos para dichos pedidos. Duranteel proceso de atención el pedido puede sufrir diversas modificaciones en la asignación de stock, y una vezconfeccionado en su totalidad, pasa a pedido listo para envío, y una vez en este estado pasará a ser tratadopor 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 elalmacén en el listado de pedidos no atendidos. El técnico de almacén podrá atender un pedido asignándolestock del almacén. Una vez confeccionado completamente el pedido, el técnico de almacén podrá hacer quefigure el pedido como listo para envío, de tal forma que el encargado de transportes sepa que lo puedecargar en el camión. En cualquier momento, el pedido podrá ser cancelado.

5.4.2 Gestión de incidencias de pedido



En caso de que en un pedido se detecte que no hay stock suficiente para poder satisfacerlo, el técnico dealmacén podrá lanzar una incidencia de pedido, en la que figurará el o los pedidos que no han podidocompletarse por falta de stock en el almacén. Posteriormente el jefe de ventas del almacén gestionará lasincidencias de pedido y el déficit de stocks. El jefe de almacén podrá solicitar stock de productos a otrosalmacenes para reponer el déficit de stock o bien podrá solicitar al ingeniero de logística que distribuyaproductos 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 noatenció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 VentasEl departamento de ventas dispone de tres servicios distintos de ventas: las ventas a domicilio del clientemediante un representante de ventas. Las ventas a través de una de las operadoras de la empresa, con la queel cliente solicita sus pedidos a través del medio telefónico. Y por último, se dispondrá de servicios webpara 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 propiosclientes (caso del representante) o bien para cualquier cliente (caso de la operadora). Los pedidos figuraránen estado de elaboración y eliminar a petición del cliente o modificar las líneas del pedido, ya sea encantidades 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 casode la operadora podrá modificar cualquier cliente, y en el caso del representante de ventas podrá modificarcualquiera de los clientes a los que representa. También podrán darse de baja clientes, o darse de alta unosnuevos. El cliente online también podrá a través de los servicios web modificar sus datos, darse de alta o debaja.

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 elcatálogo a la hora de elaborar su pedidos.

5.6 Gestión de EnvíosEn el sistema de envíos, los pedidos se cargan en los camiones y se refleja el estado nuevo de los pedidosen el sistema,

5.6.1 Enviar los pedidos del almacén pendientes de envíoCuando se realiza un envío se incorporan los datos del transportista, referencia del envío y fecha en la quese realizó el transporte.

5.6.2 Control de los recibos de entregaPosteriormente se lleva un control de recibos una vez que el cliente ha recibido los pedidos en la direcciónde envío especificada. El estado de los envíos de los pedidos se podrá consultar vía los servicios web porparte del cliente o mediante el propio sistema por parte del personal tanto de ventas como de almacén ytransportes.



5.7 Departamento de Contabilidad y FacturaciónEl departamento de contabilidad y facturación tendrá acceso a todo el subsistema de contabilidad yfacturación, es decir, todo aquello que englobe cobro de pedidos pendientes, gestión de nóminas ycomisiones, 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 Producto8.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]



A. Atributos de Características

Número ynombre de lacaracterística

Estado Beneficio Esfuerzo Riesgo Estabilidad Asignación

5.1 Depart. deRecursosHumanos

Propuesta: Sí

Aprobada: Sí

Incorporada:No

Útil Bajo [A definir porel cliente]

[A definir porel cliente]

Ninguna

5.2 Depart. deMarketing

Propuesta: Sí

Aprobada: Sí

Incorporada:No



Ninguna

5.3 Depart. deLogística

Propuesta: Sí

Aprobada: Sí

Incorporada:No

Importante

Medio [A definir porel cliente]


Ninguna

5.3.1 Control deestadísticas de

datos

Propuesta: Sí

Aprobada: Sí

Incorporada:No

Útil Medio [A definir porel cliente]


Ninguna

5.4 Gestión deAlmacén

Propuesta: Sí

Aprobada: Sí

Incorporada: Sí

Crítica Alto [A definir porel cliente]


J.A. Mocholí, GermánMira, Miguel Mascilla

y Eduardo Bueno

5.4.1 Atenciónde órdenes de

pedido

Propuesta: Sí

Aprobada: SíCrítica Alto [A definir por

el cliente][A definir por

el cliente]José Antonio Mocholí



Incorporada: Sí

5.4.2 Gestión deincidencias de

pedido

Propuesta: Sí

Aprobada: Sí

Incorporada:No



Ninguna

5.4.3 Consultade estado de los

pedidos

Propuesta: Sí

Aprobada: Sí

Incorporada: Sí

Importante



Eduardo Bueno

5.5 Gestión deVentas

Propuesta: Sí

Aprobada: Sí

Incorporada: Sí

Crítica Alto [A definir porel cliente]


José Antonio Mocholí,Germán Mira yMiguel Mascilla

5.5.1 Elaborarpedidos y

ofertas

Propuesta: Sí

Aprobada: Sí

Incorporada: Sí



José Antonio Mocholí,Germán Mira yMiguel Mascilla

5.5.2 Gestión dedatos de clientes

Propuesta: Sí

Aprobada: Sí

Incorporada:No

Importante



Ninguna

5.5.3 Consultade productos del

catálogo

Propuesta: Sí

Aprobada: Sí

Incorporada:No

Importante



Ninguna

5.6 Gestión deEnvíos

Propuesta: Sí

Aprobada: Sí

Incorporada:

Importante



Ninguna



No

5.6.1 Enviar lospedidos del

almacén

Propuesta: Sí

Aprobada: Sí

Incorporada:No

Importante

Bajo [A definir porel cliente]


Ninguna

5.6.2 Control delos recibos de

entrega

Propuesta: Sí

Aprobada: Sí

Incorporada:No



Ninguna

5.7 Depart. deContabilidad y

Facturación

Propuesta: Sí

Aprobada: Sí

Incorporada:No



Ninguna

3.2. Glosario.


20/05/2013 0.8Versión preliminar del glosario, a falta decompletar 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.0Versión modificada con la incorporación denueva terminología derivada demodificaciones en los requisitos

20/09/2013 2.1Versión revisada en la primera iteración deconstrucción. Términos actualizados

20/10/2013 2.9Versión para ser aprobada por elStakeholder en la segunda iteración de lafase de construcción

20/11/2013 3.0Versión revisada para la segunda iteración,pendiente de ser validad por el Stakeholder.



Tabla de Contenidos1. Introducción 25

1.1 Propósito 251.2 Alcance 251.3 Referencias 251.4 Organización del Glosario 25

2. Definiciones 25

2.1 Almacén 252.2 Atender pedido 252.3 Cancelar pedido atendido 262.4 Cancelar pedido en elaboración 262.5 Cancelar pedido listo para envío 262.6 Cancelar pedido online 262.7 Catálogo de productos 262.8 Cliente externo 262.9 Cliente online 262.10 Consultar pedidos a enviar 272.11 Cobro a clientes 272.12 Comprar a proveedor 272.13 Confeccionar catálogo 272.14 Consultar catálogo 272.15 Consultar pedidos no atendidos 272.16 Contable 282.17 Control de estadísticas 282.18 Departamento de contabilidad y facturación 282.19 Departamento de logística 282.20 Departamento de marketing 282.21 Departamento de recursos humanos 292.22 Elaborar pedido online 292.23 Elaborar pedido 292.24 Empleado de marketing 292.25 Empleado de recursos humanos 292.26 Empresa de transportes 292.27 Encargado de transporte 302.28 Enviar pedido 302.29 Facturar entrega de un pedido 302.30 Fecha de atención 302.31 Fecha de elaboración 302.32 Fecha de envío 312.33 Fecha de envío al almacén 312.34 Fecha de listo para envío 312.35 Gestión de almacén 312.36 Gestión de clientes 312.37 Gestión de envíos 322.38 Gestión de nóminas 322.39 Gestión de personal 322.40 Gestión de ventas 32



2.41 Incidencia pedido 322.42 Ingeniero de logística 332.43 Introducir recibos 332.44 Jefe de almacén 332.45 Jefe de recursos humanos 332.46 Jefe de ventas 332.47 Línea de pedido 342.48 Listado de pedidos en atención 342.49 Listado de pedidos enviados 342.50 Listado de pedidos listos para envío 342.51 Listado de pedidos no atendidos 342.52 Operadora 342.53 Orden de pedido 352.54 Otorgar incentivos 352.55 Pasar pedido a envío 352.56 Pedido en atención 352.57 Pedido pendiente de cobro 352.58 Pedido en elaboración 352.59 Pedido en envío 362.60 Pedido listo para envío 362.61 Pedido no atendido 362.62 Política Producto 362.63 Producto 362.64 Proveedor 362.65 Reabastecer almacén 362.66 Realizar envío 372.67 Realizar oferta 372.68 Redistribución de personal 372.69 Región 372.70 Registrarse en el sistema 372.71 Reposición de stock 372.72 Representante de ventas 382.73 Técnico de almacén 382.74 Usuario de ventas 38

3. Estereotipos UML 38



Glosario10. IntroducciónEste documento recoge todos y cada uno de los términos manejados a lo largo de todo el proyecto dedesarrollo de un sistema para la gestión de artículos deportivos de la empresa Deportes LSI 03. Se trata deun diccionario informal de datos y definiciones de la nomenclatura que se maneja, de tal modo que se creaun estándar para todo el proyecto.

10.1 PropósitoEl propósito de este glosario es definir con exactitud y sin ambigüedad la terminología manejada en el proyecto dedesarrollo de un sistema para la gestión de artículos deportivos. También sirve como guía de consulta para laclarificación de los puntos conflictivos o poco esclarecedores del proyecto.

10.2 AlcanceEl 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, eldepartamento de marketing, el departamento de contabilidad y facturación, en la gestión de envíos, en la gestión dealmacenes y en la gestión de ventas, se refleja con claridad en este documento.

10.3 ReferenciasEl 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 GlosarioEl presente documento está organizado por definiciones de términos ordenados de forma ascendente según laordenación alfabética tradicional del Español.

11. DefinicionesA continuación se presentan todos los términos manejados a lo largo de todo el proyecto de desarrollo de un sistemapara la gestión de artículos deportivos en la empresa Deportes LSI 03.

11.1 AlmacénUn almacén es una de las naves pertenecientes a la empresa Deportes LSI 03 en la que se mantiene el stockde productos que se servirá a los clientes según pedido. Existe un almacén por cada región definida, que esel encargado de servir los pedidos de aquellos clientes cuya dirección de envío sea la perteneciente a dicharegión. La empresa también dispone de un almacén central desde el cual se reabastece el stock de losdistintos almacenes regionales.

11.2 Atender pedidoEl técnico del almacén de una determinada región selecciona un pedido y asigna línea por línea una reserva de stockdel producto para dicho pedido.



11.3 Cancelar pedido atendidoUn pedido que ya ha sido atendido por un técnico de almacén puede ser cancelado por el técnico de almacénmientras el pedido esté en el almacén y no esté en envío, simplemente eliminándolo de la base de datos y liberandoel stock que tiene asignado. El cliente puede cancelar un pedido que está siendo enviado, pero con un cargo añadidopor costes de transporte.

11.4 Cancelar pedido en elaboraciónUn 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 lasegunda puede cancelar pedidos en elaboración de cualquier cliente. El propio cliente puedeeliminar directamente sus pedidos en elaboración si accede al sistema como cliente online ydirectamente a través de la página web de elaborar pedidos online.

11.5 Cancelar pedido listo para envíoUn pedido en estado de listo para envío sólo puede ser cancelado por el técnico de almacén que pertenezca alalmacén regional que sirve a dicho pedido. El pedido podrá ser eliminado de la lista de pedidos listos para envíomediante la interfaz del mencionado usuario, actualizándose la lista de pedidos listos para envío.

11.6 Cancelar pedido onlineUn pedido que está en elaboración puede ser cancelado por el cliente online simplemente seleccionando através de la página web el pedido que desea eliminar y suprimiéndolo. La base de datos se actualiza con laeliminación del pedido en elaboración. Sólo se pueden eliminar online pedidos en elaboración.

11.7 Catálogo de productosEl catálogo de productos es la colección de artículos deportivos con los que trabaja la empresa Deportes Lsi03. 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 deproductos comprende el nombre del artículo, una referencia del mismo dentro de la catalogación de laempresa, 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 delmodelo de casos de uso del negocio, el cliente externo representa uno de tantos agentes externos con losque 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 onlineEl 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 empresaDeportes LSI 03. El cliente online puede darse de alta como cliente nuevo, puede darse de baja omodificar sus datos. También puede elaborar pedidos a través de la página web.



11.10 Consultar pedidos a enviarLa consulta de los pedidos a enviar la puede realizar el encargado de transportes mediante lainterfaz gráfica que muestra la funcionalidad principal del subsistema de gestión de envíos.

11.11 Cobro a clientesEl pago de los pedidos que realizan los clientes se realiza de diversas maneras según el tipo de cliente. En primerlugar, una vez que se ha entregado la mercancía en la dirección de envío que ha especificado el cliente para laentrega de un pedido, se realiza la formalización de un recibo que posteriormente se introducirá en el sistemainformático. En segundo lugar, una vez que el recibo ha llegado al departamento de cobro y facturación, sedetermina el tipo de pago que ha de realizar el cliente según la forma de pago que haya solicitado (a 30 días, a 60días, etc.). Por último, se remite la factura al cliente una vez realizado el cobro del pedido.

11.12 Comprar a proveedorLa compra a proveedores se realiza a través del departamento de logística, encargado dereabastecer tanto el almacén central como los distintos almacenes regionales de la empresa. Elingeniero de logística contacta con los distintos proveedores cuando se detecta déficit en algúnartículo o cuando se prevé un volumen de ventas elevado. Se selecciona al proveedor quemarque el precio más competitivo de acuerdo con la política de compras que marca la empresa.

11.13 Confeccionar catálogoEl catálogo de productos sufre constantes cambios debido a la fluctuación de las demandas delos artículos y las diferentes modas que se apoderan del momento. Por tanto, es responsabilidaddel departamento de marketing de la empresa la actualización del catálogo de productos queofrece la empresa a sus clientes.

11.14 Consultar catálogoLa consulta del catálogo se realiza mediante las interfaces que ofrece el sistema. Tanto losrepresentantes de ventas como las operadoras pueden en todo momento consultar el catálogopara informar a sus clientes de las descripciones de los productos y precios, y para consultar lasreferencias de los artículos. Los empleados del departamento de marketing también consultanel catálogo para buscar posibles actualizaciones. También se puede consultar el catálogo deproductos a través de Internet vía la web de la empresa, como cliente online.

11.15 Consultar pedidos no atendidosLos pedidos que figuran como pedidos no atendidos se pueden consultar en cualquiera de losalmacenes regionales o en el almacén central por el técnico de almacén, mediante la interfaz



gráfica correspondiente en la pestaña de “no atendidos” figura la lista de los pedidos que aún nohan 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 estaconsulta sobre un pedido en particular, el pedido pasa automáticamente al estado de pedidoatendido.

11.16 ContableEmpleado del departamento de contabilidad y facturación. Encargado de los cobros yfacturaciones a clientes y de llevar la contabilidad en general de la empresa.

11.17 Control de estadísticasEl control de estadísticas es un resumen general de los datos de interés relacionado con laempresa, cada uno de los distintos usuarios autorizados podrá acceder a diferentes visiones delas estadísticas generadas, por ejemplo, para el ingeniero de logísticas las estadísticas másinteresantes 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ónEl departamento de contabilidad y facturación es el encargado del cobro de pedidos entregados a los clientes, defacturar a los clientes, de la asignación de remuneraciones de los distintos empleados y de todas las característicaspropias de la contabilidad empresarial.

11.19 Departamento de logísticaDepartamento encargado de la gestión eficiente de la distribución de productos y stock del almacén central de laempresa a los distintos almacenes regionales. También tiene la funcionalidad de compra de productos a proveedorespara reabastecer el stock del almacén central y de la gestión eficiente de las distintas regiones definidas para todoslos países en los que Deportes LSI 03 ofrece sus productos.

11.20 Departamento de marketingEste departamento está encargado de la realización de ofertas de los distintos productos delcatálogo. También están encargados de la publicidad y promoción de artículos, determinar lasdistintas políticas de ventas aplicadas, y confeccionar el catálogo cuando sufra modificacionessegún la fluctuación de oferta y demanda del mercado.



11.21 Departamento de recursos humanosEste departamento cumple con las siguientes funciones: la distribución de la plantilla de laempresa, determinar el puesto de trabajo del personal, determinar los contratos que se fijancon 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 onlineEl cliente se conecta a la página web de la empresa y puede realizar pedidos a través de Internet de un modobastante sencillo. Se identifica como cliente online con un nombre de usuario y una contraseña y abre la página deelaborar un pedido nuevo o modificar los pedidos en elaboración que ya tuviese pendientes. El cliente online puedeañadir o modificar líneas de un pedido en elaboración ya existente o añadir nuevas líneas a un pedido nuevo. Unavez haya concluido puede pasar el pedido al almacén regional correspondiente a la dirección de envío o bienguardarlo como pedido en elaboración para posteriores modificaciones.

11.23 Elaborar pedidoEl representante de ventas o la operadora reciben la petición de un cliente para elaborarpedido. El listado de pedidos en elaboración de dicho cliente aparece en la pantalla y elrepresentante de ventas o la operadora pueden modificar un pedido ya existente, borrarlo, obien crear uno nuevo. El representante de ventas o la operadora pueden añadir o modificarlíneas de un pedido en elaboración ya existente o añadir nuevas líneas a un pedido nuevo. Unavez hayan concluido pueden pasar el pedido al almacén regional correspondiente a la direcciónde envío o bien guardarlo como pedido en elaboración para posteriores modificaciones.

11.24 Empleado de marketingEl empleado de marketing es un usuario del sistema que pertenece al departamento de marketing. Puedeconfeccionar el catálogo, cambiando cualquier dato de los productos existentes, o también eliminando o agregandoproductos nuevos. Está encargado de la política de productos, es decir, de la política de ventas que se debe aplicar acada artículo. También puede realizar ofertas, definiendo precios más competitivos o ajustados a los márgenes debeneficios.

11.25 Empleado de recursos humanosEste empleado pertenece al departamento de recursos humanos y es responsable de realizar lasentrevistas de trabajo y genera y modifica la nóminas de los distintos empleados de la empresa

11.26 Empresa de transportesLa empresa de transportes es la encargada de trasladar los envíos de los distintos pedidos queestén listos para envío y se haya decidido enviar al cliente. Este empresa es una subcontrata deDeportes LSI 03 para realizar el trabajo de envío de pedidos, sin embargo el encargado detransportes es un empleado de la empresa Deportes LSI 03 y no de la subcontratada.



11.27 Encargado de transporteEste usuario del sistema es el encargado de gestionar los pedidos a enviar. Se encarga de cargar el camión con lospedidos que ya están listos para enviar, y de devolver los recibos de entrega de los pedidos. Una vez que el pedidoha sido entregado en la dirección de envío que cada cliente había especificado para cada envío, se genera un reciboque será introducido en el sistema por el encargado de transportes para el control de cobros y facturación de lospedidos enviados.

11.28 Enviar pedidoEl 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 elpedido a pedido en envío, introduce el nombre del transportista que realizará el envío y elsistema introducirá la fecha del envío.

11.29 Facturar entrega de un pedidoUna vez que un pedido ha sido entregado en la dirección de envío que había especificado elcliente, éste firma un recibo de entrega que será introducido en el sistema por el encargado detransportes. Una vez hecho esto, el pedido figura como pendiente de cobro. El empleado deldepartamento de contabilidad y facturación consulta los pedidos que quedar por facturar ygenera las facturas de los mismos, teniendo en cuenta la forma de pago especificada por pedidoy cliente.

11.30 Fecha de atenciónEs la fecha que tiene asignada una orden de pedido una vez que el técnico de almacén hacomenzado a asignarle productos del stock del almacén. La fecha de atención es única y no semodifica en ningún momento, puesto que se asigna la primera vez que un pedido recibeatención. Si el pedido figura como en elaboración o como no atendido, tendrá el campo de estafecha vacío.

11.31 Fecha de elaboraciónLa fecha de elaboración figura en los pedidos que estén en estado de elaboración. Esta fecha seasigna automáticamente cuando se crea un pedido nuevo en la elaboración de órdenes depedido por parte de la operadora o por el representante de ventas. Esta fecha no se puedemodificar en ningún momento ya que se asigna por primera vez por medio del sistema.



11.32 Fecha de envíoLa fecha de envío figura como vacía en todos aquellos pedidos que no hayan sido enviados. Si elpedido figura como pedido en envío se mostrará la fecha en la que el encargado de transportespasó 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énEsta fecha la asigna el sistema a todos aquellos pedidos en elaboración que son enviados alalmacén por los representantes de ventas o las operadoras. Esta fecha figurará vacía en todosaquellos pedidos que estén en estado de elaboración.

11.34 Fecha de listo para envíoEsta fecha se asignará por el sistema a todas aquellas órdenes de pedido que el técnico dealmacén haya pasado a listas para envío. Esta fecha figura como vacía en todos aquellos pedidosque no estén en envío o en listos para envío. Esta fecha se eliminará de aquellos pedidos quefiguren como listos para envío y que el técnico de almacén decida cancelar y pasar a enatención.

11.35 Gestión de almacénLa gestión de almacén es el subsistema definido como parte del sistema principal quecomprende toda la empresa Deportes LSI 03 y que trata todos aquellos aspectos del sistema quese refieren a tratamiento de órdenes de pedido de los diferentes clientes. La gestión de almacénse centra en la atención de órdenes de pedido, cancelación, paso a envío, consultas, gestión deincidencias de stock y reposición de stock. Los usuarios de este subsistema son los técnicos dealmacén y los jefes de almacén

11.36 Gestión de clientesGestión de clientes es un caso de uso definido dentro del subsistema de gestión de ventas, ycuya 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 declientes, ya sea alta de nuevos clientes, baja de clientes que ya figurasen en el sistema, ya sea dela modificación de los datos de los clientes que figuraban como dados de alta. Este caso de usose puede invocar a través de la interfaz de usuarios de ventas.



11.37 Gestión de envíosLa gestión de envíos es el subsistema definido como parte del sistema principal que comprendetoda la empresa de Deportes LSI 03 y que trata todos aquellos aspectos del sistema que serefieren 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 medianteun control de pedidos en envío, y tras su posterior entrega se realiza la introducción de recibospara que pasen a la funcionalidad definida para tal efecto en el subsistema del departamento decontabilidad y facturación.

11.38 Gestión de nóminasGestión de nóminas es un caso de uso invocado por el empleado de recursos humanos o por el jefe de recursoshumanos. En la gestión de nóminas se tienen en cuenta todos los aspectos que conciernen a las comisiones otorgadasa los empleados de Deportes LSI 03, los salarios fijos, las primas, datos personales de cada empleado, etc.

11.39 Gestión de personalGestión de personal es un caso de uso que invoca el jefe del departamento de recursoshumanos y cuya funcionalidad define el reparto y asignación de la plantilla y puestos de trabajode los distintos empleados de la empresa Deportes LSI 03. La redistribución y asignación detareas, etc, es la funcionalidad de este caso de uso.

11.40 Gestión de ventasLa gestión de ventas es un subsistema definido como parte del sistema principal que comprendetoda la empresa de Deportes LSI 03 y que trata todos aquellos aspectos del sistema que serefieren al tratamiento de ventas realizadas a los clientes, ya sea a través de un representantede 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 lasoperadoras aunque restringido por supuesto a sus datos personales. La funcionalidad querecoge este subsistema engloba todo lo que concierne a la elaboración de nuevas órdenes depedido, modificación de órdenes ya existentes, cancelación de las mismas o envío al almacénpara que sean servidas.

11.41 Incidencia pedidoIncidencia pedido es un caso de uso cuya funcionalidad es proporcionar al técnico de almacén la posibilidad degenerar incidencias de pedidos en los que se hayan dado situaciones especiales como lo son que al asignarcantidades del stock del almacén el sistema detecte que la cantidad a asignar deja el stock del producto en elalmacén con déficit, es decir, por debajo de una cantidad mínima, también que no existe stock de un producto



suficiente para satisfacer las necesidades de una orden de pedido, o que hayan pasado más de dos días desde que unpedido figura en atención o como listo para envío. Las incidencias de pedido las gestionará el jefe de almacén, obien haciendo una reposición de stock a través de otro almacén o bien trasladando la incidencia a cargo del ingenierode logística.

11.42 Ingeniero de logísticaEl ingeniero de logística es el empleado principal del departamento de logística , encargado de la gestión deproveedores, pedidos a los mismos, reposición de stock tanto en los distintos almacenes regionales como en elalmacén central de que dispone a la empresa Deportes LSI 03, control de estadísticas de los distintos almacenesregionales y previsión de almacenamiento de stock de los distintos productos con los que trabaja la empresa.

11.43 Introducir recibosIntroducir recibos es un caso de uso que ofrece su funcionalidad al usuario encargado detransportes, y que consiste en que cuando un pedido se entrega en destino, el cliente firma unrecibo de entrega y éste es introducido en el sistema para que figure el pedido como pendientede cobro. En el recibo figura el transportista que realizó la entrega, la fecha de envío y deentrega y el detalle de la orden de pedido entregada.

11.44 Jefe de almacénEl empleado jefe de almacén de la empresa Deportes LSI 03 participa en el sistema dentro delsubsistema de gestión de almacén, y que hace uso de las funcionalidades definidas en los casosde uso de reposición de stock, gestión de incidencias de almacén y consultas de pedidos.

11.45 Jefe de recursos humanosEl empleado jefe de recursos humanos de la empresa Deportes LSI 03 participa en el sistemadentro del subsistema de departamento de recursos humanos, y que hace uso de lasfuncionalidades definidas en los casos de uso gestión de personal, redistribución de personal ygestión de nóminas.

11.46 Jefe de ventasEl empleado jefe de ventas de la empresa Deportes LSI 03 participa en el sistema dentro delsubsistema de gestión de ventas, y que hace uso de las funcionalidades definidas en los casos deuso de control de estadísticas, otorgar incentivos y gestión de clientes.



11.47 Línea de pedidoLa línea de pedido es uno de los componentes de la orden de pedido, y es donde figuran losdetalles de los productos a pedir. Se corresponde una línea de pedido por producto solicitado enuna orden de pedido. Una línea de pedido se compone de la siguiente información: código delproducto del catálogo, referencia de la orden de pedido a la que pertenece, cantidad deproducto solicitada al almacén regional, precio del producto y por último el stock asignado en elalmacén en el que se trata la orden de pedido.

11.48 Listado de pedidos en atenciónEl listado de pedidos en atención es una parte de la funcionalidad que ofrece la interfaz de usuario del técnico dealmacén, y en la que se muestra la lista de órdenes de pedido que figuran en un almacén regional pendientes de sercompletados, es decir, en estado de atención.

11.49 Listado de pedidos enviadosEl listado de pedidos enviados es una parte de la funcionalidad que ofrece la interfaz de usuario del técnico dealmacén, y en la que se muestra la lista de órdenes que figuran como enviadas desde un almacén regional enconcreto.

11.50 Listado de pedidos listos para envíoEl listado de pedidos listos para envío es una parte de la funcionalidad que ofrece la interfaz deusuario del técnico de almacén, y en la que se muestra la lista de órdenes de pedido que figuranen un almacén regional pendientes de ser enviadas, es decir, en estado de listos para envío.

11.51 Listado de pedidos no atendidosEl listado de pedidos en atención es una parte de la funcionalidad que ofrece la interfaz deusuario del técnico de almacén, y en la que se muestra la lista de órdenes de pedido que figuranen un almacén regional pendientes de ser atendidas, es decir, en estado de no atendidas.

11.52 OperadoraLa operadora es una empleada de la empresa de Deportes LSI 03 que hace uso de la funcionalidad definida en elsubsistema de gestión de ventas, y que se comunica con los clientes por teléfono y elabora nuevas órdenes de pedidopara éstos, modifica o cancela otras existentes y puede acceder a gestión de clientes. Tiene la característica especialde poder atender a cualquier cliente, a diferencia del representante de ventas que sólo puede tratar a los clientes a losque representa.



11.53 Orden de pedidoUna orden de pedido es una solicitud de servicio por parte de un cliente para que la empresa Deportes LSI 03 lesirva una serie de artículos o productos de su catálogo. Las órdenes de pedido son generadas por los usuarios deventas 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 yson entregadas a los mismos y facturadas. Las órdenes de pedido comprenden la siguiente información dentro delsistema: código del pedido para identificarla de forma única, código del cliente que ha realizado la orden, DNI delusuario 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 desalida del almacén.

11.54 Otorgar incentivosOtorgar incentivos es un caso de uso cuya funcionalidad la utiliza el empleado jefe de ventas dentro del subsistemade gestión de ventas y que consiste en la asignación de primas y comisiones a los distintos empleados de ventas paraincentivar su trabajo.

11.55 Pasar pedido a envíoPasar pedido a envío es un caso de uso cuya funcionalidad la utiliza el técnico de almacén y cuya utilidad es la decambiar el estado de un pedido que se encuentra en atención para que figure como listo para envío. En caso de quelas cantidades de stock asignado en el almacén no se correspondan a las solicitadas por el cliente se generarán losavisos y controles pertinentes.

11.56 Pedido en atenciónUn pedido, o una orden de pedido, figura en estado de “en atención” cuando esté siendoatendido por un técnico de almacén, es decir, cuando se le estén asignando cantidades del stockque figura en el almacén.

11.57 Pedido pendiente de cobroUn pedido, o una orden de pedido, figura en estado de “pendiente de cobro” cuando ya ha sidoentregado en la dirección de envío y el cliente ha firmado el recibo que posteriormente ha sidointroducido por el encargado de transportes.

11.58 Pedido en elaboraciónUn pedido, o una orden de pedido, figura en estado de “en elaboración” cuando ha sido creadopor un usuario de ventas y aún no ha sido enviado al almacén. En este estado, el pedido puedeser modificado en líneas de pedido y dirección de envío.



11.59 Pedido en envíoUn pedido, o una orden de pedido, figura en estado de “en envío” cuando ya haya sido cargadoen un camión y esté pendiente de ser entregado en la dirección de envío que ha especificado elcliente.

11.60 Pedido listo para envíoUn pedido, o una orden de pedido, figura en estado de “listo para envío” cuando las cantidadesde stock asignadas por el técnico de almacén satisfacen las cantidades solicitadas por el clienteen el pedido.

11.61 Pedido no atendidoUn pedido, o una orden de pedido, figura en estado de “no atendido” cuando ya ha sido enviadoal 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 ProductoPolítica producto es un caso de uso definido en el subsistema departamento de marketing ycuya funcionalidad es ofrecer la posibilidad al empleado de marketing de que pueda cambiar lapolítica de ventas aplicada a los distintos productos de la empresa Deportes LSI 03.

11.63 ProductoLos productos con los que trabaja Deportes LSI 03 son artículos deportivos, es decir, todos aquellos artículos quetengan que ver con deportes, por ejemplo, balones, raquetas, ropa deportiva, pelotas, redes, y cualquier tipo deproducto relacionado con el deporte como tiendas de campaña, sacos de dormir, bicicletas y otros.

11.64 ProveedorUn 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énReabastecer almacén es un caso de uso del subsistema del departamento de logística y queconsiste en que el ingeniero de logística solicita a un proveedor o a un almacén, ya sea el centralu otro regional, que sirva artículos a uno o varios almacenes para reponer el stock necesariopara atender órdenes de pedido.



11.66 Realizar envíoRealizar envío es un caso de uso del subsistema de gestión de envíos y cuya funcionalidadofrece al encargado de transportes la posibilidad de consultar los pedidos listos para envío y alcargarlos en el camión registrar en el sistema que el pedido a pasado a estar en envío.

11.67 Realizar ofertaRealizar oferta es un caso de uso del subsistema departamento de marketing y cuyafuncionalidad ofrece al empleado de marketing la posibilidad de realizar ofertas de lanzamientode distintos productos, ofertas de venta a bajos precios u ofertas de venta a precio de costepara captar nuevos clientes u ofrecer ventajas a los clientes actuales.

11.68 Redistribución de personalRedistribución de personal es un caso de uso del subsistema departamento de recursoshumanos y cuya funcionalidad ofrece al jefe de dicho departamento la posibilidad de distribuirla plantilla o el personal ajustando las necesidades de cada momento de la empresa DeportesLSI 03.

11.69 RegiónLa empresa Deportes LSI 03 al trabajar y tener delegación en todo el mundo, ha dividido el mundo en regiones parapoder gestionar mejor a sus distintos países clientes. Existe una región central en la que se ubican las principalesinstalaciones 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 abastecimientoprincipal a los distintos almacenes regionales. En cada una de las restantes regiones se localiza un departamento degestión de ventas y de uno de gestión del almacén regional. Las órdenes de pedido de los clientes de un paísdeterminado que pertenece a una región determinada se sirven a partir del almacén asignado a dicha región.

11.70 Registrarse en el sistemaCada vez que un usuario accede al sistema debe registrarse en el mismo haciendo uso de un nombre de usuario y unacontraseña asociada al mismo. Estos datos figuran en la base de datos, y el sistema comprueba que son correctos yofrece la funcionalidad determinada según el tipo de usuario que se haya registrado. Por ejemplo, si el técnico dealmacén se registra en el sistema sólo podrá acceder a la funcionalidad de técnico de almacén y sólo podrá trabajarcon los pedidos pertenecientes a la región asignada al almacén en que trabaja.

11.71 Reposición de stockReabastecer almacén es un caso de uso del subsistema de gestión de almacén que consiste en solicitar a un


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 ventasEl representante de ventas es un empleado de la empresa Deportes LSI 03 que hace uso de la funcionalidad definidaen el subsistema de gestión de ventas, y que se comunica directamente con los clientes en sus respectivos al que elsistema ofrece distintas funcionalidades, entre las que se encuentra la elaboración de nuevos pedidos, lamodificación de pedidos que se encuentren en elaboración y la cancelación de pedidos en elaboración. También seofrece la gestión de clientes, la consulta del catálogo de productos, la consulta de productos enviados al almacén y lasolicitud de registro de incidencias en una orden de pedido. La única restricción para el representante de ventas esque sólo puede trabajar con aquellos clientes a los que representa, no tiene acceso a ningún otro cliente que norepresente.

11.73 Técnico de almacénEl técnico de almacén es un empleado de la empresa Deportes LSI 03 y que hace uso de lafuncionalidad 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 pedidocorrespondiente a una orden de pedido, y una vez completado éste, dispone la orden de pedidocomo listo para envío, de tal modo que el encargado de transportes, posteriormente, enviará enlos camiones los pedidos que el técnico de almacén ha confeccionado. También dispone de lafuncionalidad de cancelar pedidos atendidos y de registrar incidencias de pedido.

11.74 Usuario de ventasEl usuario de ventas es una generalización de los representantes de ventas, operadoras yclientes online. Ofrece una visión más general que la de sus especializaciones, y contempla en elmodelo de análisis los casos de uso comunes a representante, operadora y cliente online, comoson 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 andtheir semantic implications—a textual description of the meaning and significance of the stereotype andany limitations on its use—for stereotypes already known or discovered to be important for the systembeing modeled. The use of these stereotypes may be simply recommended or perhaps even mademandatory; for example, when their use is required by an imposed standard or when it is felt that their usemakes 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.]



3.3. Casos de Usos de Rational Rose.

3.3.1. Especificaciones de caso de uso.

Especificaciones de atender el pedido.

Historia de RevisionesFecha Versión Descripción Autor

20/05/2013 0.9 Plantilla del caso de uso para revisar con elStakeholder

20/06/2013 1.0 Plantilla revisada por el Stakeholder el día13/11/2002

20/07/2013 2.0 Versión modificada por los cambiosaplicados por el Stakeholder en una reuniónprevia.

20/08/2013 2.1 Plantilla revisada por el Stakeholder y queincluye las modificaciones de usuario parala segunda iteración de construcción

20/09/2013 3.0 Plantilla revisada para la segunda iteraciónde construcción



Tabla de Contenidos1. Atender Pedido 41

1.1 Descripción 41

2. Flujo de Eventos 41

2.1 Flujo Básico 412.2 Flujos Alternativos 41

2.2.1 En el punto 2.2 41

3. Precondiciones 42

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

3.2 El técnico de almacén ha realizado correctamente el registro en el sistema introduciendo elnombre de usuario y la contraseña 42

4. Poscondiciones 42

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

5. Puntos de Extensión 42

5.1 Incidencia Pedido en el paso 4.2 42



13. Atender Pedido13.1 Descripción

El usuario técnico de almacén selecciona de la interfaz correspondiente al mismo un pedido para atender, donde semuestra 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 elpedido continuará en estado de “en atención”. Se abre una nueva interfaz en la que se muestran los detalles delpedido seleccionado.

14. Flujo de Eventos14.1 Flujo Básico

1. El técnico de almacén selecciona un pedido la lista de pedidos no atendidos, en lapestaña “no atendidos” o de la lista de pedidos atendidos en la pestaña “en atención” ypulsa el botón de “consultar” y luego el botón de “atender pedido” en el primer caso, yen el segundo el botón “atender pedido”.

2. El sistema muestra una nueva interfaz en la que se muestran los datos del pedido: elcódigo del pedido, la fecha de llegada al almacén, la fecha de atención, la dirección deenví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 elpedido figure en la lista de pedidos en estado “listos para envío”.

14.2 Flujos Alternativos

14.2.1 En el punto 2.2Si en el paso 4.1 la cantidad es negativa el sistema generará un mensaje de error.



15. Precondiciones16. 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 elsistema introduciendo el nombre de usuario y la contraseña

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

19. Puntos de Extensión19.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 obien la cantidad asignada deja el producto en déficit, el sistema generará un aviso de generación de incidencia y sepodrá invocar al caso de uso Incidencia Pedido.

Especificaciones de cancelar pedido.



José Luis Martínez


César López Rodríguez

10/06/2013 2.0 Plantilla revisada en la primera iteración dela fase de construcción






Tabla de Contenidos1. Cancelar Pedido Atendido 44

1.1 Descripción 44




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


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



20. Cancelar Pedido Atendido20.1 Descripción

El técnico de almacén anula un pedido ya atendido.


1. El cliente ha solicitado cancelar un pedido en estado de “no atención”, en estado de “enatenció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 elcliente 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.


22. Precondiciones22.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 sistemaintroduciendo 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. Poscondiciones23.1 El pedido es eliminado del sistema y se liberan los productos reservados paraatender ese pedido.



Especificaciones de cobro a cliente.


20/05/2013 1.0 Versión preliminar lista para ser revisadapor el Stakeholder

José Luis Martínez Herrero

Tabla de Contenidos1. Cobro a Clientes 46

1.1 Descripción 46



2.2.1 En el punto 2.1 46


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


4.1. En caso de haberse dado de alta una nueva dirección de facturación, los datos de la mismaquedan almacenados en la base de datos. 474.2. Los pedidos para los cuales se imprime factura pasan al estado “factura emitida”. 474.3. Los pedidos para los que se ha abonado la factura pasan al estado “factura pagada”. 47



1. Cobro a Clientes23.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 servidosatisfactoriamente se emite una factura al cliente con el importe correspondiente al pedido. El contable seleccionaaquellos pedidos ya entregados de los que desea emitir factura. Puede seleccionar el tipo de cobro que desea elcliente (contrareembolso o transferencia bancaria) y seleeciona una dirección de facturación distinta a la usual (si elcliente dispone de más de una). Tras eso se imprimen las facturas y quedan listas para ser enviadas por correo.

2. Flujo de Eventos23.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 agenciade envíos, podrá pasar los pedidos que seleccione al estado “factura pagada”. Una vezalcanzado dicho estado, el pedido no podrá ser modificado de ninguna forma, pasando aengrosar 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.1El sistema muestra para cada cliente la dirección “default” de facturación. Si el contable quiere cambiarla pincha enla línea del cliente y pulsa “cambiar dirección de facturación”. Se le muestran todas las direcciones registradas paraese cliente. Puede seleccionar una de ellas o pulsar “introducir nueva”. Se le pedirán los datos de la nueva direccióny 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.1El contable puede seleccionar un pedido cualquier y pulsar sobre “modificar forma de pago”. Elsistema mostrará las distintas opciones de pago para que se seleccione una de ellas.

.



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






Tabla de Contenidos1. Compra a Proveedores 49

1.1 Descripción 49


2.1 Flujo Básico 49


3.1. El Ingeniero de Logística ha realizado correctamente el login en el sistema. 493.2. El Ingeniero de Logística ha seleccionado el botón “Compra a Proveedores” de su interfazgráfica. 49


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



5. Compra a Proveedores28.2 1.1 DescripciónEl caso de uso lo inicia el actor Ingeniero de Logística. Su fin es comprar los productos de losdistintos almacenes de la empresa. Esta adquisición se basa en la experiencia del propioIngeniero de Logística, que selecciona el almacén a reponer y realiza un pedido a un proveedorde una serie de productos según su criterio.


29. El Ingeniero de Logística accede a Compra a Proveedores.30. El sistema le muestra una pantalla donde llevará a cabo las selecciones correspondientes.31. Primero selecciona el almacén a reponer de la lista de almacenes y pulsa siguiente.32. 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 deproductos

32.2.1 Selecciona un producto del catálogo que se añadirá a la lista del nuevo pedido32.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 losproveedores 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. Precondiciones7.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 suinterfaz gráfica.



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

Especificación de Confeccionar Catalogo.






Tabla de Contenidos1. Confeccionar Catálogo 52

1.1 Descripción 52




3.1. El Empleado de Marketing ha realizado correctamente el registro en el sistema. 523.2. El Empleado de Marketing ha seleccionado el botón de “Confeccionar Catálogo” de su interfazgráfica. 52


4.1. En caso de haberse dado de alta una nuevo producto o proveedor, los datos del mismo quedanalmacenados en la base de datos. 52



9. Confeccionar Catálogo35.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 productosde la empresa. Actualizando productos, borrando o añadiendo nuevos. También puede para un producto determinadomodificar sus características como el proveedor, precio, etc.

10.Flujo de Eventos35.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 unproveedor puede seleccionar uno de los proveedores actuales con el botón proveedoractual 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 proveedoresregistrados. 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énafectados por el mismo).

37.3 Si selecciona modificar producto, se abrirá una ventana con los datos del mismo para queel Empleado de Marketing los modifique a su gusto.

11.Precondiciones11.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.Poscondiciones12.1. En caso de haberse dado de alta una nuevo producto o proveedor, los datos del

mismo quedan almacenados en la base de datos.



Especificación de Consultar Pedidos y Enviar.






Tabla de Contenidos1. Confeccionar Catálogo 52

1.1 Descripción 52




3.1. El Empleado de Marketing ha realizado correctamente el registro en el sistema. 523.2. El Empleado de Marketing ha seleccionado el botón de “Confeccionar Catálogo” de su interfazgráfica. 52


4.1. En caso de haberse dado de alta una nuevo producto o proveedor, los datos del mismo quedanalmacenados en la base de datos. 52



13.Confeccionar Catálogo37.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 productosde la empresa. Actualizando productos, borrando o añadiendo nuevos. También puede para un producto determinadomodificar sus características como el proveedor, precio, etc.


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 unproveedor puede seleccionar uno de los proveedores actuales con el botón proveedoractual 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 proveedoresregistrados. 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énafectados por el mismo).

39.3 Si selecciona modificar producto, se abrirá una ventana con los datos del mismo para queel Empleado de Marketing los modifique a su gusto.

15.Precondiciones15.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.Poscondiciones16.1. En caso de haberse dado de alta una nuevo producto o proveedor, los datos del

mismo quedan almacenados en la base de datos.



Especifiaciones de Consultar Pedidos No Atendidos.


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 elStakeholder


10/06/2013 2.0 Plantilla adaptada a la primera iteración dela fase de construcción


17/06/2013 3.0 Plantilla adaptada a la segunda iteración dela fase de construcción




Tabla de Contenidos1. Consultar Pedidos no Atendidos 58

1.1 Descripción 58




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



40. Consultar Pedidos no Atendidos40.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áficaprincipal. El sistema muestra del listado con los pedidos que no han sido atendidos, los detalles del pedido que hasido seleccionado para su consulta en una nueva interfaz.


1. El técnico selecciona la pestaña de “no atendidos” en su interfaz grafica principal, donde semuestra un listado con los pedidos no atendidos que hay en el sistema.

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

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

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

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

Especificación de Control de Estadística.






Tabla de Contenidos1. Control Estadísticas ¡Error! Marcador no definido.

1.1. Descripción 60


2.1. Flujo Básico 60

2.2. Flujos Alternativos 76


4. Postcondiciones ¡Error! Marcador no definido.



17.Control Estadísticas42.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 puedecrear diversas estadísticas sobre conceptos relacionados con la empresa. Por ejemplo, ventas por sección, ventas delos representantes, pedidos realizados a las operadoras, beneficio de la empresa, etc. Una vez creada una estadísticapuede ser imprimida o guardada en el sistema para su consulta posterior.


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 uotro soporte de almacenamiento.

47.2 Su pulsa el botón imprimir se mandarán a la impresora los resultados.

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










Tabla de Contenidos1. Consultar Productos ¡Error! Marcador no definido.

1.1 Descripción 62




4. Postcondiciones 62



48. Consultar Productos48.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. Semuestra una descripción del producto, su foto y el precio de venta. Puede seleccionarse cualquiera e introducirlo enla orden de pedido si se desea.


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.


50. Precondiciones3.1 El Usuario de Ventas debe estar dado de alta en el sistema

51. Postcondiciones

Especificaciones de Elaborar Pedidos On-line.










Tabla de Contenidos1. Elaborar Pedido Online 64

1.1 Descripción 64



2.2.1 En el paso 4 642.2.2 En el paso 5 642.2.3 En el paso 8 64


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


4.1 La orden de pedido queda almacenada en el sistema si el usuario ha seleccionado “guardar” 654.2 La orden de pedido se envía al almacén correspondiente a la región a la que pertenece ladirección de envío si el usuario seleccionó “enviar al almacén” 654.3 La orden de pedido no se almacena en el sistema si el usuario seleccionó “salir” 65



52. Elaborar Pedido Online52.1 Descripción

El cliente online puede introducir una orden de pedido accediendo a la página de Internet de la empresa. La orden depedido quedará almacenada en el sistema al igual que en el caso de uso Elaborar Pedido.


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 deproductos para seleccionarlos. Conforme se introducen las cantidades se muestra el total delpedido 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éncorrespondiente 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.1 En el paso 4Si 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 5Si algún producto no tiene stock disponible se avisa por pantalla.

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

54. Precondiciones54.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 elsistema



55. Poscondiciones55.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 quepertenece 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.










Tabla de Contenidos1. Elaborar Pedido 67

1.1 Descripción 67



2.2.1 En el punto 1 682.2.2 En el punto 4.1 682.2.3 En el punto 4.2 682.2.4 En el punto 5.1 682.2.5 En el punto 5.2 69


3.1 El representante de ventas o la operadora han realizado correctamente el registro en el sistemamediante el nombre de usuario y la contraseña. 69


4.1 En caso de haberse realizado un nuevo pedido y seleccionado guardar en lugar de solicitar elpaso al almacén, el pedido queda almacenado en el sistema en la lista de pedidos en elaboración. 694.2 En caso de haberse realizado un nuevo pedido y solicitado el paso al almacén, el pedido quedaalmacenado en el sistema en la lista de pedidos no atendidos del almacén. 694.3 En caso de haberse modificado un pedido en elaboración y seleccionado en lugar de solicitar elpaso al almacén, el pedido queda almacenado con las modificaciones pertinentes en el sistema en lalista de pedidos en elaboración. 694.4 En caso de haberse modificado un pedido en elaboración y solicitado el paso al almacén, elpedido queda almacenado con las modificaciones pertinentes en el sistema en la lista de pedidos noatendidos del almacén. 694.5 En caso de haberse realizado un borrado de un pedido en elaboración, el pedido quedaeliminado del sistema y por tanto de la lista de pedidos en elaboración. 69

5. Puntos de Extensión 69

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



Especificación de caso de uso: Elaborar Pedido

56. Elaborar Pedido56.1 Descripción

El representante de ventas o la operadora, después de registrarse en el sistema mediante el usuario y la contraseñapueden 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 tienependientes si los hay. Se pueden modificar, eliminar o realizar nuevos pedidos.


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 realizaruna nueva orden de pedido. En caso de realizar una nueva orden de pedido, ir al punto 4. Encaso de solicitar una modificación de un pedido en elaboración, pasar al punto 5. En caso desolicitar 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 actualdel sistema, la referencia del pedido a modificar, la dirección de envío del pedido y un listado delas líneas de pedido, en las que se reflejan el código de artículo, la descripción del mismo, lacantidad solicitada, el precio, y por último el precio total del pedido, con los datos de las líneasde 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 lacantidad deseada por el cliente. Conforme se introducen las cantidades se muestra el IVA yel 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 sealmacenará en la base de datos con los datos actuales en estado de elaboración, o puedenpasar el pedido a almacén pulsando el botón “enviar a almacén”, en cuyo caso el pedidodeja 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 actualdel sistema, la referencia del pedido a modificar, la dirección de envío del pedido y un listado delas 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íneasde 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 lacantidad deseada por el cliente. Conforme se introducen las cantidades se muestra el IVA yel total del pedido por pantalla.

19.2. El representante de ventas o la operadora pueden modificar una línea de pedidoseleccionando la línea de pedido de la lista de líneas, modificando la cantidad y por últimopulsando 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 casose almacenará en la base de datos con los datos actuales en estado de elaboración, opueden pasar el pedido a almacén pulsando el botón “enviar a almacén”, en cuyo caso elpedido deja de estar en elaboración y aparece en el listado de pedidos no atendidos delalmacén. Pasar al punto 7.

20.El representante de ventas o la operadora seleccionan el pedido en elaboración a borrar ypulsan el botón “cancelar pedido”. El sistema mostrará una ventana de aviso de borrado y depérdida de los datos. El representante de ventas o la operadora pueden confirmar el borradopulsando el botón “aceptar”o cancelar pulsando ”cancelar”. En el primer caso el pedido seelimina 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 quepueden cambiar de cliente, consultar los pedidos del cliente, tanto en elaboración como losenviados al almacén o salir de la aplicación a la pantalla inicial de registro en el sistema.


57.2.1 En el punto 1Si en el paso 1 el cliente no está dado de alta se mostrará un mensaje de error indicando el fracaso de la búsqueda yse podrá invocar el caso de uso gestión de clientes para proceder a su alta. En el caso del representante de ventaspuede ser que el problema se derive de que esté indicando un cliente al que no representa.

57.2.2 En el punto 4.1Si en el punto 4.1 al introducir alguno de los campos número, puerta o código postal se ha metido unnúmero no estrictamente positivo, el sistema generará un mensaje de error.

57.2.3 En el punto 4.2Si en el paso 4.2 el representante de ventas o la operadora introducen una referencia errónea o inexistente, el sistemagenerará un aviso de error de producto no existente. En caso de introducir una cantidad no mayor que cero el sistemagenerará un aviso de error de cantidad errónea. Si se introduce una cantidad por encima del rango máximo razonablede pedido el sistema generará un aviso de haber excedido esta cantidad.

57.2.4 En el punto 5.1Si en el paso 5.1 el representante de ventas o la operadora introducen una referencia errónea o inexistente, el sistemagenerará 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 razonablede pedido el sistema generará un aviso de haber excedido esta cantidad.

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

58. Precondiciones58.1 El representante de ventas o la operadora han realizado correctamente el registro enel sistema mediante el nombre de usuario y la contraseña.

59. Poscondiciones59.1 En caso de haberse realizado un nuevo pedido y seleccionado guardar en lugar desolicitar el paso al almacén, el pedido queda almacenado en el sistema en la lista depedidos en elaboración.

59.2 En caso de haberse realizado un nuevo pedido y solicitado el paso al almacén, elpedido 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 desolicitar el paso al almacén, el pedido queda almacenado con las modificacionespertinentes 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 alalmacén, el pedido queda almacenado con las modificaciones pertinentes en el sistema enla lista de pedidos no atendidos del almacén.

59.5 En caso de haberse realizado un borrado de un pedido en elaboración, el pedidoqueda eliminado del sistema y por tanto de la lista de pedidos en elaboración.

60. Puntos de Extensión60.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 introducirun nuevo cliente en la base de datos del sistema.

60.2 Consultar Catálogo en el punto 4.2 y 5.1En el paso 4.2 o en el paso 5.1, en caso de que la operadora o el representante de ventas desconozcan lareferencia del producto, pueden invocar al caso de uso Consultar Catálogo para realizar búsquedas deproductos.



Especificación de Entrevista de Trabajo.





Tabla de Contenidos1. Entrevista Trabajo 72

1.1 Descripción 72




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


4.1. En caso de haberse dado de alta una nueva entrevista, los datos de la misma quedanalmacenados en la base de datos. 72



20.Entrevista Trabajo60.3 1.1 Descripción

El caso de uso lo ejecuta el actor Empleado de RRHH. Se utiliza para realizar una entrevista de trabajo. Permiteintroducir los datos personales del entrevistado y la información de la encuesta que se le realice. También se utilizapara revisar las entrevistas que ya se han realizado e imprimirlas.

21.Flujo de Eventos2.2 Flujo Básico

61. La pantalla muestra una lista con las entrevistas introducidas en el sistema. Esta lista tiene loscampos “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 delentrevistado.

63.2 Seguidamente tendrá una campo de texto donde podrá introducir el contenido de laentrevista: 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 sealmacenará en el sistema.

22.Precondiciones22.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 suinterfaz gráfica.

23.PoscondicionesEn caso de haberse dado de alta una nueva entrevista, los datos de la misma quedan almacenados en labase de datos.



Especificación de Gestión de Clientes.


20/05/2013 0.9 Plantilla para revisar por el Stakeholder eldía 13/11/2002






Tabla de Contenidos1. Gestión de Clientes 75

1.1 Descripción 75



2.2.1 En el punto 2.2 762.2.2 En el punto 3.2 762.2.3 En el punto 3.6 762.2.4 En el punto 4.1 762.2.5 En el punto 4.5 77


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

4. Postcondiciones ¡Error! Marcador no definido.

4.1 En caso de haberse dado de alta un nuevo cliente, los datos del cliente quedan almacenados enla base de datos 774.2 En caso de haberse realizado una modificación de los datos de un cliente, quedan almacenadosen la base de datos. 774.3 En caso de haberse realizado un borrado de un cliente, el cliente queda eliminado del sistema ypor tanto de la lista de pedidos en elaboración de dicho cliente. 77



Especificación de caso de uso: Gestión de Clientes64. Gestión de Clientes64.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 laplantilla de clientes que tiene la empresa. El usuario de ventas, ya sea representante de ventas, operadora ocliente on-line, podrá acceder a los datos correspondientes a cada uno y realizar modificaciones. Losrepresentantes de ventas solamente pueden modificar o eliminar clientes que estén asociados a los mismos, y elalta asociará automáticamente al cliente con dicho representante. Los clientes on-line solo podrán modificardatos 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.


1. El Usuario de Ventas puede seleccionar dar de alta un nuevo cliente, pasar al punto 2; dar de bajaun 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 yCuenta 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 sistemamuestra 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 elsistema, é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ónModificar 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.




65.2.1 En el punto 2.2El sistema comprueba que los datos del nuevo cliente, DNI/CIF no se corresponden con ningún otro cliente de labase de datos. En caso afirmativo, generará un mensaje de error comunicando que dicho cliente ya está dado dealta en la base de datos. El sistema comprueba que se han introducido todos los datos restantes, en caso de queno 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 delnecesarios cliente.

65.2.1.1 En el punto 2.2Si 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.2El 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/CIFintroducido no se encuentra en la base de datos.

65.2.2.1 En el punto 3.2Si 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.6El sistema comprueba si el cliente solicitado para la baja tiene pedidos en elaboración, en casoafirmativo informará al Usuario de Ventas de que se eliminarán también los pedidos en elaboración. Elsistema también comprueba que el cliente no tiene pedidos en cualquier otro estado que no sea el deelaboració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, elsistema no borrará el cliente.

65.2.4 En el punto 4.1El 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.1Si se ha generado mensaje de error, el sistema vuelve a mostrar la interfaz gráfica de modificar

cliente.



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

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

66. Precondiciones66.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 suinterfaz gráfica

67. Poscondiciones67.1 En caso de haberse dado de alta un nuevo cliente, los datos del cliente quedanalmacenados en la base de datos

67.2 En caso de haberse realizado una modificación de los datos de un cliente, quedanalmacenados en la base de datos.

67.3 En caso de haberse realizado un borrado de un cliente, el cliente queda eliminadodel sistema y por tanto de la lista de pedidos en elaboración de dicho cliente.

Especificación de Gestión de Nominas.






Tabla de Contenidos1. Gestión de Nóminas 79

1.1 Descripción 79




3.1. El Empleado de RRHH ha realizado correctamente el login en el sistema. 793.2. El Empleado de RRHH ha seleccionado el botón de “Gestión de Nóminas” de su interfazgráfica. 79


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



24.Gestión de Nóminas67.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 laempresa. Se pueden modificar las existentes, así como los datos de domiciliciación bancaría.


67.5 La pantalla muestra una lista con los distintos trabajadores de la empresa ordenadasegún departamentos.

67.6 El Empleado de RRHH puede seleccionar una o varias personas de un departamento (conSHIFT + Click).

67.7 Seguidamente y pulsando sobre el botón modificar, accede a los datos de la o lasnóminas. Puede cambiar el importe de retribución, los datos bancarios, la fecha de pago ola adjudicación de pagas extras.

67.8 Para modificar cualquiera de los datos anteriores se pincha sobre el campo y se modificael importe. En las pagas extras aparecerán dos columnas, una que especifica los mesesdonde 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 mostrarcomo concepto.

67.10 Pulsando sobre aceptar se grabarán las modificaciones en la base de datos.

26.Precondiciones26.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 suinterfaz gráfica.

27.Poscondiciones27.1. En caso de haberse modificado una o varias nóminas, los cambios quedarán

almacenados en la base de datos.



Especificación de Gestión de Regiones.






Tabla de Contenidos1. Gestión de Regiones 82

1.1 Descripción 82




3.1. El Ingeniero de Logística ha realizado correctamente el registro en el sistema. 823.2. El Ingeniero de Logística ha seleccionado el botón de “Gestión de Regiones” de su interfazgráfica. 82


4.1. En caso de haberse dado de alta una nueva región, los datos de la misma quedanalmacenados en la base de datos. 834.2. En caso de haberse dado de alta un nuevo almacén, los datos del mismo quedan almacenadosen la base de datos. 83



28.Gestión de Regiones67.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 quese divide la empresa. Cada una de estas regiones dispone de unos almacenes a los que hacen peticiones tiendasdeportivas. El Ingeniero de Logística puede crear nuevas regiones o modificar las actuales, asignando o borrandoalmacenes.


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 datosdel almacén.

69.2.3.2 Si pulsa el botón eliminar, el sistema pedirá la confirmación para borrar elalmacén seleccionado.

69.3 Si pulsa el botón añadir, podrá agregar una nueva región e introducir sus datos.

30.Precondiciones30.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” desu interfaz gráfica.



31.Poscondiciones31.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 quedanalmacenados en la base de datos.

Especificacion de Incidencia Pedido




22/05/2002 2.0 Versión revisada para la primera iteraciónde la fase de construcción




03/06/2013 3.0 Versión revisada en la segunda iteración dela fase de construcción. Pendiente derevisión por el Stakeholer




Tabla de Contenidos1. Incidencia Pedido 85

1.1 Descripción 85



2.2 Flujos Alternativos 852.2.1 En el paso 2 85


3.1 El empleado está dado de alta en el sistema. 85

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


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



70. Incidencia Pedido70.1 1.1 Descripción

Este caso de uso lo ejecuta cualquier empleado que gestione órdenes de pedido cuando por algún motivo, el pedidoprovoca una situación conflictiva y requiere que se anote una incidencia. En el caso del técnico de almacén pordejar el stock bajo mínimos, por no poder atender una orden, etc. En cualquier caso, el empleado que genere unaincidencia de pedido debe especificar la causa de la misma.

71. Flujo de Eventos2.1Flujo Básico

1. El empleado ha detectado durante la gestión de órdenes de pedido que es necesarioregistrar una incidencia de pedido. Según la interfaz en la que se encuentre podrá generaruna incidencia pulsando el botón de “incidencia pedido”.

2. El sistema muestra la interfaz de incidencias de pedido, mostrando de forma automáticael 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 muestraun campo para observaciones.

3. El empleado introduce en el campo de observaciones los motivos por los que se hagenerado la incidencia y puede pulsar el botón “guardar” para almacenar la incidencia, obien puede pulsar “salir” para no registrar la incidencia.

71.1 2.2 Flujos Alternativos

71.1.1 2.2.1 En el paso 2Si 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 puedeintroducir una incidencia con el campo de observaciones vacío.

72. Precondiciones3.1El empleado está dado de alta en el sistema.3.2El empleado ha realizado correctamente el registro en el sistema

introduciendo el nombre de usuario y la contraseña

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



Especificacion de Introducir Recibos.










Tabla de Contenidos1. Introducir Recibos 88

1.1 Descripción 88



2.2.1 En el punto 3 882.2.2 En el punto 6 88


3.1 El encargado de transportes está dado de alta en el sistema. 883.2 El encargado de transporte ha realizado correctamente el registro en el sistema introduciendoel nombre de usuario y la contraseña 88


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



74. Introducir Recibos74.1 Descripción

El Encargado de Transporte selecciona de la interfaz correspondiente al mismo, el botón de Introducir Recibos. Acontinuación introduce en el sistema el recibo de un pedido ya entregado.


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.1 En el punto 3Si 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 6Si 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. Precondiciones76.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 sistemaintroduciendo el nombre de usuario y la contraseña



77. Poscondiciones77.1 El pedido cambia del estado “enviado” a pedido “pendiente de cobro”

Especificacion de Otorgar Incentivos.






Tabla de Contenidos1. Otorgar Incentivos 91

1.1 Descripción 91




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


4.1 En caso de haberse dado de alta un nuevo incentivo este quedará almacenado en la lista deincentivos pendientes 924.2 En caso de haberse borrado un incentivo se eliminará de la lista de incentivos pendientes 92



78. Otorgar Incentivos78.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 sistemale muestra una lista donde se almacenan los incentivos pendientes. Si pincha en el botón añadir incentivo laaplicación le mostrará una nueva pantalla donde puede especificar la clase de incentivo y a los trabajadores queafectará. El Jefe de Ventas también puede anular y modificar los incentivos ya registrados en el sistema. Losincentivos que se han cobrado (en la nomina mensual) por parte de los trabajadores desaparecen de la lista.


80. La pantalla muestra una lista con los incentivos pendientes81. 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



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.



82. Precondiciones82.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 suinterfaz gráfica.

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


20/05/2013 1.0 Plantilla de versión preliminar del caso deuso Pasar Pedido a Envío


21/06/2013 1.9 Versión lista para ser revisada por elStakeholder


20/07/2013 2.0 Versión revisada en la primera iteración deconstrucción






Tabla de Contenidos1. Pasar Pedido a Envío 94

1.1 Descripción 94



2.2.1 En el punto 2 94


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

3.2 El técnico de almacén ha realizado correctamente el registro en el sistema introduciendo elnombre de usuario y la contraseña 94


4.1 Si se satisfacen las cantidades demandadas, el pedido cambia del estado “en atención” apedido “listo para envío” 944.2 Si el técnico de almacén decide enviar el pedido a envío generando uno nuevo con lascantidades que faltaron por asignar el sistema creará un nuevo pedido en la base de datos comopedido “no atendido” y enviará el original a listo para envío. 95



84. Pasar Pedido a Envío84.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 lainterfaz correspondiente al mismo y selecciona el botón de “pasar pedido a envío”. A continuación el sistemacomprueba 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 Eventos85.1 Flujo Básico1. 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 vezconcluida la asignación de cantidades puede pulsar el botón de “pasar pedido a envío”.

2. El sistema comprueba que las cantidades asignadas coinciden con las cantidadessolicitadas en todas las líneas del pedido.

3. Si no ha habido ningún error el pedido pasa al estado “listo para envío” y figurará en ellistado de pedidos de la pestaña “listos para envío” de la interfaz gráfica principal deltécnico de almacén.


85.2.1 En el punto 2Si el sistema detecta que alguna de las cantidades de stock asignado es distinta de la cantidad que demanda la líneade pedido, entonces se genera un mensaje de aviso de pedido incompleto. El técnico de almacén puede pasar elpedido a listo para envío a pesar de no estar completo el pedido, puede cancelar el pasar el pedido a envío, o bienpuede dividir el pedido en dos: uno que pasa a listo para envío con las cantidades asignadas al pedido y otro conlas cantidades diferencia entre las que se han asignado y las que se demandaban. Este último pedido generadoautomáticamente figurará en estado de pedido en “no atención”.

86. Precondiciones87. 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 elsistema introduciendo el nombre de usuario y la contraseña

89. Poscondiciones89.1 Si se satisfacen las cantidades demandadas, el pedido cambia del estado “en



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






Tabla de Contenidos1. Política de Ventas 97

1.1 Descripción 97




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


4.1. En caso de haberse dado de alta una nueva dirección de facturación, los datos de la mismaquedan almacenados en la base de datos. 984.2. Los pedidos para los cuales se imprime factura pasan al estado “factura emitida”. 984.3. Los pedidos para los que se ha abonado la factura pasan al estado “factura pagada”. 98



32.Política de Ventas89.2 1.1 DescripciónEste caso de uso lo inicia el Empleado de Marketing. Se trata de especificar cierta política deventas sobre los productos de la empresa, por ejemplo, qué productos tienen que ser másprioritarios a la hora de vender que otros.


90. La pantalla muestra una lista con los incentivos actuales91. 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



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



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.



34.Precondiciones34.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.Poscondiciones35.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 “facturaemitida”.

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

Especificación de Reabastecer Almacen.






Tabla de Contenidos1. Reabastecer Almacén 100

1.1 Descripción 100




3.1. El Ingeniero de Logística ha realizado correctamente el login en el sistema. 1013.2. El Ingeniero de Logística ha seleccionado el botón “Reabastecer Almacén” de su interfazgráfica. 101


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



36.Reabastecer Almacén91.4 1.1 DescripciónEl caso de uso lo inicia el actor Ingeniero de Logística. Especifica los envíos desde el almacéncentral hacia los demás almacenes con el fin de reponer productos sin stock. Para ello elIngeniero dispone de una lista con los productos que necesitan reposición y otra con losdisponibles en el almacén central. Bajo su criterio pueden realizarse envíos hacia el resto dealmacenes.


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 enel almacén central.

94. Si quiere realizar un nuevo envió para reabastecer un almacén selecciona el botón nuevoenvío.

95. El sistema le muestra una lista de las regiones y los almacenes, el Ingeniero selecciona unalmacén.

96. El sistema le muestra una pantalla con dos listas, la primera con los productos disponibles enel 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 enenví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íose 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 “enenvío”.

102. Cuando llega al almacén destino se grabará en el sistema como “reabastecimientocompletado”.



38.Precondiciones38.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 suinterfaz gráfica.

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

Especificacion de Realizar Envio.








Tabla de Contenidos1. Realizar Envío 103

1.1. Descripción 103


2.1. Flujo Básico 103

2.2. Flujos Alternativos 103


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

3.2. El encargado de transporte está dado de alta en el sistema y ha realizado correctamente elregistro en el mismo mediante su nombre de usuario y su contraseña. 103


4.1. El pedido queda marcado como “Enviado”. 103

4.2. El stock de los productos del pedido queda actualizado. 103



40.Realizar Envío40.1. Descripción

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

41.Flujo de Eventos41.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 Alternativos42.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 deusuario y su contraseña.

43.Poscondiciones43.1. El pedido queda marcado como “Enviado”.

El stock de los productos del pedido queda actualizado.

Especificacion de Realizar Oferta.






Tabla de Contenidos1. Realizar Oferta 105





3.1. El Empleado de Marketing ha realizado correctamente el login en el sistema. 1053.2. El Empleado de Marketing ha seleccionado el botón de “Realizar Oferta” de su interfazgráfica. 105


4.1. En caso de haberse dado de alta una nueva oferta, los datos de la misma quedan almacenadosen la base de datos. 1064.2. Las ofertas nuevas sólo afectan a pedidos que no estén en preparación y a pedidos nuevos. 106



44.Realizar Oferta102.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 unprecio determinado. El actor consulta el catálogo de productos y selecciona aquel o aquellos a los que deseaaplicar 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.


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 definalizació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.Precondiciones46.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 suinterfaz gráfica.



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






Tabla de Contenidos1. Redistribución de Personal 108





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


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



48.Redistribución de Personal104.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 empresacomo trasladar personal entre departamentos, cambiar las funciones que realizan los empleados o eliminar yagregar personal.


104.6 La pantalla muestra una lista con los distintos trabajadores de la empresa ordenadasegún departamentos.

104.7 El Jefe de RRHH puede seleccionar una o varias personas de un departamento (conSHIFT + 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 elcargo 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 departamentoseleccionado, en cuyo caso se le abrirá una pantalla con los datos personales y defunciones 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.Precondiciones50.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 suinterfaz gráfica.

51.PoscondicionesEn caso de haberse modificado, agregado o borrado uno o varios empleados, los cambios quedaránalmacenados en la base de datos.



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 deproyecto.Los equipos pueden crear y compartir sus necesidades utilizando métodos basadosen documentos familiares, durante el uso de las capacidades de base de datos como latrazabilidad y el análisis de impacto. Esto puede mejorar la comunicación y la gestión derequisitos, 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 plenofuncionamiento, la interfaz web escalable y foros de discusión.

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

Aumentar la productividad mediante cambios de localización utilizando comparacionesversió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 laintegración con múltiples herramientas en el desarrollo de software de IBM Rational y laplataforma de entrega.

mantiene los equipos de proyectos al día gracias a la creación, análisis y gestión de losrequisitos de aplicaciones y casos de uso.

Ya que el desarrollo de software es una tarea de equipo, es crítico que los miembros queimplementen la solución comprendan los objetivos y entregables apropiados. ¿Cómo puedeun equipo entregar la solución adecuada si sus miembros no tienen acceso a la visión delproyecto, sus metas, especificaciones y otros requerimientos que detallan lo que la soluciónfinal debe hacer?



3.4.1. Stakaholders

Stakeholders: Los representantes de los usuarios y portavoces de las necesidadesde la empresa son los stakeholders. En este proyecto solamente se ha tratado con unstakeholder como representante de los usuaros y necesidades de la empresa, sinembargo 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 lascaracterísticas de software de tal manera que se puede conocer qué stakeholderpropuso qué característica.



3.4.2. actoresActores: Se define este requerimiento para listar los usuarios potenciales del sistema,en este proyecto se han definido los siguientes actores: Ingeniero de Logística, Jefede Almacén, Técnico de Almacén, Jefe de Ventas, Representante de Ventas,Contable, Empleado de Marketing, Cliente Online, Operadora, Encargado deTransporte, 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 deuso de tal manera que se puede conocer qué actor utiliza qué caso de uso



3.4.3. Características del softwareCaracterísticas de Software: Las características software son las necesidades delos usuarios propuestas por los stakeholders de la empresa, son los requisitos quedebe cumplir el sistema para satisfacer las necesidades de los trabajadores y de laempresa.

Las características definidas son las que aparecen en la matriz de atributos, siendolas indicadas como subcaracterísticas las derivadas según una clasificaciónjerárquicas.

3.4.4. caso de uso.Casos de Uso: derivados de las características software, son el resultado del análisisde las necesidades de los usuarios, cuyas especificaciones están recogidas en elpaquete Especificaciones de Casos de Uso definido en Requisite Pro.

La matriz de atributos es la siguiente:



Casos de Uso: La matriz de trazabilidad de los casos de uso relaciona a éstos conlas 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 deuso que se relacionan con los casos de pruebas.



Casos de Uso: derivados de las características software, son el resultado del análisisde las necesidades de los usuarios, cuyas especificaciones están recogidas en elpaquete Especificaciones de Casos de Uso definido en Requisite Pro.

La matriz de atributos es la siguiente:



Casos de Uso: La matriz de trazabilidad de los casos de uso relaciona a éstos conlas 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 deuso que se relacionan con los casos de pruebas.







3.4.5. Clases.Clases: Las clases son requerimientos derivados de los casos de uso comonecesidad 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 desoftware relaciona a éstas con los casos de uso de tal manera que se puede conocerqué caso de uso deriva de qué característica.













Tabla de Contenidos1. Introducción ...................................................................................................................................................... 121

1.1 Propósito ................................................................................................................................................... 1211.2 Alcance ..................................................................................................................................................... 1221.3 Resumen.................................................................................................................................................... 123

2. Vista General del Proyecto ............................................................................................................................... 123

2.1 Propósito, Alcance y Objetivos................................................................................................................. 1232.2 Suposiciones y Restricciones .................................................................................................................... 1242.3 Entregables del proyecto ........................................................................................................................... 1262.4 Evolución del Plan de Desarrollo del Software......................................................................................... 131

3. Organización del Proyecto ................................................................................................................................ 131

3.1 Participantes en el Proyecto ...................................................................................................................... 1313.2 Interfaces Externas.................................................................................................................................... 1323.3 Roles y Responsabilidades........................................................................................................................ 132

4. Gestión del Proceso .......................................................................................................................................... 133

4.1 Estimaciones del Proyecto ........................................................................................................................ 1334.2 Plan del Proyecto ...................................................................................................................................... 133

4.2.1 Plan de las Fases........................................................................................................................... 1334.2.2 Calendario del Proyecto ............................................................................................................... 136

4.3 Seguimiento y Control del Proyecto ......................................................................................................... 144

5. Referencias........................................................................................................................................................ 145




105. IntroducciónEste Plan de Desarrollo del Software es una versión preliminar preparada paraser incluida en la propuesta elaborada como respuesta al proyecto final de laasignatura de Ingeniería de Software de la Universidad del DesarrolloProfesional. Este documento provee una visión global del enfoque dedesarrollo propuesto.El proyecto ha sido basado en una metodología de Rational Unified Process enla que únicamente se procederá a cumplir con las tres primeras fases quemarca la metodología, constando únicamente en la tercera fase de dositeraciones. Es importante destacar esto puesto que utilizaremos laterminología RUP en este documento. Se incluirá el detalle para las fases deInicio y Elaboración y adicionalmente se esbozarán las fases posteriores deConstrucción y Transición para dar una visión global de todo proceso.El enfoque desarrollo propuesto constituye una configuración del proceso RUPde acuerdo a las características del proyecto, seleccionando los roles de losparticipantes, las actividades a realizar y los artefactos (entregables) que serángenerados. Este documento es a su vez uno de los artefactos de RUP.105.1 PropósitoEl propósito del Plan de Desarrollo de Software es proporcionar la informaciónnecesaria para controlar el proyecto. En él se describe el enfoque de desarrollodel software.Los usuarios del Plan de Desarrollo del Software son:

El jefe del proyecto lo utiliza para organizar la agenda y necesidades derecursos, y para realizar su seguimiento.




105.2 AlcanceEl Plan de Desarrollo del Software describe el plan global usado para eldesarrollo del “Sistema para Gestión de Artículos Deportivos”. El detalle de lasiteraciones individuales se describe en los planes de cada iteración,documentos que se aportan en forma separada. Durante el proceso dedesarrollo en el artefacto “Visión” se definen las características del producto adesarrollar, 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 enla captura de requisitos por medio del stakeholder representante de la empresapara hacer una estimación aproximada, una vez comenzado el proyecto ydurante la fase de Inicio se generará la primera versión del artefacto “Visión”, elcual se utilizará para refinar este documento. Posteriormente, el avance delproyecto y el seguimiento en cada una de las iteraciones ocasionará el ajustede este documento produciendo nuevas versiones actualizadas.



105.3 ResumenDespués de esta introducción, el resto del documento está organizado en lassiguientes secciones:Vista General del Proyecto — proporciona una descripción del propósito,alcance y objetivos del proyecto, estableciendo los entragbles que seránproducidos y utilizados durante el proyecto..Organización del Proyecto — describe la estructura organizacional del equipode desarrollo.Gestión del Proceso — explica los costos y planificación estimada, define lasfases 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 dedesarrollo de software, incluyendo métodos, herramientas y técnicas que seránutilizadas.

106. Vista General del Proyecto106.1 Propósito, Alcance y ObjetivosLa información que a continuación se incluye ha sido extraída de las diferentesreuniones que se han celebrado con el stakeholder de la empresa desde elinicio del proyecto.Deportes the runners lleva a cabo la venta al por mayor de artículos deportivosa nivel internacional. La entrada en un mercado competitivo como en el queencuentra inmersa esta firma conllevará una previsible adaptación a los nuevossistemas de información y a la evolución tecnológica. Por ello, Deportes therunners considera necesario el desarrollo de un nuevo sistema de gestión delos artículos deportivos que forman parte de sus catálogos, así como las basesde datos que recogen datos tanto estadísticos, empresariales como denóminas, plantillas de personal, etc., por tanto los solicitantes demandan unagestión más rápida, automática y segura de las gestiones de almacén y basesde datos de los distintos departamentos.”El proyecto debe proporcionar una propuesta para el desarrollo de todos lossubsistemas implicados en la gestión de artículos deportivos y bases de datosdepartamentales”. Estos subsistemas se pueden diferenciar en siete grandesbloques:a) Gestión de Ventas, incluyendo:




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







Cancelación de pedidos solicitado por el cliente.|Gestión de Envíos, incluyendo:


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 RestriccionesLas suposiciones y restricciones respecto del sistema, y que se derivandirectamente de las entrevistas con el stakeholder de la empresa son:a) Debe contemplarse las implicaciones de los siguientes puntos críticos:




Gestión de flujos de trabajo, seguridad de transacciones e intercambiode 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 lalegislación vigente y considerar la previsión de la nueva legislaciónreferente a los dominios de tercer nivel.

c) El subsistema “Gestión de Almacenes” debe diseñarse como móduloindependiente para ser utilizado posteriormente en otras regiones de losdistintos almacenes no centralizados encargados de proveer a cada regiónde 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 elartefacto “Visión”.



106.3 Entregables del proyectoA continuación se indican y describen cada uno de los artefactos que serángenerados y utilizados por el proyecto y que constituyen los entregables. Estalista constituye la configuración de RUP desde la perspectiva de artefactos, yque proponemos para este proyecto.

Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo procesoiterativo e incremental), todos los artefactos son objeto de modificaciones a lolargo del proceso de desarrollo, con lo cual, sólo al término del procesopodríamos tener una versión definitiva y completa de cada uno de ellos. Sinembargo, el resultado de cada iteración y los hitos del proyecto estánenfocados a conseguir un cierto grado de completitud y estabilidad de losartefactos. Esto será indicado más adelante cuando se presenten los objetivosde cada iteración.

1) Plan de Desarrollo del SoftwareEs el presente documento.

2) Modelo de Casos de Uso del NegocioEs un modelo de las funciones de negocio vistas desde la perspectiva de

los actores externos (Agentes de registro, solicitantes finales, otros sistemasetc.). permite situar al sistema en el contexto organizacional haciendo énfasisen los objetivos en este ámbito. Este modelo se representa con un Diagramade Casos de Uso usando estereotipos específicos para este modelo.

3) Modelo de Objetos del NegocioEs 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 generalesmanipulan y los flujos de trabajo (workflows) asociados al caso de uso delnegocio. Para la representación de este modelo se utilizan Diagramas deColaboració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 deActividad para mostrar los flujos de trabajo.

4) GlosarioEs un documento que define los principales términos usados en el

proyecto. Permite establecer una terminología consensuada. .

5) Modelo de Casos de UsoEl modelo de Casos de Uso presenta las funciones del sistema y los

actores que hacen uso de ellas. Se representa mediante Diagramas de Casosde Uso.

6) VisiónEste documento define la visión del producto desde la perspectiva del


7) Especificaciones de Casos de UsoPara 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óndetallada utilizando una plantilla de documento, donde se incluyen:precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionalesasociados. También, para casos de uso cuyo flujo de eventos sea complejopodrá adjuntarse una representación gráfica mediante un Diagrama deActividad.



8) Especificaciones AdicionalesEste documento capturará todos los requisitos que no han sido incluidos

como parte de los casos de uso y se refieren requisitos no-funcionalesglobales. Dichos requisitos incluyen: requisitos legales o normas, aplicación deestándares, requisitos de calidad del producto, tales como: confiabilidad,desempeño, etc., u otros requisitos de ambiente, tales como: sistemaoperativo, requisitos de compatibilidad, etc.

9) Prototipos de Interfaces de UsuarioSe trata de prototipos que permiten al usuario hacerse una idea más o

menos precisa de las interfaces que proveerá el sistema y así, conseguirretroalimentación de su parte respecto a los requisitos del sistema. Estosprototipos se realizarán como: dibujos a mano en papel, dibujos con algunaherramienta gráfica o prototipos ejecutables interactivos, siguiendo ese ordende acuerdo al avance del proyecto. Sólo los de este último tipo seránentregados 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 lamedida que el resultado de las iteraciones vayan desarrollando el productofinal.

10)Modelo de Análisis y DiseñoEste 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 aspectosde implementación) hacia una de diseño (incluyendo una orientación hacia elentorno de implementación), de acuerdo al avance del proyecto.

11)Modelo de DatosPreviendo que la persistencia de la información del sistema será soportada

por una base de datos relacional, este modelo describe la representaciónlógica de los datos persistentes, de acuerdo con el enfoque para modeladorelacional de datos. Para expresar este modelo se utiliza un Diagrama deClases (donde se utiliza un profile UML para Modelado de Datos, paraconseguir la representación de tablas, claves, etc.) .



12)Modelo de ImplementaciónEste modelo es una colección de componentes y los subsistemas que los

contienen. Estos componentes incluyen: ficheros ejecutables, ficheros decódigo fuente, y todo otro tipo de ficheros necesarios para la implantación ydespliegue del sistema. (Este modelo es sólo una versión preliminar al final dela fase de Elaboración, posteriormente tiene bastante refinamiento).

13)Modelo de DespliegueEste modelo muestra el despliegue la configuración de tipos de nodos del

sistema, en los cuales se hará el despliegue de los componentes.


condiciones de ejecución, las entradas de la prueba, y los resultadosesperados. Estos casos de prueba son aplicados como pruebas de regresiónen cada iteración. Cada caso de prueba llevará asociado un procedimiento deprueba con las instrucciones para realizar la prueba, y dependiendo del tipo deprueba dicho procedimiento podrá ser automatizable mediante un script deprueba.


documento. Mediante este documento se hace un seguimiento de los defectosdetectados, 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, yse asegura que éstos sean conocidos por el equipo de desarrollo. Los cambiosse establecen respecto de la última baseline (el estado del conjunto de losartefactos en un momento determinado del proyecto) establecida. En nuestrocaso al final de cada iteración se establecerá una baseline.




recursos asignados, dependencias entre ellas. Se realiza para cada iteración, ypara todas las fases.

17)Evaluación de IteraciónEste 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 leccionesaprendidas y los cambios a ser realizados.

18)Lista de RiesgosEste documento incluye una lista de los riesgos conocidos y vigentes en el

proyecto, ordenados en orden decreciente de importancia y con accionesespecíficas de contingencia o para su mitigación.


producto.

20)Material de Apoyo al Usuario FinalCorresponde 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 ySistema de Ayuda en Línea

21)ProductoLos ficheros del producto empaquetados y almacenadas en un CD con los

mecanismos apropiados para facilitar su instalación. El producto, a partir de laprimera iteración de la fase de Construcción es desarrollado incremental eiterativamente, 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.

106.4 Evolución del Plan de Desarrollo del SoftwareEl Plan de Desarrollo del Software se revisará semanalmente y se refinará

antes del comienzo de cada iteración.

107. Organización del Proyecto107.1 Participantes en el Proyecto

De momento no se incluye el personal que designará Deportes the runnerscomo Responsable del Proyecto, Comité de Control y Seguimiento, otrosparticipantes que se estimen convenientes para proporcionar los requisitos yvalidar el sistema.

El resto del personal del proyecto (por la parte del la empresaadjudicataria), considerando las fases de Inicio, Elaboración y dos iteracionesde la fase de Construcción, estará formado por los siguientes puestos detrabajo y personal asociado:Jefe de Proyecto. Labor de luis newman flores, alumno de la carrera deIngeniería de software de la universidad de desarrollo profesional. Con unaexperiencia modesta en metodologías de desarrollo, herramientas CASE ynotaciones, en particular la notación UML y el proceso de desarrollo RUP.Analista de Sistemas. El perfil establecido es: Ingeniero en sistemascomputacionales con conocimientos de UML, uno de ellos al menos conexperiencia en sistemas afines a la línea del proyecto, labor que llevará a caboAgustín Duarte Preciado4 Analistas - Programadores. Con experiencia en el entorno de desarrollo delproyecto, con el fin de que los prototipos puedan ser lo más cercanos posiblesal producto final. Este trabajo ha sido encomendado a Agustín Duarte Preciado



Ingeniero de Software. El perfil establecido es: Ingeniero en sistemascomputacionales, realizando labores de gestión de requisitos, gestión deconfiguración, documentación y diseño de datos. Encargado de las pruebasfuncionales del sistema, realizará la labor de José Elí SandovalLos Currículos Vitae del personal del proyecto que ya ha comprometido suparticipación se adjuntan por separado.107.2 Interfaces ExternasDeportes the runners definirá los participantes del proyecto que proporcionaránlos requisitos del sistema, y entre ellos quiénes serán los encargados deevaluar los artefactos de acuerdo a cada subsistema y según el planestablecido.El equipo de desarrollo interactuará activamente con los participantes deDeportes the runners para especificación y validación de los artefactosgenerados.107.3 Roles y ResponsabilidadesA continuación se describen las principales responsabilidades de cada uno delos 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

Jefe de Proyecto

El jefe de proyecto asigna los recursos, gestiona lasprioridades, coordina las interacciones con los clientesy usuarios, y mantiene al equipo del proyectoenfocado en los objetivos. El jefe de proyecto tambiénestablece un conjunto de prácticas que aseguran laintegridad y calidad de los artefactos del proyecto.Además, el jefe de proyecto se encargará desupervisar el establecimiento de la arquitectura delsistema. Gestión de riesgos. Planificación y control delproyecto.

Analista deSistemas

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



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

ProgramadorConstrucción de prototipos. Colaboración en laelaboración de las pruebas funcionales, modelo dedatos y en las validaciones con el usuario



108. Gestión del Proceso108.1 Estimaciones del ProyectoEl 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 delproyecto.


El desarrollo se llevará a cabo en base a fases con una o más iteraciones en cadauna de ellas. La siguiente tabla muestra una la distribución de tiempos y el númerode iteraciones de cada fase (para las fases de Construcción y Transición es sólouna aproximación muy preliminar)



FaseNro.



Fase deElaboración

1 2semanas


2 7semanas

Fase deTransición

- -

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

Descripción Hito


Fase deElaboración

En esta fase se analizan los requisitos y sedesarrolla un prototipo de arquitectura (incluyendolas partes más relevantes y / o críticas del sistema).Al final de esta fase, todos los casos de usocorrespondientes a requisitos que serán



implementados en la primera release de la fase deConstrucción deben estar analizados y diseñados(en el Modelo de Análisis / Diseño). La revisión yaceptación del prototipo de la arquitectura delsistema marca el final de esta fase. En nuestro casoparticular, por no incluirse las fases siguientes, larevisión y entrega de todos los artefactos hasta estepunto de desarrollo también se incluye como hito. Laprimera iteración tendrá como objetivo laidentificación y especificación de los principalescasos de uso, así como su realización preliminar enel Modelo de Análisis / Diseño, también permitiráhacer una revisión general del estado de losartefactos hasta este punto y ajustar si es necesariola planificación para asegurar el cumplimiento de losobjetivos. Ambas iteraciones tendrán una duraciónde una semana.


Durante la fase de construcción se terminan deanalizar y diseñar todos los casos de uso,refinando el Modelo de Análisis / Diseño. Elproducto se construye en base a 2 iteraciones,cada una produciendo una release a la cual se leaplican las pruebas y se valida con el cliente /usuario. Se comienza la elaboración de material deapoyo al usuario. El hito que marca el fin de estafase es la versión de la release 3.0, con lacapacidad operacional parcial del producto que sehaya considerado como crítica, lista para serentregada a los usuarios para pruebas beta.

Fase deTransición

En esta fase se prepararán dos releases paradistribución, asegurando una implantación ycambio del sistema previo de manera adecuada,incluyendo el entrenamiento de los usuarios. Elhito que marca el fin de esta fase incluye, laentrega de toda la documentación del proyecto con



los manuales de instalación y todo el material deapoyo al usuario, la finalización del entrenamientode los usuarios y el empaquetamiento delproducto.

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.





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.





Semana 1

14/10 –20/10

Semana 3

28/10 –3/11

Requisitos

GlosarioSemana 1

14/10 –20/10

Semana 3

28/10 –3/11

VisiónSemana 2

21/10 –27/10

Semana 3

28/10 –3/11


28/10 –3/11

siguientefase

Especificación de Casos de Uso Semana 3

28/10 –

siguientefase



3/11


28/10 –3/11

siguientefase

Análisis / Diseño


21/10 –27/10

siguientefase


21/10 –27/10

siguientefase

Implementación


28/10 –3/11

siguientefase


28/10 –3/11

siguientefase

Pruebas

Casos de Pruebas FuncionalesSemana 3

28/10 –3/11

siguientefase

Despliegue

Modelo de Despliegue Semana 3

28/10 –

siguientefase



3/10




Semana 1

14/10 –20/10

Semana 3

28/10 –3/11








Semana 1

14/10 –20/10

aprobado

Requisitos

GlosarioSemana 1

14/10 –20/10

aprobado

VisiónSemana 2

21/10 –27/10

aprobado

Modelo de Casos de Uso Semana 3

28/10 –Semana 5



3/11 11/12 – 17/12


28/10 –3/11

Semana 5

11/12 – 17/12


28/10 –3/11

Semana 5

11/12 – 17/12

Análisis / Diseño


21/10 –27/10



21/10 –27/10


Implementación


28/10 –3/11



28/10 –3/11


Pruebas


28/10 –3/11










Semana 1

14/10 –20/10

aprobado

Requisitos

GlosarioSemana 1

14/10 –20/10

aprobado

VisiónSemana 2

21/10 –27/10

aprobado


28/10 –3/11

Semana 511/12 – 17/12


28/10 –3/11

Semana 511/12 – 17/12


28/10 –3/11

Semana 511/12 – 17/12

Análisis / Diseño




21/10 –27/10



21/10 –27/10


Implementación


28/10 –3/11



28/10 –3/11


Pruebas


28/10 –3/11


Despliegue


28/10 –3/11





Semana 4

4/11 –Revisar encada iteración



10/11


108.3 Seguimiento y Control del ProyectoGestión de RequisitosLos requisitos del sistema son especificados en el artefacto Visión. Cadarequisito tendrá una serie de atributos tales como importancia, estado, iteracióndonde se implementa, etc. Estos atributos permitirán realizar un efectivoseguimiento de cada requisito. Los cambios en los requisitos serángestionados mediante una Solicitud de Cambio, las cuales serán evaluadas ydistribuidas para asegurar la integridad del sistema y el correcto proceso degestión de configuración y cambios.Control de PlazosEl calendario del proyecto tendrá un seguimiento y evaluación semanal por eljefe de proyecto y por el Comité de Seguimiento y Control.Control de CalidadLos defectos detectados en las revisiones y formalizados también en unaSolicitud de Cambio tendrán un seguimiento para asegurar la conformidadrespecto de la solución de dichas deficiencias Para la revisión de cadaartefacto y su correspondiente garantía de calidad se utilizarán las guías derevisión y checklist (listas de verificación) incluidas en RUP.Gestión de RiesgosA partir de la fase de Inicio se mantendrá una lista de riesgos asociados alproyecto y de las acciones establecidas como estrategia para mitigarlos oacciones de contingencia. Esta lista será evaluada al menos una vez en cadaiteración.Gestión de ConfiguraciónSe realizará una gestión de configuración para llevar un registro de losartefactos generados y sus versiones. También se incluirá la gestión de lasSolicitudes de Cambio y de las modificaciones que éstas produzcan,informando y publicando dichos cambios para que sean accesibles a todo losparticipantes en el proyecto. Al final de cada iteración se establecerá unabaseline (un registro del estado de cada artefacto, estableciendo una versión),la cual podrá ser modificada sólo por una Solicitud de Cambio aprobada.



109. Referencias


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


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



4.0. Análisis y Diseño.

El análisis del sistema es una atapa de la fase deplanificación y en ella se realiza una descripción delentorno, software que se quiere obtener y se definelos recursos humanos para su desarrollo, el coste yel calendario estimado.



En concreto, el análisis del sistema presenta lossiguientes 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 elsistema.

Análisis del Sistema: Define los flujos de información, lasestructuras primarias de datos, las características funcionales delsistema, los requerimientos de rendimiento y las restriccionesimpuestas por el cliente. Así mismo, se incorporarán los criteriosglobales de validación que se utilizarán para probar que los requisitosseñalados han sido implementados.



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



Modelo de Datos: Modelo Relacional



5.0. Implementación.

La fase de implementación de un sistema es la fase más costosa y que consumemás tiempo, se dice que es costosa por que muchas personas, herramientas yrecursos, están involucrados en el proceso y consume mucho tiempo porque secompleta todo el trabajo realizado previamente durante las demás fases.

En esta fase se instala el nuevo sistema de información para que empiece atrabajar 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 puedeser sumamente riesgoso porque si algo marcha mal, es imposible volver alsistema anterior, las correcciones deberán hacerse bajo la marcha. Regularmentecon un sistema nuevo suelen surgir problemas de pequeña y gran escala. Si setrata 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 nuevodemuestra 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 paralaborar con los dos sistemas, por lo que este método se reserva específicamentepara 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 realizandoa lo largo de un período de tiempo, sucesivamente. Una vez iniciada la primerafase, la segunda no se inicia hasta que la primera se completado con éxito. Así secontinúa hasta que se finaliza con la última fase. Es costoso porque se hace máslenta la implementación, pero sin duda tiene menor riesgo.



A continuación se presentan los prototipos de interfaces gráficas de usuariodiseñadas para la aplicación final. Cabe citar que se presentan únicamente losprototipos de interfaces de usuario que se negociaron con el cliente comocandidatos 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 primeraventana de identificación del usuario. Sólo usuarios registrados en la base dedatos pueden acceder al sistema.

La interfaz que se presenta en la identificación se puede ver en el siguienteimagen



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 registradasen el sistema.

En las siguientes iteraciones de construcción se implementarán casos de usocomo el de gestión de clientes (botón que aparece en la pantalla de los datos delcliente pero que no tiene ninguna funcionalidad asociada).



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

Gestión de Ventas

Para el subsistema de ventas el prototipo de interfaz gráfica es el de elaborarpedido.

El usuario de ventas puede generar un pedido nuevo para un cliente, modificar unpedido que esté en elaboración, consultar pedidos en elaboración, cancelarpedidos o consultar el detalle de pedidos ya enviados al almacén.



Para la gestión de almacén el prototipo de interfaz gráfica es el siguiente, en elque 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 cualesha sido reservado stock)

En la pestaña de no atendidos el técnico de almacén puede realizar lasoperaciones de consulta de detalles de un pedido, puede atender directamente elpedido seleccionado, puede cancelar el pedido seleccionado o salir de nuevo a lainterfaz de identificación.



En la pestaña de en atención el técnico de almacén dispone de las siguientesopciones en su interfaz gráfica: atender el pedido seleccionado, cancelar el pedidoseleccionado, 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 siguientesopciones en su interfaz gráfica: consultar los detalles del pedido seleccionado,cancelar el pedido seleccionado o salir a la interfaz de identificación.



Dentro de la interfaz en de la consulta de pedidos no atendidos que se puederealizar 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 unpedido, se observa la siguiente interfaz gráfica, que dispone de las opcionessiguientes: asignar cantidad al hacer doble clic sobre una línea de pedido, guardarlos 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 anteriorpulsando el botón salir.



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



Historial de Revisiones

Fecha Versión Descripción Autor










Tabla de Contenidos1. Introducción.......................................................................................................................................................121

1.1 Propósito....................................................................................................................................................1211.2 Alcance ......................................................................................................................................................1221.3 Resumen ....................................................................................................................................................123

2. Vista General del Proyecto ................................................................................................................................123

2.1 Propósito, Alcance y Objetivos .................................................................................................................1232.2 Suposiciones y Restricciones.....................................................................................................................1242.3 Entregables del proyecto ...........................................................................................................................1262.4 Evolución del Plan de Desarrollo del Software .........................................................................................131

3. Organización del Proyecto ................................................................................................................................131

3.1 Participantes en el Proyecto.......................................................................................................................1313.2 Interfaces Externas ....................................................................................................................................1323.3 Roles y Responsabilidades ........................................................................................................................132

4. Gestión del Proceso ...........................................................................................................................................133

4.1 Estimaciones del Proyecto.........................................................................................................................1334.2 Plan del Proyecto .......................................................................................................................................133

4.2.1 Plan de las Fases ...........................................................................................................................1334.2.2 Calendario del Proyecto................................................................................................................136

4.3 Seguimiento y Control del Proyecto..........................................................................................................144

5. Referencias ........................................................................................................................................................145




110. IntroducciónEste Plan de Desarrollo del Software es una versión preliminar preparadapara ser incluida en la propuesta elaborada como respuesta al proyectofinal de la asignatura de Ingeniería de Software de la Universidad delDesarrollo Profesional. Este documento provee una visión global delenfoque de desarrollo propuesto.El proyecto ha sido basado en una metodología de Rational Unified Processen la que únicamente se procederá a cumplir con las tres primeras fasesque marca la metodología, constando únicamente en la tercera fase de dositeraciones. Es importante destacar esto puesto que utilizaremos laterminología RUP en este documento. Se incluirá el detalle para las fasesde Inicio y Elaboración y adicionalmente se esbozarán las fases posterioresde Construcción y Transición para dar una visión global de todo proceso.El enfoque desarrollo propuesto constituye una configuración del procesoRUP de acuerdo a las características del proyecto, seleccionando los rolesde los participantes, las actividades a realizar y los artefactos (entregables)que serán generados. Este documento es a su vez uno de los artefactos deRUP.

110.1 PropósitoEl propósito del Plan de Desarrollo de Software es proporcionar lainformación necesaria para controlar el proyecto. En él se describe elenfoque de desarrollo del software.Los usuarios del Plan de Desarrollo del Software son:

El jefe del proyecto lo utiliza para organizar la agenda y necesidadesde recursos, y para realizar su seguimiento.



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

El Plan de Desarrollo del Software describe el plan global usado para eldesarrollo del “Sistema para Gestión de Artículos Deportivos”. El detalle delas iteraciones individuales se describe en los planes de cada iteración,documentos que se aportan en forma separada. Durante el proceso dedesarrollo en el artefacto “Visión” se definen las características del productoa desarrollar, lo cual constituye la base para la planificación de lasiteraciones. Para la versión 1.0 del Plan de Desarrollo del Software, noshemos basado en la captura de requisitos por medio del stakeholderrepresentante de la empresa para hacer una estimación aproximada, unavez comenzado el proyecto y durante la fase de Inicio se generará laprimera versión del artefacto “Visión”, el cual se utilizará para refinar estedocumento. Posteriormente, el avance del proyecto y el seguimiento encada una de las iteraciones ocasionará el ajuste de este documentoproduciendo nuevas versiones actualizadas.


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

Después de esta introducción, el resto del documento está organizado enlas siguientes secciones:Vista General del Proyecto — proporciona una descripción del propósito,alcance y objetivos del proyecto, estableciendo los entragbles que seránproducidos y utilizados durante el proyecto..Organización del Proyecto — describe la estructura organizacional delequipo de desarrollo.Gestión del Proceso — explica los costos y planificación estimada, definelas 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 procesode desarrollo de software, incluyendo métodos, herramientas y técnicas queserán utilizadas.

111. Vista General del Proyecto111.1 Propósito, Alcance y Objetivos

La información que a continuación se incluye ha sido extraída de lasdiferentes reuniones que se han celebrado con el stakeholder de laempresa desde el inicio del proyecto.Deportes the runners lleva a cabo la venta al por mayor de artículosdeportivos a nivel internacional. La entrada en un mercado competitivocomo en el que encuentra inmersa esta firma conllevará una previsibleadaptación a los nuevos sistemas de información y a la evolucióntecnológica. Por ello, Deportes the runners considera necesario eldesarrollo de un nuevo sistema de gestión de los artículos deportivos queforman parte de sus catálogos, así como las bases de datos que recogendatos tanto estadísticos, empresariales como de nóminas, plantillas depersonal, 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 losdistintos departamentos.”El proyecto debe proporcionar una propuesta para el desarrollo de todos lossubsistemas implicados en la gestión de artículos deportivos y bases dedatos departamentales”. Estos subsistemas se pueden diferenciar en sietegrandes bloques:b) Gestión de Ventas, incluyendo:


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









Cancelación de pedidos solicitado por el cliente.Gestión de Envíos, incluyendo:


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 RestriccionesLas suposiciones y restricciones respecto del sistema, y que se derivandirectamente de las entrevistas con el stakeholder de la empresa son:d) Debe contemplarse las implicaciones de los siguientes puntos críticos:




Gestión de flujos de trabajo, seguridad de transacciones eintercambio de información

Adaptación a la normativa de Protección de Datose) 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ónreferente a los dominios de tercer nivel.


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 losdistintos almacenes no centralizados encargados de proveer a cadaregió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 elartefacto “Visión”.

111.3 Entregables del proyectoA continuación se indican y describen cada uno de los artefactos que serángenerados y utilizados por el proyecto y que constituyen los entregables.Esta lista constituye la configuración de RUP desde la perspectiva deartefactos, y que proponemos para este proyecto.

Es preciso destacar que de acuerdo a la filosofía de RUP (y de todoproceso iterativo e incremental), todos los artefactos son objeto demodificaciones a lo largo del proceso de desarrollo, con lo cual, sólo altérmino del proceso podríamos tener una versión definitiva y completa decada uno de ellos. Sin embargo, el resultado de cada iteración y los hitosdel proyecto están enfocados a conseguir un cierto grado de completitud yestabilidad de los artefactos. Esto será indicado más adelante cuando sepresenten los objetivos de cada iteración.

22)Plan de Desarrollo del SoftwareEs el presente documento.

23)Modelo de Casos de Uso del NegocioEs un modelo de las funciones de negocio vistas desde la perspectiva

de los actores externos (Agentes de registro, solicitantes finales, otrossistemas etc.). permite situar al sistema en el contexto organizacionalhaciendo énfasis en los objetivos en este ámbito. Este modelo serepresenta con un Diagrama de Casos de Uso usando estereotiposespecíficos para este modelo.


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 delnegocio, estableciendo los actores internos, la información que en términosgenerales manipulan y los flujos de trabajo (workflows) asociados al casode uso del negocio. Para la representación de este modelo se utilizanDiagramas de Colaboración (para mostrar actores externos, internos y lasentidades (información) que manipulan, un Diagrama de Clases paramostrar gráficamente las entidades del sistema y sus relaciones, yDiagramas de Actividad para mostrar los flujos de trabajo.

25)GlosarioEs un documento que define los principales términos usados en el

proyecto. Permite establecer una terminología consensuada. .

26)Modelo de Casos de UsoEl modelo de Casos de Uso presenta las funciones del sistema y los

actores que hacen uso de ellas. Se representa mediante Diagramas deCasos de Uso.

27)VisiónEste documento define la visión del producto desde la perspectiva del


28)Especificaciones de Casos de UsoPara los casos de uso que lo requieran (cuya funcionalidad no sea

evidente o que no baste con una simple descripción narrativa) se realizauna descripción detallada utilizando una plantilla de documento, donde seincluyen: precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales asociados. También, para casos de uso cuyo flujo de eventossea complejo podrá adjuntarse una representación gráfica mediante unDiagrama de Actividad.


SKY BLUE, S.A de C.V.29)Especificaciones Adicionales

Este documento capturará todos los requisitos que no han sido incluidoscomo parte de los casos de uso y se refieren requisitos no-funcionalesglobales. Dichos requisitos incluyen: requisitos legales o normas, aplicaciónde estándares, requisitos de calidad del producto, tales como: confiabilidad,desempeño, etc., u otros requisitos de ambiente, tales como: sistemaoperativo, requisitos de compatibilidad, etc.

30)Prototipos de Interfaces de UsuarioSe trata de prototipos que permiten al usuario hacerse una idea más o

menos precisa de las interfaces que proveerá el sistema y así, conseguirretroalimentación de su parte respecto a los requisitos del sistema. Estosprototipos se realizarán como: dibujos a mano en papel, dibujos con algunaherramienta gráfica o prototipos ejecutables interactivos, siguiendo eseorden de acuerdo al avance del proyecto. Sólo los de este último tipo seránentregados 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 lamedida que el resultado de las iteraciones vayan desarrollando el productofinal.

31)Modelo de Análisis y DiseñoEste 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 incluiraspectos de implementación) hacia una de diseño (incluyendo unaorientación hacia el entorno de implementación), de acuerdo al avance delproyecto.

32)Modelo de DatosPreviendo que la persistencia de la información del sistema será

soportada por una base de datos relacional, este modelo describe larepresentación lógica de los datos persistentes, de acuerdo con el enfoquepara modelado relacional de datos. Para expresar este modelo se utiliza unDiagrama de Clases (donde se utiliza un profile UML para Modelado deDatos, para conseguir la representación de tablas, claves, etc.) .



33)Modelo de ImplementaciónEste modelo es una colección de componentes y los subsistemas que

los contienen. Estos componentes incluyen: ficheros ejecutables, ficherosde código fuente, y todo otro tipo de ficheros necesarios para laimplantación y despliegue del sistema. (Este modelo es sólo una versiónpreliminar al final de la fase de Elaboración, posteriormente tiene bastanterefinamiento).

34)Modelo de DespliegueEste modelo muestra el despliegue la configuración de tipos de nodos

del sistema, en los cuales se hará el despliegue de los componentes.


condiciones de ejecución, las entradas de la prueba, y los resultadosesperados. Estos casos de prueba son aplicados como pruebas deregresión en cada iteración. Cada caso de prueba llevará asociado unprocedimiento de prueba con las instrucciones para realizar la prueba, ydependiendo del tipo de prueba dicho procedimiento podrá serautomatizable mediante un script de prueba.


documento. Mediante este documento se hace un seguimiento de losdefectos detectados, solicitud de mejoras o cambios en los requisitos delproducto. Así se provee un registro de decisiones de cambios, de suevaluación e impacto, y se asegura que éstos sean conocidos por el equipode desarrollo. Los cambios se establecen respecto de la última baseline (elestado del conjunto de los artefactos en un momento determinado delproyecto) establecida. En nuestro caso al final de cada iteración seestablecerá una baseline.




recursos asignados, dependencias entre ellas. Se realiza para cadaiteración, y para todas las fases.

38)Evaluación de IteraciónEste 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 RiesgosEste documento incluye una lista de los riesgos conocidos y vigentes en

el proyecto, ordenados en orden decreciente de importancia y con accionesespecíficas de contingencia o para su mitigación.


producto.

41)Material de Apoyo al Usuario FinalCorresponde a un conjunto de documentos y facilidades de uso del

sistema, incluyendo: Guías del Usuario, Guías de Operación, Guías deMantenimiento y Sistema de Ayuda en Línea

42)ProductoLos ficheros del producto empaquetados y almacenadas en un CD con

los mecanismos apropiados para facilitar su instalación. El producto, a partirde la primera iteración de la fase de Construcción es desarrolladoincremental e iterativamente, obteniéndose una nueva release al final decada 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.

111.4 Evolución del Plan de Desarrollo del SoftwareEl Plan de Desarrollo del Software se revisará semanalmente y se

refinará antes del comienzo de cada iteración.

112. Organización del Proyecto112.1 Participantes en el Proyecto

De momento no se incluye el personal que designará Deportes therunners como Responsable del Proyecto, Comité de Control y Seguimiento,otros participantes que se estimen convenientes para proporcionar losrequisitos y validar el sistema.

El resto del personal del proyecto (por la parte del la empresaadjudicataria), considerando las fases de Inicio, Elaboración y dositeraciones de la fase de Construcción, estará formado por los siguientespuestos de trabajo y personal asociado:Jefe de Proyecto. Labor de luis newman flores, alumno de la carrera deIngeniería de software de la universidad de desarrollo profesional. Con unaexperiencia modesta en metodologías de desarrollo, herramientas CASE ynotaciones, en particular la notación UML y el proceso de desarrollo RUP.Analista de Sistemas. El perfil establecido es: Ingeniero en sistemascomputacionales con conocimientos de UML, uno de ellos al menos conexperiencia en sistemas afines a la línea del proyecto, labor que llevará acabo Agustín Duarte Preciado4 Analistas - Programadores. Con experiencia en el entorno de desarrollodel proyecto, con el fin de que los prototipos puedan ser lo más cercanosposibles al producto final. Este trabajo ha sido encomendado a AgustínDuarte PreciadoIngeniero de Software. El perfil establecido es: Ingeniero en sistemas

computacionales, realizando labores de gestión de requisitos, gestión deconfiguración, documentación y diseño de datos. Encargado de las pruebasfuncionales del sistema, realizará la labor de José Elí Sandoval


SKY BLUE, S.A de C.V.Los Currículos Vitae del personal del proyecto que ya ha comprometido suparticipación se adjuntan por separado.

112.2 Interfaces ExternasDeportes the runners definirá los participantes del proyecto queproporcionarán los requisitos del sistema, y entre ellos quiénes serán losencargados de evaluar los artefactos de acuerdo a cada subsistema ysegún el plan establecido.El equipo de desarrollo interactuará activamente con los participantes deDeportes the runners para especificación y validación de los artefactosgenerados.

112.3 Roles y ResponsabilidadesA continuación se describen las principales responsabilidades de cada unode los puestos en el equipo de desarrollo durante las fases de Inicio yElaboración, de acuerdo con los roles que desempeñan en RUP.

Puesto Responsabilidad

Jefe de Proyecto

El jefe de proyecto asigna los recursos, gestiona lasprioridades, coordina las interacciones con losclientes y usuarios, y mantiene al equipo delproyecto enfocado en los objetivos. El jefe deproyecto también establece un conjunto deprácticas que aseguran la integridad y calidad delos artefactos del proyecto. Además, el jefe deproyecto se encargará de supervisar elestablecimiento de la arquitectura del sistema.Gestión de riesgos. Planificación y control delproyecto.

Analista deSistemas

Captura, especificación y validación de requisitos,interactuando con el cliente y los usuarios medianteentrevistas. Elaboración del Modelo de Análisis yDiseño. Colaboración en la elaboración de laspruebas funcionales y el modelo de datos.

Programador Construcción de prototipos. Colaboración en laelaboración de las pruebas funcionales, modelo de



datos y en las validaciones con el usuario



113. Gestión del Proceso113.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 calendariodel proyecto.


El desarrollo se llevará a cabo en base a fases con una o más iteraciones encada una de ellas. La siguiente tabla muestra una la distribución de tiempos y elnúmero de iteraciones de cada fase (para las fases de Construcción yTransición es sólo una aproximación muy preliminar)

FaseNro.





Fase deElaboración

1 2semanas


2 7semanas

Fase deTransición

- -

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

Descripción Hito


Fase deElaboración

En esta fase se analizan los requisitos y sedesarrolla un prototipo de arquitectura (incluyendolas partes más relevantes y / o críticas del sistema).Al final de esta fase, todos los casos de usocorrespondientes a requisitos que seránimplementados en la primera release de la fase deConstrucción deben estar analizados y diseñados(en el Modelo de Análisis / Diseño). La revisión yaceptación del prototipo de la arquitectura delsistema marca el final de esta fase. En nuestro caso



particular, por no incluirse las fases siguientes, larevisión y entrega de todos los artefactos hasta estepunto de desarrollo también se incluye como hito. Laprimera iteración tendrá como objetivo laidentificación y especificación de los principalescasos de uso, así como su realización preliminar enel Modelo de Análisis / Diseño, también permitiráhacer una revisión general del estado de losartefactos hasta este punto y ajustar si es necesariola planificación para asegurar el cumplimiento de losobjetivos. Ambas iteraciones tendrán una duraciónde una semana.


Durante la fase de construcción se terminan deanalizar y diseñar todos los casos de uso,refinando el Modelo de Análisis / Diseño. Elproducto se construye en base a 2 iteraciones,cada una produciendo una release a la cual se leaplican las pruebas y se valida con el cliente /usuario. Se comienza la elaboración de material deapoyo al usuario. El hito que marca el fin de estafase es la versión de la release 3.0, con lacapacidad operacional parcial del producto que sehaya considerado como crítica, lista para serentregada a los usuarios para pruebas beta.

Fase deTransición

En esta fase se prepararán dos releases paradistribución, asegurando una implantación ycambio del sistema previo de manera adecuada,incluyendo el entrenamiento de los usuarios. Elhito que marca el fin de esta fase incluye, laentrega de toda la documentación del proyecto conlos manuales de instalación y todo el material deapoyo al usuario, la finalización del entrenamientode los usuarios y el empaquetamiento delproducto.


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.


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.





Semana 1

14/10 –20/10

Semana 3

28/10 –3/11

Requisitos

GlosarioSemana 1

14/10 –20/10

Semana 3

28/10 –3/11

VisiónSemana 2

21/10 –27/10

Semana 3

28/10 –3/11


28/10 –3/11

siguientefase


28/10 –3/11

siguientefase




28/10 –3/11

siguientefase

Análisis / Diseño


21/10 –27/10

siguientefase


21/10 –27/10

siguientefase

Implementación


28/10 –3/11

siguientefase


28/10 –3/11

siguientefase

Pruebas


28/10 –3/11

siguientefase

Despliegue


28/10 –3/10

siguientefase






Semana 1

14/10 –20/10

Semana 3

28/10 –3/11








Semana 1

14/10 –20/10

aprobado

Requisitos

GlosarioSemana 1

14/10 –20/10

aprobado

VisiónSemana 2

21/10 –27/10

aprobado


28/10 –3/11

Semana 5

11/12 – 17/12

Especificación de Casos de Uso Semana 3

28/10 –

Semana 5

11/12 – 17/12



3/11


28/10 –3/11

Semana 5

11/12 – 17/12

Análisis / Diseño


21/10 –27/10



21/10 –27/10


Implementación


28/10 –3/11



28/10 –3/11


Pruebas


28/10 –3/11










Semana 1

14/10 –20/10

aprobado

Requisitos

GlosarioSemana 1

14/10 –20/10

aprobado

VisiónSemana 2

21/10 –27/10

aprobado


28/10 –3/11

Semana 511/12 – 17/12


28/10 –3/11

Semana 511/12 – 17/12


28/10 –3/11

Semana 511/12 – 17/12

Análisis / Diseño


21/10 –27/10


Modelo de Datos Semana 2

21/10 –Revisar encada iteración



27/10

Implementación


28/10 –3/11



28/10 –3/11


Pruebas


28/10 –3/11


Despliegue


28/10 –3/11





Semana 4

4/11 –10/11




SKY BLUE, S.A de C.V.113.3 Seguimiento y Control del Proyecto

Gestión de RequisitosLos requisitos del sistema son especificados en el artefacto Visión. Cadarequisito tendrá una serie de atributos tales como importancia, estado,iteración donde se implementa, etc. Estos atributos permitirán realizar unefectivo seguimiento de cada requisito. Los cambios en los requisitos serángestionados mediante una Solicitud de Cambio, las cuales serán evaluadasy distribuidas para asegurar la integridad del sistema y el correcto procesode gestión de configuración y cambios.Control de PlazosEl calendario del proyecto tendrá un seguimiento y evaluación semanal porel jefe de proyecto y por el Comité de Seguimiento y Control.Control de CalidadLos defectos detectados en las revisiones y formalizados también en unaSolicitud de Cambio tendrán un seguimiento para asegurar la conformidadrespecto de la solución de dichas deficiencias Para la revisión de cadaartefacto y su correspondiente garantía de calidad se utilizarán las guías derevisión y checklist (listas de verificación) incluidas en RUP.Gestión de RiesgosA partir de la fase de Inicio se mantendrá una lista de riesgos asociados alproyecto y de las acciones establecidas como estrategia para mitigarlos oacciones de contingencia. Esta lista será evaluada al menos una vez encada iteración.Gestión de ConfiguraciónSe realizará una gestión de configuración para llevar un registro de losartefactos generados y sus versiones. También se incluirá la gestión de lasSolicitudes de Cambio y de las modificaciones que éstas produzcan,informando y publicando dichos cambios para que sean accesibles a todolos participantes en el proyecto. Al final de cada iteración se estableceráuna baseline (un registro del estado de cada artefacto, estableciendo unaversión), la cual podrá ser modificada sólo por una Solicitud de Cambioaprobada.

114. Referencias




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


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

FASE 6. PRUEBAS DE IMPLEMENTACION.


8/11/2002 0.9 Versión preliminar a falta de aprobacióndel 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 norevisadas por el Stakeholder

Rosa María Ogallar

09/12/2002 2.0 Versión con detalles y ajustes a laaplicación en desarrollo.


15/12/2002 2.9 Versión generada en la segunda release conevaluación de las pruebas actualizados.

Rosa María Ogallar

21/12/2002 3.0 Versión generada en la segunda release connuevas pruebas a falta de aprobación por leStakeholder

Rosa María Ogallar



Tabla de Contenidos1. Descripción 185

2. Elaborar pedido y enviar a almacén 185

2.1 Descripción 1852.2 Condiciones de ejecución 1852.3 Entrada 1852.4 Resultado esperado 1862.5 Evaluación de la Prueba 186

3. Elaborar pedido y guardar 186


4. Elaborar pedido vacío y guardar 187


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


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


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


8. Modificar un pedido añadiendo un producto inexistente 191



SKY BLUE, S.A de C.V.8.2 Condiciones de ejecución 1928.3 Entrada 1928.4 Resultado esperado 1928.5 Evaluación de la Prueba 192

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


10. Modificar pedido añadiendo / eliminando una línea de pedido y guardar 194


11. .Modificar dirección de envío del pedido 195


12. Modificar pedido eliminando todas sus líneas 196


13. Eliminar pedido 197


14. Comprobar ratio de pago del cliente 198




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 solicitamoselaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración dedicho 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 dealta en la base de datos de empleado y su clave correspondiente y que el cliente Jaime con DNI48315682-N también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver todala 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.


SKY BLUE, S.A de C.V. 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ículoo Se rellenan automáticamente los campos nombre y precio.o Introduce ‘2’ en cantidado 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 aalmacén

La operadora pulsa el botón “pasar a almacén”. El pedido aparece en el listado de pedidos enviados al almacén.

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


Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamoselaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración dedicho pedido. Una vez elaborado escogeremos la opción guardar.



125. 3.3 Entrada

Introducimos ‘maria’ en el campo usuario Introducimos ‘nike’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un operador. El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operadora.


SKY BLUE, S.A de C.V. La operadora introduce el DNI del cliente apareciendo en el formulario los datos completos


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ículoo Se rellena automáticamente los campos nombre y precio.o Introduce ‘2’ en cantidado 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”.


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



128. 4. Elaborar pedido vacío y guardar


Nos introducimos en el sistema como usuario representante de ventas, accediendo a su funcionalidady solicitamos elaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo laelaboración de dicho pedido. Una vez dentro intentaremos guardar o enviar la orden sin haberañadido ninguna línea de pedido para observar como responde el sistema.


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 correspondientey que el cliente Jaime con DNI 48315682-N también figure en la base de datos. Consultar la Base deDatos de Pruebas para ver toda la especificación completa de los datos.


SKY BLUE, S.A de C.V.131. 4.3 Entrada

Introducimos ‘luis’ en el campo usuario Introducimos ‘reebok’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un representante de ventas. El cliente ‘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.


El sistema muestra un mensaje de error avisando al cliente de que no es posible almacenar en elsistema un pedido vacío.



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


Nos introducimos en el sistema como usuario representante de ventas, accediendo a su funcionalidady solicitamos elaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo laelaboración de dicho pedido. Una vez dentro intentaremos guardar o enviar la orden sin haberañadido ninguna línea de pedido para observar como responde el sistema.





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


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


El sistema muestra un mensaje de error avisando al cliente de que no es posible almacenar en elsistema un pedido vacío.



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


Nos introducimos en el sistema como usuario representante de ventas, el sistema nos mostrara unainterfaz para que llevemos a cabo la elaboración de dicho pedido. Aparece una lista de pedidossolicitados por el cliente que están en proceso de elaboración. Seleccionaremos uno de ellos y loeditaremos para poder añadir una línea de pedido asociada a un producto ya incluido en el pedido.







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ículoo Se rellena automáticamente los campos nombre y precio.o Introduce ‘1’ en cantidado Pulsa el botón “añadir línea”


El sistema nos muestra un mensaje de aviso informándonos de que en ese pedido ya existe una líneaasociada a ese código de artículo y pregunta si desea sobrescribirla o cancelar.



146. 7. Modificar pedido añadiendo una línea de cantidad fuera derango


Nos introducimos en el sistema como usuario representante de ventas, el sistema nos mostrara unainterfaz para que llevemos a cabo la elaboración de dicho pedido. Aparece una lista de pedidossolicitados por el cliente que están en proceso de elaboración. Seleccionaremos uno de ellos y loeditaremos para poder añadir una línea de pedido, probaremos a introducir una cantidad de productoque esté fuera del rango permitido, probaremos una inferior al mínimo y otra superior al máximo.


SKY BLUE, S.A de C.V.148. 7.2 Condiciones de ejecución


149. 7.3 Entrada





o Introduce ‘3’ en código artículoo Se rellena automáticamente los campos nombre y precio.o Introduce ‘0’ en cantidado Introduce ‘10000’ en cantidad


El sistema nos muestra para cada una de las cantidades introducidas un mensaje de errorindicándonos que estamos introduciendo una cantidad errónea ya que está fuera del rango permitido.


Prueba superada con éxito.

152. 8. Modificar un pedido añadiendo un producto inexistente


Nos introducimos en el sistema como usuario representante de ventas, el sistema nos mostrara una


SKY BLUE, S.A de C.V.interfaz para que llevemos a cabo la elaboración de dicho pedido. Aparece una lista de pedidossolicitados por el cliente que están en proceso de elaboración. Seleccionaremos uno de ellos y loeditaremos para poder añadir una línea de pedido asociada a un producto ya incluido en el pedido yañadir un producto inexistente.



155. 8.3 Entrada





o Introduce ‘7’ en código artículoo Pulsa el botón “añadir línea”


El sistema nos muestra un mensaje de error informándonos de que el artículo introducido no existe.





158. 9. Modificar pedido añadiendo / eliminando una línea de pedido yenviar a almacén


Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamoselaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración dedicho pedido, que consistirá en añadir una nueva línea de pedido y eliminar una de las existentes deun pedido en elaboración. Una vez elaborado escogeremos la opción enviar a almacén.



161. 9.3 Entrada

Introducimos ‘maria’ en el campo usuario Introducimos ‘nike’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un operador. El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operadora. La operadora introduce el DNI del cliente apareciendo en el formulario los datos completos


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ículoo Se rellena automáticamente los campos descripción y precio.o Introduce ‘2’ en cantidado 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


El sistema almacena las nuevas modificaciones del pedido seleccionado.





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


Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamoselaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración dedicho pedido, que consistirá en añadir una nueva línea de pedido y eliminar una existente de unpedido en elaboración. Una vez elaborado escogeremos la opción enviar a almacé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


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ículoo Se rellena automáticamente los campos nombre y precio.o Introduce ‘1’ en cantidado Pulsa el botón “añadir línea”o Se actualiza automáticamente el precio total


SKY BLUE, S.A de C.V. El cliente solicita eliminar el par de raquetas del pedido. El representante de ventas elimina la línea de pedido correspondiente al producto que se

desea eliminar. El cliente solicita al representante de ventas finalizar el pedido escogiendo la opción

guardar. El operador pulsa el botón “guardar”.


El sistema almacena las nuevas modificaciones del pedido seleccionado.



169.

170.

171. 11. .Modificar dirección de envío del pedido


Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamoselaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración dedicho pedido, que consistirá en modificar la dirección de envío de un pedido en elaboración.



174. 11.3 Entrada

Introducimos ‘luis’ en el campo usuario Introducimos ‘reebok’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia 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



SKY BLUE, S.A de C.V.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 Calleo Introduce ‘2’ en el campo Nºo Introduce ‘23’ en el campo Pta

El representante de ventas pulsa el botón guardar


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



177. 12. Modificar pedido eliminando todas sus líneas


Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamoselaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración dedicho pedido, que consistirá en modificar la dirección de envío de un pedido en elaboración.


Las condiciones de ejecución del caso de prueba son que el usuario operadora “luis” está dado dealta en la base de datos de empleado y su clave correspondiente y que el cliente Jaime con DNI48315682-N también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver todala 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



SKY BLUE, S.A de C.V.ya ha enviado al almacén.

La operadora selecciona el pedido ‘2’ y pulsa el botón “modificar” y aparece la interfaz demodificar pedido.

La operadora elimina las dos líneas de pedido que componen el pedido, pulsandosucesivamente el botón “eliminar línea”.


El sistema muestra un mensaje de error que nos informa de que no es posible eliminar todas laslíneas de pedido de un cierto pedido.



183. 13. Eliminar pedido


Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamoselaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración dedicho pedido, que consistirá en eliminar un pedido.



186. 13.3 Entrada

Introducimos ‘maria’ en el campo usuario Introducimos ‘nike’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un operador. El cliente ‘Jaime’ con DNI ‘48315682N’ llama a la operadora. La operadora introduce el DNI del cliente apareciendo en el formulario los datos completos


ya ha enviado al almacén.


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.


El pedido seleccionado es eliminado del sistema.



14. Comprobar ratio de pago del cliente


Nos introducimos en el sistema como empleado, accediendo a su funcionalidad y solicitamoselaborar un pedido, el sistema nos mostrara una interfaz para que llevemos a cabo la elaboración dedicho pedido, que consistirá en elegir una modalidad de pago que no corresponde con el ratio depago del cliente.


Las condiciones de ejecución del caso de prueba son que el usuario operadora “maria” está dado dealta en la base de datos de empleado y su clave correspondiente y que el cliente Javier con DNI22496359-P también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver todala especificación completa de los datos.

17. 14.3 Entrada

Introducimos ‘maria’ en el campo usuario Introducimos ‘nike’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un operador. El cliente ‘Javier’ con DNI ‘22496359-P’ llama a la operadora. La operadora introduce el DNI del cliente apareciendo en el formulario los datos completos


ya ha enviado al almacén. El cliente solicita hacer un nuevo pedido.


SKY BLUE, S.A de C.V. 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ículoo Se rellena automáticamente los campos nombre y precio.o Introduce ‘2’ en cantidado 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


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





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 para revisión con elStakeholder

Rosa María Ogallar

15/01/2003 3.0 Versión preparada para la segunda iteraciónde la fase de construcción





2. Pasar pedido completo a envío desde la lista de pedidos en atención 201


3. Pasar pedido completo a envío desde atender pedido 202


4. Cancelar al pasar un pedido incompleto a envío 202


5. Pasar a envío un pedido incompleto generando un pedido con las cantidades restantes 203


6. Pasar a envío un pedido incompleto sin generar un pedido con las cantidades restantes 204




20. Descripción

Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso “Pasar Pedido a Envío”.


Pasar pedido a envío desde la lista de pedidos en atención. Pasar pedido a envío desde atender pedido. Cancelar al pasar un pedido incompleto a envío. Pasar a envío un pedido incompleto generando un pedido con las cantidades restantes. Pasar a envío un pedido incompleto sin generar un pedido con las cantidades restantes.

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

21. Pasar pedido completo a envío desde la lista de pedidos en atención

21.1 Descripción

Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad ysolicitamos consultar pedidos en atención, el sistema nos mostrara una lista con los pedidos enatención que haya almacenados en el sistema. Seleccionaremos un pedido y lo pasaremos a envío.

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 Datosde Pruebas para ver toda la especificación completa de los datos.

21.3 Entrada

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. Seleccionamos de la lista de pedidos en atención el pedido de código ‘3’. Pulsamos el botón ‘Pasar a listo para envío’.

21.4 Resultado esperado

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

21.5 Evaluación de la Prueba


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 ysolicitamos consultar pedidos en atención, el sistema nos mostrara una lista con los pedidos enatención que haya almacenados en el sistema. Seleccionaremos un pedido y después de comprobardesde la opción atender pedido que tiene todas las cantidades asignadas lo pasaremos a envío.



22.3 Entrada

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. El técnico selecciona de la lista de pedidos en atención el pedido de código ‘6’ y pulsa el

botón ‘Atender Pedido’. Una vez comprobado que tiene todas las cantidades asignadas pulsa el botón ‘Pasar a

Envíos’.


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



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 ysolicitamos consultar pedidos en atención, el sistema nos mostrara una lista con los pedidos en


SKY BLUE, S.A de C.V.atención que haya almacenados en el sistema. Seleccionaremos un pedido incompleto y lo pasaremosa envío, cancelando seguidamente dicha decisión.



23.3 Entrada

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. Seleccionamos de la lista de pedidos en atención el pedido de código ‘7’. Pulsamos el botón ‘Pasar a listo para envío’. Nos aparece un mensaje de confirmación que nos indica que el pedido esta incompleto. Elegimos la opción ‘Cancelar’.


El pedido no se modifica por dicha acción y sigue almacenado en el sistema con estado en atención.



24. Pasar a envío un pedido incompleto generando un pedido con lascantidades restantes

24.1 Descripción

Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad ysolicitamos consultar pedidos en atención, el sistema nos mostrara una lista con los pedidos enatención que haya almacenados en el sistema. Seleccionaremos un pedido incompleto y lo pasaremosa envío, responderemos afirmativamente a la confirmación de paso de envío y responderemosafirmativamente a la creación de un pedido con las cantidades restantes.





24.3 Entrada

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. Seleccionamos de la lista de pedidos en atención el pedido de código ‘7’. Pulsamos el botón ‘Pasar a listo para envío’. Nos aparece un mensaje de confirmación que nos indica que el pedido esta incompleto. Elegimos la opción ‘Aceptar’. Nos aparece un mensaje de confirmación sobre la creación de un pedido con las cantidades

restantes. Elegimos la opción ‘Aceptar’.


El pedido se almacena en el sistema con estado listo para envío y se almacena un nuevo pedido en elsistema con las cantidades que restaron del anterior con estado en elaboración.



25. Pasar a envío un pedido incompleto sin generar un pedido con lascantidades restantes

25.1 Descripción

Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad ysolicitamos consultar pedidos en atención, el sistema nos mostrara una lista con los pedidos enatención que haya almacenados en el sistema. Seleccionaremos un pedido incompleto y lo pasaremosa envío, responderemos afirmativamente a la confirmación de paso de envío y responderemosnegativamente a la creación de un pedido con las cantidades restantes.





25.3 Entrada

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. Seleccionamos de la lista de pedidos en atención el pedido de código ‘8’. Pulsamos el botón ‘Pasar a listo para envío’. Nos aparece un mensaje de confirmación que nos indica que el pedido esta incompleto. Elegimos la opción ‘Aceptar’. Nos aparece un mensaje de confirmación sobre la creación de un pedido con las cantidades

restantes. Elegimos la opción ‘Cancelar’.


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





Rosa María Ogallar



Rosa María Ogallar



16/01/2003 3.0 Versión con nuevas pruebas Rosa María Ogallar




2. Crear una incidencia normal en Almacén 207


3. Crear una incidencia vacía en Almacén 208


4. Consultar incidencias en Almacén 209


5. Crear una incidencia normal en Ventas 210

5.1 Descripción 2105.2 Condiciones de Ejecución 2105.3 Entrada 2105.4 Resultado Esperado 2105.5 Evaluación 210

6. Crear una incidencia vacía en Ventas 211


7. Consultar incidencias en Ventas 212




26. Descripción

Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso “Incidencia Pedido”.


Crear una incidencia normal en Almacén. Crear una incidencia vacía en Almacén. Consultar incidencias en Almacén. Crear una incidencia normal en Ventas. Crear una incidencia vacía en Ventas. Consultar incidencias en Ventas.


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. Antecualquier incidencia que nos ocurra mientras estemos atendiendo un pedido, tendremos laoportunidad de crear un parte de incidencia que dejara reflejado en el sistema cualquier problemaque nos haya surgido durante la atención de ese pedido.


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




La incidencia se almacena en el sistema.



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

28.1 Descripción

Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad. Antecualquier incidencia que nos ocurra mientras estemos atendiendo un pedido, tendremos laoportunidad de crear un parte de incidencia que dejara reflejado en el sistema cualquier problemaque nos haya surgido durante la atención de ese pedido. En este caso, probaremos a crear unaincidencia vacía para ver como responde el sistema.



28.3 Entrada

Introducimos ‘toni’ en el campo usuario. Introducimos ‘puma’ en el campo contraseña. Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. Seleccionamos de la lista de pedidos no atendidos el pedido de código ‘1’. Pulsamos el botón ‘Atender Pedido’. Nos aparece la interfaz para atender un pedido. Pulsamos el botón ‘Incidencia’. Nos aparece la interfaz de nueva incidencia. Pulsamos ‘Guardar’ sin haber introducido ningún comentario.


El sistema nos muestra un mensaje de error que nos indica que el campo observaciones no puede servacío.





29. Consultar incidencias en Almacén

29.1 Descripción

Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad. Antecualquier incidencia que nos ocurra mientras estemos atendiendo un pedido, tendremos laoportunidad de crear un parte de incidencia que dejara reflejado en el sistema cualquier problemaque nos haya surgido durante la atención de ese pedido. En este caso, consultaremos la lista deincidencias almacenadas en el sistema.



29.3 Entrada

Introducimos ‘toni’ en el campo usuario. Introducimos ‘puma’ en el campo contraseña. Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. Seleccionamos de la lista de pedidos no atendidos el pedido de código ‘1’. Pulsamos el botón ‘Atender Pedido’. Nos aparece la interfaz para atender un pedido. Pulsamos el botón ‘Incidencia’. Nos aparece la interfaz de nueva incidencia. Pulsamos ‘Consultar Incidencias’.


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





30. Crear una incidencia normal en Ventas30.1 Descripción

Nos introducimos en el sistema como operadora, accediendo a su funcionalidad. Ante cualquierincidencia que nos ocurra mientras estemos elaborando un pedido, tendremos la oportunidad de crearun parte de incidencia que dejara reflejado en el sistema cualquier problema que nos haya surgidodurante la elaboración de ese pedido.

30.2 Condiciones de Ejecución


30.3 Entrada

Introducimos ‘maria’ en el campo usuario Introducimos ‘nike’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un operador. El cliente ‘Jaime’ con código ‘1’ llama a la operadora. La operadora introduce el código del cliente apareciendo en el formulario los datos

completos del cliente. Aparece una lista con los pedidos en elaboración que tiene el cliente en el sistema y los que

ya ha enviado al almacén. El cliente solicita hacer modificaciones al pedido ‘4’. La operadora selecciona el pedido en cuestión y pulsa el botón “modificar”, aparece la

interfaz de modificar pedido. La operadora observa que hay anomalías y procede a la creación de una incidencia. Pulsamos el botón ‘Incidencia’. Nos aparece la interfaz de nueva incidencia. Introducimos un comentario y pulsamos ‘Guardar’. Pulsamos ‘Guardar’ o ‘Salir’ en la interfaz modificar pedido.

30.4 Resultado Esperado

La incidencia se almacena en el sistema.

30.5 Evaluación



SKY BLUE, S.A de C.V.31. Crear una incidencia vacía en Ventas31.1 Descripción

Nos introducimos en el sistema como operadora, accediendo a su funcionalidad. Ante cualquierincidencia que nos ocurra mientras estemos elaborando un pedido, tendremos la oportunidad de crearun parte de incidencia que dejara reflejado en el sistema cualquier problema que nos haya surgidodurante la elaboración de ese pedido. En este caso, probaremos a crear una incidencia vacía para vercomo responde el sistema.


Las condiciones de ejecución del caso de prueba son que el usuario operadora “maria” está dado dealta en la base de datos de empleado y su clave correspondiente y que el cliente Jaime con DNI48315682-N también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver toda laespecificación completa de los datos.

31.3 Entrada




interfaz de modificar pedido. La operadora observa que hay anomalías y procede a la creación de una incidencia. Pulsamos el botón ‘Incidencia’. Nos aparece la interfaz de nueva incidencia. Pulsamos ‘Guardar’ sin haber introducido ningún comentario.


El sistema nos muestra un mensaje de error que nos indica que el campo observaciones no puede servacío.

31.5 Evaluación



SKY BLUE, S.A de C.V.32. Consultar incidencias en Ventas32.1 Descripción

Nos introducimos en el sistema como operadora, accediendo a su funcionalidad. Ante cualquierincidencia que nos ocurra mientras estemos elaborando un pedido, tendremos la oportunidad de crearun parte de incidencia que dejara reflejado en el sistema cualquier problema que nos haya surgidodurante la elaboración de ese pedido. En este caso, consultaremos la lista de incidencias almacenadasen el sistema.



32.3 Entrada




interfaz de modificar pedido. La operadora consulta las incidencias por si el pedido en cuestión tubo alguna. Pulsamos el botón ‘Incidencia’. Nos aparece la interfaz de nueva incidencia. Pulsamos ‘Consultar Incidencias’.


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

32.5 Evaluación






Rosa María Ogallar



Rosa María Ogallar






2. Elegir opción CANCELAR en la confirmación de la cancelación de pedido 215


3. Elegir opción ACEPTAR en la confirmación de la cancelación de pedido 216




33. Descripción

Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso “Cancelar PedidoAtendido”.Realizaremos únicamente dos pruebas que consistirán en la elección de cada una de las opciones deconfirmació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 depedido

34.1 Descripción

Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad ysolicitamos consultar pedidos en atención, el sistema nos mostrara una lista con los pedidos enatención que haya almacenados en el sistema. Elegiremos el pedido que el cliente nos solicite ycancelaremos dicho pedido respondiendo a la confirmación negativamente.


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 conDNI 48315682-N también figure en la base de datos. Consultar la Base de Datos de Pruebas para vertoda la especificación completa de los datos.

34.3 Entrada

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. El cliente ‘Jaime’ con DNI ‘48315682N’ contacta con el técnico de almacén y solicita la

cancelación del pedido en atención con código ‘5’. El técnico de almacén selecciona de la lista de pedidos en atención el pedido en cuestión y

pulsa el botón ‘Cancelar Pedido’. Nos aparece un mensaje de confirmación de la cancelación del pedido. El cliente decide finalmente no cancelar el pedido. El técnico pulsa el botón ‘Cancelar’ .


El pedido seleccionado sigue almacenado en el sistema sin ninguna modificación.


SKY BLUE, S.A de C.V.34.5 Evaluación de la Prueba


35. Elegir opción ACEPTAR en la confirmación de la cancelación depedido

35.1 Descripción

Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad y solicitamosconsultar pedidos en atención, el sistema nos mostrara una lista con los pedidos en atención que hayaalmacenados en el sistema. Elegiremos el pedido que el cliente nos solicite y cancelaremos dicho pedidorespondiendo a la confirmación afirmativamente.


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 DNI48315682-N también figure en la base de datos. Consultar la Base de Datos de Pruebas para ver toda laespecificación completa de los datos.

35.3 Entrada

Introducimos ‘toni’ en el campo usuario Introducimos ‘puma’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia de un técnico de almacén. El cliente ‘Jaime’ con DNI ‘48315682N’ contacta con el técnico de almacén y solicita la

cancelación del pedido en atención con código ‘5’. El técnico de almacén selecciona de la lista de pedidos en atención el pedido en cuestión y

pulsa el botón ‘Cancelar Pedido’. Nos aparece un mensaje de confirmación de la cancelación del pedido. El cliente decide finalmente cancelar el pedido. El técnico pulsa el botón ‘Aceptar’ .


El pedido es eliminado del sistema y se libera el stock asociado a las líneas de pedido pasando denuevo al stock disponible.







Rosa María Ogallar



Rosa María Ogallar






2. Atender pedido después de consultar dicho pedido 219


3. Atender un pedido de la lista de pedidos no atendidos 220


4. Atender pedido asignando cantidades negativas 221


5. Atender pedido asignando cantidades mayores a las disponibles 222


6. Atender pedido asignando cantidades mayores a las solicitadas 223


7. Atender pedido sin asignar cantidades 224




DescripciónEste artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso “Atender Pedido”.


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.


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 ysolicitamos consultar pedidos no atendidos, el sistema nos mostrara una lista con los pedidos noatendidos que haya almacenados en el sistema. Seleccionaremos un pedido y lo consultaremoseligiendo posteriormente la opción de atender dicho pedido.



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 losdatos código y nombre del artículo.

o Introduce la cantidad solicitada.o Pulsa el botón ‘Asignar Cantidad’.o Se actualiza línea de pedido.

El técnico pulsa el botón ‘Guardar’.




El pedido queda almacenado en el sistema como en atención y el stock se reduce en las cantidadesasignadas.



37. Atender un pedido de la lista de pedidos no atendidos

37.1 Descripción

Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad ysolicitamos consultar pedidos no atendidos, el sistema nos mostrara una lista con los pedidos noatendidos que haya almacenados en el sistema. Seleccionaremos un pedido y elegiremos la opciónatender pedido.



37.3 Entrada


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


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



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 ysolicitamos consultar pedidos no atendidos, el sistema nos mostrara una lista con los pedidos noatendidos que haya almacenados en el sistema. Seleccionaremos un pedido, elegiremos la opciónatender pedido y asignaremos cantidades negativas para observar como responde el sistema.



38.3 Entrada


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


El sistema nos muestra un mensaje de error advirtiéndonos de que no es posible introducir cantidadesnegativas.


SKY BLUE, S.A de C.V.38.5 Evaluación de la Prueba


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 ysolicitamos consultar pedidos no atendidos, el sistema nos mostrara una lista con los pedidos noatendidos que haya almacenados en el sistema. Seleccionaremos un pedido, elegiremos la opciónatender pedido y asignaremos cantidades mayores al stock disponible para observar como respondeel sistema.



39.3 Entrada



automáticamente los datos código y nombre del artículo. Introduce la cantidad ‘2’. Pulsa el botón ‘Asignar Cantidad’.


El sistema nos muestra un mensaje de error advirtiéndonos de que no hay stock disponible parapoder asignar esa cantidad .





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 ysolicitamos consultar pedidos no atendidos, el sistema nos mostrara una lista con los pedidos noatendidos que haya almacenados en el sistema. Seleccionaremos un pedido, elegiremos la opciónatender pedido y asignaremos cantidades mayores a las solicitadas para observar como responde elsistema.



40.3 Entrada



automáticamente los datos código y nombre del artículo. Introduce la cantidad ‘2’. Pulsa el botón ‘Asignar Cantidad’.


El sistema nos muestra un mensaje de error advirtiéndonos de que la cantidad introducida es superiora la cantidad solicitada .





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 ysolicitamos consultar pedidos no atendidos, el sistema nos mostrara una lista con los pedidos noatendidos que haya almacenados en el sistema. Seleccionaremos un pedido, elegiremos la opciónatender pedido y no realizaremos ninguna modificación .



41.3 Entrada


botón ‘Atender Pedido’. Sin hacer ninguna modificación el técnico pulsa el botón ‘Guardar’.


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





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


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






2. Comprobar que la consulta funciona correctamente 227



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 noAtendidos”. La única prueba que se puede realizar a este caso de uso es comprobar que la consultafunciona correctamente. El entorno del cual partiremos para realizar la prueba será el formulario deentrada de la aplicación.

43. Comprobar que la consulta funciona correctamente

43.1 Descripción

Nos introducimos en el sistema como técnico de almacén, accediendo a su funcionalidad ysolicitamos consultar pedidos no atendidos, el sistema nos mostrara una lista con los pedidos noatendidos que haya almacenados en el sistema.



43.3 Entrada

Introducimos ‘pepe’ en el campo usuario Introducimos ‘adidas’ en el campo contraseña Pulsamos entrar o el botón “aceptar” de la aplicación. Nos aparece la interfaz propia del técnico de almacén, donde pulsaremos la pestaña de “No

Atendidos”. Seleccionamos uno de los pedidos en estado de no atención. Pulsamos el botón “consultar” y el sistema muestra los detalles de las líneas del pedido. Al

salir, el pedido figurará en el estado de “En Atención”.


El sistema nos muestra una interfaz que consistirá en una lista con las líneas de pedido del pedidosolicitado.




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

Empleado

NIF Usuario Contraseña Nombre Teléfono Cargo22596826-F pepe adidas José Martínez Muñoz 962468597 Técnico almacén26359874-J luis reebok Luis Fernández Vila 961387596 Representante de

Ventas48265791-L maria nike Maria López Escudero 963478952 Operadora26485963-M toni puma Antonio Milla López 963474565 Técnico almacén

Códigopedido

Fecha Estado Cliente UsuarioVentas

C.P.envío

Paísenvío

Prov.envío

Loc.envío

Ptaenvío

Nºenvío

Calleenvío

Formapago

Fechaelab.

Fecha lleg.Alm.

Fechaaten.

Fechalista

envío

Fechasal.

Alm.1 07/09/2002 En

elaboración1 48265791-

L46985 España Valencia Manises 25 3 C/

MeliasContado 07/09/2002

2 25/10/2002 Enelaboración

2 26359874-J

46758 España Valencia Xativa 12 6 C/Azorin

Contado 25/10/2002

3 10/11/2002 Noatendido

1 48265791-L

46985 España Valencia Manises 25 3 C/Melias

Crédito 10/11/2002 10/11/2002

4 21/11/2002 Enelaboración

1 48265791-L

46985 España Valencia Manises 25 3 C/Melias

Contado 21/11/2002

5 02/12/2002 Noatendido

1 48265791-L

46970 España Valencia Burjassot 14 5 C/ SanJusto

Crédito 02/12/2002 05/12/2002

6 07/12/2002 Enatención

2 48265791-L

46758 España Valencia Xativa 12 6 C/Azorín

Contado 07/12/2002 10/12/2002 11/12/2002


2 48265791-L


Contado 15/12/2002 18/12/2002 19/12/2002


2 48265791-L


Contado 04/01/2003 07/01/2003 09/01/2003



Producto-Almacén

Referencia Almacén Stock Stock Asig.1 VAL 1000 12 VAL 500 23 VAL 6 04 VAL 600 15 VAL 3000 1

Almacén

Código Nombre Dirección Teléfono País Fax Email Cod_reg TécnicoVAL Virso C/ Colón, 15-

78963479862 España 963479860 [email protected] E 26485963-M

Región

Código NombreE Europa

País

Nombre Región

España E

Proveedor

NIF Código Nombre Teléfono Dirección Nº Pta Localidad Provincia CP Pais Fax Email

26789536-D 456 JuanNavarro

Luna

963471263 C/ Jesús 48 101 Benaixida Valencia 46078 España 963471260 [email protected]


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

Referencia Precio(€) Nombre Descripción Proveedor Max_razonable1 67 Zapatillas Zapatillas illas 456 2002 34 Mochila Mochila ilas 456 1003 28 Sudadera Sudadera eras 456 3504 42 Raqueta Raquetas etas 456 1005 30 Calentadores Calentadores ores 456 1000

Línea pedido

Código pedido Referencia Cantidad Precio(€) Cantidad Asig.1 1 1 67 0

1 2 1 34 01 3 2 56 02 1 1 67 02 4 2 84 0

3 2 2 68 04 5 3 90 04 4 2 84 05 3 5 140 0

5 1 2 134 06 2 2 68 26 1 1 67 17 4 2 84 1

8 4 1 42 08 5 2 60 1

Cliente

Codigo

NIF/CIF Usuario

Contra

seña

Nombre Pta Nº Calle Teléfono

Loc. Prov. C.P. C.C.C País Email Es-empresa

Pers_contac

to

Tlf_pers_contac

to

Ratio

conf.

Representan

te

Fax

1 48315682-N

JaimeMonzónGarcía

25 3 C/Melias

961385396

Manises Valencia 46985 95-264895-0006352689

España

Jaime75

@ono.com

Excelente

26359874-J

2 22496359-P

javi kelme

JavierSoria

Garrido

12 6 C/Azorin

962359684

Xativa Valencia 46758 48-59682-0008454895

España

[email protected]

m

Regular

26359874-J

Incidencias

Cod_incidencia Cod_pedido Fecha Nif_creador Creador Observaciones1 6 11/12/2002 26485963M Antonio Milla López Reponer stock, producto

1 por debajo del mínimo2 7 21/12/2002 26485963M Antonio Milla López Pedido en atención más

de 2 días

Documents

Proyecto final victor