RUP - Aplicacion de La Metodologia 2017

Utilizando la Metodología RUP:: Desarrollo de un Sistema de Gestión::
Introducción Gestión del Proyecto Modelado del Negocio Requisitos Análisis/Diseño Implementación Prueba
Enfoque Practico de RUP

Expositor MSc. Fernando Zeballos O. ©2017
El objetivo 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 desarrollará bajo el lenguaje de programación Java, teniendo que
soportar tanto acceso a una base de datos MYSQL.
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.

FICHA DE PRODUCTOS
Ficha de Producto
Referencia: C38842
Nombre: Camiseta 1ª Equitación
Marca: ADIDAS
Procedencia: Taiwán
Proveedor: Proveedor Oficial Adidas
Dispone de tejido ClimaCool que elimina más rápidamente el sudor que

el poliéster tradicional, lo que permite que el jugador se encuentre más
seco y confortable. Presenta logos bordados, cuello redondo en color a
Descripción:
contraste y paneles laterales con tejido de malla para una mejor
transpiración del deportista. En la manga aparece la bandera española
bordada.
Precio Compra: S/. 100.00
Precio Venta: S/ 120.00

FICHA DE EMPLEADO

FICHA DE EMPRESA
Ficha de Cliente Empresa

Empresa: Dos A Dos, club deportivo RUC: 97852165234
Dirección: Autovía Chiclayo País: Perú
Población: 46540 Quart de Poblet Provincia: Chiclayo
Teléfono: 96 192 07 07 Fax: 96 192 12 38
Contacto: Marcos Estévez Luján Telf. de contacto: 630 456 654
Departamento: Ventas Cargo: Subdirector general
E-mail: mestévez@2a2.com

FICHA DE PEDIDO (ALBARAN)

FICHA DE FACTURA

Plan de Desarrollo Planificación del Proyecto Diario de Ejecución
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.

Vista General del Proyecto

Introducción
•Propósito
•Alcance
•Resumen
Vista General del Proyecto
•Propósito, Alcance y Objetivos
•Suposiciones y Restricciones
•Entregables del proyecto
•Evolución del Plan de Desarrollo del Software
Organización del Proyecto
•Participantes en el Proyecto
•Interfaces Externas
•Roles y Responsabilidades
Gestión del Proceso
•Estimaciones del Proyecto
•Plan del Proyecto
•Plan de las Fases
•Calendario del Proyecto
•Seguimiento y Control del Proyecto
Referencias

Fase de Fase de Fase de Construcción Fase de Construcción

Inicio Elaboración iteración 1 Iteración 2
Disciplinas / Artefactos Comienzo Aprobación
Modelado del Negocio
Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio Semana 14/05/11 - 20/05/11 Semana 28/05/11 - 3/06/11
Requisitos
Glosario, Visión, Modelo de Caso de Uso, Especificaciones de casos de usos,

Semana 14/05/11 - 20/05/11 Semana 28/05/08 - 3/06/11
Especificaciones Adicionales
Análisis / Diseño
Modelo de Análisis / Diseño, Modelo de Datos Semana 21/05/11 - 27/05/11 Siguiente fase
Implementación
Prototipos de Interfaces de Usuario Semana 28/05/11 - 3/06/11 Siguiente fase
Modelo de Implementación Semana 28/05/11 - 3/06/11 Siguiente fase
Pruebas
Casos de Pruebas Funcionales Semana 28/05/11 - 3/06/11 Siguiente fase
Despliegue
Modelo de Despliegue Semana 28/05/11 - 3/05/11 Siguiente fase
Gestión de Cambios y Configuración Durante todo el proyecto Durante todo el proyecto
Gestión del proyecto
Plan de Desarrollo del Software en su versión 1.0 y planes de las Iteraciones Semana 14/05/11 - 20/05/11 Semana 28/05/11 - 3/06/11
Ambiente Durante todo el proyecto Durante todo el proyecto


