Traduzido do Inglês para o Português - www.onlinedoctranslator.

com

34º IEEE Anual

Um método de análise de requisitos baseado em padrões de usabilidade para preencher a lacuna

entre as tarefas do usuário e os recursos do aplicativo

Sang-Hyun Lee, In-Young Ko, Sungwon Kang, Dan-Hyung Lee

Departamento de Engenharia da Informação e Comunicações
Instituto Avançado de Ciência e Tecnologia da Coreia
Daejeon, Coreia do Sul
{jeffapril, iko, sungwon.kang, danlee}@kaist.ac.kr

Abstrato -No desenvolvimento de software, é importante mediar várias preocupações provenientes de UCD) [4]. Ao vincular os métodos ágeis e as práticas de UCD, o Agile-
designers de experiência do usuário (UX) e desenvolvedores de aplicativos. No Agile User-Centered Design UCD pode se adequar melhor e complementar um ao outro,
(Agile-UCD), há uma função especial chamada especialista que se dedica a implementar recursos de preservando tanto os valores básicos quanto as técnicas.
aplicativos e monitorar as experiências do usuário. No entanto, o especialista normalmente tem O Agile-UCD tem principalmente duas trilhas paralelas de
dificuldade em vincular tarefas de usuário a serem acessadas por meio de uma interface de usuário (UI) em
desenvolvimento para designers de UX e desenvolvedores de
entidades de recursos do aplicativo. Além disso, o especialista também pode ter alguns riscos de
aplicativos de forma independente [5]. Essas faixas de
usabilidade incertos que podem resultar na falha em atender a certos critérios de usabilidade e passar nos
desenvolvimento paralelo resultam em funções e atividades
testes de aceitação. Para aliviar essas dificuldades dos especialistas em Agile-UCD, propomos um método
adicionais para fazer a ponte entre as tarefas de desenvolvimento
de análise de requisitos baseado em padrões de usabilidade. Esse método usa representações padronizadas
de designers de UX e desenvolvedores de aplicativos. Portanto,
e comuns da especificação de requisitos para preencher a lacuna entre as tarefas do usuário e os recursos
muitos projetos de desenvolvimento de software baseados em
de aplicativo relacionados de uma interface do usuário. Ele também fornece uma diretriz para permitir que
Agile-UCD aprimoram o papel do especialista em Agile-UCD (AUS)
o especialista reduza os riscos de usabilidade em um estágio inicial, refletindo os fatores de usabilidade dos

padrões de design de interface do usuário para um design de aplicativo. Um estudo de caso foi realizado
para mostrar como os usuários podem especificar efetivamente as tarefas do usuário e os recursos do
aplicativo nos fluxos de trabalho da interface do usuário. Também mostra como é fácil e prático entender
as representações comuns, bem como aplicar aos padrões de usabilidade. Um estudo de caso foi realizado
para mostrar como os usuários podem especificar efetivamente as tarefas do usuário e os recursos do
aplicativo nos fluxos de trabalho da interface do usuário. Também mostra como é fácil e prático entender
as representações comuns, bem como aplicar aos padrões de usabilidade. Um estudo de caso foi realizado
para mostrar como os usuários podem especificar efetivamente as tarefas do usuário e os recursos do
aplicativo nos fluxos de trabalho da interface do usuário. Também mostra como é fácil e prático entender
as representações comuns, bem como aplicar aos padrões de usabilidade.
Palavras-chave – Design Ágil Centrado no Usuário, Especialista, Tarefa
do Usuário, Recurso do Aplicativo, Método de Análise de Requisitos,
Padrão de Usabilidade
eu. euNTRODUÇÃO
No atual desenvolvimento de software em amadurecimento
de aplicativos interativos ricos, há duas coisas a serem
consideradas. Primeiro, a qualidade da experiência do usuário
[1] precisa se tornar um diferencial de aplicação como um fator
chave de sucesso no desenvolvimento de software moderno.
Portanto, o design centrado no usuário (UCD), como um
processo de design complementar utilizando perspectivas
centradas no ser humano, aborda as principais preocupações
de usabilidade para aplicativos de software [2]. Em segundo
lugar, o lançamento rápido dos recursos do aplicativo precisa
ser feito justin-time, atendendo às necessidades em constante
mudança. Portanto, os métodos ágeis, como metodologias de
desenvolvimento de software centradas em recursos, fornecem
uma moda de software funcional fornecendo vários recursos de
aplicação [3]. Mais tarde, ao tentar adicionar experiência do
usuário (UX) e recursos do aplicativo,
que governa e controla as questões acima [6]. No entanto, em
muitas referências sobre estudos de caso Agile-UCD e entrevistas
com AUSs, várias questões na fase de especificação de requisitos do
Agile-UCD foram levantadas [6][7][8][9][10][11]. A maioria desses
problemas é identificada questionando os AUSs sobre seus objetivos
e atividades. Um AUS deve investigar a comunicação e a colaboração
entre designers de UX e desenvolvedores de aplicativos. No entanto,
ele/ela tem dificuldades em informá-los com representações
comuns compreensíveis das tarefas do usuário e recursos do
aplicativo. Além disso, é difícil para o AUS conectar e separar
perfeitamente os recursos do aplicativo das tarefas do usuário por
meio de uma interface do usuário (UI). Apesar do trabalho
habilidoso que os designers de UX realizam, o AUS tem sofrido com
as dificuldades em consolidar diversos fatores de usabilidade das
funcionalidades em estágios iniciais.
Neste artigo, apresentamos um método de análise de requisitos baseado
em padrões de usabilidade para ajudar os AUSs a realizar suas tarefas de
especificação de requisitos. Isso é feito formalizando as representações de
notações estendidas da Unified Modeling Language (UML). Nossa abordagem
também fornece uma diretriz para transformar as tarefas do usuário em um
conjunto de recursos do aplicativo em uma página de interface do usuário e,
em seguida, integrar os resultados da análise de requisitos com fatores de
usabilidade comprovados – propriedades e padrões de usabilidade.
Com um estudo de caso de análise de requisitos
exploratória usando vários AUSs, mostramos neste artigo que
um nível de agilidade e usabilidade pode ser mantido usando o
método de análise de requisitos proposto. Além disso, nossa
avaliação revela que o método de análise de requisitos proposto
preenche as lacunas entre as tarefas do usuário e os recursos
do aplicativo sem degradação das características dos métodos
ágeis e práticas de UCD.
O resto do artigo está organizado da seguinte forma. A Seção II apresenta
trabalhos relacionados. A Seção III apresenta considerações sobre o método
de análise de requisitos baseado em padrões de usabilidade. Dentro

317

Uso licenciado autorizado limitado a: UNIVERSIDADE FEDERAL DE GOIAS. Baixado em 22 de fevereiro de 2022 às 23:37:14 UTC do IEEE Xplore. Restrições aplicadas.
 seção IV, explicamos detalhadamente nosso método proposto. A
