A finalidade deste Detalhe do Workflow é transformar as descrições comportamentais fornecidas pelos requisitos em um conjunto de elementos no qual o design possa se basear.

Tópicos


      Requisito de Software
Requisito
de Software
  Mapa de Navegação
Mapa de
Navegação
 
         
 
Designer de Interface com o Usuário
Designer
de Interface
com o Usuário

 

 
Projetar a Interface com o Usuário
Projetar
a Interface
com o Usuário

 
Criar um Protótipo da Interface do Usuário
Criar um
Protótipo
da Interface
do Usuário

 
         
      Mapa de Navegação
Mapa de
Navegação
  Protótipo da Interface do Usuário
Protótipo
da Interface
do Usuário
 

      Mapa de Navegação
Mapa de
Navegação
Modelo de Design
Modelo de
Design
  Mapa de Navegação
Mapa de
Navegação
Modelo de Design
Modelo de
Design
 
         
 
Revisor Técnico
Revisor
Técnico

 

 
Revisar o Design
Revisar
o Design

 
Revisar o Design
Revisar
o Design

 
         
      Registro de Revisão
Registro
de Revisão
  Registro de Revisão
Registro
de Revisão
 

      Classe de Análise
Classe de
Análise
 
       
 
Arquiteto de Software
Arquiteto
de Software

 

 
Identificar Elementos de Design
Identificar
Elementos
de Design

 
       
      Subsistema de Design
Subsistema
de Design
Modelo de Design
Modelo de
Design
 
      Pacote de Design
Pacote de
Design
Sinal
Sinal
 
      Evento
Evento
Classe de Design
Classe de
Design
 
      EJB (Enterprise Java Bean)
EJB (Enterprise
Java Bean)
Interface
Interface
 

      Caso de Uso
Caso de
Uso
 
       
 
Designer
Designer
 

 
Análise de Caso de Uso
Análise
de Caso
de Uso

 
       
      Classe de Análise
Classe de
Análise
Realização de Caso de Uso
Realização
de Caso
de Uso
 
      Modelo de Análise
Modelo de
Análise
 


Descrição Para o início da página

Este Detalhe do Workflow ocorre em cada iteração na qual existam requisitos comportamentais a serem analisados e projetados.

A análise de requisitos comportamentais inclui:

  • identificar classes de análise que atendam ao comportamento necessário
  • determinar como essas classes de análise se ajustam à arquitetura lógica (os principais subsistemas e classes) do sistema. As classes de análise podem ser determinadas para pertencer a sistemas existentes, requerer a criação de novos subsistemas ou ocasionar a redefinição dos subsistemas existentes e suas interfaces.

Este Detalhe do Workflow também pode incluir a modelagem e a criação de protótipo da interface com o usuário.

Informações Relacionadas To top of page

Esta seção fornece fornece links para informações adicionais relacionadas a este detalhe do workflow.

Sincronização Para o início da página

Inicia na fase de Elaboração, passa pelas fases de Construção e Transição.

Opcionalidade To top of page

Obrigatório

Como Formar Equipe Para o início da página

Principalmente em projetos grandes, o design e a criação de protótipo da interface com o usuário são executados por um grupo separado de pessoas, com foco na usabilidade do sistema e na interface com o usuário. No entanto, esse grupo deverá trabalhar juntamente com outros membros da equipe de desenvolvimento, principalmente aqueles responsáveis pelos requisitos e pela lógica de negócios, para certificar-se de que a interface com o usuário seja aquela esperada pelo usuário e que a lógica de negócios forneça o que é requerido pela interface com o usuário (em termos de conteúdo e de ações do usuário).

A Atividade: Análise de Caso de Uso é melhor conduzida por um grupo pequeno que tenha uma combinação de habilidades; as diretrizes de formação de equipe são apresentadas em Diretrizes: Workshop de Análise de Caso de Uso. A Atividade: Identificar Elementos de Design requer uma perspectiva mais ampla da arquitetura e os resultados dos outros workshops de análise de caso de uso, além de exigir uma certa experiência em tecnologia de implementação e em qualquer estrutura que estiver sendo utilizada no projeto. As revisões devem ser feitas por pessoas que tenham vasto conhecimento das tecnologias de implementação e uma compreensão do domínio do problema.

Diretrizes de Trabalho Para o início da página

A Atividade: Projetar a Interface com o Usuário e a Atividade: Criar Protótipo da Interface com o Usuário são executadas iterativamente nas iterações de Elaboração. Iterações iniciais têm como foco o design da interface com o usuário, que inclui a identificação e o design dos principais elementos da interface com o usuário e os caminhos de navegação entre eles. O ../../workguid/wg_stbd.htm -- This hyperlink in not present in this generated websiteesboço seqüencial é uma técnica eficaz que pode ser utilizada durante o design da interface com o usuário para se obter uma melhor compreensão de como a interface com o usuário deve se comportar. Depois que se chega a um consenso sobre o design da interface com o usuário inicial, o desenvolvimento de um protótipo de executável da interface com o usuário é iniciado. O feedback sobre o protótipo é mantido no design da interface com o usuário (e possivelmente também nos requisitos). Geralmente, o protótipo inicial suporta apenas um subconjunto dos recursos do sistema. Em iterações subseqüentes, o protótipo é expandido, incluindo gradualmente uma cobertura mais ampla dos recursos do sistema. A principal vantagem de produzir versões não funcionais da interface com o usuário ao projetá-la é adiar o investimento em protótipos funcionais da interface com o usuário mais elaborados e caros até que haja um consenso sobre o design geral da interface com o usuário. É importante trabalhar junto com os usuários ou potenciais usuários do sistema ao projetar e criar o protótipo da interface com o usuário a fim de confirmar e validar a usabilidade do sistema.

Uma série de workshops de análise de caso de uso pode ser organizada em paralelo, limitada somente pelo pool de recursos disponíveis e pelas habilidades dos participantes. Assim que possível, após cada workshop de análise de caso de uso, alguns membros do workshop e alguns membros da equipe de arquitetura devem trabalhar para mesclar os resultados do workshop na Atividade: Identificar Elementos de Design. Os membros de ambas as equipes são essenciais: os membros da equipe de análise de caso de uso compreendem o contexto em que as classes de análise foram identificadas, enquanto a equipe de arquitetura compreende o contexto mais amplo do design, bem como outros casos de uso que já foram identificados.

Quando o trabalho de design for concluído e estabilizado, cada vez mais partes maiores dele poderão e deverão ser revisadas. {\lang1033 Revisões menores e mais centradas são melhores do que revisões grandes e abrangentes. }Dezesseis revisões de duas horas em aspectos muito específicos são significativamente melhores do que uma única revisão dividida em dois dias. Nas revisões enfatizadas, defina os objetivos para restringir o enfoque da revisão e verifique se uma equipe de revisão pequena com as habilidades corretas, dado os objetivos, estará disponível para a revisão. As revisões iniciais devem enfocar basicamente a integridade da disposição em camadas e do empacotamento no design, a estabilidade e a qualidade das interfaces, e a totalidade da cobertura do comportamento de caso de uso. As revisões posteriores devem se aprofundar nos pacotes e subsistemas, a fim de garantir que seu conteúdo realizará completa e corretamente suas interfaces definidas, e que as dependências e associações entre os elementos de design serão necessárias, suficientes e corretas. Consulte os pontos de verificação de cada artefato de design para obter os pontos de revisão específicos.



Rational Unified Process   2003.06.15