Disciplinas / Artefactos generados Comienzo Aprobación
Modelado del Negocio
Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio Semana 14/05/11 - 20/05/11 Aprobado
Requisitos
Glosario, Visión, Modelo de Datos, Especificaciones de Casos de Usos,

Semana 14/05/11 - 20/05/11 Aprobado
Especificaciones Adicionales
Análisis / Diseño
Modelo de Análisis / Diseño, Modelos de Datos Semana 21/05/11 - 27/05/11 Revisar en cada iteración
Implementación
Prototipos de Interfaces de Usuario Semana 28/05/11 - 3/06/11 Revisar en cada iteración
Modelo de Implementación Semana 28/05/11 - 3/06/11 Revisar en cada iteración
Pruebas
Casos de Pruebas Funcionales Semana 28/05/11 - 3/06/11 Revisar en cada iteración
Despliegue
Modelo de Despliegue Semana 28/05/11 - 3/05/11 Revisar en cada iteración
Gestión de Cambios y Configuración Durante todo el proyecto Durante todo el proyecto
Gestión del proyecto
Plan de Desarrollo del Software en su versión 2.0 y planes de las Iteraciones Semana 14/05/11 - 20/05/11 Revisar en cada iteración
Ambiente Durante todo el proyecto Durante todo el proyecto


Disciplinas / Artefactos generados o modificados

Comienzo Aprobación
durante la Fase de Construcción (Iteración 1)
Casos de Uso negociados para la Primera Release
Elaborar Pedido (Gestión de Ventas) 19/07/2011 12/08/2011

Consultar Pedidos no Atendidos (Gestión de Almacén) 23/07/2011 12/08/2011


Disciplinas / Artefactos generados o modificados

Comienzo Aprobación
durante la Fase de Construcción (Iteración 2)
Casos de Uso negociados para la Primera Release
Elaborar Pedido (Gestión de Ventas) 19/07/2011 Aprobado
Consultar Pedidos no Atendidos (Gestión de Almacén) 23/07/2011 Aprobado
Casos de Uso negociados para la Segunda Release
Atender Pedido (Gestión de Almacén) 13/09/2011 17/09/2011
Cancelar Pedido Atendido (Gestión de Almacén) 16/09/2011 17/09/2011
Pasar Pedido a Envío (Gestión de Almacén) 13/09/2011 17/09/2011
Incidencia de Pedidos (Gestión de Almacén y Ventas) 13/09/2011 17/09/2011

Dedicación estimada
Día Actividad desarrollada
(en horas de trabajo)
03/04/2011 Reunión de los miembros del grupo. Puesta en marcha del proyecto. Organización del equipo. 3,5
07/05/2011 Reunión con el Stakeholder de la empresa cliente. Descripción general del sistema. Captura inicial de requisitos. 1
10/05/2011 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/05/2011 Elaboración del primer documento con la captura de requisitos inicial para exponer al resto del grupo. 1
17/05/2011 Reunión del grupo de trabajo. Aclaración de los requisitos iniciales del sistema. 3
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
18/05/2011 1
Software.
21/05/2011 Reunión del Jefe Proyecto y Arquitecto de Software para la planificación de tareas. Comienzo de la fase de Análisis. 3,5
Reunión del Jefe de Proyecto, Arquitecto de Software y dos Programadores para identificar subsistemas, actores y algunos casos de uso
22/05/2011 3
generales. Primeros esbozos en Rational Rose.
23/05/2011 Tercera reunión con el Stakeholder. Aclaración de las características del sistema y sus atributos. Definición de los perfiles de usuario. 1,5
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.
24/05/2011 3
Algunos posibles casos de prueba.
29/05/2011 Realización del documento Visión versión 1.0 completa. 3
31/05/2011 Presentación del artefacto Plan de Desarrollo Software y del Modelo de Casos de Uso del Negocio y de Objetos del Negocio. 1
01/06/2011 Generación del Diagrama de Clases. 3
Total de horas dedicadas al proyecto: 271,5 horas