Seção V descreve nossos resultados de avaliação e experimento. Por
fim, discutimos a conclusão e possíveis trabalhos futuros na Seção
VI.
II. REXALTADOCORKS
Com o objetivo de preencher as lacunas entre designers de UX e
desenvolvedores de aplicativos para desenvolvimentos rápidos de
software com a consideração de usuários finais, várias técnicas de
modelagem orientada a objetos e padrões de design de interface do
usuário foram tentadas.
Nos campos de Interação Humano-Computador (HCI), com uma
estrutura unificada, a modelagem orientada a objetos para projetos
de interface do usuário tem sido considerada uma abordagem
importante para desenvolver sistemas de software interativos. O
método Wisdom estendeu as notações UML para ajudar designers e
desenvolvedores a compartilhar representações comuns entre si
[12]. Ele suporta semântica compartilhada de comunicação ou
resultados para designers e desenvolvedores. Além disso, é
vantajoso em decompor os trabalhos de desenvolvimento relativos à
análise de tarefas do usuário e análise de tarefas do sistema
aplicativo. No entanto, ele assume que os problemas de arquitetura
só podem ser identificados com equívocos dos requisitos do usuário
pelos desenvolvedores. Portanto, não aplicou os padrões de design
UX com perspectivas arquiteturais de atributos de usabilidade no
estágio inicial da engenharia de requisitos.
A abordagem Outra Dimensão da Informação (ADOI) fornece
várias representações de modelagem que também são extensões de
notações UML para tarefas do usuário e do sistema aplicativo [13]. É
útil para designers de arquitetura decidirem táticas de design de
aplicativos com práticas de UCD. No entanto, a abordagem ADOI
requer a preparação de um modelo de análise considerável. Além
disso, não solicita os pontos de verificação visuais de tarefas do
usuário com alto nível de operações de recursos, apesar de sua
abordagem de métodos simples de análise de modelagem. Além
disso, sem atividades coordenadas de design de usabilidade, ele
aborda e resolve apenas aspectos limitados da usabilidade do
sistema aplicativo.
Na engenharia de software, o contexto extremo de
metodologias voltadas ao usuário surge com entregas de design de
experiência do usuário simples e pequenas, bem como as
informações da biblioteca de padrões. O processo de usabilidade
ágil considera múltiplas perspectivas de design como um Central
Design Record (CDR), que se assemelha à ferramenta de
gerenciamento de requisitos editoriais de texto [14]. No entanto, o
CDR não inclui regulamentos específicos de representações visuais
para feedbacks rápidos. Além disso, não implica explicitamente em
restrições técnicas na automação de processos de negócios. Isso
significa que ele tem diferentes representações de tarefas do
usuário e recursos do aplicativo. Por outro lado, as diretrizes de
funcionalidades de usabilidade auxiliam os desenvolvedores de
aplicativos a determinar se e como os recursos de usabilidade se
aplicam aos subdomínios do aplicativo [15]. Isso leva a melhorar a
usabilidade do aplicativo final a ser implementado pelos
desenvolvedores de aplicativos. No entanto, é difícil alcançar um
entendimento comum entre designers de UX e desenvolvedores de
aplicativos sobre a usabilidade das tarefas do usuário e do sistema.
Além disso, as diretrizes de funcionalidades de usabilidade incluem
318
Uso licenciado autorizado limitado a: UNIVERSIDADE FEDERAL DE GOIAS. Baixado em 22 de fevereiro de 2022 às 23:37:14 UTC do IEEE Xplore. Restrições aplicadas.
uma lista de verificação de riscos e competências de usabilidade, que não é uma lista de verificação de
preenchimento de recursos para tarefas do usuário em uma página de interface do usuário [16].
III. CCONSIDERAÇÕES
Para superar as limitações dos trabalhos relacionados,
desenvolvemos uma técnica de modelagem comum para a análise de
requisitos em Agile-UCD. Nossa abordagem fornece pontos de
verificação visuais da conclusão da tarefa do usuário e usa padrões de
design de interface do usuário na perspectiva da arquitetura de software
na especificação de requisitos.
Tendo formulado representações rendendo a
análise de requisitos padronizados, este artigo aborda uma notação
visual de modelagem ágil que decompõe uma tarefa do usuário nas
entidades do sistema de aplicação em uma página de interface do
usuário. Isso decreta os registros síncronos de recursos de aplicativos
baseados em interface do usuário em uma tarefa de usuário. Além disso,
aplica padrões de design de UI de nível de design de arquitetura nas
tarefas do usuário, o que estabelece os critérios de entrada das
funcionalidades de usabilidade para vários testes de usabilidade.
Com a discussão de uma abordagem de mediação baseada em
modelo, que preenche as lacunas no Agile-UCD entre tarefas do usuário
por designers de UX e recursos de aplicativos por desenvolvedores de
aplicativos. Portanto, a abordagem deste trabalho pode tirar proveito de:
• Aprimoramento da comunicação e
colaboração, tanto internas quanto externas
• O domínio do desenvolvimento funciona facilmente capaz de
quebrar as tarefas do usuário e do sistema de aplicativos
• Flexibilidade dos desenvolvedores de aplicativos para serem
incentivados a tomar iniciativa e não serem obrigados a seguir
os resultados dos designers de UX
• Melhoria e criatividade dos riscos de usabilidade, e gestão
fomentando a competitividade dos critérios de usabilidade
em etapas rápidas e iniciais.
4. UMAAPROXIMAÇÃO
A abordagem neste artigo é principalmente unir as tarefas do
usuário e os recursos do aplicativo. Isso fornece garantia para todas as
partes interessadas e geralmente identifica as tarefas do usuário e as
tarefas relativas do sistema de aplicação [17]. Em seguida, especifica
fluxos de tarefas essenciais de aplicativos interativos. Portanto, é possível
para o AUS traduzir com sucesso as tarefas do usuário e os recursos
relativos do aplicativo em construção UML. Os casos de uso essenciais
são os cenários de linguagem natural de tarefas do usuário e tarefas do
sistema de aplicativos em uma página de interface do usuário. Portanto,
o método de análise de requisitos identifica várias propriedades e
padrões de usabilidade, que são aplicados em recursos de aplicação
formalizados das condições de controle e de contorno. Quando uma
abordagem é nomeada como um método de análise de requisitos
baseado em padrão de usabilidade, é um acoplamento de análise
conjunta entre: uma análise de modelo de notação visual unindo as
tarefas do usuário e as entidades relativas do sistema de aplicação;
ocorre uma análise abstrata de padrões de usabilidade que elicita e
aplica padrões de design de UI de alto nível arquitetural [18].
 Dentro detalhe, a proposto baseado em padrão de usabilidade

O método de análise de requisitos foi dividido em duas atividades de

