Roteiro: Engenharia de UsabilidadeTópicos
Introdução
|
|
Atividade
|
Artefato |
Conteúdo Relacionado à Usabilidade |
| Identificar Solicitações dos Principais Envolvidos | Solicitações dos Principais Envolvidos |
Essa atividade envolve a realização de entrevistas de usuários, questionários e workshops para compreender melhor o usuário e o seu ambiente. Isso inclui:
O template de Artefato: Solicitações dos Principais Envolvidos capta um perfil detalhado de usuário, incluindo formação educacional, conhecimentos de informática, experiência, ambiente existente, expectativas, metas, etc. Ele também capta uma descrição dos problemas e das prioridades do ponto de vista do usuário. As Solicitações dos Principais Envolvidos são a matéria-prima a partir da qual a Visão é compilada. |
| Desenvolver a Visão | Visão |
A seção Ambiente de Usuário do template Visão descreve o ambiente de trabalho dos usuários finais, ou o que a ISO denomina Contexto do Ambiente [ISO 13407]. A seção Perfil do Usuário do template Visão descreve a formação do usuário, o conhecimento técnico, as responsabilidades, os critérios de êxito, os produtos liberados, etc. Isso é o que a ISO denomina Contexto do Usuário [ISO 13407]. |
| Localizar Atores e Casos de Uso, Estruturar o Modelo de Casos de Uso, Detalhar um Caso de Uso | Modelo de Casos de Uso |
O Modelo de Casos de Uso descreve as tarefas (casos de uso) que os usuários (Atores humanos) realizam. Ele capta semelhanças e relacionamentos entre Atores, usando relacionamentos de generalização. Os Atores estão relacionados a casos de uso através de comunicações. Isto é similar ao "Modelo de Papéis" de Constantine [CON99]. Os casos de uso são estruturados e relacionados uns com os outros e com atores através de relacionamentos de associação de comunicação, de inclusão, de generalização e de extensão. Os workshops são uma excelente forma de envolver o usuário. Consulte: |
|
|
As características dos atores humanos são captadas como atributos de Atores. Isso inclui:
|
|
|
|
Podem incluir casos de uso essenciais, conforme descrito por Constantine [CON99] (consulte Conceitos: Design Centrado no Usuário para obter informações sobre casos de uso essenciais). Requisitos de usabilidade específicos de um determinado caso de uso podem ser captados como "Requisitos Especiais" na especificação do caso de uso. | |
| Detalhar os Requisitos de Software | As Especificações Suplementares captam requisitos não especificados nos casos de uso. Isso inclui requisitos de disponibilidade e desempenho que podem estar diretamente ligados a usabilidade. Requisitos gerais de usabilidade aplicáveis a vários casos de uso são captados aqui, juntamente com a legislação e os padrões de usabilidade correspondentes (consulte Conceitos: Design Centrado no Usuário para obter detalhes sobre a legislação e os padrões de usabilidade). | |
| Gerenciar Dependências | Atributos de Requisitos | À medida que os requisitos de usabilidade e de casos de uso são "descobertos", a importância ou benefício deles deve ser observado. Isso requer consulta aos usuários e outros envolvidos. Outros atributos, como a freqüência de execução de um caso de uso, podem ser captados nesse artefato. |
| Revisar Requisitos | Solicitação de Mudança | Um esforço de desenvolvimento centrado no usuário busca maximizar o envolvimento dos usuários em todas as revisões de requisitos possíveis. |
| Captar um Vocabulário Comum | Glossário | Capta a terminologia comum específica do domínio dos usuários para facilitar a comunicação e o entendimento entre usuários e o restante da equipe de desenvolvimento. |
Várias outras atividades nessa disciplina enfatizam a forma e o design da interface do usuário. São elas:
|
Atividade
|
Artefato |
Conteúdo Relacionado à Usabilidade |
| Modelar a Interface do Usuário |
Classe de Fronteira, Encenação de Caso de Uso |
Essa atividade cria o que geralmente é conhecido como Design Conceitual [FER01]. Essa é a abstração inicial da interface do usuário, captando as principais janelas e caminhos de navegação apresentados ao usuário. Essa atividade enfatiza os casos de uso que orientam o design da interface do usuário. A Encenação de Caso de Uso é uma Realização de Casos de Uso, semelhante à Análise de Caso de Uso. Ela fornece orientações detalhadas sobre como gerar as Classes de Fronteira que compõem a interface do usuário e permite que elas sejam avaliadas percorrendo cenários (descritos em Encenações de Caso de Uso). |
| Criar um Protótipo da Interface do Usuário | Protótipo da Interface do Usuário |
É possível criar três tipos básicos de protótipos: Desenhos (no papel) A principal finalidade de criar um protótipo da interface do usuário é poder expor e testar a funcionalidade e a usabilidade do sistema antes de iniciar realmente o design e o desenvolvimento. Dessa forma, é possível garantir que o sistema correto esteja sendo criado antes de desperdiçar tempo e recursos no desenvolvimento. |
A disciplina Modelagem de Negócios envolve a compreensão do ambiente de negócios no qual os usuários operam.
|
Atividade
|
Artefatos de Modelagem de Negócios |
Conteúdo Relacionado à Usabilidade |
| Definir e Ajustar Metas | Visão do Negócio |
Parte da criação da Visão do Negócio é identificar os envolvidos. Isso inclui as pessoas que interagem com o negócio (clientes e fornecedores), além daqueles que trabalham no negócio - muitos deles são ou serão usuários de sistemas automatizados. Semelhante ao documento Visão em Requisitos, o Template Visão do Negócio capta uma descrição das características dos envolvidos e do ambiente de trabalho do negócio, incluindo formação, conhecimento técnico, responsabilidades, critérios de êxito, produtos liberados, etc. |
| Localizar Atores e Casos de Uso de Negócios, Estruturar o Modelo de Casos de Uso de Negócios |
Modelo de Casos de Uso de Negócios | O modelo de Casos de Uso de Negócios descreve as tarefas (casos de uso de negócios) que os Atores Humanos de Negócios realizam. Ele capta semelhanças e relacionamentos entre Atores de Negócios, usando relacionamentos de generalização. Os casos de uso de negócios são estruturados e relacionados uns com os outros através de relacionamentos de generalização, de extensão e de associação. |
|
|
Os Atores Humanos de Negócios são cliente e/ou fornecedores que interagem com o negócio. Geralmente, eles são (ou se tornam) usuários de sistemas automatizados e, mesmo quando não correspondem a usuários, uma compreensão de suas características oferece um melhor entendimento do ambiente do usuário. O artefato Ator de Negócios inclui os seguintes atributos:
Consulte Diretrizes: Ator de Negócio. |
|
|
|
As tarefas realizadas pelos Atores de Negócios são descritas pelos Casos de Uso de Negócios. Como geralmente estão livres de suposições de tecnologia e enfatizam metas, eles se qualificam como "essenciais" (consulte Conceitos: Design Centrado no Usuário). | |
| Localizar Entidades e Trabalhadores de Negócios |
Modelo de Objeto de Negócios(Modelo de Domínio) |
Geralmente, a modelagem de negócios é usada em um escopo limitado, denominado Modelagem de Domínio. Um modelo de domínio capta os objetos que são importantes no domínio e, conseqüentemente, de interesse e importância para os usuários. Consulte Workshop de Modelagem de Objetos de Negócios, Conceitos: Escopo de Modelagem de Negócios e Detalhamento do Fluxo de Trabalho: Desenvolver um Modelo de Domínio. |
| Localizar Entidades e Trabalhadores de Negócios, Detalhar um Trabalhador de Negócio |
Modelo de Objetos de Negócios (Trabalhador de Negócio) |
Os papéis representados pelas pessoas no negócio são descritos pelos Trabalhadores de Negócios. Os atributos semelhantes aos descritos acima para o Ator de Negócio são capturados. Como os Trabalhadores de Negócios são modelados como classes de UML, a generalização e a associação podem ser usadas para descrever relacionamentos entre Trabalhadores de Negócios. Consulte Diretrizes: Generalização no Modelo de Objetos de Negócios e Diretrizes: Associação no Modelo de Objetos de Negócios. Os relacionamentos entre Atores, Atores de Negócios e Trabalhadores de Negócios são abordados posteriormente em Diretriz: Transição de Modelos de Negócios para Sistemas. |
| Outra | Outro | A maioria dos outros artefatos - como Glossário de Negócios, Regras de Negócios e assim por diante - contribuem para uma compreensão do negócio e, conseqüentemente, para o ambiente do usuário. |
O design da interface do usuário é amplamente abordado pelas atividades Requisitos descritas anteriormente. No entanto, as atividades Análise e Design a seguir são complementares.
|
Atividade
|
Artefato |
Conteúdo Relacionado à Usabilidade |
| Análise de Caso de Uso | Classe de Análise, Classe de Fronteira, Realização de Caso de Uso |
Consulte também: |
| Design da Classe |
Classe de Fronteira |
Essa atividade usa os resultados da modelagem e da criação de protótipo da interface do usuário para projetar classes. Ao contrário dos protótipos, esse não é um trabalho conceitual de interface do usuário que seja descartável; destina-se a representar o design do sistema liberado. Consulte também as seguintes diretrizes: |
A implementação da interface do usuário segue o Fluxo de Trabalho de Implementação geral. Observe que a implementação da interface do usuário geralmente é feita como parte da atividade de design (consulte Diretrizes: Design de Classes em Visual Basic).
O teste de usabilidade, incluindo o teste de desempenho relacionado à usabilidade, deve ser iniciado quando houver moldes ou protótipos executáveis da interface do usuário. O teste deve incluir a verificação dos requisitos de usabilidade e de desempenho captados nas Especificações Suplementares ou como "Requisitos Especiais" na especificação do caso de uso.
Os usuários devem estar bastante envolvidos no Detalhamento do Fluxo de Trabalho: Produto de Teste Beta e no Teste de Usabilidade final durante o Detalhamento do Fluxo de Trabalho: Gerenciar Teste de Aceitação.
O Detalhamento do Fluxo de Trabalho: Desenvolver Material de Suporte inclui o desenvolvimento do material de treinamento e do material de suporte do sistema para garantir que os usuários possam usar o software liberado.
Gerenciamento de Projeto é a arte de balancear objetivos que competem entre si, gerenciar riscos e superar obstáculos para liberar com êxito um produto que atenda às necessidades dos clientes (que pagaram por ele) e dos usuários. Do ponto de vista da engenharia da usabilidade, a atividade mais crítica é Atividade: Definir a Equipe e a Organização do Projeto. Essa atividade define a estrutura da organização, as interfaces externas, os papéis e as responsabilidades. Isso inclui a definição do grau de envolvimento dos usuários no processo de desenvolvimento e determina se os desenvolvedores devem ter experiência em métodos de engenharia de usabilidade.
A disciplina de Ambiente inclui a definição do processo de desenvolvimento que deve ser seguido por um projeto ou por uma organização. A Atividade: Elaborar Caso de Desenvolvimento (Artefato: Caso de Desenvolvimento) define as técnicas de engenharia de usabilidade que serão aplicadas e como os vários artefatos e atividades do RUP serão adaptados para incorporar essas técnicas.
Outra atividade importante é a Atividade: Desenvolver Guia de Interface do Usuário, que cria o Artefato: Guia de Interface do Usuário. Essas diretrizes ajudam a manter a consistência da interface do usuário, que pode ser uma ajuda significativa para a usabilidade. Elas também captam os princípios de usabilidade a serem seguidos, como diretrizes para atalhos, recursos de "desfazer", saídas reconhecidas, interação não-modal, etc.
O ciclo de vida de software do RUP é dividido ao longo do tempo em quatro fases seqüenciais, cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais. Em cada final de fase é executada uma avaliação (Atividade: Revisar Marcos de Ciclo de Vida) para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase.
Dentro de cada fase podem existir várias iterações. Uma iteração é um loop completo de desenvolvimento que resulta em um release (interno ou externo) de um produto executável, um subconjunto do produto final em desenvolvimento, que cresce gradativamente de iteração em iteração até se tornar o sistema final. A usabilidade se beneficia bastante dessa abordagem iterativa. Ela permite que os usuários forneçam feedback antecipado sobre a usabilidade e evita um trabalho que não atenda às necessidades do usuário.
O usuário deve estar envolvido em cada iteração, a fim de refinar requisitos, avaliar conceitos de design e testar/avaliar a usabilidade de cada protótipo de prova de conceito e o sistema em desenvolvimento.
As seções a seguir descrevem os critérios de conclusão da fase relacionada à usabilidade e as principais atividades de cada fase.
Dois dos objetivos-chave da Fase de Iniciação são:
Do ponto de vista da engenharia de usabilidade, isso significa destacar as atividades Requisitos e Modelagem de Negócios relacionadas à:
A fase de Iniciação muitas vezes também é o momento para explorar o design conceitual e a criação de protótipo de "prova de conceito". Isso é verdadeiro quando os principais riscos do projeto estão relacionados às questões de usabilidade e interface do usuário. O teste de usabilidade, incluindo o teste de desempenho relacionado à usabilidade, deve ser iniciado quando houver moldes ou protótipos executáveis da interface do usuário.
Como o RUP é um processo iterativo, os artefatos criados na Iniciação são revisitados e revisados com usuários a fim de gerenciar o escopo e garantir que o sistema em desenvolvimento atenda às necessidades do usuário.
Na Elaboração, o foco é na arquitetura de software - incluindo a arquitetura da interface do usuário. A interface conceitual do usuário é definida, e os elementos críticos e/ou de risco do design da interface do usuário são implementados. As atividades relacionadas à arquitetura de software geralmente se aplicam à interface do usuário - existem projetos desenvolvidos internamente e adquiridos prontos para serem usados que devem ser avaliados, incluindo considerações de reutilização, seleção de mecanismos e padrões, etc.
Essa fase destaca o design e a modelagem de interface do usuário referentes a atividades Requisitos e a atividades de suporte provenientes da disciplina Análise e Design. Implementação e Teste também estão envolvidos, desde que a conclusão da Elaboração precise que um sistema executável seja construído para que possa ser avaliado.
O teste de usabilidade e o teste de desempenho relacionado à usabilidade devem destacar os requisitos de risco captados nas Especificações Suplementares ou como "Requisitos Especiais" na especificação do caso de uso.
Na Construção, o foco é na implementação de mais casos de uso. Isso envolve adicionar à interface do usuário, sem deixar de se manter fiel ao modelo conceitual da interface do usuário e ao Guia de Interface do Usuário. O Teste de Usabilidade continua sendo muito importante à medida que os novos recursos são adicionados.
A seleção da funcionalidade a ser colocada em cada iteração é baseada no valor para os usuários.
O foco na fase de Transição começa a mudar para a disciplina Implantação. Em um esforço de desenvolvimento centrado no usuário, você não deve esperar até a fase de Transição para envolver o usuário. Ele deve permanecer envolvido, principalmente para fornecer feedback. Quando o usuário fica envolvido durante todo o desenvolvimento, o teste beta e de aceitação formal geralmente é reduzido ou não existe. Assim, o feedback
detalhado do usuário e a aprovação ocorrem durante o esforço de desenvolvimento.
O desenvolvimento do material de treinamento e do material de suporte do sistema são finalizados na Transição, mas devem ser iniciados nas fases iniciais, se possível, a fim de permitir o feedback do usuário.
Na Transição, existe um sistema de trabalho que pode ser usado pelos usuários finais. É recomendável planejar pelo menos algumas iterações durante a transição, para que problemas com o release inicial sejam corrigidos e para que o feedback dos principais usuários seja incorporado.
|
Rational Unified Process
|