La Empresa Modelado del Negocio
Se muestra los artefactos utilizados de la metodología RUP para

definir un modelo del negocio, modelos de objetos del negocio y el
modelo del dominio.
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.

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 Caso de uso del Negocio

Modelo del Dominio

Modelos de Objetos del Negocio
Están asociados a cada uno de los casos de uso del negocio. Por ser de
mayor prioridad para la empresa, el caso de uso para el cual se desarrolló
el modelo de objetos fue el del caso de uso del negocio "vender
productos".

Modelo de Objetos de Vender Productos

Modelo de Objetos de Seguimiento y Consulta de Productos

Modelo de Objetos de Reponer Stock

Modelo de Objetos Modificar Catalogo

Modelo de Objetos de Realizar Entrega

MODELO DE REQUISITOS

Tiene como objetivo delimitar el sistema y capturar la funcionalidad que

debe ofrecer desde la perspectiva del usuario. Este modelo puede
funcionar como un contrato entre el desarrollador y el cliente o usuario
del sistema, y por lo tanto proyecta lo que el cliente desea según la
percepción del desarrollador.
El propósito del modelo de requisito es comprender completamente el

problema y sus implicaciones.

Visión Glosario Casos de Usos Gestión de Requisitos
Introducción
•Propósito
•Alcance El propósito de éste documento es
•Referencias
Posicionamiento recoger, analizar y definir las
•Oportunidad del Negocio necesidades y las características del
Descripción de los Participantes del Proyecto
•Participantes en el Proyecto sistema.
•Perfiles de usuarios El documento se centra en la
Descripción Global del Producto
•Perspectivas funcionalidad requerida por los
•Costos y precios participantes en el proyecto y los
Restricciones
Precedencias y Prioridades usuarios finales.
Otros Requisitos del Producto
Requisitos de Documentación
Manual de Usuario
Ayuda en Línea

Introducción
•Propósito Recoge todos y cada uno de los
•Alcance
•Referencias términos manejados a lo largo de
•Organización del Glosario todo el proyecto.
Definiciones
•Lista de Términos manejados a lo largo de todo
el proyecto
Se trata de un diccionario informal de datos y definiciones de la

nomenclatura que se maneja, de tal modo que se crea un estándar para
todo el proyecto.

La Empresa lleva a cabo la venta al por mayor de artículos deportivos a nivel internacional. La
entrada en un mercado competitivo como en el que encuentra inmersa este firma conllevará una
previsible adaptación a los nuevos sistemas de información y a la evolución tecnológica. Por ello,
la empresa considera necesario el desarrollo de un nuevo sistema de gestión de los artículos
deportivos que forman parte de sus catálogos.
El proyecto debe proporcionar una propuesta para el desarrollo de todos los subsistemas
implicados en la gestión de artículos deportivos. Estos subsistemas se pueden diferenciar en siete
grandes bloques:
•Gestión de Ventas, incluyendo:

•Procedimiento de venta de productos vía operadoras de teléfono.
•Procedimiento de venta mediante la atención de comerciales a domicilio del cliente.
•Procedimiento de venta mediante el sistema online, vía Web.
•Gestión de Almacenes, incluyendo:
Gestión de nuevos pedidos.
Reserva de stock para la preparación de pedidos.
Gestión de Envíos.
Gestión de Pedidos.
Gestión de recibos.
•Departamento de Recursos Humanos.
•Departamento de Marketing.
•Departamento de Logística.
•Contabilidad y Facturación.

El modelo de casos de uso describe un sistema en término de sus distintas

formas de utilización, cada uno de estas formas es conocida como un caso
de uso. Cada caso de uso o flujo se compone de una secuencia de eventos
iniciada por el usuario.
Para comprender los casos de uso de un sistema primero es necesario
saber quienes son sus usuarios.
Por ejemplo, conducir un automóvil es distinto a arreglarlo, donde los