análise e atividades de subanálise relacionadas. A primeira é a Análise do
Modelo de Link Contextual, que é uma técnica de modelagem de notação
visual que decompõe e vincula tarefas de usuário baseadas em UI e
entidades relativas do sistema. Para identificar e estruturar as tarefas do
usuário e as tarefas do sistema aplicativo, ele possui duas atividades de
subanálise. Primeiro, a Análise de Tarefas do Usuário distingue as tarefas
do usuário dos trechos da interface do usuário. A segunda é a Análise
Interna do Sistema que classifica os recursos do aplicativo
separadamente das tarefas do usuário na Análise da Tarefa do Usuário. A
segunda atividade de análise é a Análise de Padrões de Usabilidade da UI
que é uma elicitação de objetos de usabilidade (ou seja, propriedades e
padrões) pelo framework de usabilidade [19]. A Análise do Padrão de
Usabilidade da IU, então, aplica objetos de usabilidade na Análise do
Modelo de Link Contextual. Este também possui duas atividades de
subanálise, sendo a primeira delas a Análise Interna do Sistema. É uma
atividade que confirma se os recursos de aplicativos identificados podem
ser entrelaçados e são úteis ou não. Em seguida, a segunda subanálise é
a Análise de Estrutura de Usabilidade, que vincula padrões de usabilidade
arquiteturalmente sensíveis às lógicas de recursos do aplicativo e
aspectos externos.
A. Análise do modelo de link contextual
A Análise do Modelo de Link Contextual é um método de
modelagem de comunicação visual formalizado. Ele intermedia
tarefas de desenvolvimento entre designers de UX e
desenvolvedores de aplicativos para capturar elementos de
requisitos significativos. Ele fornece uma especificação de recursos
interativos a serem usados pelos usuários ao invocar a
funcionalidade principal dos recursos do aplicativo. Além disso, tem
o efeito de um driver de viabilidade da avaliação em fase de projeto
do Agile-UCD. A Análise do Modelo de Link Contextual exibe várias
diferenças de requisitos entre as tarefas do usuário e os recursos do
aplicativo. Portanto, torna os recursos mínimos de aplicativos
mensuráveis a partir do contexto de uso nas experiências do
usuário. A Análise do Modelo de Link Contextual identifica e
estrutura as principais operações dos usuários e interações com
funcionalidades relativas, incluindo estilos e técnicas de interação.
Isso pode ser amplamente usado como a consulta de especificação
de requisitos orientada por modelo que cria e simplifica os
requisitos elicitados para designers de UX e desenvolvedores de
aplicativos.
1) Princípios da Análise do Modelo de Link Contextual: A
análise de modelo de link contextual proposta é um novo
Figura 1. Uma dimensão da análise do modelo de link contextual
Com referência a um determinado framework de análise UML,
bem como a introdução de duas dimensões adicionais – as
dimensões de apresentação e diálogo – por Wisdom [12], a Análise
de Modelo de Link Contextual redefine classes e associações de
tarefas do usuário e recursos relativos da aplicação. A Análise do
Modelo de Link Contextual separa a <<Interação>> e <<Limite>> das
interfaces do usuário das tarefas do usuário e do sistema. E então,
ele regula sequências de níveis de tarefa do usuário como <<Task>>
e níveis de tarefa do sistema como <<Control>>. Além disso, a
<<Entidade>> é compartilhada entre as dimensões específicas da
interface do usuário e as dimensões internas do aplicativo. Esta
classe <<Entity>> adia a adaptação do domínio para outros modelos
em níveis mais baixos de abstração. Próximo, o modelo Contextual
Link tem duas associações – <<Communicate>> e <<Subscribe>> -
entre classes interferentes de forma que elas denotam direções de
interação entre classes diretamente relativas. Enquanto duas
associações são usadas com classes inteiras, o << Subscribe
> > tem uma rota de sentido único. Por outro lado, o <<
Comunicar >> tem uma via de mão dupla. Cada classe e
notação foi apresentada na Tabela 1.
TABELA I. CESTEREÓTIPOS DE LASS E ASSOCIAÇÃO DO
CEM TEXTUALeuTINTAMODELUMANÁLISE
Classe Notação Descrição
Usado para modelar a interação entre o
sistema aplicativo e os externos (incluindo
Limite
humanos), o que corresponde ao alto nível
de padrões de usabilidade
Usado para representar a coordenação,
sequenciamento e controle de objetos do
Ao controle
sistema, o que corresponde ao alto nível de
propriedades de usabilidade
Usado para mostrar o nível abstrato de classes de
Entidade recursos do comportamento do domínio lógico
refletindo as tarefas do usuário perduráveis
Usado para representar a estrutura de
diálogo para um usuário com um conjunto significativo
Tarefa
de ações refletindo a realização de uma meta do

modelo UML estendido para acomodar a abrangência das usuário em uma interface de usuário

dimensões de informação, diálogo e apresentação mostradas Usado para modelar o espaço dentro de uma
Interação interface de usuário de um sistema de aplicativo
na Figura 1. Enquanto mantém as separações desejadas de
correspondente às experiências do usuário
preocupações com requisitos, mapeia claramente as etapas de
Usado para denotar a direção da interação
pré-requisito do projeto de arquitetura conceitual modelagem
Comunicar entre as classes. A direção da Comunicação
no desenvolvimento de aplicativos interativos. deve ser de uma ou duas vias
Usado para denotar a direção da interação
entre a classe de origem (assinante) e a
classe de destino (editor); o assinante é
Se inscrever
notificado quando um determinado evento
ocorre em objetos do editor. A direção do
Subscribe é o único caminho

319

Uso licenciado autorizado limitado a: UNIVERSIDADE FEDERAL DE GOIAS. Baixado em 22 de fevereiro de 2022 às 23:37:14 UTC do IEEE Xplore. Restrições aplicadas.
 2) Fluxos de trabalho da análise do modelo de link contextual:
Como a primeira parte do método de análise de requisitos
baseado em padrão de usabilidade, o diagrama de atividades para o
fluxo de trabalho de análise da Análise do Modelo de Link
Contextual é ilustrado na Figura 2. O fluxo superior é a Análise de
Tarefa do Usuário que estrutura o modelo de interação em termos
de classes de tarefas e espaços de interação. É como as classes são
organizadas para suportar a interface do usuário do sistema
aplicativo. Ele é dividido em dois fluxos simultâneos que suportam a
dimensão de diálogo e apresentação das tarefas do usuário e do
sistema aplicativo. O fluxo inferior reflete a Análise Interna do
Sistema e como as classes de análise são organizadas para realizar
os diferentes casos de uso essenciais com histórias de usuários. Ele
facilita a dimensão das informações das tarefas do aplicativo nas
entidades de recursos do aplicativo.
<<Entidade>> classes de análise. Inicialmente, as tarefas e objetos
do sistema de aplicação são extraídos com uma versão leve do
cartão CRC e métodos relativos. A próxima sub-atividade segue para
estruturar e distribuir as classes <<Entity>> identificadas em
estereótipos de análise dando responsabilidades.
B. Análise do padrão de usabilidade da interface do usuário
A Análise de Padrões de Usabilidade da UI é uma forma de capturar
soluções para problemas comuns de usabilidade em um contexto específico.
Tem como objetivo facilitar o entendimento de uma interface e realizar os
trabalhos do sistema de aplicação garantindo alta usabilidade para todos os
stakeholders. Os padrões de design de interface do usuário são boas soluções
para problemas de design de interface de usuário padrão em relação à eficácia
da usabilidade. E garantem estratégias de implementação verificadas de
eficiência de usabilidade. Portanto, os padrões de design da interface do
usuário tornaram-se um método para o AUS usar como uma técnica de
gerenciamento de produtos e processos.

1) Princípios da Análise do Padrão de Usabilidade da IU: A

