Ejemplo de Desarrollo de Software Uml

Ejemplo de desarrollo software utilizando la metodología RUP

Introducción

Gestión del Proyecto

Modelado del Negocio

Requisitos

Análisis/Diseño

Implementación

Introducción El objetivo de esta página web es mostrar un ejemplo de desarrollo de software basado en la metodología de Rational Unified Process (RUP). El proyecto es el desarrollo de un sistema para la gestión de artículos deportivos de una empresa del sector de ventas de deportes a clientes tanto a mayoristas como a minoristas. Se incluye hasta la segunda iteración de la fase de construcción, según la división establecida en el documento Plan de Desarrollo Software. Por motivos de privacidad no se pueden publicar los datos de la entidad para la que se diseñó el software.

Descargar el Proyecto Completo

Contexto de Desarrollo

Este proyecto ha sido desarrollado en el contexto de la asignatura de quinto curso de Ingeniería Informática, Laboratorio de Sistemas de Información (http://www.dsic.upv.es/asignaturas/facultad/lsi/ ), de la Facultad de Informática (http://www.fiv.upv.es ) de la Universid Universidad ad Politécnica de Valencia bajo la supervisión del profesor Patricio Orlando Letelier Torres (http://www.dsic.upv.es/~letelier ). El equipo de desarrollo que ha llevado a cabo este proyecto es el siguiente:

Pruebas

• Jefe del Proyecto: César López Rodríguez ([email protected] ) [email protected] [email protected] .es)) • Arquitecto de Software: José Luis Martínez Herrero ( jomarh • Analista/Desarrollador: Germán Mira Rico ([email protected] ) • Analista/Desarrollador: Miguel Antonio Mascilla Guzmán ([email protected] ) [email protected] @inf.upv.es)) • Programador: José Antonio Mocholí Agües ( jomocag [email protected])) • Programador: Eduardo Bueno Medina ([email protected] • Tester: Rosa María Ogallar Verjillos ( Verjillos ([email protected] [email protected] ) Top Proyecto La aplicación se desarrolló bajo el lenguaje de programación Visual Basic 6.0, teniendo que soportar tanto acceso a una base de datos Oracle como a una base de datos Access, dependiendo de la selección del usuario en el arranque del programa. Cabe citar que el equipo de desarrollo estaba limitado a unos conocimientos medios del lenguaje de programación, por lo que las soluciones adoptadas pueden no ser completamente eficientes. En el partado de Gestión del Proyecto se Proyecto se muestran las planificaciones temporales de desarrollo del proyecto en su fase de inicio y de elaboración, así como el diario de ejecución del proyecto, junto con el diario de construcción de la aplicación y cumplimiento de los plazos estimados. En el apartado de Modelado del Negocio se Negocio se encuentr encuentran an los artefactos utilizados de l a metodología RUP para definir un modelo del negocio, modelos de objetos del negocio y el modelo del dominio. En el apartado Requisitos Requisitos se se muestran todos los enlaces a los documentos en formato word y pdf consultables desde el navegador. Dicha documentación consta de los artefactos definidos según la metodología RUP, es decir, el documento plan de desarrollo software, el documento visión, el documento glosario y las especificaciones tanto de los casos de uso como de los casos de pruebas relacionados con estos. También se recoge la gestión del proyecto con la herramienta de Rational, el Requisite Pro, con la que además de llevar el control de toda la documentación, se puede seguir la trazabilidad entre requerimientos de todo el proyecto. En este apartado se muestran las matrices de atributos de todos los requerimientos así como la navegabilidad entre ellos. Por añadidura también se muestran los casos de uso de cada subsistema generados con la herramienta Rational Rose, y desde los cuales también se puede consultar la especificación del caso de uso. En el apartado Análisis/Diseño Análisis/Diseño se se muestran tanto el modelo de análisis/diseño (diagrama de clases) como el modelo de datos (modelo entidad - relación), desde los cuales se puede consultar la especificación de los métodos de clase más relevantes o las especificaciones de atributos. En el apartado Implementación Implementación se se muestran los prototipos de interfaces de usuario de la aplicación, tanto para el sistema de gestión de ventas como para el sistema de gestión de almacén. También en este apartado se muestran los diagramas de componentes y diagrama de despliegue que modela las aplicaciones incorporadas en el proyecto hasta la

segunda iteración de la fase de construcción (según la definición de fases e iteraciones de la metodología RUP) y desde los cuales, a través de los componentes se puede consultar el código fuente de cada uno. Por último, en el apartado Pruebas Pruebas se se encuentran los enlaces a los documentos word de especificación de casos de pruebas funcionales consultables mediante el navegador o bien descargables mediante un enlace en formato zip. Se muestran únicamente los casos de pruebas generados para los casos de uso incorporados hasta la segunda iteración de la fase de construcción.

Top Plantillas Para facilitar el desarrollo de este proyecto se utilizaron como soporte las siguientes plantillas basadas en la metodología RUP y también los documentos de información adicional de la empresa de deportes. El p royecto genérico en Rational Requisite Pro que se utilizó como apoyo y guía para la generación de la documentación del proyecto se puede descargar en el siguiente enlace:

Descargar el proyecto genérico Fichas de datos de la empresa de deportes, tanto de personal como de clientes, productos, albaranes y facturas.

Fichas de Productos Fichas de Empleados Fichas de Clientes

Albaranes Facturas

Palabras Clave: Ejemplo UML, RUP, Rational Unified Process, Metodología Desarrollo Software, Rational Rose, Requisite Pro

Esta página web ha sido diseñada para una resolución de pantalla óptima de 800x600 Autor: César López Rodríguez ( [email protected] ) Última actualización: 28 de Julio de 2003

Ejemplo de desarrollo software utilizando la metodología RUP

Introducción


Plan Desarrollo Software

Fase de Inicio


Planificación del Proyecto

Fase de Elaboración

Requisitos

Análisis/Diseño

Implementación

Pruebas

Diario de Ejecución

Fase de Construcción (Iteración 1)

Fase de Construcción (Iteración 2)

Gestión del Proyecto En este apartado se detalla la planificación inicial del proyecto para la fase de inicio y la fase de elaboración (según la definición de la metodología RUP) y el diario de ejecución del proyecto, sesión tras sesión de trabajo.

Plan de Desarrollo Software

Ver el Plan de Desarrollo Software como documento WORD

Ver el Plan de Desarrollo Software como documento como PDF

Top Planificación del Proyecto

Disciplinas / Artefactos generados o modificados durante la Fase de Inicio

Comienzo

Aprobación

Semana 14/10/02 20/10/02

Semana 28/10/02 3/11/02

Glosario

Semana 14/10/02 20/10/02

Semana 28/10/02 3/11/02

Visión

Semana 21/10/02 27/10/02

Semana 28/10/02 3/11/02

Modelo de Casos de Uso

Semana 28/10/02 3/11/02

Siguiente fase

Especificación de Casos de Uso

Semana 28/10/02 3/11/02

Siguiente fase

Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio Requisitos

Semana 28/10/02 3/11/02

Siguiente fase

Modelo de Análisis / Diseño

Semana 21/10/02 27/10/02

Siguiente fase

Modelo de Datos

Semana 21/10/02 27/10/02

Siguiente fase

Prototipos de Interfaces de Usuario

Semana 28/10/02 3/11/02

Siguiente fase

Modelo de Implementación

Semana 28/10/02 3/11/02

Siguiente fase

Semana 28/10/02 3/11/02

Siguiente fase

Semana 28/10/02 3/10/02

Siguiente fase

Durante todo el proyecto


Semana 14/10/02 20/10/02

Semana 28/10/02 3/11/02



Especificaciones Adicionales Análisis / Diseño

Implementación

Pruebas

Casos de Pruebas Funcionales Despliegue Modelo de Despliegue

Gestión de Cambios y Configuración Gestión del proyecto Plan de Desarrollo del Software en su versión 1.0 y planes de las Iteraciones

Ambiente

Top

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

Comienzo

Aprobación

Semana 14/10/02 20/10/02

Aprobado


Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio

Requisitos

Glosario

Semana 14/10/02 20/10/02

Aprobado

Visión

Semana 21/10/02 27/10/02

Aprobado

Modelo de Casos de Uso

Semana 28/10/02 3/11/02

Semana 11/12/02 17/12/02

Especificación de Casos de Uso

Semana 28/10/02 3/11/02

Semana 11/12/02 17/12/02

Especificaciones Adicionales

Semana 28/10/02 3/11/02

Semana 11/12/02 17/12/02

Modelo de Análisis / Diseño

Semana 21/10/02 27/10/02

Revisar en cada iteración

Modelo de Datos

Semana 21/10/02 27/10/02


Análisis / Diseño

Implementación


Semana 28/10/02 3/11/02


Modelo de Implementación

Semana 28/10/02 3/11/02


Semana 28/10/02 3/11/02


Semana 28/10/02 3/10/02




Semana 14/10/02 20/10/02




Pruebas

Casos de Pruebas Funcionales

Despliegue

Modelo de Despliegue

Gestión de Cambios y Configuración Gestión del proyecto

Plan de Desarrollo del Software en su versión 2.0 y planes de las Iteraciones

Ambiente

Top Disciplinas / Artefactos generados o modificados durante la Fase de Construcción (Iteración 1)

Comienzo

Aprobación

19/11/2002

12/12/2002

23/11/2002

12/12/2002

Casos de Uso negociados para la Primera Release Elaborar Pedido (Gestión de Ventas) Consultar Pedidos no Atendidos (Gestión de Almacén)

Top Disciplinas / Artefactos generados o modificados durante la Fase de Construcción (Iteración 2)

Comienzo

Aprobación

19/11/2002

Aprobado

23/11/2002

Aprobado

13/01/2003

17/01/2003

16/12/2002

17/01/2003

13/01/2003

17/01/2003

13/01/2003

17/01/2003

Casos de Uso negociados para la Primera Release Elaborar Pedido (Gestión de Ventas) Consultar Pedidos no Atendidos (Gestión de Almacén) Casos de Uso negociados para la Segunda Release Atender Pedido (Gestión de Almacén) Cancelar Pedido Atendido (Gestión de Almacén) Pasar Pedido a Envío (Gestión de Almacén) Incidencia de Pedidos (Gestión de Almacén y Ventas)

Top

Diario de Ejecución

Día

Actividad desarrollada

Dedicación estimada (en horas de trabajo)

03/09/2002

Reunión de los miembros del grupo. Puesta en marcha del proyecto. Organización del equipo.

07/10/2002

Reunión con el Stakeholder de la empresa cliente. Descripción general del sistema. Captura inicial de requisitos.

1

10/10/2002

Reunión con dos de los integrantes del grupo no asistentes a la anterior reunión. Explicación de la presentación del proyecto.

4

14/10/2002

Elaboración del primer documento con la captura de requisitos inicial para exponer al resto del grupo.

17/10/2002

Reunión del grupo de trabajo. Aclaración de los requisitos iniciales del sistema.

18/10/2002

Segunda reunión con el Stakeholder para la aclaración de dudas anteriores, y para el inicio del documento Visión y Plan de Desarrollo Software.

21/10/2002

Reunión del Jefe Proyecto y Arquitecto de Software para la planificación de tareas. Comienzo de la fase de Análisis.

22/10/2002

Reunión del Jefe de Proyecto, Arquitecto de Software y dos Programadores para identificar subsistemas, actores y algunos casos de uso generales. Primeros esbozos en Rational Rose.

23/10/2002

Tercera reunión con el Stakeholder. Aclaración de las características del sistema y sus atributos. Definición de los perfiles de usuario.

24/10/2002

Presentación de la versión 1.0 del documento Visión. Cuarta reunión con el Stakeholder. Casos de uso generales y glosario encaminados. Algunos posibles casos de prueba.

29/10/2002

Realización del documento Visión versión 1.0 completa.

31/10/2002

Presentación del artefacto Plan de Desarrollo Software y del Modelo de Casos de Uso del Negocio y de

3,5

1

3

1

3,5

3

1,5

3

3 1

Objetos del Negocio. 01/11/2002

Generación del Diagrama de Clases.

04/11/2002

Creación de las Plantillas de Especificación de Casos de Uso y revisión de otros artefactos.

05/11/2002

Reunión del todo el equipo para revisar cada artefacto y asegurar que todos los miembros del grupo están al tanto del proyecto, y de la labor de cada uno.

06/11/2002

Realización de la Especificación de los Casos de Uso.

07/11/2002

Preparación de las especificaciones de algunos casos de uso, a falta de corroborar con el usuario. Búsqueda de más información con la herramienta Rational Rose.

07/11/2002

Quinta reunión con el Stakeholder de la empresa para aprobar el modelo de casos de uso del negocio, el modelo de objetos del negocio, y revisar los casos de uso y el modelo de datos.

1,5

10/11/2002

Elaboración casos de uso y estudio de ejemplos de Casos de Prueba por parte del Tester. Elaboración de la documentación con Requisite Pro.

7,5

11/11/2002

Elaboración de plantillas de casos de uso, cada uno de los miembros del grupo tiene asignadas una o dos plantillas.

7

12/11/2002

Realización de la primera versión del modelo de la Base de Datos, Especificación Casos de Uso y Diagrama de Clases

13/11/2002

Sexta reunión con el Stakeholder, revisión de las plantillas de los casos de uso negociados para la primera release: Elaborar Pedido y Consultar Pedidos no Atendidos. Elaboración de los Prototipos de Interfaces y Casos de Prueba asociados a los mismos.

14/11/2002

Aprobación de la Arquitectura del Software. Entrega de prototipos de interfaces gráficas y modelos de casos de pruebas. Se ratifican los casos de uso que se incorporarán en la 1ª release. Presentación del modelo Rational Rose (diagrama de casos de uso, especificación de casos de uso, modelo de negocio, diagrama de clases), del modelo de la base de datos, de los casos de prueba y de las interfaces gráficas. Refinamiento del modelo de la base de datos, con lo que obtenemos la segunda versión del mismo.

3 5,5

2,5

7,5

2

7,5

9,5

7

16/11/2002

Mejora de las Interfaces Gráficas, también revisión de las plantillas de las especificaciones de Casos de Uso de Elaborar Pedido y Consultar Pedidos no Atendidos y los Casos de Pruebas asociados.

17/11/2002

Elaboración nuevos Casos de Prueba detectados.

18/11/2002

Séptima reunión con el Stakeholder. Revisión de las interfaces de los casos de uso incorporados en la 1ª release y de los casos de pruebas.

19/11/2002

Elaboración informe reunión. Integración del modelo de la base de datos en el sistema de gestión de bases de datos Oracle. Realización de la segunda versión de las interfaces gráficas, de acuerdo con los requerimientos del cliente.

20/11/2002

Comienzo de la elaboración de la documentación y requisitos con el RequisitePro. Revisión Casos de Uso.

21/11/2002

Octava reunión con el Stakeholder. Revisión del Visión y del Plan de Desarrollo Software. Continuación del desarrollo del proyecto y documentación en RequisitePro. Elaboración de nuevos Casos de Prueba.

9

21/11/2002

Inicio de la implementación del primer frame de la aplicación, correspondiente a la identificación de los usuarios. Conexión a la Base de Datos.

6,5

23/11/2002

Elaboración de Casos de Prueba. Elaboración de la documentación con Requisite Pro.

5,5

24/11/2002

Elaboración de Casos de Prueba.

3

25/11/2002

Reunión de equipo para revisión de las tareas asignadas. Elaboración de la documentación con Requisite Pro.

5

25/11/2002

Novena reunión con el Stakeholder para la revisión de Interfaces Gráficas y Modelo de Pruebas.

1,5

25/11/2002

Revisión del modelo en Rational Rose en el RequisitePro y los módulos de programación para que todo sea consistente.

25/11/2002

Finaliza la implementación del primer frame. Se inicia la implementación del frame correspondiente a “Elaborar Pedido” por parte de un representante.

6

1,5

1,5

3

9,5

3

4,5

26/11/2002

Elaboración de la documentación con Requisite Pro.

26/11/2002

Creación Modelo de Objetos del Negocio, Diagrama de Despliegue y Diagrama de Componentes. Reunión con los Implementadores. Elaboración de Casos de Prueba por parte del Tester.

8,5

26/11/2002

Elaboración de la documentación con Requisite Pro. Avanza la implementación del frame “Elaborar Pedido”.

7,5

27/11/2002

Décima reunión con el Stakeholder para resolver dudas puntuales y algunos detalles. Reunión posterior del grupo para aclarar esfuerzos individuales.

2,5

28/11/2002

Elaboración de Casos de Prueba de la 2ª Release.

1

30/11/2002

Modificación Base de Datos de pruebas.

2

02/12/2002

Reunión del grupo para aclarar la dinámica de trabajo, esfuerzos individuales y planificar nuevas tareas. Continúa la implementación y depuración de “Elaborar pedido”.

7,5

03/12/2002

Ajustes del Modelo de Rational Rose y depuración de “Elaborar pedido”. Elaboración de la documentación con Requisite Pro.

8,5

05/12/2002

Modificación Base de Datos de pruebas y continuación de la depuración de "Elaborar Pedido".

5,5

09/12/2002

Reunión del grupo. Realización Pruebas diseñadas por el Tester y otras pruebas funcionales no documentadas. Depuración del código generado.

9

10/12/2002

Creación de nuevos Diagramas y Casos de Uso. Continúa la realización de Pruebas.

6

11/12/2002

Modificación Base de Datos de pruebas, revisión de las pruebas realizadas. Realización de Pruebas por parte del Usuario.

4,5

12/12/2002

Exposición de la 1ª Release

0,5

14/12/2002

Estudio de nuevos Prototipos de Interfaces Gráficas. Elaboración de la documentación con Requisite

5

2

Pro. 16/12/2002

Reunión con el Stakeholder de la empresa cliente. Revisión de Prototipos y Casos de Prueba asociados.

5,5

17/12/2002

Creación de nuevos Diagramas y estudio Caso de Pruebas.

6

19/12/2002

Reunión del grupo para aclarar la dinámica de trabajo, esfuerzos individuales y objetivos comunes.

2

19/12/2002

Reunión con el cliente con el fin de negociar los casos de uso que se implementarán para la 2ª Release.

1,5

21/12/2002

Implementación de los Casos de Uso pactados. Realización casos prueba 2ª Release.

7,5

22/12/2002

Creación de nuevos Casos de Uso. Implementación del caso de uso “Pasar a listo para envío”.

7,5

23/12/2002

Implementación de los Casos de Uso pactados para la 2ª Release.

7,5

26/12/2002

Creación de nuevos casos de uso

26/12/2002

Realización casos prueba 2ª Release.

3,5

27/12/2002


8,5

28/12/2002


9

29/12/2002

Realización de Casos de Prueba 2ª Release y modificación Base de Datos de prueba.

5,5

03/01/2003

Creación de nuevos Diagramas de Actividad. Realizaci ón de los Casos de Prueba 2ª Release.

6,5

05/01/2003

Realización casos prueba 2ª Release y modificación Base de Datos de prueba.

4

06/01/2003

Modificación de documentos del Requisite Pro.

5

3

08/01/2003

Modificación de los Casos de Pruebas. Elaboración de la documentación con Requisite Pro.

5,5

10/01/2003

Revisión de los Diagramas de Acitividad. Elaboración de la documentación con Requisite Pro.

4,5

15/01/2003

Reunión del grupo para la confirmación de todos los entregables de la 2ª Release.

6,5

15/01/2003

Presentación de la 2ª Release al cliente, entrega de lo convenido hasta la fecha. Revisión del Usuario y Fin del Proyecto. Total de horas dedicadas al proyecto:

1

271,5 horas

Nota: en los casos de reuniones de grupo se han computado solamente las horas dedicadas a la reunión en total, no las horas de cada miembro del equipo en la reunión. En el resto de casos las horas computadas son la suma de las dedicadas por los integrantes del equipo en suma del día.

Introducción



Empresa de Deportes

Requisitos

Análisis/Diseño

Implementación

Pruebas


Modelado del Negocio de la Empresa de Deportes Lsi 03

A continuación se presentan los modelos definidos en RUP como modelo del negocio (modelo de casos de uso del negociomo y delo de objetos del negocio), modelo de datos y modelo de análisis y diseño. También se muestran los diagramas de componentes y diagramas de despliegue del proyecto.

Top

Empresa de Deportes

La empresa de deportes que solicitó el proyecto de desarrollo software consta de varios departamentos centralizados, un almacén central y de diversas sucursales de ventas repartidas en distintos países. Cada sucursal de ventas dispone de un almacén regional que suministra los pedidos de los clientes a los países que conforman una región determinada, siendo el almacén central el que abastece al resto de almacenes. El diagrama que representa los diferentes subsistemas en los que se ha dividido la empresa a nivel de abstracción es el siguiente:

Top Modelado del Negocio

El modelado del negocio se basa en dos diagramas principales, el modelo de casos de uso del negocio, el modelo del dominio y los modelos de objetos del negocio . La empresa interactúa con distintos elementos externos, entre los que se identifican el cliente externo (persona o entidad que solicita la compra de productos a la empresa), el proveedor (persona o entidad que reabastece de productos a la empresa) y por último la empresa de transportes, que es una subcontrata encargada de servir los pedidos desde los distintos almacenes regionales a los clientes de la empresa.

Modelo de Casos de Uso del Negocio

Top

Modelo del Dominio

Top

Los modelos de objetos del dominio están asociados a cada uno de los casos de uso del negocio. Por ser de mayor prioridad para la empresa, el

caso de uso para el cual se desarrolló el modelo de objetos fue el del caso de uso del negocio "vender productos".

Modelo de Objetos de Vender Productos

Modelo de Objetos de Seguimiento y Consulta de Productos

Top

Modelo de Objetos de Reponer Stock

Modelo de Objetos de Modificar Catálogo

Modelo de Objetos de Realizar Entrega

Introducción

Visión


Glosario


Requisitos

Casos de Uso con Rational Rose

Análisis/Diseño

Implementación

Pruebas

Gestión de Requisitos con Requisite Pro

Especificaciones de Casos de Uso

Requisitos

A continuación se publican los enlaces a cada una de los documentos word utilizados en la herramienta Rational Requisite Pro para declarar los requisitos software, es decir, el documento plan de desarrollo software, el documento visión, el documento glosario y tanto las especificaciones de los casos de uso incorporados hasta la segunda iteración de la fase de construcción, y otros que fueron propuestos para las siguientes releases, como las especificaciones de casos de prueba de los casos de uso incorporados hasta la segunda iteración de la fase de construcción .

Visión y Glosario

Ver el documento WORD

Ver el documento en formato PDF

Documento Visión

Documento Glosario

Top Especificaciones de Casos de Uso

Las especificaciones de casos de uso están divididas según el subsistema al que pertenezcan, atendiendo a los subsistemas definidos en el documento Visión. Los documentos se encuentran en formato word. Ver el documento WORD


Departamento de Contabilidad/Faturación:

Especificación del caso de uso "cobro a clientes"

Departamento de Logística: Top Especificación del caso de uso "compra a proveedores"

Especificación del caso de uso "gestión de regiones"

Especificación del caso de uso "reabastecer almacén"

Departamento de Marketing:

Especificación del caso de uso "confeccionar catálogo"

Especificación del caso de uso "política de ventas"

Especificación del caso de uso "realizar oferta"

Departamento de Recursos Humanos:

Especificación del caso de uso "entrevista de trabajo"

Especificación del caso de uso "gestión de nóminas"

Especificación del caso de uso "gestión de personal"

Especificación del caso de uso "redistribución de personal"

Gestión de Almacén:

Especificación del caso de uso "consultar pedidos no atendidos"

Especificación del caso de uso "atender pedido"

Especificación del caso de uso "cancelar pedido atendido"

Especificación del caso de uso "incidencia pedido"

Especificación del caso de uso "pasar pedido a envío"

Especificación del caso de uso "reposición de stock"

Gestión de Envíos:

Especificación del caso de uso "consultar pedidos a enviar"

Especificación del caso de uso "introducir recibos"

Especificación del caso de uso "realizar envío"

Gestión de Ventas:

Especificación del caso de uso "control de estadísticas"

Especificación del caso de uso "consultar catálogo"

Especificación del caso de uso "otorgar incentivos"

Especificación del caso de uso "elaborar pedido"

Especificación del caso de uso "elaborar pedido online"

Especificación del caso de uso "gestión de clientes"

Top

Si algún enlace es incorreto informar aquí:

Introducción



Requisitos

Modelo de Análisis/Diseño

Análisis/Diseño

Implementación

Modelo de Datos

Análisis / Diseño

A continuación se presentan los modelos definidos en RUP como modelo de datos y modelo de análisis / diseño. Constará de un diagrama de clases en el que se mustran tan sólo las clases generadas a partir de los casos de uso incorporados a la aplicación hasta la segunda iteración de la fase de construcción, y de un modelo de datos (modelo relacional) donde se muestran las entidades que participan en las relaciones definidas en el proyecto (teniendo en cuenta de nuevo que se alcanzó únicamente la segunda iteración de la fase de construcción).

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

Nota: Se pueden consultar los detalles de los métodos de clase haciendo clic sobre la clase correspondiente

Pruebas

Top Modelo de Datos: Modelo Relacional

Nota: Se pueden consultar los detalles de cada entidad haciendo clic sobre la entidad correspondiente

Introducción



Requisitos

Análisis/Diseño

Implementación Pruebas


Interfaces Comunes

Implementación

Componentes / Despliegue

Almacén

Ventas

A continuación se presentan los prototipos de interfaces gráficas de usuario diseñadas para la aplicación final. Cabe sitar que se presentan únicamente los prototipos de interfaces de usuario que se negociaron con el cliente como candidatos a ser incluidos hasta la segunda iteración de la fase de construcción (en los subsistemas de gestión de almacén y gestión de ventas respectivamente).

Diseño de Prototipos de Interfaces en zip: Interfaces Comunes

La aplicación de cualquier subsistema de la empresa dispone de una primera ventana de identificación del usuario. Sólo usuarios registrados en la base de datos pueden acceder al sistema. Para la demo descargable se puede utilizar el usuario operadora cuyo nombre de usuario es "maria" y cuyo password es "nike".

La interfaz que se presenta en la identificación identificación se puede ver en el siguiente enlace: enlace:

En caso de seleccionar incidencia pedido, la interfaz gráfica que se mostrará será la siguiente:

En la consulta de incidencias se podrá ver una lista de las incidencias registradas registradas en el sistema. En las siguientes iteraciones de construcción se implementarán casos de uso como el de gestión de clientes (botón que aparece en la pantalla de los datos del cliente pero que no tiene ninguna funcionalidad asociada).

El enlace que muestra esta interfaz es el siguiente:

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

Top Gestión de Ventas

Para el subsistema de ventas el prototipo de interfaz gráfica es el de elaborar pedido. Para la aplicación demo se puede introducir por ejemplo en nombre "jaime" y pulsar el botón "buscar". Aparecerán los datos de este cliente.

El prototipo de interfaz gráfica es el del siguiente enlace: El usuario de ventas puede generar un pedido nuevo para un cliente, modificar un pedido que esté en elaboración, consultar pedidos en elaboración, cancelar pedidos o consultar el detalle de pedidos ya enviados al almacén. En el caso de elaborar un pedido nuevo o de modificar uno existente la interfaz gráfica que se presentará será la siguiente: Top Gestión de Almacén

Para la gestión de almacén el prototipo de interfaz gráfica es el siguiente, en el que se pueden observar cuatro pestañas principales, una para no atendidos (pedidos en estado de no atención), otra para en atención (pedidos para los cuales ha sido reservado stock) En la pestaña de no atendidos el técnico de almacén puede realizar las operaciones de consulta de detalles de un pedido, puede atender directamente el pedido seleccionado, puede cancelar el pedido seleccionado o salir de nuevo a la interfaz de identificación.

Para ver la interfaz gráfica principal de técnico de almacén en no atendidos es la siguiente: En la pestaña de en atención el técnico de almacén dispone de las siguientes opciones en su interfaz gráfica: atender el pedido seleccionado, cancelar el pedido seleccionado, pasar un pedido determinado tanto si está completo como si está completo a envío, y salir a la interfaz de identificación.

El enlace para la interfaz de en atención es el siguiente: En la pestaña de listos para envío, el técnico de almacén dispone de las siguientes opciones en su interfaz gráfica: consultar los detalles del pedido seleccionado, cancelar el pedido seleccionado o salir a la interfaz de identificación.

El enlace para la interfaz de listos para envío es el siguiente: Dentro de la interfaz en de la coinsulta de pedidos no atendidos que se puede realizar desde la pestaña de no atendidos, se observa la siguiente interfaz gráfica: Al atender, tanto si es la primera atención como si se trata de una modificación posterior de un pedido, se observa la siguiente interfaz gráfica, que dispone de las opciones siguientes: asignar cantidad al hacer doble clic sobre una línea de pedido, guardar los cambios realizados pulsando el botón guardar, pasar el pedido a envíos, generar una incidencia respecto a este envío o volver a la interfaz anterior pulsando el botón salir.

El enlace para la interfaz de atender pedido es el siguiente:

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

Introducción



Requisitos

Análisis/Diseño

Implementación

Pruebas Funcionales

A continuación se publican los enlaces a cada una de los documentos word utilizados como casos de pruebas funcionales de los casos de uso incluidos en el proyecto de desarrollo software hasta la segunda iteración de la fase de construcción, como se indica en el plan de desarrollo software.

Especificaciones de Casos de Prueba

Pruebas

Las especificaciones de casos de uso están divididas según el subsistema al que pertenezcan, atendiendo a los subsistemas definidos en el documento Visión. Los documentos se encuentran en formato word. Ver el documento en formato WORD

Base de Datos de Prueba: (Imprescindible para ver los datos utilizados en los casos de pruebas)

Especificación de la base de datos de pruebas

Gestión de Almacén:

Especificación del caso de prueba "consultar pedidos no atendidos"

Especificación del caso de prueba "atender pedido"

Especificación del caso de prueba "cancelar pedido atendido"

Especificación del caso de prueba "incidencia pedido"

Especificación del caso de prueba "pasar pedido a envío"

Gestión de Ventas:


Especificación del caso de prueba "elaborar pedido"

Ejemplo de Desarrollo de Software Uml

Recommend Documents