usuarios también son distintos, el dueño del automóvil y el mecánico,
respectivamente. Para ello se define el concepto de actor

Los actores son entidades distintas a los usuarios, en el sentido que los
usuarios son las personas reales que utilizan el sistema, mientras que los
actores representan un cierto papel que una persona real puede jugar.
Utilizando terminología orientada a objetos, se considera al actor como una
clase de usuario, mientras que los usuarios se consideran como objetos o
instancias de esa clase.
Los actores modelan cualquier entidad externa que necesite intercambiar

información con el sistema. Los actores no están restringidos a ser
personas físicas, pudiendo representar otros sistemas externos al actual. Lo
esencial es que los actores representen entidades externas al sistema.
Además, cada uno de estos actores podrá ejecutar una o más tareas del
sistema.

Para especificar los actores de un sistema, se dibuja un diagrama

correspondiente a la delimitación del sistema, la cual representa al sistema
como una “caja negra” y a los diferentes actores como entidades externas a
ésta, como se muestra en la figura.

Volviendo a la distinción entre actor y persona, una misma persona puede

jugar el papel del actor Usuario cuando hace reservas y además puede
trabajar para el sistema de reservaciones, por ejemplo como Operador,
correspondiente a otro actor no mostrado en nuestro ejemplo.
Delimitación del sistema de reservaciones de vuelo.

El actor Usuario se considera un actor primario, ya que el sistema se

construye pensando en sus usuarios, mientras que Base de Datos de
Reservas y Base de Datos de Registro son ambos actores secundarios, ya
que si no existieran usuarios no habría necesidad del sistema.
Delimitación del sistema de reservaciones de vuelo.
Actor
Concreto
Actor
Abstracto

Caso de Uso, se define la funcionalidad propia del sistema por medio de

los casos de uso. Utilizando terminología orientada a objetos, cada caso de
uso define una clase o forma particular de usar el sistema mientras que
cada ejecución del caso de uso se puede ver como una instancia del caso
de uso, o sea, un objeto, con estado y comportamiento. Cada caso de uso
constituye un flujo completo de eventos especificando la interacción que
toma lugar entre el actor y el sistema.
El actor primario es encargado de dar inicio a esta interacción, mientras que

los casos de uso son instanciados como respuesta al evento anterior.

En el sistema de reservaciones de vuelos utilizamos los actores ya

identificados como punto de partida. Dado que el Usuario es el actor
primario se comienza con él. El sistema tiene que poder dar ciertos
servicios al usuario, como consultas y reservas. De aquí podemos definir
nuestros casos de uso principales, Consultar Información y Hacer
Reservación.

Cuando diferentes actores juegan roles similares ellos pueden heredar de

un actor abstracto común, como se muestra mediante el actor abstracto
Base de Datos en el ejemplo de la figura siguiente. El resto de los actores
se conoce como actores concretos, utilizando terminología similar a aquella
de herencia.

En la descripción del problema se menciona que para poder utilizar el

sistema el usuario debe estar registrado, por lo cual agregamos un caso de
uso Registrar Usuario. Por otro lado, se debe incluir la Base de Datos de
Reservas, y la Base de Datos de Registro ya que son actores secundarios
necesarios. Estos tres casos de uso se muestran en la figura.

La extensión especifica cómo un caso de uso puede insertarse en otro

para extender la funcionalidad del anterior. El caso de uso donde se va a
insertar la nueva funcionalidad debe ser un flujo completo, por lo cual éste
es independiente del caso de uso a ser insertado. De esta manera, el caso
de uso inicial no requiere consideraciones adicionales al caso de uso a ser
insertado, únicamente especificando su punto de inserción.

Inclusión. Es una relación adicional entre casos de uso es la inclusión. A

diferencia de una extensión, la inclusión se define como una sección de un
caso de uso que es parte obligatoria del caso de uso básico. El caso de uso
donde se va a insertar la funcionalidad depende del caso de uso a ser
insertado. Se etiqueta la relación con “incluye” (“include”). Por ejemplo, en
el Sistema de Reservaciones de Vuelos, el caso de uso de Consultar
Información incluye el caso de uso Validar Usuario como se muestra en la
figura.