Análise de Padrões de Usabilidade de UI proposta identifica
padrões de usabilidade de lógicas de sistemas de aplicativos e
aspectos externos relativos no framework de usabilidade. Portanto,
ele aplica propriedades e padrões de usabilidade no modelo de Link
Contextual da Análise Interna do Sistema. A UI Usabilidade Pattern
Analysis refere-se ao framework de usabilidade de propriedades e
padrões de usabilidade, como na Figura 3 [19]. A propriedade de
usabilidade é o conceito de vincular padrões de usabilidade
Figura 2. O diagrama de atividades da Análise do Modelo de Link Contextual
sensíveis à arquitetura aos requisitos considerados como tendo uma
influência direta na lógica de recursos do aplicativo. Além disso, o
A atividade de Análise de Tarefa do Usuário diz respeito
padrão de usabilidade é uma técnica que pode ser aplicada ao
principalmente ao design conceitual externo de um aplicativo, que é
projeto da arquitetura de um sistema aplicativo para atender a uma
responsável pela interface do usuário que suporta as tarefas
necessidade identificada por uma propriedade de usabilidade.
previstas dos usuários. Existem duas sub-atividades nesta Análise
Interna do Sistema: identificar e estruturar as classes de interação -
<<Task>> e <<Interaction>>. O estereótipo da classe <<Task>> é o
elemento do componente de diálogo. E o estereótipo da classe
<<Interaction>> é o elemento do componente de apresentação. Para
identificar as classes <<Task>> e <<Interaction>>, o fluxo de tarefas
essenciais da Análise de Tarefas do Usuário é referido a partir de
casos de uso essenciais baseados em histórias de usuários. A
<<Task>> geralmente é mapeada para as etapas da tarefa nos fluxos
de tarefa. A principal preocupação para a identificação de tarefas do
usuário é distinguir um conjunto de tarefas que suportam os fluxos
de tarefas essenciais, garantindo a robustez e a reutilização das
interfaces do usuário. Em relação ao componente de apresentação,
identificar e estruturar a <<Interação>> é um acordo entre uma
interação do usuário e uma tarefa do usuário das transições. Isso
produz várias versões da usabilidade em relação ao design da
interface do usuário e condições de teste de aceitação com
usabilidade de atributos de qualidade. Figura 3. Os padrões de interface do usuário na análise de padrões de usabilidade da interface do usuário
A atividade de Análise Interna do Sistema facilita a identificação
e estruturação dos requisitos funcionais em um modo das classes A Análise de Padrão de Usabilidade da UI especifica fatores de
<<Entidade>>. Ele avança os desenvolvedores de aplicativos na usabilidade para garantir a alta qualidade das atividades de usabilidade
compreensão e gerenciamento dos trabalhos de implementação do promovidas para designers de UX e desenvolvedores de aplicativos. Além
sistema de aplicativos. Ele se concentra na análise de abstrações de disso, como a maneira comprovada para designers de UX e
conceitos de domínio capturados no fluxo de trabalho de requisitos desenvolvedores de aplicativos, ele avança no gerenciamento de riscos
com adiamento de atributos de qualidade de manipulação. Assim de usabilidade nos estágios iniciais e mitiga os riscos de usabilidade em
como as atividades complementares da Análise de Tarefas do relação aos limites de usabilidade das funcionalidades.
Usuário, a Análise Interna do Sistema tem duas subatividades:
2) Fluxos de trabalho da análise do padrão de usabilidade da interface do usuário:
identificação e estruturação de

320

Uso licenciado autorizado limitado a: UNIVERSIDADE FEDERAL DE GOIAS. Baixado em 22 de fevereiro de 2022 às 23:37:14 UTC do IEEE Xplore. Restrições aplicadas.
 Como uma segunda parte do método de análise de V. EEXEMPLO DOUMAAPROXIMAÇÃO
requisitos baseado em padrão de usabilidade, o diagrama Como exemplo do método de análise de requisitos
de atividades para o fluxo de trabalho de análise da Análise baseado em padrões de usabilidade proposto, um aplicativo
de padrão de usabilidade da interface do usuário é ilustrado simples de reserva de hotel móvel é ilustrado [21]. Embora o
na Figura 5. O fluxo superior é a Análise de sistema interna domínio deste exemplo seja para o aplicativo móvel, é muito
que verifica a tarefa de usuário predefinida entidades para semelhante com o aplicativo Web da reserva do hotel.
saber se podem operar tarefas do sistema de aplicativos. Portanto, um caso de uso essencial do aplicativo de reserva
Também é dividido em duas atividades que reidentificam e de hotel – MakeReservation – é explorado na Tabela II.
reestruturam as entidades de recursos do aplicativo. Então,
o fluxo mais baixo pode refletir os fatores relacionados à
usabilidade (propriedades e padrões de usabilidade). Ao TABELA II. AGENERALESENCIALvocêSECASE DOMOBILEHOTEL
identificar as propriedades de usabilidade pertinentes, a RESERVAÇÃOUMAAPLICAÇÃO
Análise de Estrutura de Usabilidade aplica padrões de
Descrição
design de UI relacionados à usabilidade nos resultados da
Degrau

Análise de Sistema Interno. Ao cumprir a estrutura de 1

O cliente solicita para verificar um quarto de hotel reservado disponível nas

usabilidade, proximidades.
O sistema pesquisa um hotel e mostra um feedback da reserva de
2
hotel disponível.
O cliente seleciona um tipo de quarto de hotel e insere as datas de início e
3
término da estadia.
O sistema informa a disponibilidade para o tipo de quarto nas datas
4
especificadas.
Se um quarto apropriado estiver disponível, o sistema calcula
5 as taxas de depósito e solicita ao cliente que confirme a
reserva.
6 O cliente confirma a reserva de um hotel.
O sistema solicita o pagamento com cartão de crédito e dados
7
pessoais do cliente.
O cliente envia os detalhes de pagamento do cartão de crédito e
8
os dados pessoais do cliente.
Figura 4. O diagrama de atividades da análise de padrões de usabilidade da interface do usuário O sistema cria um novo cliente de reserva no banco de dados de
9
reservas, atribuindo um número de reserva exclusivo.
O Modelo de Link Contextual A análise de notações no O cliente mostra os detalhes da reserva, incluindo um
10
número de reserva.
modelo de análise de requisitos representa o alto nível de
diálogo e aulas de apresentação. Portanto, a Análise do Padrão
De acordo com os fluxos de trabalho do método de abordagem, as
de Usabilidade da UI pode ser mapeada nos estereótipos do
identificações de tarefas do usuário e tarefas do sistema de aplicativos de
modelo de análise, ou seja, <<Control>> e <<Boundary>>. À
objetos por uma página de interface do usuário são precedidas na Figura 5.
medida que as atividades de Análise Interna do Sistema são
Neste momento, as tarefas do usuário em um caso de uso essencial devem ser
concluídas, várias entidades de recursos do aplicativo são
identificadas por uma página de interface do usuário. No domínio de um
validadas ou extraídas recentemente da segunda análise de
aplicativo móvel moderno, uma tarefa é definida como uma única tarefa que
tarefas do sistema do aplicativo. Portanto, o AUS identifica as
pode ser declarada em uma única pergunta ou declaração concisa em uma
classes de atributos <<Control>> e <<Boundary>>. Eles são
página de interface do usuário [21]. Como uma composição de 5 declarações
mapeados intuitivamente a partir do contexto do domínio do
em geral, uma tarefa é claramente combinada nas 5 classes do Modelo de Link
aplicativo e do contexto de uso.
Contextual: Limite-Controle-Entidade-Tarefa-Interação [22].
Após obter a identificação dos níveis de arquitetura das
propriedades e padrões de usabilidade da estrutura de
usabilidade, a Análise de Padrão de Usabilidade da UI aplica
uma propriedade e um padrão de usabilidade nas classes
<<Control>> e <<Boundary>> da Análise de Modelo de Link
Contextual. Neste momento, a propriedade de usabilidade deve
ser confirmada com a Análise do Modelo de Link Contextual de
notações. Isso ocorre porque a propriedade de usabilidade é
capaz de ter conceitos multiplex que são capazes de definir
vários padrões de usabilidade alternativos. O AUS completou a
reação confirmatória da propriedade de usabilidade nas classes
<<Control>>. Em seguida, a análise do padrão de usabilidade da
interface do usuário é finalizada, transformando as classes
<<Boundary>> nos padrões de usabilidade ativados.

Figura 5. Análise do modelo de link contextual (Parte I) para um hotel móvel

pedido de reserva

321

