Universidade de Brasiacutelia - UnBFaculdade UnB Gama - FGA
Engenharia de Software
Processo de Design de Interaccedilatildeo Orientado aMeacutetricas
Autora Jessica SuzukiOrientadora Professora Dra Edna Dias Canedo
Brasiacutelia DF2017
Jessica Suzuki
Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Monografia submetida ao curso de graduaccedilatildeoem (Engenharia de Software) da Universi-dade de Brasiacutelia como requisito parcial paraobtenccedilatildeo do Tiacutetulo de Bacharel em (Enge-nharia de Software)
Universidade de Brasiacutelia - UnB
Faculdade UnB Gama - FGA
Orientador Professora Dra Edna Dias Canedo
Brasiacutelia DF2017
Jessica SuzukiProcesso de Design de Interaccedilatildeo Orientado a Meacutetricas Jessica Suzuki ndash Bra-
siacutelia DF 2017-79 p il (algumas color) 30 cm
Orientador Professora Dra Edna Dias Canedo
Trabalho de Conclusatildeo de Curso ndash Universidade de Brasiacutelia - UnBFaculdade UnB Gama - FGA 20171 Design de Interaccedilatildeo 2 Interaccedilatildeo Humano-Computador 3 Processo Orien-
tado a Meacutetricas 4 Processo de Design de Interaccedilatildeo 5 Processo de UsabilidadeI Professora Dra Edna Dias Canedo II Universidade de Brasiacutelia III FaculdadeUnB Gama IV Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
CDU 021410056
Jessica Suzuki
Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Monografia submetida ao curso de graduaccedilatildeoem (Engenharia de Software) da Universi-dade de Brasiacutelia como requisito parcial paraobtenccedilatildeo do Tiacutetulo de Bacharel em (Enge-nharia de Software)
Trabalho aprovado Brasiacutelia DF 26 de Junho de 2017
Professora Dra Edna Dias CanedoOrientador
Professora MsC Cristiane SoaresRamos FGAConvidado 1
Professor MsC Ricardo Ajax DiasKosloski FGA
Convidado 2
Brasiacutelia DF2017
Agradecimentos
Primeiramente eu gostaria de agradecer agrave Deus por ter me dado a oportunidadede estudar na UnB foi ele quem me deu forccedila e sauacutede para chegar ateacute aqui Depois delevem a pessoa mais importante na minha vida que sempre apoiou os meus estudos e fez opossiacutevel e impossiacutevel para me ajudar esta eacute a minha matildee Sheila Guedes Pereira SuzukiGostaria de agradecer tambeacutem toda a minha famiacutelia que de alguma forma me ajudounessa etapa da vida fornecendo todo suporte necessaacuterio
Quero deixar meus sinceros agradecimentos ao meu namorado Danilo FeitozaMelo por ter passado ao meu lado por vaacuterios momentos difiacuteceis durante a minha gradu-accedilatildeo e principalmente pela dedicaccedilatildeo em sempre me ajudar
Por fim e natildeo menos importante agradeccedilo a minha orientadora Edna Dias Canedoe a colaboradora Fabiana Freitas Mendes por sempre me dar auxiacutelio e suporte durante aexecuccedilatildeo desse trabalho
ResumoA qualidade de Software cada vez mais se expande para aleacutem do coacutedigo visto que osaspectos perceptiacuteveis pelo usuaacuterio tambeacutem devem ser considerados Com o intuito decapturar esses aspectos a aacuterea de conhecimento de Design de Interaccedilatildeo eacute estudada nadisciplina de Interaccedilatildeo Humano-Computador (IHC) Para aplicar os conceitos dessa disci-plina existem procedimentos que devem ser respeitados formando entatildeo um processo Aqualidade de software pode ser avaliada durante o processo por meio de meacutetricas Nestecontexto este trabalho propotildee um processo de design de interaccedilatildeo orientado a meacutetricasutilizando a metodologia de revisatildeo de literatura para definir um processo como base Porfim um questionaacuterio foi aplicado com conhecedores de IHC eou processos no intuito devalidar e melhorar o processo proposto
Palavras-chaves Design de interaccedilatildeo Interaccedilatildeo Humano-Computador Processo orien-tado a meacutetricas Processo de design de interaccedilatildeo Processo de usabilidade
AbstractThe Software quality expands beyond the code the aspects noticeable for the user mustbe considered In order to capture these aspects there is the area of Interaction Designwhich is studied in the discipline Human-Computer Interaction (HCI) To apply conceptsof this discipline there are procedures that must be respected thus forming a processThe software quality could be evaluated during the process for example using metricsIn this context this project purposes a process of design interaction oriented by metricsusing the methodology of literature review to define a process for support Finally theresults were collected from a questionnaire applied with knowing of HCI andor processto validate and improve the proposed process
Key-words Interaction design Human-Computer Interaction Process oriented by met-rics Interaction design process Usability process
Lista de ilustraccedilotildees
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos in-terdisciplinares que se preocupam com o design de interaccedilatildeo (ROGERSSHARP PREECE 2013) 19
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009) 23Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993) 24Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999) 25Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011) 30Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de
(ISO25010 2011) 32Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida
de (ISO25010 2011) 33Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999) 34Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas 38Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo 40Figura 11 ndash Graacutefico de Conhecimento em IHC 63Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida 63Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software 64Figura 14 ndash Graacutefico de Conhecimento sobre GQM 65Figura 15 ndash Processo estaacute modularizado 66Figura 16 ndash Graacutefico sobre Entendimento do Processo 66Figura 17 ndash Versatildeo 1 do Processo 74Figura 18 ndash Versatildeo 2 do Processo 75Figura 19 ndash Rastreabilidade do GQM Definido 78
Lista de tabelas
Tabela 1 ndash Trabalhos selecionados para Coleta de dados 28Tabela 2 ndash Niacutevel de detalhamento dos trabalhos 29Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT
1999) 35Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999) 35Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio 41Tabela 6 ndash Anaacutelise de Tarefas 43Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma 44Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade 46Tabela 9 ndash Planejamento do GQM 47Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees 48Tabela 11 ndash Engenharia do Trabalho 49Tabela 12 ndash Projeto do Modelo Conceitual 50Tabela 13 ndash Prototipagem do Modelo Conceitual 51Tabela 14 ndash Definiccedilatildeo de Meacutetricas 52Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual 53Tabela 16 ndash Anaacutelise dos Dados Coletados 54Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela 55Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela 56Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 57Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio 58Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado 59Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil 67Tabela 23 ndash Dados coletados sobre o Processo 68Tabela 24 ndash Dados coletados sobre o Processo 69Tabela 25 ndash Definiccedilatildeo do Time 76Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout
1999) 76Tabela 27 ndash Abstraction Sheet 77Tabela 28 ndash Meacutetricas 79
Lista de abreviaturas e siglas
COBIT Control Objectives for Information and Related Technologies
FGA Faculdade do Gama
GQM Goal Questions Metrics
IEC International Electrotechnical Commission
IHC Interaccedilatildeo Humano-Computador
ISO International Organization for Standardization
RACI Responsible Accountable Consulted and Informed
SQuaRE Systems and software Quality Requirements and Evaluation
TI Tecnologia da Informaccedilatildeo
UnB Universidade de Brasiacutelia
Sumaacuterio
1 INTRODUCcedilAtildeO 1311 Contextualizaccedilatildeo 1312 Problematizaccedilatildeo 14121 Formulaccedilatildeo do Problema 14122 Soluccedilatildeo do Problema 1513 Objetivos 15131 Objetivo Geral 15132 Objetivos Especiacuteficos 1514 Metodologia 15141 Revisatildeo Literaacuteria 16142 Definiccedilatildeo do Processo 16143 Avaliaccedilatildeo do Processo 1615 Organizaccedilatildeo do Trabalho 16
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 1821 Design de Interaccedilatildeo e IHC 18211 Definiccedilotildees 18212 Metas do Design de Interaccedilatildeo e IHC 202121 Metas de Usabilidade 202122 Metas decorrentes da Experiecircncia do Usuaacuterio 202123 Heuriacutesticas de Nielsen 2122 Diferenccedila entre Processo e Ciclo de Vida 2223 Processos de Design de Interaccedilatildeo 2524 Qualidade de Software 29241 SQuaRE 302411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade 312412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade 312413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade 312414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade 312415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade 32242 Caracteriacutesticas de Qualidade de Software 32243 Goal Question Metric (GQM) 34
3 ESPECIFICACcedilAtildeO DO PROCESSO 3731 Objetivo do Processo 3732 Objetivo das Fases 39
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Jessica Suzuki
Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Monografia submetida ao curso de graduaccedilatildeoem (Engenharia de Software) da Universi-dade de Brasiacutelia como requisito parcial paraobtenccedilatildeo do Tiacutetulo de Bacharel em (Enge-nharia de Software)
Universidade de Brasiacutelia - UnB
Faculdade UnB Gama - FGA
Orientador Professora Dra Edna Dias Canedo
Brasiacutelia DF2017
Jessica SuzukiProcesso de Design de Interaccedilatildeo Orientado a Meacutetricas Jessica Suzuki ndash Bra-
siacutelia DF 2017-79 p il (algumas color) 30 cm
Orientador Professora Dra Edna Dias Canedo
Trabalho de Conclusatildeo de Curso ndash Universidade de Brasiacutelia - UnBFaculdade UnB Gama - FGA 20171 Design de Interaccedilatildeo 2 Interaccedilatildeo Humano-Computador 3 Processo Orien-
tado a Meacutetricas 4 Processo de Design de Interaccedilatildeo 5 Processo de UsabilidadeI Professora Dra Edna Dias Canedo II Universidade de Brasiacutelia III FaculdadeUnB Gama IV Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
CDU 021410056
Jessica Suzuki
Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Monografia submetida ao curso de graduaccedilatildeoem (Engenharia de Software) da Universi-dade de Brasiacutelia como requisito parcial paraobtenccedilatildeo do Tiacutetulo de Bacharel em (Enge-nharia de Software)
Trabalho aprovado Brasiacutelia DF 26 de Junho de 2017
Professora Dra Edna Dias CanedoOrientador
Professora MsC Cristiane SoaresRamos FGAConvidado 1
Professor MsC Ricardo Ajax DiasKosloski FGA
Convidado 2
Brasiacutelia DF2017
Agradecimentos
Primeiramente eu gostaria de agradecer agrave Deus por ter me dado a oportunidadede estudar na UnB foi ele quem me deu forccedila e sauacutede para chegar ateacute aqui Depois delevem a pessoa mais importante na minha vida que sempre apoiou os meus estudos e fez opossiacutevel e impossiacutevel para me ajudar esta eacute a minha matildee Sheila Guedes Pereira SuzukiGostaria de agradecer tambeacutem toda a minha famiacutelia que de alguma forma me ajudounessa etapa da vida fornecendo todo suporte necessaacuterio
Quero deixar meus sinceros agradecimentos ao meu namorado Danilo FeitozaMelo por ter passado ao meu lado por vaacuterios momentos difiacuteceis durante a minha gradu-accedilatildeo e principalmente pela dedicaccedilatildeo em sempre me ajudar
Por fim e natildeo menos importante agradeccedilo a minha orientadora Edna Dias Canedoe a colaboradora Fabiana Freitas Mendes por sempre me dar auxiacutelio e suporte durante aexecuccedilatildeo desse trabalho
ResumoA qualidade de Software cada vez mais se expande para aleacutem do coacutedigo visto que osaspectos perceptiacuteveis pelo usuaacuterio tambeacutem devem ser considerados Com o intuito decapturar esses aspectos a aacuterea de conhecimento de Design de Interaccedilatildeo eacute estudada nadisciplina de Interaccedilatildeo Humano-Computador (IHC) Para aplicar os conceitos dessa disci-plina existem procedimentos que devem ser respeitados formando entatildeo um processo Aqualidade de software pode ser avaliada durante o processo por meio de meacutetricas Nestecontexto este trabalho propotildee um processo de design de interaccedilatildeo orientado a meacutetricasutilizando a metodologia de revisatildeo de literatura para definir um processo como base Porfim um questionaacuterio foi aplicado com conhecedores de IHC eou processos no intuito devalidar e melhorar o processo proposto
Palavras-chaves Design de interaccedilatildeo Interaccedilatildeo Humano-Computador Processo orien-tado a meacutetricas Processo de design de interaccedilatildeo Processo de usabilidade
AbstractThe Software quality expands beyond the code the aspects noticeable for the user mustbe considered In order to capture these aspects there is the area of Interaction Designwhich is studied in the discipline Human-Computer Interaction (HCI) To apply conceptsof this discipline there are procedures that must be respected thus forming a processThe software quality could be evaluated during the process for example using metricsIn this context this project purposes a process of design interaction oriented by metricsusing the methodology of literature review to define a process for support Finally theresults were collected from a questionnaire applied with knowing of HCI andor processto validate and improve the proposed process
Key-words Interaction design Human-Computer Interaction Process oriented by met-rics Interaction design process Usability process
Lista de ilustraccedilotildees
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos in-terdisciplinares que se preocupam com o design de interaccedilatildeo (ROGERSSHARP PREECE 2013) 19
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009) 23Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993) 24Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999) 25Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011) 30Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de
(ISO25010 2011) 32Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida
de (ISO25010 2011) 33Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999) 34Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas 38Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo 40Figura 11 ndash Graacutefico de Conhecimento em IHC 63Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida 63Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software 64Figura 14 ndash Graacutefico de Conhecimento sobre GQM 65Figura 15 ndash Processo estaacute modularizado 66Figura 16 ndash Graacutefico sobre Entendimento do Processo 66Figura 17 ndash Versatildeo 1 do Processo 74Figura 18 ndash Versatildeo 2 do Processo 75Figura 19 ndash Rastreabilidade do GQM Definido 78
Lista de tabelas
Tabela 1 ndash Trabalhos selecionados para Coleta de dados 28Tabela 2 ndash Niacutevel de detalhamento dos trabalhos 29Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT
1999) 35Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999) 35Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio 41Tabela 6 ndash Anaacutelise de Tarefas 43Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma 44Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade 46Tabela 9 ndash Planejamento do GQM 47Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees 48Tabela 11 ndash Engenharia do Trabalho 49Tabela 12 ndash Projeto do Modelo Conceitual 50Tabela 13 ndash Prototipagem do Modelo Conceitual 51Tabela 14 ndash Definiccedilatildeo de Meacutetricas 52Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual 53Tabela 16 ndash Anaacutelise dos Dados Coletados 54Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela 55Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela 56Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 57Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio 58Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado 59Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil 67Tabela 23 ndash Dados coletados sobre o Processo 68Tabela 24 ndash Dados coletados sobre o Processo 69Tabela 25 ndash Definiccedilatildeo do Time 76Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout
1999) 76Tabela 27 ndash Abstraction Sheet 77Tabela 28 ndash Meacutetricas 79
Lista de abreviaturas e siglas
COBIT Control Objectives for Information and Related Technologies
FGA Faculdade do Gama
GQM Goal Questions Metrics
IEC International Electrotechnical Commission
IHC Interaccedilatildeo Humano-Computador
ISO International Organization for Standardization
RACI Responsible Accountable Consulted and Informed
SQuaRE Systems and software Quality Requirements and Evaluation
TI Tecnologia da Informaccedilatildeo
UnB Universidade de Brasiacutelia
Sumaacuterio
1 INTRODUCcedilAtildeO 1311 Contextualizaccedilatildeo 1312 Problematizaccedilatildeo 14121 Formulaccedilatildeo do Problema 14122 Soluccedilatildeo do Problema 1513 Objetivos 15131 Objetivo Geral 15132 Objetivos Especiacuteficos 1514 Metodologia 15141 Revisatildeo Literaacuteria 16142 Definiccedilatildeo do Processo 16143 Avaliaccedilatildeo do Processo 1615 Organizaccedilatildeo do Trabalho 16
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 1821 Design de Interaccedilatildeo e IHC 18211 Definiccedilotildees 18212 Metas do Design de Interaccedilatildeo e IHC 202121 Metas de Usabilidade 202122 Metas decorrentes da Experiecircncia do Usuaacuterio 202123 Heuriacutesticas de Nielsen 2122 Diferenccedila entre Processo e Ciclo de Vida 2223 Processos de Design de Interaccedilatildeo 2524 Qualidade de Software 29241 SQuaRE 302411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade 312412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade 312413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade 312414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade 312415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade 32242 Caracteriacutesticas de Qualidade de Software 32243 Goal Question Metric (GQM) 34
3 ESPECIFICACcedilAtildeO DO PROCESSO 3731 Objetivo do Processo 3732 Objetivo das Fases 39
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Jessica SuzukiProcesso de Design de Interaccedilatildeo Orientado a Meacutetricas Jessica Suzuki ndash Bra-
siacutelia DF 2017-79 p il (algumas color) 30 cm
Orientador Professora Dra Edna Dias Canedo
Trabalho de Conclusatildeo de Curso ndash Universidade de Brasiacutelia - UnBFaculdade UnB Gama - FGA 20171 Design de Interaccedilatildeo 2 Interaccedilatildeo Humano-Computador 3 Processo Orien-
tado a Meacutetricas 4 Processo de Design de Interaccedilatildeo 5 Processo de UsabilidadeI Professora Dra Edna Dias Canedo II Universidade de Brasiacutelia III FaculdadeUnB Gama IV Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
CDU 021410056
Jessica Suzuki
Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Monografia submetida ao curso de graduaccedilatildeoem (Engenharia de Software) da Universi-dade de Brasiacutelia como requisito parcial paraobtenccedilatildeo do Tiacutetulo de Bacharel em (Enge-nharia de Software)
Trabalho aprovado Brasiacutelia DF 26 de Junho de 2017
Professora Dra Edna Dias CanedoOrientador
Professora MsC Cristiane SoaresRamos FGAConvidado 1
Professor MsC Ricardo Ajax DiasKosloski FGA
Convidado 2
Brasiacutelia DF2017
Agradecimentos
Primeiramente eu gostaria de agradecer agrave Deus por ter me dado a oportunidadede estudar na UnB foi ele quem me deu forccedila e sauacutede para chegar ateacute aqui Depois delevem a pessoa mais importante na minha vida que sempre apoiou os meus estudos e fez opossiacutevel e impossiacutevel para me ajudar esta eacute a minha matildee Sheila Guedes Pereira SuzukiGostaria de agradecer tambeacutem toda a minha famiacutelia que de alguma forma me ajudounessa etapa da vida fornecendo todo suporte necessaacuterio
Quero deixar meus sinceros agradecimentos ao meu namorado Danilo FeitozaMelo por ter passado ao meu lado por vaacuterios momentos difiacuteceis durante a minha gradu-accedilatildeo e principalmente pela dedicaccedilatildeo em sempre me ajudar
Por fim e natildeo menos importante agradeccedilo a minha orientadora Edna Dias Canedoe a colaboradora Fabiana Freitas Mendes por sempre me dar auxiacutelio e suporte durante aexecuccedilatildeo desse trabalho
ResumoA qualidade de Software cada vez mais se expande para aleacutem do coacutedigo visto que osaspectos perceptiacuteveis pelo usuaacuterio tambeacutem devem ser considerados Com o intuito decapturar esses aspectos a aacuterea de conhecimento de Design de Interaccedilatildeo eacute estudada nadisciplina de Interaccedilatildeo Humano-Computador (IHC) Para aplicar os conceitos dessa disci-plina existem procedimentos que devem ser respeitados formando entatildeo um processo Aqualidade de software pode ser avaliada durante o processo por meio de meacutetricas Nestecontexto este trabalho propotildee um processo de design de interaccedilatildeo orientado a meacutetricasutilizando a metodologia de revisatildeo de literatura para definir um processo como base Porfim um questionaacuterio foi aplicado com conhecedores de IHC eou processos no intuito devalidar e melhorar o processo proposto
Palavras-chaves Design de interaccedilatildeo Interaccedilatildeo Humano-Computador Processo orien-tado a meacutetricas Processo de design de interaccedilatildeo Processo de usabilidade
AbstractThe Software quality expands beyond the code the aspects noticeable for the user mustbe considered In order to capture these aspects there is the area of Interaction Designwhich is studied in the discipline Human-Computer Interaction (HCI) To apply conceptsof this discipline there are procedures that must be respected thus forming a processThe software quality could be evaluated during the process for example using metricsIn this context this project purposes a process of design interaction oriented by metricsusing the methodology of literature review to define a process for support Finally theresults were collected from a questionnaire applied with knowing of HCI andor processto validate and improve the proposed process
Key-words Interaction design Human-Computer Interaction Process oriented by met-rics Interaction design process Usability process
Lista de ilustraccedilotildees
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos in-terdisciplinares que se preocupam com o design de interaccedilatildeo (ROGERSSHARP PREECE 2013) 19
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009) 23Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993) 24Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999) 25Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011) 30Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de
(ISO25010 2011) 32Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida
de (ISO25010 2011) 33Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999) 34Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas 38Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo 40Figura 11 ndash Graacutefico de Conhecimento em IHC 63Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida 63Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software 64Figura 14 ndash Graacutefico de Conhecimento sobre GQM 65Figura 15 ndash Processo estaacute modularizado 66Figura 16 ndash Graacutefico sobre Entendimento do Processo 66Figura 17 ndash Versatildeo 1 do Processo 74Figura 18 ndash Versatildeo 2 do Processo 75Figura 19 ndash Rastreabilidade do GQM Definido 78
Lista de tabelas
Tabela 1 ndash Trabalhos selecionados para Coleta de dados 28Tabela 2 ndash Niacutevel de detalhamento dos trabalhos 29Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT
1999) 35Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999) 35Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio 41Tabela 6 ndash Anaacutelise de Tarefas 43Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma 44Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade 46Tabela 9 ndash Planejamento do GQM 47Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees 48Tabela 11 ndash Engenharia do Trabalho 49Tabela 12 ndash Projeto do Modelo Conceitual 50Tabela 13 ndash Prototipagem do Modelo Conceitual 51Tabela 14 ndash Definiccedilatildeo de Meacutetricas 52Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual 53Tabela 16 ndash Anaacutelise dos Dados Coletados 54Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela 55Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela 56Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 57Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio 58Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado 59Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil 67Tabela 23 ndash Dados coletados sobre o Processo 68Tabela 24 ndash Dados coletados sobre o Processo 69Tabela 25 ndash Definiccedilatildeo do Time 76Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout
1999) 76Tabela 27 ndash Abstraction Sheet 77Tabela 28 ndash Meacutetricas 79
Lista de abreviaturas e siglas
COBIT Control Objectives for Information and Related Technologies
FGA Faculdade do Gama
GQM Goal Questions Metrics
IEC International Electrotechnical Commission
IHC Interaccedilatildeo Humano-Computador
ISO International Organization for Standardization
RACI Responsible Accountable Consulted and Informed
SQuaRE Systems and software Quality Requirements and Evaluation
TI Tecnologia da Informaccedilatildeo
UnB Universidade de Brasiacutelia
Sumaacuterio
1 INTRODUCcedilAtildeO 1311 Contextualizaccedilatildeo 1312 Problematizaccedilatildeo 14121 Formulaccedilatildeo do Problema 14122 Soluccedilatildeo do Problema 1513 Objetivos 15131 Objetivo Geral 15132 Objetivos Especiacuteficos 1514 Metodologia 15141 Revisatildeo Literaacuteria 16142 Definiccedilatildeo do Processo 16143 Avaliaccedilatildeo do Processo 1615 Organizaccedilatildeo do Trabalho 16
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 1821 Design de Interaccedilatildeo e IHC 18211 Definiccedilotildees 18212 Metas do Design de Interaccedilatildeo e IHC 202121 Metas de Usabilidade 202122 Metas decorrentes da Experiecircncia do Usuaacuterio 202123 Heuriacutesticas de Nielsen 2122 Diferenccedila entre Processo e Ciclo de Vida 2223 Processos de Design de Interaccedilatildeo 2524 Qualidade de Software 29241 SQuaRE 302411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade 312412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade 312413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade 312414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade 312415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade 32242 Caracteriacutesticas de Qualidade de Software 32243 Goal Question Metric (GQM) 34
3 ESPECIFICACcedilAtildeO DO PROCESSO 3731 Objetivo do Processo 3732 Objetivo das Fases 39
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Jessica Suzuki
Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Monografia submetida ao curso de graduaccedilatildeoem (Engenharia de Software) da Universi-dade de Brasiacutelia como requisito parcial paraobtenccedilatildeo do Tiacutetulo de Bacharel em (Enge-nharia de Software)
Trabalho aprovado Brasiacutelia DF 26 de Junho de 2017
Professora Dra Edna Dias CanedoOrientador
Professora MsC Cristiane SoaresRamos FGAConvidado 1
Professor MsC Ricardo Ajax DiasKosloski FGA
Convidado 2
Brasiacutelia DF2017
Agradecimentos
Primeiramente eu gostaria de agradecer agrave Deus por ter me dado a oportunidadede estudar na UnB foi ele quem me deu forccedila e sauacutede para chegar ateacute aqui Depois delevem a pessoa mais importante na minha vida que sempre apoiou os meus estudos e fez opossiacutevel e impossiacutevel para me ajudar esta eacute a minha matildee Sheila Guedes Pereira SuzukiGostaria de agradecer tambeacutem toda a minha famiacutelia que de alguma forma me ajudounessa etapa da vida fornecendo todo suporte necessaacuterio
Quero deixar meus sinceros agradecimentos ao meu namorado Danilo FeitozaMelo por ter passado ao meu lado por vaacuterios momentos difiacuteceis durante a minha gradu-accedilatildeo e principalmente pela dedicaccedilatildeo em sempre me ajudar
Por fim e natildeo menos importante agradeccedilo a minha orientadora Edna Dias Canedoe a colaboradora Fabiana Freitas Mendes por sempre me dar auxiacutelio e suporte durante aexecuccedilatildeo desse trabalho
ResumoA qualidade de Software cada vez mais se expande para aleacutem do coacutedigo visto que osaspectos perceptiacuteveis pelo usuaacuterio tambeacutem devem ser considerados Com o intuito decapturar esses aspectos a aacuterea de conhecimento de Design de Interaccedilatildeo eacute estudada nadisciplina de Interaccedilatildeo Humano-Computador (IHC) Para aplicar os conceitos dessa disci-plina existem procedimentos que devem ser respeitados formando entatildeo um processo Aqualidade de software pode ser avaliada durante o processo por meio de meacutetricas Nestecontexto este trabalho propotildee um processo de design de interaccedilatildeo orientado a meacutetricasutilizando a metodologia de revisatildeo de literatura para definir um processo como base Porfim um questionaacuterio foi aplicado com conhecedores de IHC eou processos no intuito devalidar e melhorar o processo proposto
Palavras-chaves Design de interaccedilatildeo Interaccedilatildeo Humano-Computador Processo orien-tado a meacutetricas Processo de design de interaccedilatildeo Processo de usabilidade
AbstractThe Software quality expands beyond the code the aspects noticeable for the user mustbe considered In order to capture these aspects there is the area of Interaction Designwhich is studied in the discipline Human-Computer Interaction (HCI) To apply conceptsof this discipline there are procedures that must be respected thus forming a processThe software quality could be evaluated during the process for example using metricsIn this context this project purposes a process of design interaction oriented by metricsusing the methodology of literature review to define a process for support Finally theresults were collected from a questionnaire applied with knowing of HCI andor processto validate and improve the proposed process
Key-words Interaction design Human-Computer Interaction Process oriented by met-rics Interaction design process Usability process
Lista de ilustraccedilotildees
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos in-terdisciplinares que se preocupam com o design de interaccedilatildeo (ROGERSSHARP PREECE 2013) 19
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009) 23Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993) 24Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999) 25Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011) 30Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de
(ISO25010 2011) 32Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida
de (ISO25010 2011) 33Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999) 34Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas 38Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo 40Figura 11 ndash Graacutefico de Conhecimento em IHC 63Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida 63Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software 64Figura 14 ndash Graacutefico de Conhecimento sobre GQM 65Figura 15 ndash Processo estaacute modularizado 66Figura 16 ndash Graacutefico sobre Entendimento do Processo 66Figura 17 ndash Versatildeo 1 do Processo 74Figura 18 ndash Versatildeo 2 do Processo 75Figura 19 ndash Rastreabilidade do GQM Definido 78
Lista de tabelas
Tabela 1 ndash Trabalhos selecionados para Coleta de dados 28Tabela 2 ndash Niacutevel de detalhamento dos trabalhos 29Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT
1999) 35Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999) 35Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio 41Tabela 6 ndash Anaacutelise de Tarefas 43Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma 44Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade 46Tabela 9 ndash Planejamento do GQM 47Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees 48Tabela 11 ndash Engenharia do Trabalho 49Tabela 12 ndash Projeto do Modelo Conceitual 50Tabela 13 ndash Prototipagem do Modelo Conceitual 51Tabela 14 ndash Definiccedilatildeo de Meacutetricas 52Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual 53Tabela 16 ndash Anaacutelise dos Dados Coletados 54Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela 55Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela 56Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 57Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio 58Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado 59Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil 67Tabela 23 ndash Dados coletados sobre o Processo 68Tabela 24 ndash Dados coletados sobre o Processo 69Tabela 25 ndash Definiccedilatildeo do Time 76Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout
1999) 76Tabela 27 ndash Abstraction Sheet 77Tabela 28 ndash Meacutetricas 79
Lista de abreviaturas e siglas
COBIT Control Objectives for Information and Related Technologies
FGA Faculdade do Gama
GQM Goal Questions Metrics
IEC International Electrotechnical Commission
IHC Interaccedilatildeo Humano-Computador
ISO International Organization for Standardization
RACI Responsible Accountable Consulted and Informed
SQuaRE Systems and software Quality Requirements and Evaluation
TI Tecnologia da Informaccedilatildeo
UnB Universidade de Brasiacutelia
Sumaacuterio
1 INTRODUCcedilAtildeO 1311 Contextualizaccedilatildeo 1312 Problematizaccedilatildeo 14121 Formulaccedilatildeo do Problema 14122 Soluccedilatildeo do Problema 1513 Objetivos 15131 Objetivo Geral 15132 Objetivos Especiacuteficos 1514 Metodologia 15141 Revisatildeo Literaacuteria 16142 Definiccedilatildeo do Processo 16143 Avaliaccedilatildeo do Processo 1615 Organizaccedilatildeo do Trabalho 16
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 1821 Design de Interaccedilatildeo e IHC 18211 Definiccedilotildees 18212 Metas do Design de Interaccedilatildeo e IHC 202121 Metas de Usabilidade 202122 Metas decorrentes da Experiecircncia do Usuaacuterio 202123 Heuriacutesticas de Nielsen 2122 Diferenccedila entre Processo e Ciclo de Vida 2223 Processos de Design de Interaccedilatildeo 2524 Qualidade de Software 29241 SQuaRE 302411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade 312412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade 312413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade 312414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade 312415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade 32242 Caracteriacutesticas de Qualidade de Software 32243 Goal Question Metric (GQM) 34
3 ESPECIFICACcedilAtildeO DO PROCESSO 3731 Objetivo do Processo 3732 Objetivo das Fases 39
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Agradecimentos
Primeiramente eu gostaria de agradecer agrave Deus por ter me dado a oportunidadede estudar na UnB foi ele quem me deu forccedila e sauacutede para chegar ateacute aqui Depois delevem a pessoa mais importante na minha vida que sempre apoiou os meus estudos e fez opossiacutevel e impossiacutevel para me ajudar esta eacute a minha matildee Sheila Guedes Pereira SuzukiGostaria de agradecer tambeacutem toda a minha famiacutelia que de alguma forma me ajudounessa etapa da vida fornecendo todo suporte necessaacuterio
Quero deixar meus sinceros agradecimentos ao meu namorado Danilo FeitozaMelo por ter passado ao meu lado por vaacuterios momentos difiacuteceis durante a minha gradu-accedilatildeo e principalmente pela dedicaccedilatildeo em sempre me ajudar
Por fim e natildeo menos importante agradeccedilo a minha orientadora Edna Dias Canedoe a colaboradora Fabiana Freitas Mendes por sempre me dar auxiacutelio e suporte durante aexecuccedilatildeo desse trabalho
ResumoA qualidade de Software cada vez mais se expande para aleacutem do coacutedigo visto que osaspectos perceptiacuteveis pelo usuaacuterio tambeacutem devem ser considerados Com o intuito decapturar esses aspectos a aacuterea de conhecimento de Design de Interaccedilatildeo eacute estudada nadisciplina de Interaccedilatildeo Humano-Computador (IHC) Para aplicar os conceitos dessa disci-plina existem procedimentos que devem ser respeitados formando entatildeo um processo Aqualidade de software pode ser avaliada durante o processo por meio de meacutetricas Nestecontexto este trabalho propotildee um processo de design de interaccedilatildeo orientado a meacutetricasutilizando a metodologia de revisatildeo de literatura para definir um processo como base Porfim um questionaacuterio foi aplicado com conhecedores de IHC eou processos no intuito devalidar e melhorar o processo proposto
Palavras-chaves Design de interaccedilatildeo Interaccedilatildeo Humano-Computador Processo orien-tado a meacutetricas Processo de design de interaccedilatildeo Processo de usabilidade
AbstractThe Software quality expands beyond the code the aspects noticeable for the user mustbe considered In order to capture these aspects there is the area of Interaction Designwhich is studied in the discipline Human-Computer Interaction (HCI) To apply conceptsof this discipline there are procedures that must be respected thus forming a processThe software quality could be evaluated during the process for example using metricsIn this context this project purposes a process of design interaction oriented by metricsusing the methodology of literature review to define a process for support Finally theresults were collected from a questionnaire applied with knowing of HCI andor processto validate and improve the proposed process
Key-words Interaction design Human-Computer Interaction Process oriented by met-rics Interaction design process Usability process
Lista de ilustraccedilotildees
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos in-terdisciplinares que se preocupam com o design de interaccedilatildeo (ROGERSSHARP PREECE 2013) 19
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009) 23Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993) 24Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999) 25Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011) 30Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de
(ISO25010 2011) 32Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida
de (ISO25010 2011) 33Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999) 34Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas 38Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo 40Figura 11 ndash Graacutefico de Conhecimento em IHC 63Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida 63Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software 64Figura 14 ndash Graacutefico de Conhecimento sobre GQM 65Figura 15 ndash Processo estaacute modularizado 66Figura 16 ndash Graacutefico sobre Entendimento do Processo 66Figura 17 ndash Versatildeo 1 do Processo 74Figura 18 ndash Versatildeo 2 do Processo 75Figura 19 ndash Rastreabilidade do GQM Definido 78
Lista de tabelas
Tabela 1 ndash Trabalhos selecionados para Coleta de dados 28Tabela 2 ndash Niacutevel de detalhamento dos trabalhos 29Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT
1999) 35Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999) 35Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio 41Tabela 6 ndash Anaacutelise de Tarefas 43Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma 44Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade 46Tabela 9 ndash Planejamento do GQM 47Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees 48Tabela 11 ndash Engenharia do Trabalho 49Tabela 12 ndash Projeto do Modelo Conceitual 50Tabela 13 ndash Prototipagem do Modelo Conceitual 51Tabela 14 ndash Definiccedilatildeo de Meacutetricas 52Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual 53Tabela 16 ndash Anaacutelise dos Dados Coletados 54Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela 55Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela 56Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 57Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio 58Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado 59Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil 67Tabela 23 ndash Dados coletados sobre o Processo 68Tabela 24 ndash Dados coletados sobre o Processo 69Tabela 25 ndash Definiccedilatildeo do Time 76Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout
1999) 76Tabela 27 ndash Abstraction Sheet 77Tabela 28 ndash Meacutetricas 79
Lista de abreviaturas e siglas
COBIT Control Objectives for Information and Related Technologies
FGA Faculdade do Gama
GQM Goal Questions Metrics
IEC International Electrotechnical Commission
IHC Interaccedilatildeo Humano-Computador
ISO International Organization for Standardization
RACI Responsible Accountable Consulted and Informed
SQuaRE Systems and software Quality Requirements and Evaluation
TI Tecnologia da Informaccedilatildeo
UnB Universidade de Brasiacutelia
Sumaacuterio
1 INTRODUCcedilAtildeO 1311 Contextualizaccedilatildeo 1312 Problematizaccedilatildeo 14121 Formulaccedilatildeo do Problema 14122 Soluccedilatildeo do Problema 1513 Objetivos 15131 Objetivo Geral 15132 Objetivos Especiacuteficos 1514 Metodologia 15141 Revisatildeo Literaacuteria 16142 Definiccedilatildeo do Processo 16143 Avaliaccedilatildeo do Processo 1615 Organizaccedilatildeo do Trabalho 16
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 1821 Design de Interaccedilatildeo e IHC 18211 Definiccedilotildees 18212 Metas do Design de Interaccedilatildeo e IHC 202121 Metas de Usabilidade 202122 Metas decorrentes da Experiecircncia do Usuaacuterio 202123 Heuriacutesticas de Nielsen 2122 Diferenccedila entre Processo e Ciclo de Vida 2223 Processos de Design de Interaccedilatildeo 2524 Qualidade de Software 29241 SQuaRE 302411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade 312412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade 312413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade 312414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade 312415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade 32242 Caracteriacutesticas de Qualidade de Software 32243 Goal Question Metric (GQM) 34
3 ESPECIFICACcedilAtildeO DO PROCESSO 3731 Objetivo do Processo 3732 Objetivo das Fases 39
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
ResumoA qualidade de Software cada vez mais se expande para aleacutem do coacutedigo visto que osaspectos perceptiacuteveis pelo usuaacuterio tambeacutem devem ser considerados Com o intuito decapturar esses aspectos a aacuterea de conhecimento de Design de Interaccedilatildeo eacute estudada nadisciplina de Interaccedilatildeo Humano-Computador (IHC) Para aplicar os conceitos dessa disci-plina existem procedimentos que devem ser respeitados formando entatildeo um processo Aqualidade de software pode ser avaliada durante o processo por meio de meacutetricas Nestecontexto este trabalho propotildee um processo de design de interaccedilatildeo orientado a meacutetricasutilizando a metodologia de revisatildeo de literatura para definir um processo como base Porfim um questionaacuterio foi aplicado com conhecedores de IHC eou processos no intuito devalidar e melhorar o processo proposto
Palavras-chaves Design de interaccedilatildeo Interaccedilatildeo Humano-Computador Processo orien-tado a meacutetricas Processo de design de interaccedilatildeo Processo de usabilidade
AbstractThe Software quality expands beyond the code the aspects noticeable for the user mustbe considered In order to capture these aspects there is the area of Interaction Designwhich is studied in the discipline Human-Computer Interaction (HCI) To apply conceptsof this discipline there are procedures that must be respected thus forming a processThe software quality could be evaluated during the process for example using metricsIn this context this project purposes a process of design interaction oriented by metricsusing the methodology of literature review to define a process for support Finally theresults were collected from a questionnaire applied with knowing of HCI andor processto validate and improve the proposed process
Key-words Interaction design Human-Computer Interaction Process oriented by met-rics Interaction design process Usability process
Lista de ilustraccedilotildees
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos in-terdisciplinares que se preocupam com o design de interaccedilatildeo (ROGERSSHARP PREECE 2013) 19
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009) 23Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993) 24Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999) 25Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011) 30Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de
(ISO25010 2011) 32Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida
de (ISO25010 2011) 33Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999) 34Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas 38Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo 40Figura 11 ndash Graacutefico de Conhecimento em IHC 63Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida 63Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software 64Figura 14 ndash Graacutefico de Conhecimento sobre GQM 65Figura 15 ndash Processo estaacute modularizado 66Figura 16 ndash Graacutefico sobre Entendimento do Processo 66Figura 17 ndash Versatildeo 1 do Processo 74Figura 18 ndash Versatildeo 2 do Processo 75Figura 19 ndash Rastreabilidade do GQM Definido 78
Lista de tabelas
Tabela 1 ndash Trabalhos selecionados para Coleta de dados 28Tabela 2 ndash Niacutevel de detalhamento dos trabalhos 29Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT
1999) 35Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999) 35Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio 41Tabela 6 ndash Anaacutelise de Tarefas 43Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma 44Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade 46Tabela 9 ndash Planejamento do GQM 47Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees 48Tabela 11 ndash Engenharia do Trabalho 49Tabela 12 ndash Projeto do Modelo Conceitual 50Tabela 13 ndash Prototipagem do Modelo Conceitual 51Tabela 14 ndash Definiccedilatildeo de Meacutetricas 52Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual 53Tabela 16 ndash Anaacutelise dos Dados Coletados 54Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela 55Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela 56Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 57Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio 58Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado 59Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil 67Tabela 23 ndash Dados coletados sobre o Processo 68Tabela 24 ndash Dados coletados sobre o Processo 69Tabela 25 ndash Definiccedilatildeo do Time 76Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout
1999) 76Tabela 27 ndash Abstraction Sheet 77Tabela 28 ndash Meacutetricas 79
Lista de abreviaturas e siglas
COBIT Control Objectives for Information and Related Technologies
FGA Faculdade do Gama
GQM Goal Questions Metrics
IEC International Electrotechnical Commission
IHC Interaccedilatildeo Humano-Computador
ISO International Organization for Standardization
RACI Responsible Accountable Consulted and Informed
SQuaRE Systems and software Quality Requirements and Evaluation
TI Tecnologia da Informaccedilatildeo
UnB Universidade de Brasiacutelia
Sumaacuterio
1 INTRODUCcedilAtildeO 1311 Contextualizaccedilatildeo 1312 Problematizaccedilatildeo 14121 Formulaccedilatildeo do Problema 14122 Soluccedilatildeo do Problema 1513 Objetivos 15131 Objetivo Geral 15132 Objetivos Especiacuteficos 1514 Metodologia 15141 Revisatildeo Literaacuteria 16142 Definiccedilatildeo do Processo 16143 Avaliaccedilatildeo do Processo 1615 Organizaccedilatildeo do Trabalho 16
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 1821 Design de Interaccedilatildeo e IHC 18211 Definiccedilotildees 18212 Metas do Design de Interaccedilatildeo e IHC 202121 Metas de Usabilidade 202122 Metas decorrentes da Experiecircncia do Usuaacuterio 202123 Heuriacutesticas de Nielsen 2122 Diferenccedila entre Processo e Ciclo de Vida 2223 Processos de Design de Interaccedilatildeo 2524 Qualidade de Software 29241 SQuaRE 302411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade 312412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade 312413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade 312414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade 312415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade 32242 Caracteriacutesticas de Qualidade de Software 32243 Goal Question Metric (GQM) 34
3 ESPECIFICACcedilAtildeO DO PROCESSO 3731 Objetivo do Processo 3732 Objetivo das Fases 39
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
AbstractThe Software quality expands beyond the code the aspects noticeable for the user mustbe considered In order to capture these aspects there is the area of Interaction Designwhich is studied in the discipline Human-Computer Interaction (HCI) To apply conceptsof this discipline there are procedures that must be respected thus forming a processThe software quality could be evaluated during the process for example using metricsIn this context this project purposes a process of design interaction oriented by metricsusing the methodology of literature review to define a process for support Finally theresults were collected from a questionnaire applied with knowing of HCI andor processto validate and improve the proposed process
Key-words Interaction design Human-Computer Interaction Process oriented by met-rics Interaction design process Usability process
Lista de ilustraccedilotildees
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos in-terdisciplinares que se preocupam com o design de interaccedilatildeo (ROGERSSHARP PREECE 2013) 19
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009) 23Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993) 24Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999) 25Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011) 30Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de
(ISO25010 2011) 32Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida
de (ISO25010 2011) 33Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999) 34Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas 38Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo 40Figura 11 ndash Graacutefico de Conhecimento em IHC 63Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida 63Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software 64Figura 14 ndash Graacutefico de Conhecimento sobre GQM 65Figura 15 ndash Processo estaacute modularizado 66Figura 16 ndash Graacutefico sobre Entendimento do Processo 66Figura 17 ndash Versatildeo 1 do Processo 74Figura 18 ndash Versatildeo 2 do Processo 75Figura 19 ndash Rastreabilidade do GQM Definido 78
Lista de tabelas
Tabela 1 ndash Trabalhos selecionados para Coleta de dados 28Tabela 2 ndash Niacutevel de detalhamento dos trabalhos 29Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT
1999) 35Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999) 35Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio 41Tabela 6 ndash Anaacutelise de Tarefas 43Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma 44Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade 46Tabela 9 ndash Planejamento do GQM 47Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees 48Tabela 11 ndash Engenharia do Trabalho 49Tabela 12 ndash Projeto do Modelo Conceitual 50Tabela 13 ndash Prototipagem do Modelo Conceitual 51Tabela 14 ndash Definiccedilatildeo de Meacutetricas 52Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual 53Tabela 16 ndash Anaacutelise dos Dados Coletados 54Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela 55Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela 56Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 57Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio 58Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado 59Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil 67Tabela 23 ndash Dados coletados sobre o Processo 68Tabela 24 ndash Dados coletados sobre o Processo 69Tabela 25 ndash Definiccedilatildeo do Time 76Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout
1999) 76Tabela 27 ndash Abstraction Sheet 77Tabela 28 ndash Meacutetricas 79
Lista de abreviaturas e siglas
COBIT Control Objectives for Information and Related Technologies
FGA Faculdade do Gama
GQM Goal Questions Metrics
IEC International Electrotechnical Commission
IHC Interaccedilatildeo Humano-Computador
ISO International Organization for Standardization
RACI Responsible Accountable Consulted and Informed
SQuaRE Systems and software Quality Requirements and Evaluation
TI Tecnologia da Informaccedilatildeo
UnB Universidade de Brasiacutelia
Sumaacuterio
1 INTRODUCcedilAtildeO 1311 Contextualizaccedilatildeo 1312 Problematizaccedilatildeo 14121 Formulaccedilatildeo do Problema 14122 Soluccedilatildeo do Problema 1513 Objetivos 15131 Objetivo Geral 15132 Objetivos Especiacuteficos 1514 Metodologia 15141 Revisatildeo Literaacuteria 16142 Definiccedilatildeo do Processo 16143 Avaliaccedilatildeo do Processo 1615 Organizaccedilatildeo do Trabalho 16
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 1821 Design de Interaccedilatildeo e IHC 18211 Definiccedilotildees 18212 Metas do Design de Interaccedilatildeo e IHC 202121 Metas de Usabilidade 202122 Metas decorrentes da Experiecircncia do Usuaacuterio 202123 Heuriacutesticas de Nielsen 2122 Diferenccedila entre Processo e Ciclo de Vida 2223 Processos de Design de Interaccedilatildeo 2524 Qualidade de Software 29241 SQuaRE 302411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade 312412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade 312413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade 312414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade 312415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade 32242 Caracteriacutesticas de Qualidade de Software 32243 Goal Question Metric (GQM) 34
3 ESPECIFICACcedilAtildeO DO PROCESSO 3731 Objetivo do Processo 3732 Objetivo das Fases 39
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Lista de ilustraccedilotildees
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos in-terdisciplinares que se preocupam com o design de interaccedilatildeo (ROGERSSHARP PREECE 2013) 19
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009) 23Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993) 24Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999) 25Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011) 30Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de
(ISO25010 2011) 32Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida
de (ISO25010 2011) 33Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999) 34Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas 38Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo 40Figura 11 ndash Graacutefico de Conhecimento em IHC 63Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida 63Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software 64Figura 14 ndash Graacutefico de Conhecimento sobre GQM 65Figura 15 ndash Processo estaacute modularizado 66Figura 16 ndash Graacutefico sobre Entendimento do Processo 66Figura 17 ndash Versatildeo 1 do Processo 74Figura 18 ndash Versatildeo 2 do Processo 75Figura 19 ndash Rastreabilidade do GQM Definido 78
Lista de tabelas
Tabela 1 ndash Trabalhos selecionados para Coleta de dados 28Tabela 2 ndash Niacutevel de detalhamento dos trabalhos 29Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT
1999) 35Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999) 35Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio 41Tabela 6 ndash Anaacutelise de Tarefas 43Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma 44Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade 46Tabela 9 ndash Planejamento do GQM 47Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees 48Tabela 11 ndash Engenharia do Trabalho 49Tabela 12 ndash Projeto do Modelo Conceitual 50Tabela 13 ndash Prototipagem do Modelo Conceitual 51Tabela 14 ndash Definiccedilatildeo de Meacutetricas 52Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual 53Tabela 16 ndash Anaacutelise dos Dados Coletados 54Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela 55Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela 56Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 57Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio 58Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado 59Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil 67Tabela 23 ndash Dados coletados sobre o Processo 68Tabela 24 ndash Dados coletados sobre o Processo 69Tabela 25 ndash Definiccedilatildeo do Time 76Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout
1999) 76Tabela 27 ndash Abstraction Sheet 77Tabela 28 ndash Meacutetricas 79
Lista de abreviaturas e siglas
COBIT Control Objectives for Information and Related Technologies
FGA Faculdade do Gama
GQM Goal Questions Metrics
IEC International Electrotechnical Commission
IHC Interaccedilatildeo Humano-Computador
ISO International Organization for Standardization
RACI Responsible Accountable Consulted and Informed
SQuaRE Systems and software Quality Requirements and Evaluation
TI Tecnologia da Informaccedilatildeo
UnB Universidade de Brasiacutelia
Sumaacuterio
1 INTRODUCcedilAtildeO 1311 Contextualizaccedilatildeo 1312 Problematizaccedilatildeo 14121 Formulaccedilatildeo do Problema 14122 Soluccedilatildeo do Problema 1513 Objetivos 15131 Objetivo Geral 15132 Objetivos Especiacuteficos 1514 Metodologia 15141 Revisatildeo Literaacuteria 16142 Definiccedilatildeo do Processo 16143 Avaliaccedilatildeo do Processo 1615 Organizaccedilatildeo do Trabalho 16
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 1821 Design de Interaccedilatildeo e IHC 18211 Definiccedilotildees 18212 Metas do Design de Interaccedilatildeo e IHC 202121 Metas de Usabilidade 202122 Metas decorrentes da Experiecircncia do Usuaacuterio 202123 Heuriacutesticas de Nielsen 2122 Diferenccedila entre Processo e Ciclo de Vida 2223 Processos de Design de Interaccedilatildeo 2524 Qualidade de Software 29241 SQuaRE 302411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade 312412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade 312413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade 312414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade 312415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade 32242 Caracteriacutesticas de Qualidade de Software 32243 Goal Question Metric (GQM) 34
3 ESPECIFICACcedilAtildeO DO PROCESSO 3731 Objetivo do Processo 3732 Objetivo das Fases 39
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Lista de tabelas
Tabela 1 ndash Trabalhos selecionados para Coleta de dados 28Tabela 2 ndash Niacutevel de detalhamento dos trabalhos 29Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT
1999) 35Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999) 35Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio 41Tabela 6 ndash Anaacutelise de Tarefas 43Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma 44Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade 46Tabela 9 ndash Planejamento do GQM 47Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees 48Tabela 11 ndash Engenharia do Trabalho 49Tabela 12 ndash Projeto do Modelo Conceitual 50Tabela 13 ndash Prototipagem do Modelo Conceitual 51Tabela 14 ndash Definiccedilatildeo de Meacutetricas 52Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual 53Tabela 16 ndash Anaacutelise dos Dados Coletados 54Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela 55Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela 56Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 57Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio 58Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado 59Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil 67Tabela 23 ndash Dados coletados sobre o Processo 68Tabela 24 ndash Dados coletados sobre o Processo 69Tabela 25 ndash Definiccedilatildeo do Time 76Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout
1999) 76Tabela 27 ndash Abstraction Sheet 77Tabela 28 ndash Meacutetricas 79
Lista de abreviaturas e siglas
COBIT Control Objectives for Information and Related Technologies
FGA Faculdade do Gama
GQM Goal Questions Metrics
IEC International Electrotechnical Commission
IHC Interaccedilatildeo Humano-Computador
ISO International Organization for Standardization
RACI Responsible Accountable Consulted and Informed
SQuaRE Systems and software Quality Requirements and Evaluation
TI Tecnologia da Informaccedilatildeo
UnB Universidade de Brasiacutelia
Sumaacuterio
1 INTRODUCcedilAtildeO 1311 Contextualizaccedilatildeo 1312 Problematizaccedilatildeo 14121 Formulaccedilatildeo do Problema 14122 Soluccedilatildeo do Problema 1513 Objetivos 15131 Objetivo Geral 15132 Objetivos Especiacuteficos 1514 Metodologia 15141 Revisatildeo Literaacuteria 16142 Definiccedilatildeo do Processo 16143 Avaliaccedilatildeo do Processo 1615 Organizaccedilatildeo do Trabalho 16
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 1821 Design de Interaccedilatildeo e IHC 18211 Definiccedilotildees 18212 Metas do Design de Interaccedilatildeo e IHC 202121 Metas de Usabilidade 202122 Metas decorrentes da Experiecircncia do Usuaacuterio 202123 Heuriacutesticas de Nielsen 2122 Diferenccedila entre Processo e Ciclo de Vida 2223 Processos de Design de Interaccedilatildeo 2524 Qualidade de Software 29241 SQuaRE 302411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade 312412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade 312413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade 312414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade 312415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade 32242 Caracteriacutesticas de Qualidade de Software 32243 Goal Question Metric (GQM) 34
3 ESPECIFICACcedilAtildeO DO PROCESSO 3731 Objetivo do Processo 3732 Objetivo das Fases 39
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Lista de abreviaturas e siglas
COBIT Control Objectives for Information and Related Technologies
FGA Faculdade do Gama
GQM Goal Questions Metrics
IEC International Electrotechnical Commission
IHC Interaccedilatildeo Humano-Computador
ISO International Organization for Standardization
RACI Responsible Accountable Consulted and Informed
SQuaRE Systems and software Quality Requirements and Evaluation
TI Tecnologia da Informaccedilatildeo
UnB Universidade de Brasiacutelia
Sumaacuterio
1 INTRODUCcedilAtildeO 1311 Contextualizaccedilatildeo 1312 Problematizaccedilatildeo 14121 Formulaccedilatildeo do Problema 14122 Soluccedilatildeo do Problema 1513 Objetivos 15131 Objetivo Geral 15132 Objetivos Especiacuteficos 1514 Metodologia 15141 Revisatildeo Literaacuteria 16142 Definiccedilatildeo do Processo 16143 Avaliaccedilatildeo do Processo 1615 Organizaccedilatildeo do Trabalho 16
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 1821 Design de Interaccedilatildeo e IHC 18211 Definiccedilotildees 18212 Metas do Design de Interaccedilatildeo e IHC 202121 Metas de Usabilidade 202122 Metas decorrentes da Experiecircncia do Usuaacuterio 202123 Heuriacutesticas de Nielsen 2122 Diferenccedila entre Processo e Ciclo de Vida 2223 Processos de Design de Interaccedilatildeo 2524 Qualidade de Software 29241 SQuaRE 302411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade 312412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade 312413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade 312414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade 312415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade 32242 Caracteriacutesticas de Qualidade de Software 32243 Goal Question Metric (GQM) 34
3 ESPECIFICACcedilAtildeO DO PROCESSO 3731 Objetivo do Processo 3732 Objetivo das Fases 39
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Sumaacuterio
1 INTRODUCcedilAtildeO 1311 Contextualizaccedilatildeo 1312 Problematizaccedilatildeo 14121 Formulaccedilatildeo do Problema 14122 Soluccedilatildeo do Problema 1513 Objetivos 15131 Objetivo Geral 15132 Objetivos Especiacuteficos 1514 Metodologia 15141 Revisatildeo Literaacuteria 16142 Definiccedilatildeo do Processo 16143 Avaliaccedilatildeo do Processo 1615 Organizaccedilatildeo do Trabalho 16
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 1821 Design de Interaccedilatildeo e IHC 18211 Definiccedilotildees 18212 Metas do Design de Interaccedilatildeo e IHC 202121 Metas de Usabilidade 202122 Metas decorrentes da Experiecircncia do Usuaacuterio 202123 Heuriacutesticas de Nielsen 2122 Diferenccedila entre Processo e Ciclo de Vida 2223 Processos de Design de Interaccedilatildeo 2524 Qualidade de Software 29241 SQuaRE 302411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade 312412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade 312413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade 312414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade 312415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade 32242 Caracteriacutesticas de Qualidade de Software 32243 Goal Question Metric (GQM) 34
3 ESPECIFICACcedilAtildeO DO PROCESSO 3731 Objetivo do Processo 3732 Objetivo das Fases 39
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
321 Anaacutelise de Requisitos 39322 Design Avaliaccedilatildeo e Desenvolvimento 3933 Detalhamento dos Papeacuteis 3934 Responsabilidades dos Papeacuteis 4035 Especificaccedilatildeo das Atividades 41351 Definiccedilatildeo do Perfil do Usuaacuterio 41352 Anaacutelise de Tarefas 43353 Definiccedilatildeo das Caracteriacutesticas da Plataforma 44354 Definiccedilatildeo das Metas de Usabilidade 46355 Planejamento do GQM 47356 Definiccedilatildeo do Objetivo e Questotildees 48357 Engenharia do Trabalho 49358 Projeto do Modelo Conceitual 50359 Prototipagem do Modelo Conceitual 513510 Definiccedilatildeo de Meacutetricas 523511 Avaliaccedilatildeo Iterativa do Modelo Conceitual 533512 Anaacutelise dos Dados Coletados 543513 Definiccedilatildeo dos Padrotildees de Design de Tela 553514 Prototipagem dos Padrotildees de Deseign de Tela 563515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela 573516 Design Detalhado da Interface do Usuaacuterio 583517 Avaliaccedilatildeo Iterativa do Design Detalhado 59
4 AVALIACcedilAtildeO DO PROCESSO 6041 Questionaacuterio 60411 Puacuteblico Alvo 60412 O questionaacuterio 60413 Dados Coletados 62414 Anaacutelise dos Dados 62
5 CONSIDERACcedilOtildeES FINAIS 7051 Conclusatildeo 70
REFEREcircNCIAS 71
APEcircNDICES 73
APEcircNDICE A ndash VERSOtildeES DO PROCESSO 74
APEcircNDICE B ndash EXEMPLO DE GQM 76
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
B1 Planejamento 76B11 Projeto de Aplicaccedilatildeo 76B12 Definiccedilatildeo do Time 76B13 Aacuterea de Melhoria 76B2 Definiccedilatildeo 76B21 Abstraction Sheet 77
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
13
1 Introduccedilatildeo
Com os recentes avanccedilos nas pesquisas em desenvolvimento de software especifica-mente na aacuterea de design de interaccedilatildeo os produtos ofertados pelas empresas de Tecnologiada Informaccedilatildeo (TI) tecircm focado na melhoria da qualidade das interfaces desenvolvidasonde eacute preciso termos aplicaccedilotildees em que o usuaacuterio final se sinta confortaacutevel em usaacute-las
11 ContextualizaccedilatildeoTodos os dias estamos em contato com algum produtosoftware que precisa de
uma interaccedilatildeo humana Se parar para pensar eacute faacutecil identificar por exemplo ao acordardesligamos o despertador mexemos no celular ou no controle da televisatildeo Satildeo muitos osaparelhos com os quais preicsamos interagir Eacute importante avaliar o quanto os aparelhose ou produtos que manuseamos diariamente satildeo realmente faacuteceis de utilizar O quantoos fabricantes dos mesmos estatildeo preocupados com a facilidade de interaccedilatildeo por parte dousuaacuterio Eacute nesse contexto que entra a aacuterea de conhecimento Design de Interaccedilatildeo definidacomo ldquocriar experiecircncias que melhorem e estendam a maneira como as pessoas trabalhamse comunicam e interagemrdquo (ROGERS SHARP PREECE 2013)
O design de interaccedilatildeo eacute estudado por meio da disciplina de Interaccedilatildeo Humano-Computador (IHC) Esta disciplina estaacute preocupada com o design avaliaccedilatildeo e imple-mentaccedilatildeo de sistemas computacionais interativos para uso humano e com o estudo dosprincipais fenocircmenos ao redor deles(ROCHA BARANAUSKAS 2003) Todo esse pro-cesso busca potencializar o alcance de metas quanto agrave utilizaccedilatildeo do software pelo usuaacuterioe suas percepccedilotildees Poreacutem muitos produtos natildeo foram necessariamente projetados tendocomo preocupaccedilatildeo o usuaacuterio (ROGERS SHARP PREECE 2013) Isso significa quequem projetou o produto natildeo pensou no puacuteblico alvo que o usaria dificultando muitasvezes a interaccedilatildeo do usuaacuterio com o produto
Com o objetivo de melhorar a interaccedilatildeo do usuaacuterio com o sistema a IHC tentaredirecionar a preocupaccedilatildeo com o usuaacuterio trazendo a usabilidade grau em que um pro-duto ou sistema pode ser usado por usuaacuterios especiacuteficos para alcanccedilar objetivos especiacuteficoscomo efetividade eficiecircncia e satisfaccedilatildeo em um contexto de uso especificado(ISO250102011) para o design do sistema o que significa que o usuaacuterio alcanccedilaria seu objetivo comefetividade eficiecircncia e satisfaccedilatildeo Para o usuaacuterio o software eacute a interface por isso o seudesign deve se adaptar a ele e natildeo o contraacuterio Em seu livro Norman (2013) afirma que
Para criar uma tecnologia que se adapte ao ser humano eacute necessaacuterio estudaacute-loMas hoje temos uma tendecircncia de estudar apenas a tecnologia Como consequecircncia exige-
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 1 Introduccedilatildeo 14
se que as pessoas se adaptem agrave tecnologia Eacute chegada a hora de inverter a tendecircncia ahora de fazer com que a tecnologia se adapte agraves pessoas
A interface eacute um item do sistema que pode afetar a qualidade do produto por issoeacute importante analisaacute-la e adequaacute-la de acordo com as necessidades do usuaacuterio De acordocom Crosby (1992) ldquoA qualidade eacute a conformidade aos requisitosrdquo ou seja se um produtoestaacute cumprindo todos os seus requisitos possui qualidade Mas a preocupaccedilatildeo com a qua-lidade de software vai aleacutem da qualidade do coacutedigo Os aspectos de qualidade perceptiacuteveispara o usuaacuterio tambeacutem devem ser considerados Visando estabelecer padrotildees no aspectode qualidade do produto de software a International Organization for Standardization(ISO) criou um conjunto de normas as quais foram denominadas Systems and softwareQuality Requirements and Evaluation (SQuaRE) Esta norma define caracteriacutesticas e subcaracteriacutesticas de qualidade a qual estaacute melhor detalhada no Capiacutetulo 2
Eacute necessaacuterio definir as caracteriacutesticas de qualidade que se deseja alcanccedilar no soft-ware SQuaRE pode auxiliar nessa definiccedilatildeo Uma grande dificuldade eacute conseguir avaliaressas caracteriacutesticas depois de definidas Para isso pode se utilizar mediccedilatildeo de softwareque eacute ldquouma avaliaccedilatildeo quantitativa de qualquer aspecto dos processos e produtos da En-genharia de Softwareldquo (BASS et al 1999) O meacutetodo Goal Questions Metrics (GQM) eacutemuito utilizado para planejar o processo de mediccedilatildeo O GQM se inicia com os objetivosde mediccedilatildeo derivando entatildeo as questotildees para atingir cada objetivo A partir das questotildeessatildeo definidas as meacutetricas para respondecirc-las obtendo assim as mediccedilotildees
12 Problematizaccedilatildeo
121 Formulaccedilatildeo do Problema
A aacuterea de Design de Interaccedilatildeo natildeo eacute estudada soacute pela Engenharia de Softwareeacute aplicada e estudada por quase todas as aacutereas de conhecimento A partir da revisatildeoliteraacuteria realizada foi possiacutevel identificar que natildeo existem muitos processos de Design deInteraccedilatildeo bem definidos A maioria dos autores aconselham as empresas a criarem o seuproacuteprio processo seguindo procedimentos como base que podem ser vistos em (ROGERSSHARP PREECE 2013)
Deborah Mayhew (1999) em seu livro ldquoThe usability engineering lifecyclerdquo defineum processo e detalha todas as suas atividades O processo por ela criado eacute bem definido epossui um alto niacutevel de detalhamento poreacutem natildeo integra a preocupaccedilatildeo com a qualidadedo produto de software Integrar a preocupaccedilatildeo com o usuaacuterio na interface do software ea qualidade dessa interface pode facilitar que defeitos sejam encontrados e melhorados omais raacutepido possiacutevel
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 1 Introduccedilatildeo 15
122 Soluccedilatildeo do Problema
A interface eacute a forma com que o usuaacuterio interage com o sistema logo uma interfacede qualidade afetaraacute de maneira positiva o desempenho do usuaacuterio final A qualidade dainterface pode ser medida atraveacutes de mediccedilotildees
A soluccedilatildeo para melhorar a qualidade do produto na perspectiva em relaccedilatildeo ausabilidade seguindo um processo de design de interaccedilatildeo eacute a definiccedilatildeo de um processo dedesign de interaccedilatildeo orientado a meacutetricas que conseguiraacute auxiliar na avaliaccedilatildeo da interfacee identificar aspectos que podem ser melhorados antes da entrega final do produto
13 Objetivos
131 Objetivo Geral
Este trabalho tem por objetivo geral propor e validar um Processo de Designde Interaccedilatildeo Orientado a Meacutetricas para melhorar a qualidade do software em relaccedilatildeo ausabilidade
132 Objetivos Especiacuteficos
Para atingir o objetivo geral deste trabalho foram definidos os seguintes objetivosespeciacuteficos
∙ Investigar e identificar exemplos de processos de design de interaccedilatildeo existentes naliteratura
∙ Avaliar e selecionar um processo de design de interaccedilatildeo detalhado para ser utilizadona especificaccedilatildeo do processo orientado a meacutetricas
∙ Especificar um processo de design de interaccedilatildeo orientado a meacutetricas
∙ Avaliar o processo definido
14 MetodologiaEste trabalho foi divido em etapas que estatildeo detalhadas nas subseccedilotildees 141 142
e 143 Inicialmente foi realizada uma revisatildeo literaacuteria seguida da definiccedilatildeo de umprocesso que por fim foi validado por meio de um questionaacuterio
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 1 Introduccedilatildeo 16
141 Revisatildeo Literaacuteria
A revisatildeo literaacuteria consistiu em responder quatro questotildees de pesquisa que seratildeomelhor detalhadas no Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Em um alto niacutevel as questotildeesestatildeo relacionadas com os seguintes itens
∙ Design de Interaccedilatildeo e IHC
∙ Processos e Ciclos de Vida
∙ Processos de Design de Interaccedilatildeo
∙ Qualidade de Software
142 Definiccedilatildeo do Processo
Primeiramente foi definido um processo de design orientado a meacutetricas tendocomo base o processo definido por Mayhew (MAYHEW 1999) o qual foi selecionadona etapa de revisatildeo da literatura A proacutexima etapa foi composta pelo detalhamento doprocesso definido que consiste em objetivo do processo objetivo das fases detalhamentodos papeacuteis e especificaccedilatildeo das atividades o qual seraacute apresentado na Seccedilatildeo 3
143 Avaliaccedilatildeo do Processo
Com o intuito de validar e avaliar o processo definido um questionaacuterio foi criadoe aplicado com conhecedores de IHC eou Processos de Software Os grupos escolhidosforam Alunos de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdadede Tecnologia da UnB alunos de Engenharia de Software da UnB-FGA que jaacute cursarama disciplina de IHC Professores de Engenharia de Software da UnB-FGA
15 Organizaccedilatildeo do TrabalhoAleacutem deste Capiacutetulo introdutoacuterio este trabalho estaacute estruturado em mais 4 Capiacute-
tulos
∙ Capiacutetulo 2 - Fundamentaccedilatildeo Teoacuterica Tem por objetivo fornecer o embasamentoteoacuterico sobre das aacutereas que compotildeem esse trabalho design de interaccedilatildeo e IHCprocessos e ciclos de vida processo de design de interaccedilatildeo e qualidade de software
∙ Capiacutetulo 3 - Definiccedilatildeo do Processo Apresenta o Processo de Design de InteraccedilatildeoOrientado a Meacutetricas definido e seu detalhamento como objetivo do processoobjetivo das fases detalhamento dos papeacuteis e especificaccedilatildeo das atividades
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 1 Introduccedilatildeo 17
∙ Capiacutetulo 4 - Avaliaccedilatildeo do Processo Este capiacutetulo eacute designado a validaccedilatildeo doprocesso por meio de um questionaacuterio realizado com conhecedores de IHC eouProcessos de Software
∙ Capiacutetulo 5 - Consideraccedilotildees Finais Relata os resultados alcanccedilados em todo otrabalho e seus futuros direcionamentos
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
18
2 Fundamentaccedilatildeo Teoacuterica
Este capiacutetulo apresenta a fundamentaccedilatildeo teoacuterica a qual foi realizada por meio darevisatildeo de literatura Foram definidas algumas questotildees de pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo jaacute existentes na literaturaconsiderando um alto niacutevel de detalhamento
Q4 - O que eacute Qualidade de Software
21 Design de Interaccedilatildeo e IHCEsta Seccedilatildeo responde a primeira Questatildeo de Pesquisa
Q1 - O que eacute Design de Interaccedilatildeo e IHC
211 Definiccedilotildees
O design de interaccedilatildeo eacute uma proposta para completar algumas lacunas percebidasnos processos de desenvolvimento de software que eacute a preocupaccedilatildeo com o usuaacuterio Atu-almente os produtos tentam cada vez mais se adaptarem ao usuaacuterio o que natildeo ocorriaantigamente onde o usuaacuterio precisava se adaptar aos produtos Um exemplo pode sero telefone inicialmente com fio e apenas os nuacutemeros para discar Depois se adaptou anecessidade do usuaacuterio de levar o telefone para diferentes locais perdendo o fio e hojeganhou ateacute um display que mostra informaccedilotildees como agenda identificador de ligaccedilotildeesetc
Design de Interaccedilatildeo significa ldquodesign de produtos interativos que fornecem suporteagraves atividades cotidianas das pessoas seja no lar ou no trabalholdquo (ROGERS SHARPPREECE 2013) Pode-se entender como o design da interface que se preocupe com ainteraccedilatildeo do humano com o produto com o objetivo de facilitaacute-la Mas o que pode serentendido como facilitaacute-la
Facilitar a interaccedilatildeo do humano com a interface significa se preocupar com ausabilidade do produto entender o comportamento do usuaacuterio e seus sentimentos Paraalcanccedilar esse objetivo o design de interaccedilatildeo envolve vaacuterias aacutereas conforme apresentadona Figura 1
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
Figura 1 ndash Relaccedilatildeo entre disciplinas acadecircmicas praacuteticas de design de campos interdis-ciplinares que se preocupam com o design de interaccedilatildeo (ROGERS SHARPPREECE 2013)
Como pode ser observado na Figura 1 o design de interaccedilatildeo eacute fundamental paravaacuterias disciplinas campos e abordagens que se preocupam em projetar sistemas para hu-manos O campo mais conhecido nessa aacuterea eacute o de Interaccedilatildeo Humano-Computador (IHC)Esta eacute uma disciplina interessada com o projeto implementaccedilatildeo e avaliaccedilatildeo de sistemascomputacionais interativos para uso humano juntamente com os fenocircmenos relacionadosa esse uso(HEWETT et al 1992)
Segundo Simone Barbosa e Bruno Silva (2010) enquanto grande parte da Com-putaccedilatildeo mais especificamente a Engenharia de Software estaacute interessada na construccedilatildeode sistemas interativos mais eficientes robustos livres de erros e de faacutecil manutenccedilatildeoa aacuterea de IHC estaacute interessada na qualidade de uso desses sistemas e no seu impacto navida dos usuaacuterios
Pode se interpretar que a Computaccedilatildeo costuma desenvolver os sistemas de ldquodentropara foraldquo ou seja inicia pela representaccedilatildeo dos dados arquitetura do sistema e todo oprojeto do mesmo Em contrapartida a IHC concebe seus sistemas de ldquofora para dentroldquoonde comeccedila investigando os papeacuteis envolvidos seus objetivos caracteriacutesticas como osistema pode intervir no mundo real do usuaacuterio e entatildeo planejar a interface e o sistemaEm um design de IHC desde sua concepccedilatildeo e durante todo o seu desenvolvimento umsistema interativo deve ter o propoacutesito de apoiar os usuaacuterios a alcanccedilarem seus objetivos(BARBOSA SILVA 2010)
De acordo com Hewett et at (1992) os objetos de estudo de IHC podem ser classifi-cados em cinco toacutepicos relacionados entre si a natureza da interaccedilatildeo humano-computador
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
o uso de sistemas interativos situado em contexto caracteriacutesticas humanas arquiteturade sistemas computacionais e da interface com usuaacuterios e processos de desenvolvimentopreocupados com uso
212 Metas do Design de Interaccedilatildeo e IHC
Tornar um sistema mais faacutecil para o usuaacuterio utilizar nem sempre eacute uma tarefaque todos conhecem aleacutem de que faacutecil para uma pessoa pode natildeo ser o mesmo paraoutra pessoa Dessa forma o que um sistema deve ter para que o usuaacuterio tenha uma boainteraccedilatildeo Eacute aiacute entatildeo que entram as metas hoje na literatura as principais satildeo as metas deusabilidade metas decorrentes da experiecircncia do usuaacuterio (ROGERS SHARP PREECE2013) e Heuriacutesticas de Nielsen (NIELSEN 1994a)
2121 Metas de Usabilidade
As metas de usabilidade satildeo preocupadas com os criteacuterios de usabilidade Traduzidode (NIELSEN 1994b)
∙ Facilidade de aprendizagem - o sistema deve ser faacutecil de aprender a usar para queo usuaacuterio consiga rapidamente iniciar uma atividade
∙ Eficiecircncia - o sistema deve ser eficiente para uso entatildeo uma vez que o usuaacuterioaprendeu a usar eacute possiacutevel um alto niacutevel de produtividade
∙ Facilidade de memorizaccedilatildeo - o sistema deve ser faacutecil de lembrar permitindo umusuaacuterio a ficar um tempo sem usar o sistema e entatildeo retornar o uso sem precisaraprender tudo novamente
∙ Erros - o sistema deve ter uma baixa taxa de erros e se o usuaacuterio cometer algum osistema deve permitir desfazer esse erro facilmente aleacutem de que erros catastroacuteficosnatildeo podem ocorrer
∙ Satisfatoacuterio - o uso do sistema deve ser prazeroso onde os usuaacuterio estatildeo subjetiva-mente satisfeitos em utilizaacute-lo
2122 Metas decorrentes da Experiecircncia do Usuaacuterio
As metas decorrentes da experiecircncia do usuaacuterio se preocupam com explicar a qua-lidade dessa experiecircncia As quais satildeo classificadas como (ROGERS SHARP PREECE2013)
∙ Satisfatoacuterios
∙ Agradaacuteveis
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
∙ Divertidos
∙ Interessantes
∙ Uacuteteis
∙ Motivadores
∙ Esteticamente apreciaacuteceis
∙ Incentivadores de criatividade
∙ Compensadores
∙ Emocionalmente adequados
2123 Heuriacutesticas de Nielsen
As Heuriacutesticas de Nielsen satildeo premissas que facilitam o desenvolvedor a compre-ender algo novo diminuindo as chances de erro As heuriacutesticas satildeo (NIELSEN 1994a)
∙ Visibilidade do status do sistema - O sistema precisa manter os usuaacuterios informadossobre o que estaacute acontecendo fornecendo um feedback adequado dentro de umtempo razoaacutevel
∙ Concordacircncia do sistema com o mundo real - O sistema precisa falar a linguagemdo usuaacuterio com palavras frases e conceitos familiares ao usuaacuterio ao inveacutes de ter-mos orientados ao sistema Seguir convenccedilotildees do mundo real fazendo com que ainformaccedilatildeo apareccedila em uma ordem natural e loacutegica
∙ Controle e liberdade do usuaacuterio - Os usuaacuterios frequentemente escolhem por enganofunccedilotildees do sistema e precisam ter claras saiacutedas de emergecircncia para sair do estadoindesejado sem ter que percorrer um extenso diaacutelogo O sistema deve portantoprover funccedilotildees ldquoundordquo e ldquoredordquo
∙ Consistecircncia e padrotildees - Os usuaacuterios natildeo precisam adivinhar que diferentes pala-vras situaccedilotildees ou accedilotildees significam a mesma coisa Seguir convenccedilotildees de plataformacomputacional
∙ Prevenccedilatildeo de erros - Eacute melhor que o sistema possua um design cuidadoso o qualprevina o erro antes dele acontecer
∙ Reconhecer ao inveacutes de lembrar - O sistema deve tornar objetos accedilotildees e opccedilotildeesvisiacuteveis O usuaacuterio natildeo deve ter que lembrar informaccedilatildeo de uma para outra parte dodiaacutelogo Instruccedilotildees para uso do sistema devem estar visiacuteveis e facilmente recuperaacuteveisquando necessaacuterio
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
∙ Flexibilidade e eficiecircncia de uso - Os usuaacuterios novatos se tornam peritos com o uso Osistema deve prover aceleradores de forma a aumentar a velocidade da interaccedilatildeo Osistema deve permitir aos usuaacuterios experientes cortar caminhoem accedilotildees frequentes
∙ Esteacutetica e design minimalista - Os diaacutelogos natildeo devem conter informaccedilatildeo irrelevanteou raramente necessaacuteria Qualquer unidade de informaccedilatildeo extra no diaacutelogo iraacute com-petir com unidades relevantes de informaccedilatildeo e diminuir sua visibilidade relativa
∙ Ajudar os usuaacuterios a reconhecer diagnosticar e corrigir erros - As mensagens deerro devem ser expressas em linguagem clara (sem coacutedigos) indicando precisamenteo problema e construtivamente sugerindo uma soluccedilatildeo
∙ Ajuda e documentaccedilatildeo - Eacute necessaacuterio prover ajuda e documentaccedilatildeo embora sejamelhor um sistema que possa ser usado sem documentaccedilatildeo Essas informaccedilotildees devemser faacuteceis de encontrar focalizadas na tarefa do usuaacuterio e natildeo muito extensas
22 Diferenccedila entre Processo e Ciclo de VidaEsta Seccedilatildeo responde a segunda Questatildeo de Pesquisa
Q2 - Qual a diferenccedila entre Processo e Ciclo de Vida
Em seu livro Engenharia de Software Pressman (2009) define processo como umconjunto de atividades de trabalho accedilotildees e tarefas realizadas quando algum artefato desoftware deve ser criado A Figura 23 representa o esquema de um processo onde cadaatividade eacute composta por um conjunto de accedilotildees Cada accedilatildeo eacute definida por um conjuntode tarefas artefatos fatores de garantia da qualidade e pontos de controle do projeto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
Figura 2 ndash Uma metodologia do processo de software (PRESSMAN 2009)
Processo eacute uma seacuterie de etapas que envolvem atividades restriccedilotildees e recursos paraalcanccedilar a saiacuteda desejada Quando um processo envolve a elaboraccedilatildeo de um produtoalgumas vezes nos referimos a ele como um ciclo de vida (PFLEEGER 2004)
Sommerville (2012) em seu livro define processo de software como um conjuntode atividades que leva agrave produccedilatildeo de um produto de software
A ISOIEC 12207 (2008) diz que o modelo do ciclo de vida eacute composto por umasequumlecircncia de etapas que podem se sobrepor e ou iterar conforme apropriado para oescopo do projeto magnitude complexidade necessidades e oportunidades em mudanccedilaCada etapa eacute descrita com uma declaraccedilatildeo de propoacutesito e resultados Os processos eatividades do ciclo de vida satildeo selecionados e empregados em uma fase para cumprira finalidade e os resultados dessa etapa Diferentes organizaccedilotildees podem realizar etapasdiferentes no ciclo de vida
Fazendo uma comparaccedilatildeo pode-se dizer que um ciclo de vida seria um item deum processo uma simplificaccedilatildeo dele ou uma outra forma de visualizaacute-lo Um processoeacute constituiacutedo por vaacuterios itens como por exemplo os citado anteriormente atividadesentradas saiacutedas e tarefas
Um exemplo eacute apresentado no livro Interaccedilatildeo Humano-Computador da SimoneBarbosa e Bruno Silva (2010) onde existe um capiacutetulo com o tiacutetulo de Processos de Design
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
de IHC que cita dentre vaacuterios o ciclo de vida em estrela e o processo de engenharia deusabilidade (MAYHEW 1999) A Figura 3 apresenta o ciclo de vida em estrela e a Figura4 apresenta o processo de Engenharia de Usabilidade definido pela Mayhew (1999)
Figura 3 ndash Ciclo de vida Estrela (HIX HARTSON 1993)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Figura 4 ndash Engenharia de Usabilidade Traduzida de (MAYHEW 1999)
Como eacute faacutecil observar um tem muito mais detalhes do que o outro aleacutem do maisque o processo apresentado na Figura 4 faz parte de um livro feito todo para explicaresse processo
23 Processos de Design de InteraccedilatildeoEsta Seccedilatildeo responde a terceira Questatildeo de Pesquisa
Q3 - Quais satildeo os Processos de Design de Interaccedilatildeo detalhados jaacute existentes naliteratura
A revisatildeo de literatura realizada eacute baseada em uma revisatildeo sistemaacutetica na aacuterea deEngenharia de Software Teve como finalidade alcanccedilar o objetivo especiacutefico de identificarum processo de design de interaccedilatildeo detalhado A revisatildeo foi dividida em 3 fases planeja-mento execuccedilatildeo da pesquisa e anaacutelise dos resultados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
Planejamento
Na fase de planejamento foram definidos os objetivos as questotildees da pesquisa e aestrateacutegia de busca
I - Objetivo - O objetivo da revisatildeo literaacuteria eacute identificar um processo de designde interaccedilatildeo detalhado jaacute existente para entatildeo se atingir o objetivo geral dessa pesquisa
II - Questatildeo de pesquisa - Para atingir o objetivo especiacutefico desta revisatildeo literaacuteriafoi definida uma questatildeo de pesquisa
Q - Quais satildeo os processos de design de interaccedilatildeo existentes considerando umniacutevel alto de detalhamento
III - Estrateacutegia de busca para a seleccedilatildeo dos trabalhos - A string de busca foidefinida em portuguecircs e utilizada tambeacutem em inglecircs utilizando os operadores loacutegicos rsquoersquoe rsquooursquo Foram definidas as seguintes strings de busca
((ldquoprocessordquo) e (ldquousabilidaderdquo ou ldquoIHCrdquo ou ldquodesign de interfacerdquo ou ldquodesign deinteraccedilatildeordquo ou ldquocentrado no usuaacuteriordquo))
ou ((ldquoprocesso de engenharia de softwarerdquo) e (ldquoIHCrdquo))
ou (ldquodesign de interaccedilatildeordquo) ou (ldquoIHCrdquo)
Como base da pesquisa foram coletados artigos e livros por meio da ferramentade busca
∙ Google Acadecircmico
∙ IEEE xplore
∙ ACM-DL Digital Library
∙ Springer Link
Como criteacuterios de inclusatildeo foram selecionados trabalhos
∙ Artigos eou livros
∙ A partir do ano de 1989
∙ Nos idiomas portuguecircs inglecircs e espanhol
Criteacuterio de exclusatildeo
∙ Trabalhos sem referecircncia a processo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Execuccedilatildeo
Primeiramente houve uma exclusatildeo dos trabalhos onde natildeo era possiacutevel encontraralguma referecircncia a processo Posteriormente houve uma seleccedilatildeo de trabalhos que retra-tavam processos de IHC ou de Design de Interaccedilatildeo ou Usabilidade integrados ou natildeo aoutras aplicaccedilotildees metodologias ou processos Por fim restaram onze (11) trabalhos paracoleta de dados apresentados na Tabela 1
A Tabela 1 apresenta os onze trabalhos identificados que possuem um processocom IHC ou design de interaccedilatildeo A lista de trabalhos selecionados estaacute organizada deacordo com as datas de publicaccedilatildeo dos trabalhos
Anaacutelise dos Resultados
Na fase final da revisatildeo literaacuteria nota-se que a grande maioria dos estudos deprocesso de IHC estaacute ligado a fazer uma relaccedilatildeo de integraccedilatildeo do processo de IHC aoprocesso de desenvolvimento de software o que tornou difiacutecil a identificaccedilatildeo de processosde design de interaccedilatildeo puros A aacuterea de Design de Interaccedilatildeo e IHC eacute um pouco subjetiva eabstrata sendo assim eacute de comum acordo entre os autores que um processo de design deinteraccedilatildeo deve seguir basicamente 4 procedimentos (ROGERS SHARP PREECE 2013)
1 Identificar necessidades e estabelecer requisitos
2 Desenvolver designs alternativos que preencham esses requisitos
3 Construir versotildees interativas dos designs de maneira que possam ser comunicadose analisados
4 Avaliar o que estaacute sendo construiacutedo durante o processo
Esses procedimentos satildeo interpretados e aplicados de acordo com o desenvolvedorlogo produz atividades e artefatos diferentes para cada processo aplicado Sobre a questatildeode pesquisa proposta para essa revisatildeo foi levantado que a maioria dos trabalhos queexistem satildeo processos que integram o design de interaccedilatildeo agrave engenharia de software ou aodesenvolvimento
Foi selecionado um trabalho para auxiliar como base para a definiccedilatildeo do processode design de interaccedilatildeo orientado a meacutetricas Os trabalhos foram analisados de acordocom o niacutevel de detalhamento dos mesmos onde esse niacutevel se refere a conter atividadesdescriccedilatildeo das atividades tarefas a serem executadas dentro de cada atividade entradas esaiacutedas da atividade e artefatos A comparaccedilatildeo entre os trabalhos eacute apresentado na Tabela2
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Tabela 1 ndash Trabalhos selecionados para Coleta de dados
No Tiacutetulo Autor(es) Complemento Ano1 Evolving the software
usability engineeringprocess at Hewlett-Packard
Rideout T andUyeda K andWilliams E
Hewlett-Packard 1989
2 Universal accessibilityin HCI Process-oriented designguidelines and toolrequirements
Stephanidis CAkoumianakisD Sfyrakis Mand ParamythisA
Foundation for Researchand Technology-Hellas(FORTH) Science andTechnology Park of CreteHeraklion Crete - Greece
1998
3 The usability enginee-ring lifecycle
Mayhew D San Francisco Calif Mor-gan Kaufmann Publishers
1999
4 Integration of Usabi-lity Techniques intothe Software Develop-ment Process
Ferre X In Bridging the Gapsbetween Software Enginee-ring and Human-ComputerInteraction InternationalConference on SoftwareEngineering ICSErsquo03Portland Oregon p 28-35
2003
5 RUPi ndash A UnifiedProcess that Integra-tes Human-ComputerInteraction and Soft-ware Engineering
Sousa K andFurtado M E
Universidade de Fortaleza 2005
6 Modelo e diretrizespara o processo de de-sign de interface webadaptativa
Batista C Universidade Federal deSanta Catarina
2008
7 Interaccedilatildeo Humano-Computador
Barbosa S andSilva B
2010
8 Integrating UsabilityEngineering and AgileSoftware Develop-mentA LiteratureReview
Sohaib O andKhan K
College of Computing andInformation Sciences PAF-KIET Karachi Pakistan
2010
9 Projetando SistemasWeb com o uso deTeacutecnicas de InteraccedilatildeoHumano-Computador
Souza P Ma-ciel C and Mo-raes L
Universidade Federal deMato Grosso (UFMT)
2012
10 Design de interaccedilatildeo Preece J Ro-gers Y SharpH and Possa-mai V
Porto Alegre Bookman 2013
11 Praacuteticas de IHCversus Processos deEngenharia de Soft-ware Uma Anaacutelisepara Adoccedilatildeo
Bastos J andOliveira S
Universidade Federal doParaacute (UFPA)
2015
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Tabela 2 ndash Niacutevel de detalhamento dos trabalhosNo Atividades Descriccedilatildeo atividades Tarefas Entradas Saiacutedas Artefatos1 X X2 X3 X X X X X X4 X5 X X6 X X X X7 X X8 X9 X X10 X11 X X
A Tabela 2 estaacute representando quais detalhes possuem os trabalhos que estatildeoclassificados por nuacutemeros O trabalho 1 conteacutem atividades e tarefas do processo jaacute osprocessos dso trabalhos 2 4 8 e 10 possuem apenas as atividades O trabalho 3 eacute o maisdetalhado e possui todos os criteacuterios estabelecidos na Tabela 2 Os trabalhos 5 7 9 e 11detalham as atividades e as descriccedilotildees das mesmas No trabalho 6 eacute possiacutevel encontraratividades do processo bem como a descriccedilatildeo tarefas e artefatos poreacutem satildeo focados parainterface web
De acordo com o apresentado na Tabela 2 eacute possiacutevel identificar que o trabalho commaior niacutevel de detalhamento eacute o da Deborah Mayhew (1999) trabalho 3 e por isso foi oescolhido para auxiliar no trabalho futuro de definir um processo de design de interaccedilatildeoorientado a meacutetricas
O livro da Mayhew D (1999) The usability engineering lifecycle descreve o pro-cesso definido pela mesma que eacute dividido em 3 fases anaacutelise de requisitos design ava-liaccedilatildeo e desenvolvimento instalaccedilatildeo Cada capiacutetulo descreve uma atividade do processobem como suas tarefas entradas e saiacutedas teacutecnicas utilizadas e artefatos produzidos
24 Qualidade de SoftwareEsta Seccedilatildeo responde a quarta Questatildeo de Pesquisa
Q4 - O que eacute Qualidade de Software
Um planejamento de projeto eficaz deve executar as mais variadas mediccedilotildees sobaspectos do produto e do projeto em si de forma a aferir indicadores que garantam me-lhores resultados no processo produtivo A mediccedilatildeo eacute feita para responder agrave objetivos demediccedilatildeo que por sua vez respondem agrave objetivos de negoacutecio onde cada contexto requerdiferentes mediccedilotildees
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
O design de interaccedilatildeo busca prover focado em usabilidade a aplicaccedilatildeo de con-ceitos construiacutedos com base na observaccedilatildeo das experiecircncias e de testes com usuaacuterios amelhoria da relaccedilatildeo homem-maacutequina No acircmbito de software considera essencialmente asatisfaccedilatildeo do usuaacuterio quanto aos requisitos estabelecidos Dentro da qualidade de softwareexiste uma caracteriacutestica que eacute a usabilidade A ISO define que usabilidade eacute tida como ograu em que um produto ou sistema pode ser usado por usuaacuterios especiacuteficos para atingirmetas especiacuteficas com eficaacutecia eficiecircncia e satisfaccedilatildeo em um contexto especiacutefico de uso(ISO25010 2011) Usabilidade eacute composta de aspectos abstratos difiacuteceis de mensurargeralmente satildeo mensurados somente apoacutes o software estar pronto o que tarda e dificultamelhorias e aumenta o custo de manutenccedilatildeorefatoraccedilatildeo
A literatura que define processos para design de interaccedilatildeo eacute escassa quanto ameacutetricas de software aplicaacuteveis e quanto a atividades relacionadas agrave mediccedilatildeo em taisprocessos o que acaba se mostrando como uma lacuna a ser preenchida considerandoque muitas vezes o sucesso de um software depende muito da experiecircncia interativa queele proporciona
241 SQuaRE
O SQuaRE eacute um conjunto de padrotildees internacionais (seacuterie ISOIEC 25000) queconstitui um framework para a avaliaccedilatildeo da qualidade de produtos de software Eacute carac-terizado por cinco divisotildees ISOIEC 2500n a 2504n que abordam diferentes perspectivasde avaliaccedilatildeo e representaccedilatildeo de modelos de qualidade
O SQuaRE realizou uma reorganizaccedilatildeo das antigas normas resultando em umanova divisatildeo conforme apresentado na Figura 5
Figura 5 ndash Divisatildeo da norma SQuaRE Traduzida de (ISO25010 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
2411 ISOIEC 25000 Divisatildeo do Gerenciamento de Qualidade
Corresponde agraves definiccedilotildees que satildeo base de todos as outras divisotildees de padrotildees doSQuaRE Oferece os guias baacutesicos que devem incluir terminologia modelo arquitetural emodelos de referecircncia Define ainda aspectos de suporte agraves atividades de gerenciamentoda especificaccedilatildeo e avaliaccedilatildeo de requisitos do produto de software
2412 ISOIEC 2501n Divisatildeo do Modelo de Qualidade
Refere-se agrave proposta detalhada de modelos para a qualidade de produtos de soft-ware em uso ou de dados Aleacutem disso conceitualiza as caracteriacutesticas e subcaracteriacutesticasrelacionadas a cada um dos modelos
A qualidade de um sistema se refere ao grau de satisfaccedilatildeo do sistema a um con-junto de necessidades definidas Nos modelos de qualidade propostos pelo SQuaRE taisnecessidades satildeo representadas pelas caracteriacutesticas A decomposiccedilatildeo hieraacuterquica podelevar ainda a subcaracteriacutesticas e a propriedades de qualidade relacionadas
O SQuaRE define trecircs modelos de qualidade que juntos devem cobrir todas ca-racteriacutesticas O primeiro deles o modelo de qualidade em uso eacute constituiacutedo por cincocaracteriacutesticas e se refere aos resultados do uso de um software em um contexto especiacute-fico Este modelo eacute capaz de caracterizar o impacto que um produto de software exercesobre os stakeholders Por sua vez o modelo de qualidade de produto de software eacute cons-tituiacutedo por oito caracteriacutesticas Enquanto a qualidade em uso tem como foco todo o con-junto humano-computador a qualidade de produto tem foco nos sistemas de computadorespeciacuteficos
2413 ISOIEC 2502n Divisatildeo da Mediccedilatildeo de Qualidade
Esta categoria corresponde agrave definiccedilatildeo de um modelo de referecircncia para a medi-ccedilatildeo de qualidade de produtos de software o que inclui um guia praacutetico e a referecircnciamatemaacutetica para a definiccedilatildeo das medidas de qualidade
Aborda alusotildees ao modelo de referecircncia incluindo guia para aplicaccedilatildeo de medi-das e definiccedilotildees de medidas baacutesicas e derivadas que satildeo entradas recomendadas para amediccedilatildeo da qualidade em uso ou qualidade do produto de software Aleacutem disso abordaindividualmente a mediccedilatildeo de qualidade em uso e qualidade de produto de softwareconsiderando as peculiaridades de cada um dos modelos de qualidade
2414 ISOIEC 2503n Divisatildeo dos Requisitos de Qualidade
A divisatildeo que engloba os padrotildees que auxiliam na especificaccedilatildeo dos requisitos dequalidade que podem ser utilizados como entrada do processo de avaliaccedilatildeo de qualidadeInclui recomendaccedilotildees e guias para a definiccedilatildeo de requisitos de qualidade
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 32
2415 ISOIEC 2504n Divisatildeo da Avaliaccedilatildeo de Qualidade
Refere-se agrave definiccedilatildeo de orientaccedilotildees para a avaliaccedilatildeo de produtos de softwareAborda os conceitos gerais para a especificaccedilatildeo e avaliaccedilatildeo da qualidade de softwarealeacutem de guias e moacutedulos para a avaliaccedilatildeo que descrevem orientaccedilotildees relacionadas agravespraacuteticas e agrave documentaccedilatildeo
242 Caracteriacutesticas de Qualidade de Software
Cada modelo de qualidade eacute formado por um conjunto de caracteriacutesticas querepresentam as possiacuteveis necessidades dos diferentes stakeholders Cada uma destas ca-racteriacutesticas pode ainda ser dividida em uma seacuterie de subcaracteriacutesticas
Figura 6 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade em uso Traduzida de(ISO25010 2011)
Apesar da usabilidade ser uma caracteriacutestica do modelo de qualidade de produtoconforme apresentado na Figura 7 o SQuaRE tambeacutem a define como um subconjuntoda qualidade em uso constituiacuteda pelas caracteriacutesticas de Eficaacutecia Eficiecircncia e Satisfaccedilatildeoconforme apresentado na Figura 6
Pela definiccedilatildeo da ISOIEC 25010 a eficaacutecia se refere agrave precisatildeo e completude comque um usuaacuterio realiza seus objetivos especiacuteficos A eficiecircncia por sua vez se refere aosrecursos gastos levando em consideraccedilatildeo a eficaacutecia no cumprimento dos mesmos propoacutesi-tos Define-se ainda a satisfaccedilatildeo como a resposta do usuaacuterio agrave interaccedilatildeo com o sistemasendo o grau de realizaccedilatildeo de suas necessidades expressa pelas quatro subcaracteriacutesticasde utilidade confianccedila prazer e conforto
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 33
∙ Utilidade diz respeito ao grau de satisfaccedilatildeo do ponto de vista do usuaacuterio o queinclui os resultados aparentes de sua utilizaccedilatildeo
∙ Confianccedila reflete o grau de confiabilidade do comportamento do sistema aindado ponto de vista do usuaacuterio
∙ Prazer refere-se ao grau de aprazimento do usuaacuterio decorrente agrave utilizaccedilatildeo dosistema mais especificamente agrave realizaccedilatildeo de suas necessidades
∙ Conforto grau de conforto fiacutesico decorrente agrave utilizaccedilatildeo do sistema
Figura 7 ndash Caracteriacutesticas e subcaracteriacutesticas de qualidade do produto Traduzida de(ISO25010 2011)
Outra alternativa eacute especificar a usabilidade atraveacutes das seis subcaracteriacutesticasdefinidas do ponto de vista da qualidade de produto Neste caso a usabilidade diz respeitoao grau com que o sistema ao ser usado por um grupo especiacutefico de usuaacuterios em umcontexto predeterminado eacute capaz de garantir eficiecircncia eficaacutecia e satisfaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 34
∙ Reconhecimento de adequaccedilatildeo grau de capacidade do usuaacuterio em reconhecerque o sistema eacute adequado para suas necessidades a partir das impressotildees iniciais oudocumentaccedilotildees associadas (como por exemplo tutoriais viacutedeos e seccedilotildees de ajuda)
∙ Capacidade de aprendizado expressa a capacidade de um grupo de usuaacuteriosalcanccedilar objetivos de aprendizado em relaccedilatildeo agrave utilizaccedilatildeo do sistema
∙ Operabilidade grau de facilidade do sistema em ser operado e controlado
∙ Proteccedilatildeo a erros de usuaacuterio representa a capacidade do sistema em evitar queusuaacuterios cometam erros
∙ Interface de usuaacuterio retrata o prazer e a satisfaccedilatildeo que o sistema proporcionapara os usuaacuterios Refere-se especificamente a elementos esteacuteticos
∙ Acessibilidade refere-se agrave capacidade do sistema em ser utilizado por diferentesusuaacuterios que apresentam diferentes caracteriacutesticas e capacidades Tais caracteriacutesti-cas incluem por exemplo idade avanccedilada ou incapacidades fiacutesicas
243 Goal Question Metric (GQM)
O GQM se refere ao processo de Mediccedilatildeo de Software Dirigido a Objetivos Baseia-se em princiacutepios baacutesicos que indicam que os objetivos de mediccedilatildeo satildeo derivados dos obje-tivos de negoacutecio que modelos mentais em evoluccedilatildeo auxiliam na manutenccedilatildeo do contextoe que o processo em questatildeo eacute capaz de formalizar objetivos em estruturas de mediccedilatildeo
Conforme apresentado na Figura 8 pode-se observar quatro fases no processo doGQM partindo do planejamento seguido pelas etapas de definiccedilatildeo e coleta de dados ateacutealcanccedilar a interpretaccedilatildeo dos resultados
Figura 8 ndash Fases do GQM Traduzida de (SOLINGEN BERGHOUT 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 35
A primeira fase diz respeito ao planejamento Neste contexto planejar significaestabelecer as definiccedilotildees fundamentais por exemplo a aacuterea de melhoria a equipe e ocontexto
A fase de definiccedilatildeo diz respeito agrave identificaccedilatildeo dos objetivos questotildees e meacutetricasnesta ordem Para cada objetivo espera-se identificar diferentes questotildees e para cadauma destas uacuteltimas diversas meacutetricas relacionadas
Os objetivos de mediccedilatildeo devem ser claros e bem definidos refletindo com precisatildeoa motivaccedilatildeo da organizaccedilatildeo Objetivos especiacuteficos devem ser derivados a partir de umobjetivo geral que deve refletir o objeto sobre mediccedilatildeo o propoacutesito e o contexto ATabela 3 descreve um template de exemplo para a descriccedilatildeo do objetivo de mediccedilatildeo
Tabela 3 ndash Template para definir objetivo Traduzido de (SOLINGEN BERGHOUT1999)
Analisar o design da in-terface
Com o Propoacutesito de melhorar a qua-lidade do pro-duto
Com respeito a qualidade do de-sign da interaccedilatildeo
Sob ponto de vista do usuaacuterio dosistema
No contexto o ambiente que amediccedilatildeo ocorre
Cada objetivo de mediccedilatildeo deve ser caracterizado por uma seacuterie de questotildees e cadauma destas uacuteltimas deve ser associada a uma seacuterie de meacutetricas Para a definiccedilatildeo destes ele-mentos propotildee-se a utilizaccedilatildeo de Abstraction Sheets (SOLINGEN BERGHOUT 1999)que direciona o levantamento as questotildees de interesse a partir de uma estrutura definidaapresentada na Tabela 4
Tabela 4 ndash Abstraction Sheet Traduzido de (SOLINGEN BERGHOUT 1999)
Foco de Qualidade Fatores de VariaccedilatildeoQuais satildeo as possiacuteveis meacutetricas paramedir o objeto do objetivo de acordocom os especialistas
Quais fatores os especialistas acham que in-fluenciam o resultado dessa meacutetrica
Hipoacuteteses de Baseline Impactos nas hipoacuteteses de BaselineQual eacute o conhecimento atual dos es-pecialistas com respeito a essas meacutetri-cas Suas expectativas satildeo documenta-das como hipoacutetese de baseline para asmeacutetricas
Como esses fatores influenciam as mediccedilotildeesatuais Que tipo de dependecircncias haacute entre asmeacutetricas e os fatores de variaccedilatildeo
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 36
A fase de coleta de dados segue a definiccedilatildeo das meacutetricas e trata da definiccedilatildeo eexecuccedilatildeo dos processos de extraccedilatildeo das informaccedilotildees Os resultados obtidos nesta fase seratildeoentrada para a fase de interpretaccedilatildeo onde a anaacutelise dos elementos seraacute feita em ordeminversa agrave trabalhada na fase de definiccedilatildeo Isto eacute a partir dos resultados obtidos para asmeacutetricas identificadas responder agraves questotildees que por sua vez respondem aos objetivosde mediccedilatildeo
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
37
3 Especificaccedilatildeo do Processo
Para o desenvolvimento do processo de interaccedilatildeo orientado a meacutetricas propostoneste trabalho foi utilizado como base o processo da Mayhew D (1999) para a definiccedilatildeodo processo orientado a meacutetricas Assim vale ressaltar que por ter sido baseado emum processo jaacute existente algumas especificaccedilotildees das atividades estatildeo parecidas com asdefinidas por Mayhew Eacute possiacutevel ver um exemplo do GQM no Apendice C
A Figura 9 apresenta o Processo de Design de Interaccedilatildeo Orientado a Meacutetricasmodelado na ferramenta BONITASOFT v731 O processo representado consiste emduas fases
1 Anaacutelise de requisitos
2 Design avaliaccedilatildeo e desenvolvimento
Cada fase tem suas atividades que estatildeo representadas por retacircngulos azuis e oartefato gerado e modificado eacute o guia de estilo
31 Objetivo do ProcessoA identificaccedilatildeo tardia de uma maacute qualidade do software pode acarretar em custos
para o cliente sem falar na insatisfaccedilatildeo do usuaacuterio final Eacute por isso que o desenvolvi-mento de software vem cada dia mais sendo realizado com o auxiacutelio de IHC que visa acentralizaccedilatildeo no usuaacuterio Mesmo com o processo voltado para o usuaacuterio eacute difiacutecil mensu-rar a qualidade do produto Diante disso foi proposto um processo orientado a meacutetricaspara que durante todo processo essa qualidade seja medida qualitativa ou quantitati-vamente O processo eacute dividido em duas fases anaacutelise de requisitos design avaliaccedilatildeo edesenvolvimento
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 38
Figura 9 ndash Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 39
32 Objetivo das Fases
321 Anaacutelise de Requisitos
A fase de anaacutelise de requisitos como o proacuteprio nome diz eacute responsaacutevel pela identifi-caccedilatildeo dos requisitos buscando compreender todo o cenaacuterio em que o sistema seraacute inseridoEacute nessa fase que o GQM eacute planejado e satildeo definidos o objetivo e as questotildees em relaccedilatildeo aqualidade do produto como pode ser observado na faixa superior do processo na Figura9 Atualmente na literatura existem templates para auxiliar na definiccedilatildeo do objetivo oApendice C desse trabalho apresenta um exemplo de GQM definido para um projeto
322 Design Avaliaccedilatildeo e Desenvolvimento
A faixa central do processo eacute a fase de design avaliaccedilatildeo e desenvolvimento queeacute onde ocorre a construccedilatildeo do sistema juntamente com seu design e eacute dividida em trecircsniacuteveis No primeiro niacutevel eacute realizado o modelo conceitual no segundo niacutevel os padrotildees dedesign de tela e por uacuteltimo o design detalhado da interface com o usuaacuterio como mostra a9 Todos os niacuteveis satildeo seguidos de avaliaccedilotildees e definiccedilatildeo das meacutetricas para cada niacutevel Ameacutetricas podem ser matidas alteradas ou incluiacutedas de acordo com o niacutevel de maturidadeda interface
33 Detalhamento dos PapeacuteisOs papeacuteis para o processo de design de interaccedilatildeo orientado a meacutetricas foram
definidos seguindo a matriz de responsabilidades RACI conforme definido por COBIT(ISACA 2012) RACI em inglecircs significa responsible accountable consulted informeduma traduccedilatildeo pode ser vista em (CHAVES et al 2013) como responsaacutevel autorizadorconsultado e informado onde o mesmo diz que
∙ lsquoRrsquo (Responsaacutevel) - eacute quem executa a tarefa
∙ lsquoArsquo (Autorizador) - eacute quem eacute responsabilizado pela execuccedilatildeo correta da tarefa muitasvezes eacute o dono do projeto
∙ lsquoCrsquo (Consultado) - satildeo as pessoas que fornecem informaccedilotildees para o projeto
∙ lsquoIrsquo (Informado) - eacute quem recebe informaccedilotildees sobre o progresso da tarefa
A matriz de responsabilidade definida para esse processo eacute apresentado na Figura10
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 40
Figura 10 ndash Matriz de Responsabilidades RACI definida para o Processo
34 Responsabilidades dos PapeacuteisOs papeacuteis e suas responsabilidades identificados nesse processo foram
∙ Gerente de Equipe - eacute o responsaacutevel de TI (Tecnologia da Informaccedilatildeo) pelo projetoem desenvolvimento
∙ Gerente de Projeto - eacute o responsaacutevel pelo projeto bem como seu andamento
∙ Analista de Requisitos - eacute o responsaacutevel por identificar os requisitos do sistema
∙ Analista de Usabilidade - eacute o responsaacutevel pela usabilidade do sistema
∙ Analista de Meacutetricas - eacute o responsaacutevel por definir e analisar meacutetricas
∙ Desenvolvedor - eacute o responsaacutevel por desenvolver o sistema
∙ Usuaacuterio - eacute o usuaacuterio final do sistema
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 41
35 Especificaccedilatildeo das Atividades
351 Definiccedilatildeo do Perfil do Usuaacuterio
Tabela 5 ndash Definiccedilatildeo do Perfil do Usuaacuterio
Objetivo Determinar o perfil dos usuaacuterios do sistemaDescriccedilatildeo Desenvolve uma descriccedilatildeo do puacuteblico alvo esperado em rela-
ccedilatildeo a caracteriacutesticas relevantes para o design de interface deusuaacuterio
Entrada(s) Natildeo haacuteSaiacuteda(s)
∙ Questionaacuterioentrevista
∙ Resumo dos dados
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Guia de Estilo
Teacutecnica(s)
∙ Entrevista eou questionaacuterio
Tarefas
1 Determinar a categoria do usuaacuterio
2 Definir caracteriacutesticas relevantes do usuaacuterio (Ex Carac-teriacutesticas fiacutesicas ou psicoloacutegicas)
3 Analisar as caracteriacutesticas e definir o puacuteblico alvo
Papeacuteis envolvidos
R - Analista de RequisitosA - Gerente de EquipeC - Analista de Usabilidade e UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 42
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 43
352 Anaacutelise de Tarefas
Tabela 6 ndash Anaacutelise de TarefasObjetivo Obter um modelo de trabalho centralizado no usuaacuterioDescriccedilatildeo Conduzir um estudo do usuaacuterio realizando seu trabalho em
um contexto realEntrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
Saiacuteda(s)
∙ Anaacutelises do ambiente de trabalho
∙ Tarefas de cenaacuterio
∙ Atual modelo de trabalho do usuaacuterio
∙ Guia de Estilo
Teacutecnica(s)
∙ Observaccedilatildeo direta ou entrevista
∙ Modelos formais de trabalho
∙ Brainstorming com tarefas do cenaacuterio
∙ Mapeamento da trajetoacuteria
∙ Entrevistar pessoas com conhecimento sobre tarefas detrabalho e ambiente do usuaacuterio
Tarefas
1 Analisar o documento de visatildeo (se existir) aacutes vezes eacutepossiacutevel identificar informaccedilotildees sobre o atual modelo detrabalho do usuaacuterio
2 Reunir com membros das equipes do projeto como porexemplo analistas desenvolvedores e gerentes
3 Reunir com um representante de usuaacuterio final
4 Definir atores e casos de uso principais para guiar umfluxo principal de trabalho
5 Conduzir observaccedilotildees e entrevistas com o usuaacuterio final
6 Documentar a anaacutelise do ambiente de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 44
353 Definiccedilatildeo das Caracteriacutesticas da Plataforma
Tabela 7 ndash Definiccedilatildeo das Caracteriacutesticas da Plataforma
Objetivo Estabelecer os recursos e restriccedilotildees da plataforma tecnoloacutegicaa qual iraacute limitar as alternativas de design da interface deusuaacuterio
Descriccedilatildeo Estudo dos recursos e restriccedilotildees da plataforma para interfacede usuaacuterio escolhida para o produto
Entrada(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo da plataforma escolhida
Saiacuteda(s)
∙ Guia de Estilo
∙ Documentaccedilatildeo dos recursos e restriccedilotildees da plataforma
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo da plataforma
∙ Entrevista com especialistas na plataforma
Tarefas
1 Identificar todos os aspectos relevantes de hardware esoftware da plataforma
2 Revisar qualquer documentaccedilatildeo da plataforma
3 Entrevistar desenvolvedores
4 Documentar recursos e restriccedilotildees da plataforma esco-lhida
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - DesenvolvedorI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 45
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 46
354 Definiccedilatildeo das Metas de Usabilidade
Tabela 8 ndash Definiccedilatildeo das Metas de Usabilidade
Objetivo Estabelecer especiacuteficas metas quantitativas e qualitativas deusabilidade que iratildeo guiar o design de interface do usuaacuterio
Descriccedilatildeo Extrair metas qualitativas de usabilidade de tarefas anteriorese tambeacutem das regras de negoacutecio para guiar o design de inter-face de usuaacuterio e quantificar um subconjunto de metas de altaprioridade para serem utilizadas nos criteacuterios de aceitaccedilatildeo dostestes de usabilidade
Entrada(s)
∙ Guia de Estilo
∙ Anaacutelises e conclusotildees do puacuteblico alvo
∙ Anaacutelises do ambiente de trabalho
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Documentaccedilatildeo de metas de usabilidade
∙ Guia de estilo
Teacutecnica(s)
∙ Revisatildeo da documentaccedilatildeo do puacuteblico alvo
∙ Revisatildeo das tarefas do ambiente de trabalho
Tarefas
1 Revisar o puacuteblico alvo a partir dele podem ser identifi-cadas metas de usabilidade (Ex Usuaacuterios de plataformaWindows se adaptam melhor com sistemas que sigam amesma interface)
2 Revisar a anaacutelise das tarefas realizadas pelo usuaacuterio (ExUm usuaacuterio onde eacute interrompido frequentemente en-quanto realiza uma tarefa teria mais facilidade de usarum sistema que o lembre rapidamente onde ele parou)
3 Identificar as metas de usabilidade qualitativas
4 Formular metas quantitativas de usabilidade
5 Priorizar e documentar as metas de usabilidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 47
355 Planejamento do GQM
Tabela 9 ndash Planejamento do GQM
Objetivo Planejar o GQM para alcanccedilar o objetivo desejadoDescriccedilatildeo Eacute a fase do plano do projeto onde se define qual o projeto de
aplicaccedilatildeo o time GQM e a aacuterea de melhoriaEntrada(s)
∙ Documento de visatildeo
Saiacuteda(s)
∙ Planejamento do GQM
Teacutecnica(s) Natildeo haacuteTarefas
1 Definir o projeto de aplicaccedilatildeo do GQM
2 Definir o time GQM quem satildeo os responsaacuteveis por fazero GQM
3 Definir a aacuterea de melhoria
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 48
356 Definiccedilatildeo do Objetivo e Questotildees
Tabela 10 ndash Definiccedilatildeo do Objetivo e Questotildees
Objetivo Definir o objetivo da mediccedilatildeo e as questotildeesDescriccedilatildeo Definir o objetivo de mediccedilatildeo e as questotildees para alcanccedilar esse
objetivoEntrada(s)
∙ Planejamento do GQM
∙ Documento de visatildeo
∙ Guia de estilo
Saiacuteda(s)
∙ Objetivo e questotildees
Teacutecnica(s)
∙ Existem templates que auxiliam na definiccedilatildeo do objetivode mediccedilatildeo
Tarefas
1 Definir o objetivo de mediccedilatildeo
2 Definir as questotildees
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 49
357 Engenharia do Trabalho
Tabela 11 ndash Engenharia do Trabalho
Objetivo Estruturar ou reestruturar o atual modelo de trabalho dousuaacuterio com o propoacutesito de realizar o potencial de automaccedilatildeoe mais eficiente suporte de metas de negoacutecio minimizando oretrabalho e maximizando a produtividade
Descriccedilatildeo Estruturar ou reestruturar o atual modelo de trabalho e do-cumentar o mesmo em um modelo descrevendo como a funci-onalidade do produto seraacute organizada e estruturada O atualmodelo de trabalho do usuaacuterio soacute eacute reestruturado se for ne-cessaacuterio explorar o potencial de automaccedilatildeo
Entrada(s)
∙ Atual modelo de trabalho do usuaacuterio
Saiacuteda(s)
∙ Modelo de reengenharia do trabalho
Teacutecnica(s)
∙ Orientaccedilotildees de tarefas de cenaacuterio
Tarefas
1 Refazer o modelo de trabalho
2 Validar com o usuaacuterio o novo modelo
3 Documentar o novo modelo de trabalho
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 50
358 Projeto do Modelo Conceitual
Tabela 12 ndash Projeto do Modelo Conceitual
Objetivo Ilustrar os principais conceitos do domiacutenio do problemaDescriccedilatildeo Conduz o primeiro passo no atual design de interface do usuaacute-
rio Projeta um conjunto de alto niacutevel de regras de apresen-taccedilatildeo e interaccedilatildeo aleacutem de identificar a maioria das telas ecaminhos entre elas
Entrada(s)
∙ Guia de Estilo
∙ Modelo de engenharia do trabalho
Saiacuteda(s)
∙ Guia de Estilo
∙ Projeto de modelo conceitual
Teacutecnica(s)
∙ Adaptaccedilatildeo do Guia de Estilo da plataforma (Ex MSWindows Apple Macintosh)
∙ Gera regras de apresentaccedilatildeo que satildeo mapeadas com omodelo de reengenharia do trabalho
Tarefas
1 Definir o modelo conceitual para o produto ou processo
2 Identificar claramente todos os produtos ou processos
3 Projeta regras de apresentaccedilatildeo do produto ou processo
4 Projetar regras para as janelasIdentificar as principaistelas
5 Definir o caminho navegacional das principais telas
Eacute importante ressaltar que as representaccedilotildees natildeosejam detalhadas para natildeo se perder muito tempo emdefiniccedilotildees precoces
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 51
359 Prototipagem do Modelo Conceitual
Tabela 13 ndash Prototipagem do Modelo Conceitual
Objetivo Suportar avaliaccedilatildeo refinamento e validaccedilatildeo do design do mo-delo conceitual
Descriccedilatildeo Incorpora as regras de design que foram definidas no modeloconceitual em um protoacutetipo de algumas funcionalidades doproduto
Entrada(s)
∙ Modelo conceitual
Saiacuteda(s)
∙ Protoacutetipos de papel e caneta
∙ Protoacutetipo de baixa fidelidade
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Selecionar as principais funcionalidades
2 Modelar o design da interface para essas funcionalida-des
3 Construir os protoacutetipos de papel ou executaacuteveis embaixa fidelidade
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 52
3510 Definiccedilatildeo de Meacutetricas
Tabela 14 ndash Definiccedilatildeo de Meacutetricas
Objetivo Definir meacutetricas para o produtoDescriccedilatildeo Esta atividade ocorre em vaacuterias etapas do processo onde as
meacutetricas satildeo elaboradas de acordo com o produto que estaacutesendo avaliado com a evoluccedilatildeo do produto podem ser acres-centadas meacutetricas (Ex meacutetricas para interface rodando satildeomais especiacuteficas do que para protoacutetipo de papel)
Entrada(s)
∙ Documento de visatildeo
∙ Modelo conceitual
∙ Guia de estilo
∙ Padrotildees de tela
∙ Meacutetricas
Saiacuteda(s)
∙ Abstraction sheet
Teacutecnica(s)
∙ Prototipagem de papel e caneta
∙ Prototipagem executaacutevel em baixa fidelidade
Tarefas
1 Analisar as questotildees
2 Preencher o abstraction sheet
3 Definir as meacutetricas para o produto
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 53
3511 Avaliaccedilatildeo Iterativa do Modelo Conceitual
Tabela 15 ndash Avaliaccedilatildeo Iterativa do Modelo Conceitual
Objetivo Avaliar refinar e validar o projeto do modelo conceitualDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-
liaccedilatildeo para iterativamente avaliar refinar e validar o projetodo modelo conceitual
Entrada(s)
∙ Modelo conceitual
∙ Protoacutetipo do modelo conceitual
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
∙ Definir os usuaacuterios e tarefas para o teste de usabilidade
∙ Planejar a avaliaccedilatildeo
∙ Recrutar usuaacuterios para realizar a avaliaccedilatildeo
∙ Realizar a avaliaccedilatildeo e coletar dados
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 54
3512 Anaacutelise dos Dados Coletados
Tabela 16 ndash Anaacutelise dos Dados ColetadosObjetivo Analisar os dados coletadosDescriccedilatildeo Essa atividade ocorre apoacutes avaliaccedilatildeo do produto (em cada niacute-
vel o produto tem um niacutevel de maturidade) a partir dos dadoscoletados eacute feita a anaacutelise por meio das meacutetricas definidas
Entrada(s)
∙ Produto (protoacutetipo ou sistema)
∙ Meacutetricas
∙ Dados coletados nas avaliaccedilotildees
Saiacuteda(s)
∙ Relatoacuterio consolidado da avaliaccedilatildeo
Teacutecnica(s)
∙ Orientado a meacutetricas
Tarefas
1 Pegar os dados coletados da avaliaccedilatildeo
2 Analisar os dados coletados de acordo com as meacutetricas
Papeacuteis envolvidos
R - Analista de Usabilidade e Analista de MeacutetricasA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Equipe
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 55
3513 Definiccedilatildeo dos Padrotildees de Design de Tela
Tabela 17 ndash Definiccedilatildeo dos Padrotildees de Design de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Conduz o segundo niacutevel do design da interface do usuaacuterioDesign um conjunto de padrotildees de tela que guiaraacute a consis-tecircncia entre o design da interface do usuaacuterio e a interaccedilatildeo dainterface do produto
Entrada(s)
∙ Projeto do modelo conceitual
∙ Protoacutetipo do modelo conceitual
∙ Guia de estilo
Saiacuteda(s)
∙ Padrotildees de design de tela
∙ Guia de estilo
Teacutecnica(s)
∙ Adaptaccedilatildeo de guias de estilo jaacute existentes
Tarefas
1 Esboccedilar padrotildees de controle (Ex Tentar utilizar omesmo tipo de escolha para o design como check box)
2 Esboccedilar padrotildees para telas dos produtos ou processos
3 Esboccedilar padrotildees para caixa de diaacutelogo
4 Esboccedilar padrotildees para mensagens de diaacutelogo
5 Esboccedilar padrotildees de feedback para o usuaacuterio
6 Esboccedilar design de interaccedilotildees do usuaacuterio (Ex Um cliquecom o mouse)
7 Documentar todos os padrotildees definidos
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 56
3514 Prototipagem dos Padrotildees de Deseign de Tela
Tabela 18 ndash Prototipagem dos Padrotildees de Deseign de Tela
Objetivo Estabelecer e definir um conjunto de padrotildees de design le-vando em consideraccedilatildeo a expectativa natural do usuaacuterio emutilizar um sistema
Descriccedilatildeo Incorpora os padrotildees de design da tela em um protoacutetipo doconjunto de algumas funcionalidades do produto
Entrada(s)
∙ Padrotildees de design de tela
Saiacuteda(s)
∙ Protoacutetipo executaacutevel
Teacutecnica(s)
∙ Prototipagem executaacutevel
Tarefas
1 Selecionar as funcionalidades para serem prototipadas
2 Construir o protoacutetipo executaacutevel
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - Natildeo haacuteI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 57
3515 Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Tabela 19 ndash Avaliaccedilatildeo Iterativa dos Protoacutetipos de Tela
Objetivo Avaliar refinar e validar os padrotildees de design de telaDescriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de avali-
accedilatildeo para iterativamente avaliar refinar e validar os padrotildeesde design de tela
Entrada(s)
∙ Modelo Conceitual
∙ Padrotildees de design de tela
∙ Protoacutetipo do design de tela
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Testes formais de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeoRecrutar usuaacuterios para realizar aavaliaccedilatildeo
3 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 58
3516 Design Detalhado da Interface do Usuaacuterio
Tabela 20 ndash Design Detalhado da Interface do Usuaacuterio
Objetivo Projetar a interface do usuaacuterio do produto completa e deta-lhadamente
Descriccedilatildeo Eacute o terceiro niacutevel do design da interface do usuaacuterio Projeta edocumenta toda a interface de usuaacuterio do produto em detalhescomo uma especificaccedilatildeo de interface de usuaacuterio
Entrada(s)
∙ Guia de Estilo
∙ Padrotildees de design de tela
∙ Modelo conceitual
Saiacuteda(s)
∙ Especificaccedilatildeo do design detalhado da interface do usuaacute-rio
Teacutecnica(s)
∙ Os padrotildees do Guia de Estilo devem ser aplicados paraprojetar todas as interfaces do usuaacuterio de todas as fun-cionalidades do produto
Tarefas
1 Fazer o caminho de todas as telas e caixas de diaacutelogo ede mensagem
2 Completar o design da barra de menu e todas outrasaccedilotildees de controle
3 Completar o design da interaccedilatildeo com o usuaacuterio
Papeacuteis envolvidos
R - DesenvolvedorA - Gerente de EquipeC - Analista de UsabilidadeI - Gerente de Projeto
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 3 Especificaccedilatildeo do Processo 59
3517 Avaliaccedilatildeo Iterativa do Design Detalhado
Tabela 21 ndash Avaliaccedilatildeo Iterativa do Design Detalhado
Objetivo Avaliar refinar e validar o design detalhado da interface dousuaacuterio Expandir o escopo de todas as avaliaccedilotildees de tarefade interface do usuaacuterio anteriores
Descriccedilatildeo Aplicar uma dentre a variedade de teacutecnicas objetivas de ava-liaccedilatildeo para iterativamente avaliar refinar e validar o designdetalhado da interface do usuaacuterio assim que for feito
Entrada(s)
∙ Documento do design detalhado da interface
∙ Guia de estilo
Saiacuteda(s)
∙ Plano de avaliaccedilatildeo
∙ Materiais da avaliaccedilatildeo
∙ Dados da avaliaccedilatildeo
Teacutecnica(s)
∙ Formais testes de usabilidade
∙ Meacutetodos de inspeccedilatildeo de usabilidade
Tarefas
1 Definir os usuaacuterios e tarefas para o teste de usabilidade
2 Planejar a avaliaccedilatildeo
3 Recrutar usuaacuterios para realizar a avaliaccedilatildeo
4 Realizar a avaliaccedilatildeo e coletar dados
Papeacuteis envolvidos
R - Analista de UsabilidadeA - Gerente de EquipeC - UsuaacuterioI - Gerente de Projeto
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
60
4 Avaliaccedilatildeo do Processo de Design de Inte-raccedilatildeo Orientado a Meacutetricas
41 QuestionaacuterioUma pesquisa eacute muitas vezes uma investigaccedilatildeo realizada retrospectivamente quando
por exemplo uma ferramenta ou teacutecnica tem sido usada por um tempo O principal meiode coletar dados qualitativos ou quantitativos satildeo entrevistas ou questionaacuterios Estes satildeofeitos atraveacutes da tomada de uma amostra que eacute representativa da populaccedilatildeo a ser estu-dada Os resultados da pesquisa satildeo entatildeo analisados para derivar conclusotildees descritivase explicativas (WOHLIN et al 2012)
411 Puacuteblico Alvo
O questionaacuterio foi aplicado inicialmente com os alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo da Faculdade de Tecnologia da Uni-versidade de Brasiacutelia Esse grupo avaliou a versatildeo 1 do processo que pode ser vista noApendice A
A nova versatildeo (versatildeo 2) do processo foi feita a partir das consideraccedilotildees apontadaspelos alunos do lato sensu a mesma pode ser vista no Apendice A Entatildeo o questionaacuteriofoi aplicado com a versatildeo 2 para os alunos que jaacute cursaram a disciplina de InteraccedilatildeoHumano-Computador do curso de Engenharia de Software da Faculdade do Gama (UnB-FGA) e alunos cursando a disciplina de Melhoria de Processos de Software (MPS) tambeacutemda FGA
A uacuteltima versatildeo do processo versatildeo 3 foi criada a partir da anaacutelise dos dados epode ser vista no Capiacutetulo 3
Cada grupo possui um perfil que pode agregar valor ao processo desenvolvidoO questionaacuterio foi aplicado com o grupo da poacutes-graduaccedilatildeo no final de uma disciplinarelacionada a qualidade de processos e com alunos cursando uma disciplina de melhoriade processo portanto estes alunos possuem um conhecimento maior sobre processo Jaacuteo grupo de alunos que cursaram a disciplina de IHC possuem conhecimento na aacuterea deDesign de Interaccedilatildeo
412 O questionaacuterio
O questionaacuterio foi feito na ferramenta TYPEFORM e contecircm 25 questotildees que satildeodo tipo muacuteltipla escolha sim ou natildeo classificaccedilatildeo escala e texto As questotildees satildeo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 4 Avaliaccedilatildeo do Processo 61
1 Qual o seu grau de conhecimento sobre Interaccedilatildeo Humano-Computador
2 Vocecirc jaacute trabalhou ou trabalha na aacuterea de IHC
3 Qual o seu grau de conhecimento sobre processos e ciclos de vida utilizados naEngenharia de Software
4 Vocecirc jaacute trabalhou ou trabalha na aacuterea de Processo de Software
5 Qual o seu niacutevel de familiaridade com Systems and software Quality Requirementsand Evaluation (SQuaRE)
6 Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade deSoftware
7 Qual a sua familiaridade com o meacutetodo Goal Questions Metrics (GQM) para realizarmediccedilotildees de qualidade do produto
8 Vocecirc conhece eou utiliza processos de design de interaccedilatildeo
9 Vocecirc jaacute utilizou algum processo de design de interaccedilatildeo orientado a meacutetricas
10 Durante o desenvolvimento de um produto vocecirc se preocupa em observar as Metasdecorrentes da Experiecircncia do Usuaacuterio
11 Vocecirc considera as Heuriacutesticas de Nielsen como premissas importantes
12 Eacute possiacutevel medir a qualidade da interface a partir do processo
13 Vocecirc acha que identificar os papeacuteis e suas responsabilidades em um processo eacuteimportante
14 Classifique o processo em relaccedilatildeo ao seu tamanho
15 Decirc uma nota para a complexidade do processo
16 O processo estaacute modularizado
17 O nuacutemero de atividades do processo estaacute adequado
18 O Processo de Design de Interaccedilatildeo Orientado a Meacutetricas proposto eacute de faacutecil enten-dimento
19 Avalie o processo em relaccedilatildeo a sua efetividade
20 Avalie o processo em relaccedilatildeo a sua eficiecircncia
21 Decirc uma nota para a consistecircncia do processo
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 4 Avaliaccedilatildeo do Processo 62
22 Avalie a flexibilidade do processo
23 Vocecirc adotaria esse Processo de Design de Interaccedilatildeo Orientado a Meacutetricas
24 Decirc uma nota para a qualidade do processo
25 Qual a sua sugestatildeo de melhoria para o Processo de Design de Interaccedilatildeo Orientadoa Meacutetricas proposto
413 Dados Coletados
Foram realizadas 3 coletas de dados na primeira o questionaacuterio foi respondido por29 alunos da poacutes-graduaccedilatildeo (lato-sensu) utilizando a versatildeo 1 do processo A segunda eterceira coleta foram com a versatildeo 2 do processo onde 18 alunos que cursaram IHC e 12alunos cursando Melhoria de Processo de Software (MPS) responderam o questionaacuterioEssa Seccedilatildeo relata o resumo dos dados coletados para definir o perfil das pessoas queresponderam o questionaacuterio como mostram as Tabela 22 Tabela 23 e Tabela 24 O IDsignifica o nuacutemero da questatildeo de acordo com os nuacutemeros da Seccedilatildeo 422 pergunta poacutesrepresenta a quantidade de alunos da poacutes graduaccedilatildeo que responderam IHC a quantidadede alunos de Engenharia de Software que jaacute cursaram a disciplina de IHC que responderame MPS a quantidade de alunos da disciplina Melhoria de Processo que preencheram oquestionaacuterio
414 Anaacutelise dos Dados
Como jaacute dito anteriormente foram realizadas 3 rodadas da pesquisa por meio doquestionaacuterio A primeira parte do questionaacuterio tinha o objetivo de definir o perfil dosentrevistados e a segunda parte avaliar a qualidade do processo Sendo assim foi possiacutevelidentificar que a maioria dos entrevistados possui nenhum ou pouco conhecimento sobreIHC
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 4 Avaliaccedilatildeo do Processo 63
Figura 11 ndash Graacutefico de Conhecimento em IHC
O graacutefico da Figura 11 ilustra a porcentagem do niacutevel de conhecimento dos dadoscoletados de acordo com a pergunta 1 do questionaacuterio Qual o seu grau de conhecimentosobre Interaccedilatildeo Humano-Computador Onde apenas 10 possui muito bom conheci-mento em IHC 8 bom 15 razoaacutevel 32 pouco conhecimento e 35 nenhum
Figura 12 ndash Graacutefico de Conhecimento em Processos e Ciclos de Vida
Como o objetivo dessa pesquisa era avaliar o processo foi perguntado o niacutevel de
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 4 Avaliaccedilatildeo do Processo 64
conhecimento sobre Processos e Ciclos de Vida de Software como pode ser visto na Figura12 Esse graacutefico representa os dados da pergunta 3 Qual o seu grau de conhecimentosobre processos e ciclos de vida utilizados na Engenharia de Software A partir daanaacutelise do mesmo eacute possiacutevel perceber que a grande maioria dos entrevistados conhecesobre o assunto onde 17 possui um grau de conhecimento muito bom 41 possui umconhecimento bom e 19 razoaacutevel
Outro conhecimento questionado foi sobre Qualidade de Software na pergunta 6Qual o seu grau de conhecimento a cerca dos conceitos e normas de Qualidade de Soft-ware O processo proposto nesse trabalho relaciona qualidade com design de interaccedilatildeoportanto eacute importante saber o niacutevel de conhecimento sobre o tema A Figura 13 mostraque apenas 2 possui muito bom conhecimento 17 bom 38 razoaacutevel 38 pouco e2 nenhum
Figura 13 ndash Graacutefico de Conhecimento sobre Qualidade de Software
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 4 Avaliaccedilatildeo do Processo 65
Figura 14 ndash Graacutefico de Conhecimento sobre GQM
Dentro da qualidade de Software existe um meacutetodo chamado GQM que eacute utilizadono processo proposto para realizar mediccedilotildees Eacute entatildeo que entra a questatildeo 7 Qual a suafamiliaridade com o meacutetodo Goal Questions Metrics (GQM) para realizar mediccedilotildees dequalidade do produto A Figura 14 mostra que a maioria dos entrevistados possui umniacutevel de familiaridade razoaacutevel em relaccedilatildeo ao GQM
A primeira avaliaccedilatildeo realizada foi com os alunos da poacutes-graduaccedilatildeo que estavamcursando a disciplina de Qualidade de Processo de Software e por isso foram consideradosno perfil de conhecedores de processos jaacute que 52 desses entrevistados possuem conheci-mento em Processos de Software O alunos cursando a disciplina de MPS tambeacutem foramconsiderados no perfil de conhecedores de processos onde apenas 1 entrevistado natildeo pos-sui conhecimento sobre o assunto Os alunos que cursaram IHC foram considerados noperfil de conhecedores de IHC
A partir da primeira avaliaccedilatildeo foi identificado que o processo estava grande ecom uma inadequaccedilatildeo em relaccedilatildeo a fase de instalaccedilatildeo Portanto a primeira evoluccedilatildeo doprocesso consistiu em tirar a uacuteltima pool de instalaccedilatildeo o que causou a diminuiccedilatildeo dacomplexidade do processo de meacutedia 631 para 571 de acordo com a primeira e segundaavaliaccedilatildeo realizada Outra melhoria foi a ligaccedilatildeo entre a fase 1 e a 2 no processo
Na segunda parte do questionaacuterio foi possiacutevel identificar que o processo estaacute mo-dularizado como mostra a Figura 15 onde 81 respondeu sim para a questatildeo 16 Oprocesso estaacute modularizado
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 4 Avaliaccedilatildeo do Processo 66
Figura 15 ndash Processo estaacute modularizado
As respostas da pergunta 18 O Processo de Design de Interaccedilatildeo Orientado a Meacute-tricas proposto eacute de faacutecil entendimentomostram que o processo eacute de faacutecil entendimentocomo ilustra a Figura 16
Figura 16 ndash Graacutefico sobre Entendimento do Processo
Por meio do questionaacuterio tambeacutem eacute possiacutevel dizer que o processo eacute efetivo eficazconsistecircnte e flexiacutevel Os entrevistados ficaram divididos em relaccedilatildeo a talvez adotar oprocesso 48 das respostas ou adotar com restriccedilotildees 47
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 4 Avaliaccedilatildeo do Processo 67
Tabela 22 ndash Dados coletados para definiccedilatildeo do perfil
ID Resposta Poacutes IHC MPS
1
Nenhum 15 5 1Pouco 8 10 1Razoaacutevel 1 4 4Bom 0 0 5Muito Bom 5 0 1
2 Sim 23 5 4Natildeo 5 14 8
3
Nenhum 2 0 1Pouco 10 1 0Razoaacutevel 6 3 2Bom 7 12 5Muito Bom 3 3 4
4 Sim 15 11 5Natildeo 14 8 6
5
Nenhum 8 7 6Pouco 13 7 4Razoaacutevel 4 4 2Bom 2 1 0Muito 1 0 0
6
Nenhum 0 0 1Pouco 14 6 3Razoaacutevel 6 12 5Bom 8 0 2Muito Bom 1 1 1
7
Nenhum 10 0 3Pouco 10 4 1Razoaacutevel 6 9 3Bom 2 3 4Muito 0 3 1
8
Natildeo 14 7 3Um pouco 11 9 8Com frequecircncia 4 3 1Muito 0 0 0
9
Natildeo 22 13 9Poucas Vezes 7 5 2Muitas Vezes 0 1 1Em todos os produtos 0 0 0
10Natildeo 3 2 1As vezes 12 7 7Sempre 14 10 4
11Natildeo 5 1 2Algumas vezes 7 9 4Sim 17 9 4
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 4 Avaliaccedilatildeo do Processo 68
Tabela 23 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
12
Natildeo 0 1 1Um pouco 6 2 1Preciso aplicar 14 9 5Sim 9 5 5
13
Natildeo 0 8 1Um pouco 0 5 4Eacute importante 8 4 3Muito importante 21 0 4
14
Muito curto 0 0 1Curto 2 1 2Adequado 17 9 4Longo 5 6 5Muito longo 5 1 0
15
0 = Pouco complexo 0 0 11 0 0 02 0 1 03 2 1 04 3 3 25 3 3 56 5 4 17 10 2 28 5 1 19 0 1 010 = Muito complexo 1 1 0
16 Sim 23 16 8Natildeo 6 1 4
17Poucas atividades 5 0 3Adequado 19 14 7Muitas atividades 5 3 2
18
Natildeo 2 1 2Pouco entendimento 3 3 1Bom entendimento 23 11 8Muito bom entendimento 1 2 1
19Pouco efetivo 2 2 1Efetivo 24 12 9Muito efetivo 3 2 2
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Capiacutetulo 4 Avaliaccedilatildeo do Processo 69
Tabela 24 ndash Dados coletados sobre o ProcessoID Resposta Poacutes IHC MPS
20Pouco eficiente 3 2 3Eficiente 24 14 6Muito eficiente 2 1 3
21
0 = Pouco consistente 0 1 11 0 0 02 0 0 03 2 0 04 2 1 05 2 2 46 2 1 07 12 6 48 7 2 29 1 0 110 = Muito consistente 1 4 0
22Pouco flexiacutevel 14 3 5Flexiacutevel 14 10 5Muito flexiacutevel 1 4 2
23
Natildeo 0 1 1Talvez 13 9 6Adotaria com restriccedilotildees 15 7 5Adotaria por completo 1 0 0
24
0 = Pouca qualidade 0 1 11 0 0 02 0 0 03 1 0 04 1 1 25 2 2 26 3 1 17 13 5 38 8 5 29 1 1 110 = Muita qualidade 0 1 0
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
70
5 Consideraccedilotildees Finais
51 ConclusatildeoAtualmente existem muitos estudos que tentam relacionar o desenvolvimento de
software com a aacuterea de IHC Dessa forma a maioria destes integra atividades referentes adesign de interaccedilatildeo em um processo de desenvolvimento de software o que tornou difiacutecila identificaccedilatildeo de processos puros de design de interaccedilatildeo
O processo de design de interaccedilatildeo orientado a meacutetricas visa melhorar a qualidadeda interface dos produtos de software facilitando a anaacutelise dessa qualidade por meiodas meacutetricas definidas durante o processo Tendo como base o processo selecionado daMayhew D (1999) o processo proposto foi adaptado acrescentando atividades referentesao GQM durante todo o processo aleacutem de detalhar cada atividade de acordo com os itensobjetivo descriccedilatildeo entrada saiacuteda teacutecnica tarefa papeacuteis envolvidos
Para validar o processo orientado a meacutetricas proposto foi elaborado um questio-naacuterio para aplicar com os seguintes grupos
1 Alunos de uma turma de poacutes-graduaccedilatildeo em Gestatildeo de Tecnologia da Informaccedilatildeo daFaculdade de Tecnologia da Universidade de Brasiacutelia
2 Alunos de Engenharia de Software da UnB-FGA que jaacute cursaram IHC
3 Alunos cursando a disciplina MPS da UnB-FGA
Apoacutes a anaacutelise dos dados coletados eacute possiacutevel inferir que o processo tem utilidaae pode ser utilizado Aleacutem de que eacute possiacutevel adaptar o processo de acordo com o contextodesejado
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
71
Referecircncias
BARBOSA S SILVA B Interaccedilatildeo humano-computador [Sl] 2010 Citado 2 vezesnas paacuteginas 19 e 23
BASS L et al Constructing Superior Software [Sl] 1999 Citado na paacutegina 14
BONITASOFT Acessado em 2017 [Sl] Disponiacutevel em lthttpwwwbonitasoftcomgtCitado na paacutegina 37
CHAVES E C J et al Implantaccedilatildeo de projetos de sistemas da Aacuterea de serviccedilosAvaliaccedilatildeo da gestatildeo de stakeholders In II Simpoacutesio Internacional de Gestatildeo de Projetose I Simpoacutesio internacional de Inovaccedilatildeo e Sustentabilidade [Sl sn] 2013 Citado napaacutegina 39
CROSBY P B Quality is Free the Art of Making Quality Certain [Sl] 1992 Citadona paacutegina 14
HEWETT et al ACM SIGCHI Curricula for Human-Computer Interaction [Sl] 1992Disponiacutevel em lthttpoldsigchiorgcdggt Citado na paacutegina 19
HIX D HARTSON H R Developing User Interfaces Ensuring Usability ThroughProduct and Process [Sl] 1993 Citado 2 vezes nas paacuteginas 7 e 24
ISACA COBIT 5 A Business Framework for the Governance and Management ofEnterprise IT [Sl] 2012 Citado na paacutegina 39
ISO12207 Systems and software engineering ndash Software life cycle processes [Sl] 2008Citado na paacutegina 23
ISO25010 Software Engineering - Software Product Quality Requirements and Evaluation(SQuaRE) [Sl] 2011 Citado 5 vezes nas paacuteginas 7 13 30 32 e 33
MAYHEW D The usability engineering lifecycle [Sl] 1999 Citado 8 vezes naspaacuteginas 7 14 16 24 25 29 37 e 70
NIELSEN J Heuristic evaluation In Usability inspection methods [Sl sn] 1994 p25ndash62 Citado 2 vezes nas paacuteginas 20 e 21
NIELSEN J Usability engineering In Elsevier [Sl sn] 1994 Citado na paacutegina 20
NORMAN D Design of everyday things Revised and expanded 2013Disponiacutevel em lthttpccdroolcupcomwp-contentuploads201507The-Design-of-Everyday-Things-Revised-and-Expanded-Editionpdfgt Citadona paacutegina 13
PFLEEGER S L Engenharia de Software - Teoria e Praacutetica [Sl] 2004 v 2 Citadona paacutegina 23
PRESSMAN R S Software Engineering A Practitionerrsquos Approach [Sl] 2009 Citado3 vezes nas paacuteginas 7 22 e 23
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Referecircncias 72
ROCHA H V BARANAUSKAS M C Design e avaliaccedilatildeo de interfaces humano-computador UNICAMP Brasil 2003 Citado na paacutegina 13
ROGERS Y SHARP H PREECE J Design de Interaccedilatildeo aleacutem da interaccedilatildeohumano-computador [Sl] 2013 v 3 Citado 7 vezes nas paacuteginas 7 13 14 18 19 20e 27
SOLINGEN V BERGHOUT E The GoalQuestionMetric Method a practical guidefor quality improvement of software development [Sl] 1999 Citado 4 vezes nas paacuteginas7 8 34 e 35
SOMMERVILLE I Engenharia de Software [Sl] 2012 v 9 Citado na paacutegina 23
TYPEFORM Acessado em 2017 [Sl] Disponiacutevel em lthttpswwwtypeformcomgtCitado na paacutegina 60
WOHLIN C et al Experimentation in software engineering [Sl] 2012 Citado napaacutegina 60
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Apecircndices
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
74
APEcircNDICE A ndash Versotildees do Processo
Figura 17 ndash Versatildeo 1 do Processo
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
APEcircNDICE A Versotildees do Processo 75
Figura 18 ndash Versatildeo 2 do Processo
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
76
APEcircNDICE B ndash Exemplo de GQM
B1 Planejamento
B11 Projeto de Aplicaccedilatildeo
O GQM foi definido para interface de sistemas criados na disciplina de IHC daUniversidade de Brasiacutelia - Faculdade do Gama durante o 1o2016 Todos os sistemastratam de e-commerce de um produto qualquer definido pelo grupo Brevemente o sistemamanteacutem um cadastro de produtos atualizado pelo administrador sob os quais o cliente ousuaacuterio que navega no site pode realizar o pedido de itens que seratildeo entregues no endereccedilodo cliente Desta forma o administrador manteacutem controle dos pedidos e produtos
B12 Definiccedilatildeo do Time
Tabela 25 ndash Definiccedilatildeo do Time
Nome PapelJessica Equipe GQMAlunos IHC Designer de Interface
B13 Aacuterea de Melhoria
Por meio do processo a aacuterea de melhoria eacute a qualidade do produto mais especifi-camente em relaccedilatildeo agraves caracteriacutesticas do design de interface definido para o sistema
B2 DefiniccedilatildeoPara a definiccedilatildeo do objetivo de mediccedilatildeo foi utilizado o template abaixo da Tabela
26
Tabela 26 ndash Template para definir objetivo traduzido de (Van Solingen Berghout 1999)
Analisar o design da interfaceCom o Propoacutesito de melhorar a qualidade do produtoCom respeito a qualidade do design da interaccedilatildeoSob ponto de vista do usuaacuterio do sistemaNo contexto e-commerce
∙ Objetivo Geral Melhorar a qualidade do sistema em relaccedilatildeo ao design de interaccedilatildeo
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
APEcircNDICE B Exemplo de GQM 77
B21 Abstraction Sheet
Para apoiar a comunicaccedilatildeo entre a equipe do GQM e os especialistas do produtoo time do GQM utiliza um template chamado ldquoabstraction sheetsrdquo como mostra a tabela27 O GQM foi definido utilizando as Heuriacutesticas de Nielsen como base
Tabela 27 ndash Abstraction SheetFoco de Qualidade Fatores de Variaccedilatildeo1 Grau de visibilidade do status do sistema 1 4 Niacutevel de experiecircncia na aplicaccedilatildeo2 Concordacircncia do sistema com o mundoreal
1 4 5 7 Niacutevel de conhecimento do usuaacuterio3 Consistecircncia e padrotildees
2 Padrotildees da sociedade4 Prevenccedilatildeo de erros5 Reconhecer ao inveacutes de lembrar6 Ajudar os usuaacuterios a reconhecer diagnos-ticar e corrigir erros7 Ajuda e documentaccedilatildeoHipoacuteteses de Baseline Impactos nas hipoacuteteses de Baseline1 Quanto maior mais compreensiacutevel
1 Quanto maior a experiecircncia ou o niacutevel deconhecimento do usuaacuterio mais faacutecil de iden-tificar o estado do sistema
2 Quanto maior a concordacircncia mais natu-ral o uso
2 Quanto maior a concordacircncia com os pa-drotildees da sociedade mais natural eacute o uso dosistema
4 Quanto maior menos erros4 Quanto maior a experiecircncia ou niacutevel deconhecimento do usuaacuterio menos erros seratildeocometidos no sistema
5 Quanto maior mais faacutecil o entendimento5 Quanto maior o niacutevel de conhecimento dousuaacuterio mais faacutecil o reconhecimento logo oentendimento dos recursos graacuteficos
7 Quanto maior mais faacutecil a aprendizagem 7 Quanto maior o niacutevel de conhecimentodo usuaacuterio mais faacutecil de identificar ajuda eaprender a utilizar o sistema
Com base nos estudos relatados no abstraction sheet foram definidas as seguintesquestotildeesQ1 - O sistema possui uma boa interaccedilatildeo com o usuaacuterioQ2 - O sistema segue padrotildees reconhecido pelo usuaacuterioQ3 - O sistema ajuda o usuaacuterio a realizar as tarefas desejadas
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
APEcircNDICE B Exemplo de GQM 78
A partir das questotildees foram definidas meacutetricas como ilustra a tabela 28 cadameacutetrica eacute relacionada a uma pergunta podendo a mesma se relacionar com mais de umaquestatildeo As questotildees foram identificadas como Q1 Q2 Q3 e as meacutetricas como Mn arastreabilidade pode ser identificada pela Figura 19
Figura 19 ndash Rastreabilidade do GQM Definido
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
APEcircNDICE B Exemplo de GQM 79
Tabela 28 ndash MeacutetricasID Nome Meacutetrica Descriccedilatildeo MedidaM1 Visibilidade do es-
tado do sistemaExistem mecanismos que mostrem sempre ao usuaacuterio oestado atual do sistema
Sim(S)ouNatildeo(N)
M2 Conceitos familia-res
O sistema utiliza linguagem e conceitos familiares aousuaacuterio
S ouN
M3 Aderecircncia a con-venccedilotildees
O sistema segue convenccedilotildees da plataforma e padrotildees deinterface adotados pelo design Ex Todos os bototildees deavanccedilar seguem um padratildeo de nomenclatura
S ouN
M4 Interface graacuteficaconsistente
A terminologia graacuteficos e siacutembolos da interface do sis-tema estatildeo consistentes Ex Uma lixeira representa aaccedilatildeo de excluir
S ouN
M5 Dados obrigatoacuterios Os dados obrigatoacuterios de entrada estatildeo claramente iden-tificados
S ouN
M6 Formato dos dadosde entrada
O sistema indica ao usuaacuterio qual o formato correto dodado para cada campo
S ouN
M7 Design minimalista O sistema conteacutem apenas informaccedilotildees relevantes S ouN
M8 Anaacutelise da interface A interface natildeo agride visualmente o usuaacuterio Ex Cores S ouN
M9 Leitura na interface O usuaacuterio consegue ler todas as informaccedilotildees presentesna interface Ex Tamanho ou tipo da fonte utilizada
S ouN
M10 Prevenccedilatildeo de erros O sistema previne que o usuaacuterio cometa um erro ExEmitir mensagens de alerta
S ouN
M11 Ajuda O sistema possui mensagens de ajuda Ex Tooltips S ouN
M12 Dados jaacute fornecidos Eacute faacutecil visualizar dados jaacute fornecidos S ouN
M13 Correccedilatildeo de erros O usuaacuterio consegue facilmente corrigir um erro come-tido Ex Botatildeo de desfazer
S ouN
M14 Mensagem infor-mativa
O sistema oferece mensagens informando qual o estadoda accedilatildeo Ex Mensagem de cadastro realizado com su-cesso
S ouN
M15 Guia de uso O sistema oferece um guia de uso S ouN
M16 Padratildeo de mensa-gem de erro
As mensagens de erro satildeo apresentadas de acordo comum padratildeo
S ouN
M17 Mensagem de erroauto explicativa
As mensagens de erro satildeo auto explicativas S ouN
Top Related