Generalización. Es una relación adicional entre casos de uso es la

generalización la cual apoya la reutilización de los casos de uso. Mediante
la relación de generalización es necesario describir las partes similares una
sola vez en lugar de repetirlas para todos los casos de uso con
comportamiento común.
Se conoce a los casos de uso que se extraen como casos de uso abstractos,
ya que no serán instanciados independientemente

Los casos de uso adicionales en este diagrama son la extensión de Registrar Tarjeta y Pagar
Reservación. Este último caso de uso es interesante por que extiende Hacer Reservación e
incluye Registrar Tarjeta, ambos requisitos para poder comprar un boleto con el sistema.
Además de la inclusión anterior, también se incluyen los casos de uso de Validar Usuario y
Ofrecer Servicios en los casos de uso básicos: Registrar Usuario, Consultar Información y
Hacer Reservación.

Ventas Almacén Envíos Logística Marketing Contabilidad RR.HH
A continuación se presentan los diagramas de

casos de uso planteados para cada uno de los
subsistemas definidos para la empresa.


CU-CONTROL DE ESTADISTICA
Descripción
El Jefe de Ventas o el Ingeniero de Logística inicia el caso de uso. El
sistema le muestra una pantalla donde puede crear diversas estadísticas
sobre conceptos relacionados con la empresa. Por ejemplo, ventas por
sección, ventas de los representantes, pedidos realizados a las operadoras,
beneficio de la empresa, etc. Una vez creada una estadística puede ser
impresa o guardada en el sistema para su consulta posterior.

Flujo de Eventos
1. La pantalla muestra una lista con las posibles estadísticas a crear.

2. El actor selecciona una de ellas y pulsa el botón crear.
3. El sistema le muestra una pantalla donde puede asignar regiones,
almacenes o trabajadores afectados por la estadística.
4. 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.
5. Pulsando siguiente aparecerán los resultados que podrá guardar o
imprimir.
a) Si pulsa el botón guardar el sistema le permitirá grabar los
resultados en el disco duro u otro soporte de almacenamiento.
b) Si pulsa el botón imprimir se enviará a la impresora los resultados.

Precondiciones
1. El actor ha realizado correctamente el registro en el sistema.
2. El actor ha seleccionado el botón de “Control Estadísticas” de su interfaz
gráfica.








stakeholders Actores Características Caso de Clase

del Software Usos
Stakeholders: Los representantes de los usuarios y portavoces de las necesidades

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


del Software Usos
Stakeholders: La matriz de trazabilidad de los stakeholders relaciona a éstos con las

características de software de tal manera que se puede conocer qué stakeholder
propuso qué característica.


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


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


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


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


del Software Usos


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


del Software Usos
Casos de Uso:
derivados de las
características
software, son el
de las necesidades
de los usuarios, cyas
especificaciones
paquete
Especificaciones de
Casos de Uso
Pro.


del Software Usos
Casos de Uso:
derivados de las
características
software, son el
de las necesidades
de los usuarios,
cuyas
especificaciones
paquete
Especificaciones de
Casos de Uso
Pro.


del Software Usos


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












Modelo de Diseño







































Semana 28/05/11–
03/06/11
19/07/2011 12/08/2011
23/07/2011 12/08/2011

19/07/2011
23/07/2011
13/09/2011 17/09/2011
16/09/2011 17/09/2011
13/09/2011 17/09/2011
13/09/2011 17/09/2011



29/08/11
07/09/11
10/09/11
17/09/11


FIN !!
¿¿Preguntas??

RUP - Aplicacion de La Metodologia 2017

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RUP - Aplicacion de La Metodologia 2017

Uploaded by

Copyright:

Available Formats

Utilizando la Metodología RUP:: Desarrollo de un Sistema de Gestión::