Uso licenciado autorizado limitado a: UNIVERSIDADE FEDERAL DE GOIAS. Baixado em 22 de fevereiro de 2022 às 23:37:14 UTC do IEEE Xplore. Restrições aplicadas.
 Em seguida, a organização (ie estrutura) dos resultados
identificados das tarefas do usuário e do sistema de aplicação é
seguida pela interconexão de cada classe vizinha com
associações relativas – <<Communicate>> ou <<Subscribe>>. Os
resultados estão na Figura 6.
Figura 6. Análise do modelo de link contextual (Parte II) para um hotel móvel
pedido de reserva
Após concluir um conjunto de ações de estrutura na Análise
do Modelo de Link Contextual, a Análise Interna do Sistema na
Análise do Padrão de Usabilidade da UI é executada. Ele valida
as entidades do sistema aplicativo se elas podem ser
desenvolvidas de maneira adequada ou não. Tendo
neutralizado entre as tarefas do usuário e do sistema aplicativo,
as classes <<Entity>> são verificadas quanto às suas viabilidades
na Análise do Modelo de Link Contextual e validadas pela
Análise do Padrão de Usabilidade da UI. Em seguida, é realizada
a rotulagem das classes <<Control>> e <<Boundary>>, sendo
consideradas tarefas do sistema aplicativo.
A Análise do Framework de Usabilidade é a etapa final. O AUS
busca as propriedades de usabilidade em termos de contexto de uso
da classe <<Control>>, o que resulta no padrão de usabilidade com
mapeamento da classe <<Boundary>> na Figura 7. Como já
mencionamos, uma propriedade de usabilidade tem conceitos
multiplex que são capazes de definir vários padrões alternativos de
usabilidade. Portanto, a AUS concluiu o reajuste confirmatório da
propriedade de usabilidade. Em seguida, a análise do padrão de
usabilidade da interface do usuário é concluída, transformando as
classes <<Boundary>> nos padrões de usabilidade.
Figura 7. Análise do padrão de usabilidade da interface do usuário para uma reserva de hotel móvel
inscrição
322
Uso licenciado autorizado limitado a: UNIVERSIDADE FEDERAL DE GOIAS. Baixado em 22 de fevereiro de 2022 às 23:37:14 UTC do IEEE Xplore. Restrições aplicadas.
VI. EAVALIAÇÃO
Usamos 10 AUSs de nível sênior para esta avaliação. 5
especialistas são nativos da trilha de desenvolvimento de
aplicativos; por outro lado, os outros 5 são nativos da trilha de
design UX. Eles têm, em média, experimentado mais de 4,40
anos de práticas de implementação, bem como 4,10 anos de
design de UX. Além disso, os examinandos experimentaram, em
média, projetos Agile-UCD cerca de 2,80 vezes.
Enquanto isso, o exemplo ao longo desta avaliação é baseado
no problema simples do caso de uso essencial de um aplicativo de
leilão móvel ilustrado na Tabela III [23]. Além disso, o caso de uso
essencial é o Bid que é uma situação da vida real onde aplicativos
móveis modernos foram desenvolvidos para suportar trabalhos
cooperativos e interativos entre as tarefas do usuário e os recursos
do aplicativo.
TABELA III. UMANESENCIALvocêSECASE DE AMOBILEUMALEITURA
UMAAPLICAÇÃO
Degrau Descrição
1 O licitante seleciona a opção de lance.
O sistema exibe o lance atual e solicita que o licitante insira um
2
novo lance.
3 O licitante entra no lance.
4 O valor do lance é maior que o valor atual.
5 O licitante torna-se o licitante mais alto atual.
6 O valor do lance se torna o valor do lance mais alto.
7 O sistema atualiza e exibe o lance.
8 O licitante entra no lance.
9 O valor do lance não é maior que o valor atual.
10 O lance cai.
11 O sistema alerta o licitante de um valor muito baixo.
Após o experimento do estudo de caso do aplicativo de leilão
móvel, um questionário de avaliação é utilizado para identificar as
tendências práticas dos experimentadores com uma escala Likert.
Definimos cinco pontos de escala Likert para práticas ágeis, e cada
ponto tem pontuações numéricas diferentes: problema ágil grave
(-4), problema ágil principal (-2), problema ágil menor (0), nenhum
problema ágil (2) , e altamente ágil (4). A escala de cinco pontos da
escala Likert para práticas de UCD tem as mesmas pontuações
numéricas que a de práticas ágeis. As questões estão principalmente
relacionadas com as questões dos objetivos e atividades da AUS a
partir de referências e entrevistas. As questões são derivadas dos
princípios de modelagem ágil [24] e critérios de usabilidade do
processo de funcionalidade [25], que alinha a extensão das
vantagens em nossa abordagem; mencionado acima seção III. C
CONSIDERAÇÃO. Entre nove questões para avaliação, cinco delas, da
Questão 1 até a Questão 5, são para aprender os comportamentos
de agilidade baseados em métodos ágeis. E da pergunta 6 à
pergunta 9, quatro das perguntas devem envolver o comportamento
de usabilidade das práticas de UCD:
• Pergunta 1: Outros AUSs entendem o conteúdo dele? – O
método de análise de requisitos baseado em padrões de
usabilidade promove a participação ativa das partes
interessadas ao ser exibido publicamente. Também
pressupõe uma consciência comum do significado.
• Pergunta 2: É uma representação tão simples quanto os
artefatos de especificação de requisitos? – O método de análise
de requisitos baseado em padrões de usabilidade se aplica
 os artefatos certos para serem usados como a ferramenta
mais simples da análise de requisitos. Além disso, ele descreve
expressões simples para facilitar a comunicação.
• Pergunta 3: Está em conformidade com os padrões UML na
Modelagem Ágil? – O método de análise de requisitos baseado
em padrões de usabilidade é necessário para funcionar para
todas as partes interessadas. Ele define a notação e a
semântica para modelos orientados a objetos comuns
• Pergunta 4: Os designers de UX e os desenvolvedores de
aplicativos entendem o conteúdo? – O método de análise
de requisitos baseado em padrões de usabilidade cria um
conjunto de modos de comunicação para desenvolver uma
visão comum entre designers de UX e desenvolvedores de
aplicativos. Em seguida, promove as avaliações de
usabilidade e implementação orientadas a testes.
• Pergunta 5: É possível conter fatores desnecessários que
excluam as preocupações do usuário? – O método de análise de
requisitos baseado em padrões de usabilidade aumenta a
decisão de sincronizar metáforas de requisitos a partir de
preocupações do usuário. Em seguida, descarta e formaliza os
recursos essenciais do aplicativo de contrato.
• Pergunta 6: Ele define as tarefas do usuário em uma página de interface do
usuário como uma unidade básica? – O método de análise de requisitos baseado
em padrões de usabilidade é intuitivo em termos de visualização de uso, tendo
assim uma baixa barreira de entrada para iniciantes. Ele também explica
facilmente os objetivos das tarefas do usuário em uma página de interface do
usuário.
• Pergunta 7: Ela define objetos de operação do
aplicativo em termos de tarefas do usuário? – O método
de análise de requisitos baseado em padrões de
usabilidade simplifica as sequências de operação do
sistema aplicativo executando tarefas do usuário.
Abrange sequências um tanto complexas do sistema de
aplicação de forma simples.
• Pergunta 8: As tarefas do usuário são facilmente aplicadas
em padrões de usabilidade? – O método de análise de
requisitos baseado em padrões de usabilidade suporta
várias maneiras de fazer execuções de tarefas do usuário.
Além disso, fornece diretrizes de configurações de
usabilidade garantidas.
• Pergunta 9: É possível alternar o design da interface do usuário dos
padrões de usabilidade para os recursos do aplicativo? – O método
de análise de requisitos baseado em padrões de usabilidade faz com
que os recursos do aplicativo reflitam bem os estilos de manipulação
de usabilidade e as necessidades do usuário. Promove as
preocupações de usabilidade no suporte funcional das tarefas do
usuário.
Em seguida, em relação aos problemas das AUS e suas resoluções,
uma avaliação valida as eficiências de modelagem, ou seja, o tempo de
conclusão da modelagem e as conformidades dos comportamentos de
modelagem. Em outras palavras, essa métrica de avaliação foi composta
por quatro medidas de subcategoria: a eficiência do tempo de conclusão
da modelagem; a eficiência da modelagem ágil; a eficiência em fazer a
ponte entre as tarefas do usuário e os recursos do aplicativo; e a
eficiência do padrão de usabilidade.
323
Uso licenciado autorizado limitado a: UNIVERSIDADE FEDERAL DE GOIAS. Baixado em 22 de fevereiro de 2022 às 23:37:14 UTC do IEEE Xplore. Restrições aplicadas.
A. Tempo de Modelagem - Eficiência do Modelo I
O Tempo de Modelagem (ou seja, Eficiência do Modelo I; ME-I) é uma
verificação do tempo de conclusão da modelagem. Como um caso de uso
é geralmente de 5 tarefas de usuário [26], um aplicativo móvel
geralmente tem menos de 10 casos de uso [27]. Neste momento, a
conclusão da modelagem em desenvolvimentos de software Agile leva
normalmente 2,5 horas [28]. Portanto, no Agile-UCD, uma tarefa deve ser
rapidamente analisada e modelada em 3 minutos. E, o tempo de
modelagem do experimento de dez resultados de AUSs são
apresentados na Figura 8.
Figura 8. Resultados da avaliação do Modelo de Eficiência I
Todos os AUSs concluíram com sucesso as tarefas do método de
análise de requisitos baseado em padrões de usabilidade. Eles
especificaram tarefas de usuário e tarefas de sistema corretas. Eles
concluíram que o método de análise de requisitos baseado em padrão de
usabilidade funciona em 2,90 minutos para uma tarefa. Em comparação
com o tempo de modelagem geral na Modelagem Ágil – 3 minutos, o
resultado da avaliação do ME-I indica que o comportamento temporal
deste modelo de análise de requisitos é mais eficiente. Ao final, o modelo
de análise de requisitos proposto satisfez a eficiência de seu
comportamento temporal para que as AUSs o utilizem de forma prática.
No entanto, os resultados da avaliação indicam o fato de que
vários AUSs nativos do designer (ou seja, U1, U2 e U5) estão um
pouco atrás do valor padrão do tempo de modelagem comparado
ao AUSs nativo do desenvolvedor. Os AUSs nativos do designer se
sentiram estranhos com as notações de modelo (e suas ações) da
UML 2.0 estendida. No entanto, espera-se que a torpeza das ações
seja reduzida por meio de treinamento e orientação. Como um dos
AUSs nativos do designer, o U3 AUS foi examinado duas vezes para
esta avaliação em um intervalo de duas semanas. Neste momento, o
resultado do segundo exame do tempo de conclusão da modelagem
(ou seja, 2,00 Minutos/Tarefa) havia sido reduzido em 45% em
comparação com o resultado do primeiro exame (ou seja, 3,67
Minutos/Tarefa).
B. Conformidade da Modelagem Ágil - Eficiência do Modelo II
A Conformidade da Modelagem Ágil (ou seja, Model Efficiency II;
ME-II) é uma validação da modelagem em critérios de agilidade. Ele
resolve o problema de interconexões semânticas mal
compartilhadas entre designers de UX e desenvolvedores de
aplicativos. Considerando o contexto do problema, possui uma
estratégia de valorização da comunicação e colaboração, tanto para
os stakeholders internos como para os externos. Então, ao refletir
sobre a estratégia do problema, o ME-II deve estar relacionado a
vários métodos ágeis.
 Práticas de modelagem - Participação ativa das partes interessadas,
Exibição de modelos publicamente, Aplicação dos artefatos corretos,
Representação simples de modelos, Propriedade coletiva,
Modelagem com outras pessoas e Consideração da testabilidade.
Em seguida, essas práticas são aplicadas nos critérios do ME-II -
Comunicativo, Simples, Padrão e Colaborativo - com as questões 1 a
4. Finalmente, o examinado AUS mediu o quanto a abordagem
proposta aprimora a comunicação e a colaboração para ambos os
designers de UX e desenvolvedores de aplicativos como uma
representação padrão simples.
Dez especialistas votaram no nível de agilidade do
método de análise de requisitos baseado em padrões de
usabilidade. Considerando o significado e o impacto de 4
critérios para o ME-II, oito AUSs, quatro AUSs, seis AUSs e
nove AUSs não classificaram nenhum problema Agile e
altamente Agile para critérios Comunicativo, Simples,
Padrão e Colaborativo. Com a análise detalhada de cada
critério de agilidade do ME-II a partir das pontuações
médias da escala Likert, os critérios comunicativos e
colaborativos foram satisfeitos com o ponto Likerscale de
nenhum problema ágil (ou seja, 2.0). O Agile emite valor
na Figura 9.
Figura 9. Resultados da avaliação da eficiência do Modelo II
Vários AUSs nativos do desenvolvedor (ou seja, A1, A3 e
A4) tiveram dificuldades com os novos trabalhos de
modelagem e consolidação de UML para fazer o artefato.
Além disso, eles consideraram essa abordagem como um
dos requisitos adicionais da engenharia. Eles sugerem que o
método de análise de requisitos baseado em padrões de
usabilidade seja desenvolvido como uma ferramenta com
representações simples, mantendo sua funcionalidade. Em
relação aos critérios padrão, alguns AUSs ficaram confusos
sobre várias notações de estereótipos herdadas. Eles
consideraram as notações UML legadas a serem usadas para
tarefas de aplicativos inteiros, incluindo tarefas de usuário e
tarefas do sistema. Nessa situação, eles pensaram que a
representação recém-ampliada e seus papéis induzem
poucas dificuldades para os trabalhos de modelagem. No
entanto, depois de ser dada uma explicação sobre este
método de abordagem,
C. Conformidade de Transformar Tarefas em Recursos - Eficiência
do Modelo III
A Conformidade de Transformar Tarefas em Recursos (ou seja,
Model Efficiency III; ME-III) é uma validação de modelagem em critérios
de agilidade e usabilidade. Ele resolve um problema de dificuldade de
direcionar recursos de aplicativos priorizados a partir de tarefas do
usuário. Com referência ao essencial do problema, tem um conjunto de
estratégias: domínio do controle do desenvolvimento
324
Uso licenciado autorizado limitado a: UNIVERSIDADE FEDERAL DE GOIAS. Baixado em 22 de fevereiro de 2022 às 23:37:14 UTC do IEEE Xplore. Restrições aplicadas.
tarefas facilmente capazes de dividir as tarefas do usuário e do
sistema; flexibilidade no sentido de que os desenvolvedores de
aplicativos são incentivados a tomar a iniciativa e não são obrigados
a seguir os resultados dos designers de UX. Ao refletir estratégias do
problema, o ME-III deve estar relacionado com duas práticas de
modelagem ágil: Descartar modelos temporários e Formalizar
modelos de contrato. Além disso, abrange as principais práticas do
UCD – Suporte visual de objetivos de tarefas e sequências de
operação para executar uma tarefa. Essas práticas de agilidade e
usabilidade são então aplicadas aos critérios do ME-III – Contrátil,
Tarefa intuitiva e Sequencial, que é baseado nas questões 5 a 7.
Eventualmente, os AUSs examinados inspecionaram o quanto o
método de análise de requisitos baseado em padrões de usabilidade
domina a alocação de tarefas de desenvolvimento facilmente
capazes de quebrar as tarefas do usuário e do sistema de
aplicativos. E eles também validaram como nossa abordagem
incentiva o desenvolvedor de aplicativos a tomar iniciativa nas
preocupações de design de UX e não se sentir obrigado a seguir os
resultados dos designers de UX.
Dez especialistas também foram pesquisados sobre o nível de
agilidade e usabilidade do método de análise de requisitos baseado
em padrões de usabilidade. Para 3 critérios do ME-III, sete AUSs não
classificaram nenhum problema de Agile e altamente Agile para
critérios Contractible. E nove deles deram notas de nenhum
problema de UCD e altamente UCD para critérios intuitivos de
Tarefa. Além disso, sete AUSs avaliaram nenhuma emissão de UCD e
altamente UCD para critérios Sequenciais. Sob a análise do ponto
médio da escala Likert para agilidade ágil e usabilidade UCD por
resultados de pesquisa, o método de análise de requisitos baseado
em padrão de usabilidade foi classificado sem problemas de Agile
ou UCD. E então, este resultado indica isso. O método de análise de
requisitos baseado em padrão de usabilidade tem uma viabilidade
pertinente da modelagem baseada em contrato. Portanto, ele
resolveu a dificuldade de direcionar recursos de aplicativos
priorizados a partir de tarefas do usuário. Por serem validados
especificamente quanto à agilidade e usabilidade no ME-III, os
critérios Contractible e Sequencial apresentam pequenos problemas
no Agile ou UCD, conforme mostrado na Figura 10.
Figura 10. Resultados da avaliação da eficiência do Modelo III
A maioria dos AUSs acha as ações de detalhamento mais fáceis em
comparação com os casos de uso essenciais para especificar e priorizar as
tarefas do usuário e os recursos do aplicativo em uma página de interface do
usuário. No entanto, vários AUSs nativos do desenvolvedor são dispositivos de
decomposição de tarefas muito detalhadas para extrair os fundamentos do
design de detalhes, o que resultou em resultados inúteis para perspectivas de
design de arquitetura de software, além de estar fora de conformidade com o
contrato de desenvolvimento. Para os critérios Sequenciais, alguns AUSs (ou
seja, A2 e A3) reclamaram de tarefas do sistema ontológico que não são
capazes de otimizar a estrutura de
 recursos do aplicativo. Um deles decompôs as tarefas do usuário em