Enfoque Practico de RUP

El objetivo es mostrar un ejemplo de desarrollo de software basado en

El Proyecto es el desarrollo de un sistema para la gestión de artículos

Expositor MSc. Fernando Zeballos O. ©2017

Nombre: Camiseta 1ª Equitación

Proveedor: Proveedor Oficial Adidas

Dispone de tejido ClimaCool que elimina más rápidamente el sudor que

Precio Compra: S/. 100.00

Precio Venta: S/ 120.00

Expositor MSc. Fernando Zeballos O. ©2017

Expositor MSc. Fernando Zeballos O. ©2017

Ficha de Cliente Empresa

Expositor MSc. Fernando Zeballos O. ©2017

FICHA DE PEDIDO (ALBARAN)

Expositor MSc. Fernando Zeballos O. ©2017

Expositor MSc. Fernando Zeballos O. ©2017

Plan de Desarrollo Planificación del Proyecto Diario de Ejecución

Se muestran las planificaciones temporales de desarrollo

Expositor MSc. Fernando Zeballos O. ©2017

Plan de Desarrollo Planificación del Proyecto Diario de Ejecución

Vista General del Proyecto

Expositor MSc. Fernando Zeballos O. ©2017

Plan de Desarrollo Planificación del Proyecto Diario de Ejecución

Fase de Fase de Fase de Construcción Fase de Construcción

Disciplinas / Artefactos Comienzo Aprobación

Modelado del Negocio

Glosario, Visión, Modelo de Caso de Uso, Especificaciones de casos de usos,

Prototipos de Interfaces de Usuario Semana 28/05/11 - 3/06/11 Siguiente fase

Modelo de Implementación Semana 28/05/11 - 3/06/11 Siguiente fase

Casos de Pruebas Funcionales Semana 28/05/11 - 3/06/11 Siguiente fase

Modelo de Despliegue Semana 28/05/11 - 3/05/11 Siguiente fase

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

Gestión del proyecto

Ambiente Durante todo el proyecto Durante todo el proyecto

Expositor MSc. Fernando Zeballos O. ©2017

Plan de Desarrollo Planificación del Proyecto Diario de Ejecución

Fase de Fase de Fase de Construcción Fase de Construcción

Disciplinas / Artefactos generados Comienzo Aprobación

Modelado del Negocio

Glosario, Visión, Modelo de Datos, Especificaciones de Casos de Usos,

Prototipos de Interfaces de Usuario Semana 28/05/11 - 3/06/11 Revisar en cada iteración

Modelo de Implementación Semana 28/05/11 - 3/06/11 Revisar en cada iteración

Casos de Pruebas Funcionales Semana 28/05/11 - 3/06/11 Revisar en cada iteración

Modelo de Despliegue Semana 28/05/11 - 3/05/11 Revisar en cada iteración

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

Gestión del proyecto

Ambiente Durante todo el proyecto Durante todo el proyecto

Expositor MSc. Fernando Zeballos O. ©2017

Plan de Desarrollo Planificación del Proyecto Diario de Ejecución

Fase de Fase de Fase de Construcción Fase de Construcción

Disciplinas / Artefactos generados o modificados

Casos de Uso negociados para la Primera Release

Elaborar Pedido (Gestión de Ventas) 19/07/2011 12/08/2011

Expositor MSc. Fernando Zeballos O. ©2017

Plan de Desarrollo Planificación del Proyecto Diario de Ejecución

Fase de Fase de Fase de Construcción Fase de Construcción

Disciplinas / Artefactos generados o modificados

Elaborar Pedido (Gestión de Ventas) 19/07/2011 Aprobado

Consultar Pedidos no Atendidos (Gestión de Almacén) 23/07/2011 Aprobado

Casos de Uso negociados para la Segunda Release

Atender Pedido (Gestión de Almacén) 13/09/2011 17/09/2011

Cancelar Pedido Atendido (Gestión de Almacén) 16/09/2011 17/09/2011