subtarefas e operações relativas. No entanto, ele concordou com o
fato de que os trabalhos de decomposição devem ser impostos
apenas pelos desenvolvedores de aplicativos.
D. Conformidade do Padrão de Usabilidade - Eficiência do Modelo IV
A Conformidade do Padrão de Usabilidade (ou seja, Model
Efficiency IV; ME-IV) é uma validação de modelagem em critérios de
usabilidade. Resolve um problema de altos riscos de usabilidade por
limite de usabilidade de funcionalidade. Em relação ao contexto do
problema, possui uma estratégia de melhoria e criatividade
fomentando a competitividade dos critérios de usabilidade em
etapas rápidas e iniciais. Com a consideração dos problemas, o ME-
IV tem coerência com as práticas centrais da UCD, ou seja, suporte
de interação eficiente e suporte funcional às necessidades do
usuário. Além disso, as práticas voltadas à usabilidade são
empregadas com os critérios do ME-IV (Padrão Executivo e
Transformativo). Os AUSs nativos do desenvolvedor ou nativos do
design realizaram a avaliação de quanto afeta improvisatoriamente
a competitividade dos critérios de usabilidade em domínios de
aplicação turbulentos.
Dez AUSs completaram uma pesquisa de graus de usabilidade sobre
o método de análise de requisitos baseado em padrões de usabilidade.
Com um conjunto de critérios do ME-IV, sete AUSs classificaram nenhum
problema de UCD e altamente UCD para critérios executivos de Padrão. E
oito deles deram notas de nenhum problema de UCD e altamente UCD
para critérios transformativos. Eles avaliaram que essa abordagem tem
várias formas de promoção que fazem com que as tarefas do usuário
sejam executadas com táticas de design bem definidas. Além disso,
fornece diretrizes de configurações de usabilidade garantidas que
tornam os recursos do aplicativo refletidos em estilos de manipulação de
usabilidade.
Ao analisar cada critério de agilidade do ME-IV em detalhes, o critério
executivo do Padrão está muito acima do ponto da escala Liker de
nenhum problema de UCD (ou seja, 2.0). No entanto, os critérios
transformativos têm a questão menor de UCD foi anotado como o 1,80
– uma média de pontos na escala Likert – na Figura 11.
Figura 11. Resultados da avaliação da eficiência do Modelo IV
Alguns dos AUSs nativos do desenvolvedor estão bastante
satisfeitos com a execução do padrão de usabilidade, o que reduz os
insights profundos do design de arquitetura de alto nível, além de
diminuir o risco de usabilidade na fase inicial. Apesar dessas
vantagens, vários AUSs nativos do desenvolvedor têm dificuldade
em obter propriedades de usabilidade a partir dos resultados da
Análise Interna do Sistema na Análise do Modelo de Link Contextual.
Por outro lado, AUSs nativos do designer divulgaram um design de
interface do usuário de dificuldade de padrão de usabilidade para
325
Uso licenciado autorizado limitado a: UNIVERSIDADE FEDERAL DE GOIAS. Baixado em 22 de fevereiro de 2022 às 23:37:14 UTC do IEEE Xplore. Restrições aplicadas.
ser aplicado nas tarefas detalhadas do usuário e nas tarefas do sistema. No
entanto, como eles estão usando padrões de usabilidade universais, eles
esperavam que essa abordagem fosse usada como uma indicação de
informações de tarefas e configurações de usabilidade relativas.
VII. CONCLUSÃO
Os modernos sistemas de software interativos têm sido
operados de perto com as demandas do usuário e o rápido
lançamento de um produto, em vez da complicada tecnologia de
desenvolvimento [28][29]. Essa característica exige que métodos
ágeis e práticas de UCD sejam combinados no Agile-UCD. Neste
momento, o método de análise de requisitos baseado em padrões
de usabilidade proposto torna-se a representação chave dos ricos
desenvolvimentos de software de aplicativos. Ele mostra todas as
partes das responsabilidades do AUS para manter partes coerentes
do design de UX e atividades de desenvolvimento ágil. Devido à
inclusão de Análise de Modelo de Link Contextual e Análise de
Padrões de Usabilidade de UI, nosso método apresenta um método
de especificação de requisitos leve em Agile-UCD abrangendo três
aspectos, como segue:
• Fortaleça a comunicação e a colaboração entre
designers de UX e desenvolvedores de aplicativos
em trilhas paralelas de projetos e desenvolvimentos
de aplicativos
• Desenvolva representações apropriadas de fluxos de trabalho para
tarefas do usuário e do sistema de aplicativos com base na interface do
usuário, definindo um conjunto de notações de modelagem compatíveis
• Considere os critérios de usabilidade orientados ao fluxo de trabalho
no modelo orientado a objetos para garantir a usabilidade das
funcionalidades
Nossa abordagem é complementar ao Agile-UCD que aprimora
a comunicação e a colaboração para todas as partes interessadas.
Ele racionaliza perfeitamente os modos caóticos de interconexões
semânticas entre designers de UX e desenvolvedores de aplicativos.
Além disso, controla a especificação de requisitos que impede o
detalhamento do projeto de software. Isso afeta o AUS,
impulsionando o dispositivo mais comunicativo e colaborativo para
a utilização da engenharia de requisitos. Ao promover uma
linguagem de modelagem orientada a tarefas baseada em interface
do usuário, este documento garante que o desenvolvimento de alta
agilidade progride com representações padronizadas simples. No
entanto, alguns AUSs solicitam uma análise inicial do modelo em
detalhes para dimensões de diálogo e apresentação. Além disso,
outros AUSs revelaram alguma dificuldade com as representações
UML estendidas na realização de trabalhos de modelagem.
Embora nossa abordagem tenha resolvido com sucesso os três
principais problemas do Agile-UCD na fase de especificação de requisitos,
há necessidade de treinamento em modelagem para aplicar
perfeitamente a abordagem nas práticas. Além disso, embora essa
abordagem satisfaça a transformação visual e a expressão das tarefas do
usuário em recursos do aplicativo, algumas das tarefas do usuário
dificilmente devem converter o recurso correto de entidades do
aplicativo. Portanto, o nível de entidades de recursos do aplicativo deve
ser definido em coerência com as tarefas do usuário, bem como com as
tarefas do sistema do aplicativo. Além disso, como definimos o escopo do
Agile-UCD nos requisitos
 especificação, o próprio Agile-UCD define o próximo ciclo de [21] Microsoft Corporation, "Diretrizes de interface de usuário indutivo da Microsoft",
engenharia de requisitos até o momento do término do projeto. artigos técnicos de interface de usuário do Windows, 2001

Portanto, verificações quantitativas de pré-implementação e pós- [22] Max Möllers et al., "Towards Systematic Usabilidade Verification",
CHI2009, ACM 978-1-60558-247-4/09/04, pp. 4645-4650, 2009
implementação em cada ciclo são solicitadas neste trabalho.
Portanto, planejamos investigar para garantir a confiabilidade do [23] H. Motsi, "Aplicativos sem fio para comunidades virtuais de
prática", Tshwane University of Technology, 2004
nosso método em Agile-UCD. Consequentemente, verificações e
[24] SW Ambler, "Lessons in Agility from Internet-Based
validações na pós-implementação poderiam ser aplicadas em
Development", IEEE Software (2002) 0740-7459/02, 2002
práticas reais de projetos.
[25] J. Heo, "Uma estrutura para avaliar a usabilidade de telefones celulares com base
em multi-nível, modelo hierárquico de fatores de usabilidade", Interagindo
com Computadores 21 (2009), pp. 263-275, 2009
VIII. REFERÊNCIAS [26] Mobile Marketing Association, "Mobile Search Use Cases",
[1] R. Beauregard, A. Younkin, P. Corriveau, R. Doherty e E. Salskov, Versão 87, 2007
"Avaliando a qualidade da experiência do usuário", Intel [27] IK Ibrahim, "Agent-Based Mobile Auctions: The Flea Market Scenario", Conferência
Technology Journal Vol.11 Issue 1, 2007 Internacional de Pesquisa sobre Inovações em Tecnologia da Informação (IIT2004),
[2] Z. Hussain et al., "Agile User-Centered Design Applied to a Mobile universidade dos Emirados Árabes Unidos, pp. 89-98, 2004
Multimedia Streaming Application", USAB 2008, LNCS 5298, pp. [28] SW Ambler, "Modelagem ágil: Práticas eficazes para programação
313-330, 2008. eXtreme e o processo unificado", ISBN: 0-471-20282-7, Wiley & Sons,
[3] P. Abrahamsson et al., "Métodos de desenvolvimento de software ágil Ltd, 2003
- Revisão e Análise", ESPOO 2002, VTT Electronics, ISBN [29] Z. Hussain, A. Holzinger e W. Slany, "Current State of Agile User-
951-38-6010-8, 2002 Centered Design: A Survey", USAB2009, LNCS5889, Springer
[4] Z. Hussain, et al., "Investigating Agile User-Centered Design in 2009
Practice: A Grounded Theory Perspective", USAB2009, LNCS 5889
pp.279-289, 2009
[5] L. Miller e D. Sy, "Agile User Experience SIG", CHI2009, ACM
978-1-60558-247-4/09/04, pp. 2751-2754, 2009
[6] D. Fox, J. Sillito e F. Maurer, "Métodos ágeis e design centrado no
usuário: como essas duas metodologias estão sendo integradas
com sucesso na indústria", Agile 2008 Conference, IEEE
978-0-7695-3321- 08/06, 2008
[7] J. Dickinson e D. Kumana, "Agile and UCD: Building the right
thing, the right way", 2009
[8] SW Ambler, "Adaptando a usabilidade em projetos de desenvolvimento de software ágil",
Amadurecimento de usabilidade, Springer, Londres, 2008

[9] J. Dickinson e D. Kumana, "Getting Agile with User-Centered Design:

Create software users can't live without", StickyMinds, 2008
[10] M. Budwing, S. Jeong e K. Kelkar, "When User Experience Met
Agile: A Case Study", CHI2009, ACM, 2009
[11] M. Federoff e C. Courage, "Successful User Experience in an Agile
Enterprise Environment", Salesforce.com, HCII2009, 2009
[12] J. Belenguer et al., "HCI Designers and Engineers: It is possible to
work together?", IFIP2003 - Closing the Gap: Software Engineering
and Human-Computer Interaction, pp.20-25, 2003
[13] DNJ Nunes, "Object Modeling for User-Centered Development and
User Interface Design: The Wisdom Approach", Universidade da
Madeira, 2001
[14] Q. Hua et al., "A UCD Method for Modeling Software Architecture",
IPSI, 2002
[15] JC Lee e DS McCrickard, "Towards Extreme(ly) Usable Software:
Explorando Tensões Entre Usabilidade e Desenvolvimento de
Software Ágil" AGILE 2007, ISBN:0-7695-2872-4, pp. 59-71, 2007
[16] N. Juristo et al., "Guidelines for Eliciting Usabilidade Functionalities",
IEEE Transactions on Software Engineering, Vol. 33, nº 11, 2007
[17] Ahmed Seffah , Taleb Mohamed , Halima Habieb-Mammar , Alain Abran,
Reconciliando usabilidade e arquitetura de sistemas interativos usando
padrões, Journal of Systems and Software, v.81 n.11, p.1845-1852,
novembro de 2008
[18] E. Folmer, M. Welie e J. Bosch, "Padrões de ponte: Uma abordagem
para preencher lacunas entre SE e HCI", Tecnologia da Informação e
Software 48 (2006) pp.69-89, 2005
[19] E. Folmer, J. Gurp e J. Bosch, "Análise de arquitetura de software de
usabilidade", Universidade de Groningen, 2005
[20] P. Ng, "Buscando Cenários de Casos de Uso", The Rational Edge,
Rational Software 2003, 2003

326

Uso licenciado autorizado limitado a: UNIVERSIDADE FEDERAL DE GOIAS. Baixado em 22 de fevereiro de 2022 às 23:37:14 UTC do IEEE Xplore. Restrições aplicadas.