FUNDAÇÃO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA - UNIFOR
CENTRO DE CIÊNCIAS TECNOLÓGICAS-CCT
CURSO DE INFORMÁTICA
CLAUDIUS WALBER NÓBREGA DE ARAÚJO
8610205-6
ANÁLISE DOS PRINCÍPIOS DE USABILIDADE NUM
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
USANDO MATRIZ INTERATIVA DE AVALIAÇÃO
Fortaleza – 2004
CLAUDIUS WALBER NÓBREGA DE ARAÚJO
8610205-6
ANÁLISE DOS PRINCÍPIOS DE USABILIDADE NUM
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
USANDO MATRIZ INTERATIVA DE AVALIAÇÃO
O presente Trabalho de Conclusão de Curso
tem por finalidade Apresentar um instrumento
que auxilie na análise de Processos de
Desenvolvimento de Software.
Orientador: D.Sc .Elizabeth Sucupira Furtado
Fortaleza – 2004
ANÁLISE DOS PRINCÍPIOS DE USABILIDADE NUM
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
USANDO MATRIZ INTERATIVA DE AVALIAÇÃO
Claudius Walber Nóbrega de Araújo – 8610205-6
PARECER: ___________________________________
DATA: _____/_____/____________
BANCA EXAMINADORA:
DSC. ELIZABETH SUCUPIRA FURTADO
DR. ARNALDO DIAS BELCHIOR
AGRADECIMENTOS
A Deus e a N.S. de Aparecida, por terem me abençoado e dado força para subir mais
um degrau na escalada da vida.
À minha orientadora, Profª. Elizabeth, que apostou em uma idéia inovadora.
Aos meus familiares, pelo carinho e incentivo dispensados a minha pessoa, em
especial meu pai e minha esposa.
Aos professores que me incentivaram nos momentos mais difíceis, bem como os que
me elogiaram nos meus momentos de glória: Adbeel Gomes, Ângelo Brayner, Augusto Pedroza,
Arnaldo Belchior, Elizabeth Furtado, Fernando Parente, Francisco Arnoldo, Francisco Lúcio, José
Bezerra, José Wagner, Maikol Rodrigues, Manuel Américo, Marcos César, Micheline Elga ,
Nabor Cha gas e Sandra Freitas.
Aos amigos que contribuíram direta ou indiretamente para a realização deste trabalho,
em especial: Kênia Sousa.
RESUMO
Diversos autores tais como ((Furtado, 2003), (Pressman, 2000), (Paula Filho, 2003)), têm
ressaltado a importância de se obter software de qualidade. Muitos deles enfatizam que para
se obter software de qualidade é necessário que o Processo de Desenvolvimento de Software
– PDS, possua qualidade. A busca por qualidade no PDS é evidenciada pela aplicação de
normas, pela realização de atividades estabelecidas em métodos e pela gerência destas
atividades. Este Trabalho de Conclusão de Curso tem por finalidade reunir informações
quanto às etapas de um PDS e confronta- las com critérios de usabilidade. O instrumento com
a capacidade de reunir as etapas do PDS e os critérios de usabilidade foi definido como
Matriz Interativa de Avaliação – MIA. Como resultado desta aplicação, isto é, do uso da MIA
proposta, surgirão indicadores que auxiliarão desenvolvedores a verificar se durante um PDS
foram adotados critérios de usabilidade capazes de se obter um produto final com usabilidade.
SUMÁRIO
AGRADECIMENTOS
RESUMO
Lista de Acrônimos
Lista de Figuras
Lista Quadros
1 – INTRODUÇÃO
12
1.1. Conceitos Iniciais
12
1.2. Motivação
15
1.3. Objetivos
18
1.3.1. Geral
18
1.3.2. Específicos
18
1.4. Estrutura da monografia
19
2- PROCESSO DE DESENVOLVIMENTO DE SOFTWARE – PDS
20
2.1 – Breve Histórico
20
2.1.1 – Fases de um Processo de Desenvolvimento de Software Genérico
21
2.1.2 – Principais Ciclos de Vida
23
2.2 – Princípios do Rational Unified Process – RUP
27
2.2.1 - Aspectos Dinâmicos
28
2.2.2 - Aspectos Estáticos
32
2.3 – Princípios do Unifed Process Interative – UPi
35
2.3.1 - Desenvolvimento do software iterativamente
36
2.3.2 - Gerenciamento dos requerimentos
36
2.3.3 - Uso de arquiteturas baseada em componentes
36
2.3.4 - Modelagem visual de um Software
36
2.3.5 - Verificação continua da qualidade do software
37
2.3.6 - Controle das mudanças no software
37
2.3.7 – Aspectos de Usabilidade do UPi
38
3 – PRINCÍPIOS DA INTERAÇÃO HUMANO COMPUTADOR (IHC) A
SEREM CONSIDERADOS NUM PDS
41
3.1 - Interação Humano Computador – IHC
41
3.2 – Princípios da Engenharia da Usabilidade
43
3.2.1 – Centralização de Foco no Usuário
43
3.2.2 – Recomendações Ergonômicas
46
3.2.3 – Testes de Usabilidade
48
3.3 – Princípios Relevantes de IHC
51
3.3.1 – Sensibilidade ao Contexto
51
3.3.2 – Uso de Modelos
51
3.3.3 – Desenvolvimento Dirigido por Pattern
55
3.3.4 – Independência de Dispositivos
58
3.4 – Conclusão
58
4 – MATRIZ INTERATIVA DE AVALIAÇÃO (MIA)
59
4.1 – Princípios das MIA
59
4.2 – Princípios de Usabilidade a Serem Incorporados na MIA
62
4.3 – Fases do RUP a serem Incorporados na Matriz Interativa de Avaliação
63
4.4 – Relacionamento Entre os Aspectos de Usabilidade e Fases do RUP e UPi
65
na MIA
4.5 – Análise dos Processos RUP e UPi, segundo a Intensidade e Uso de 77
Princípios de Usabilidade
4.6 – Síntese da Análise
87
5 – CONCLUSÕES
89
6 – BIBLIOGRAFIA
91
7. ANEXOS
LISTA DE ACRÔNIMOS
ABNT – Associação Brasileira de Normas Técnicas
HFES – Human Factors and Ergonomics Society
IHC – Interação Humano Computador
ISO – International Standards Organization
J2EE - Java 2 Platform, Enterprise Edition
MIA – Matriz Interativa de Avaliação
MVC – Modelo Visualização Controle
PDS – Processo de Desenvolvimento de Software
RUP - Rational Unified Process
SI – Sistema Interativo
UML - Unified Modeling Language
UNIFOR – Universidade de Fortaleza
UPi – Unified Process Interactive
UI – User Interface
LISTA DE FIGURAS
Figura 1 – Representação Gráfica do PDS Genérico
21
Figura 2 – Representação Gráfica do Ciclo de Vida em Cascata
24
Figura 3 – Representação Gráfica do Ciclo de Vida em Cascata com 25
Realimentação
Figura 4 – Representação Gráfica do Ciclo de Vida em Espiral
25
Figura 5 – Representação Gráfica do Ciclo de Vida Cone
26
Figura 6 – Arquitetura do RUP
28
Figura 7 – Exemplo de Storyboard para consulta em uma biblioteca
53
Figura 8 – Planificação Hierárquica de Tarefas
53
Figura 9 – Exemplo de Modelo de Tarefa
54
Figura 10 – Modelo de Interface Conceitual de um formulário de identificação
55
Figura 11 – Modelo 3 Camadas – MVC
56
Figura 12 – Matriz interativa de Leopold
60
Figura 13 – Passos para criação de uma Matriz Interativa de Avaliação
67
Figura 14 – Matriz Interativa de Avaliação (Exemplo)
68
LISTA QUADROS
Quadro 1 – Evolução do Processso de Desenvolvimento de Software – PDS
20
Quadro 2 – Interações entre Disciplinas da Fase de Iniciação do RUP e Princípios 69
de Usabilidade
Quadro 3 – Interações entre Disciplinas da Fase de Elaboração do RUP e
Princípios de Usabilidade
Quadro 4 – Interações entre Disciplinas da Fase de Construção do RUP e
Princípios de Usabilidade
Quadro 5 – Interações entre Disciplinas da Fase de Transição do RUP e Princípios
de Usabilidade
Quadro 6 – Interações entre Disciplinas da Fase de Iniciação do UPi e Princípios
de Usabilidade
Quadro 7 – Interações entre Disciplinas da Fase de Elaboração do UP i e Princípios
de Usabilidade
Quadro 8 – Interações entre Disciplinas da Fase de Construção do UPi e Princípios
de Usabilidade
Quadro 9 – Interações entre Disciplinas da Fase de Transição do RUP e Princípios
de Usabilidade
Quadro 10 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de
Usabilidade na Fase de Iniciação
Quadro 11 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de
Usabilidade na Fase de Elaboração
Quadro 12 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de
Usabilidade na Fase de Construção
Quadro 13 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de
Usabilidade na Fase de Transição
70
71
72
73
74
75
76
78
81
84
86
LISTA GRÁFICOS
Gráfico 1 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de 79
Usabilidade na Fase de Iniciação
Gráfico 2 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de 82
Usabilidade na Fase de Elaboração
Gráfico 3 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de 85
Usabilidade na Fase de Construção
Gráfico 4 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de 87
Usabilidade na Fase de Transição
1 – INTRODUÇÃO
1.1. Conceitos Iniciais
Para a melhor compreensão do presente trabalho é necessário que se faça
inicialmente pequena s considerações a respeito dos seguintes temas:
- Processo de Desenvolvimento de Software
- Qualidade de Software;
- Usabilidade de Software;
- Aspectos relativos a Interação Humano Computador – IHC;
- Rational Unifed Process – RUP
- Unifed Process Interative – UPi
Um Processo de Desenvolvimento de Software (PDS) pode ser definido como uma
espécie de algoritmo que exige o cumprimento de diversas etapas, dentre as quais se
destacam: levantamento de necessidades ou requisitos, análise, projeto, implementação e
testes.
Estas etapas incluem atividades diversas, sendo realizadas por uma equipe de
desenvolvedores e produzindo diversos artefatos.
Cada vez mais, estudos existem para que não somente o artefato tenha qualidade,
mas o PDS também.
13
Para que um PDS garanta a qualidade é necessário que ele seja concebido
contemplando alguns aspectos básicos, dentre os quais podemos destacar: Fase de
Planejamento bem elaborada, Atuação ativa da Equipe de Desenvolvedores, Geração de
Produtos intermediários antes da geração do Produto final e Acompanhamento e Participação
do Cliente no PDS, este último intimamente relacionado com o critério de usabilidade.
?
Planejamento – é de grande importância para o desenvolvimento de um projeto. São
merecedores de planejamento: organização da equipe, prazos, metodologia de trabalho,
técnicas e ferramentas, fases, produtos, forma de revisão, aprovação e acompanhamento.
O Planejamento, portanto é um dos fatores que auxiliam na busca de um resultado préestabelecido;
?
Atuação da Equipe de Desenvolvedores – este tópico influencia diretamente no
andamento do projeto, principalmente no que diz respeito às questões de distribuição de
tarefas, definição de responsabilidades e, principalmente, gerenciamento de conflitos.
?
Geração de Produtos – cada fase deve gerar produtos concretos (propostas, documentos
ou modelos compatíveis com a fa se na qual se encontra o projeto). Uma fase
adequadamente gerenciada e desenvolvida dará origem (gerará) o produto previsto;
?
Acompanhamento – o acompanhamento do projeto, associado às medidas corretivas
quando identificados desvios em relação ao planejado, é uma ação fundamental no
processo de desenvolvimento. Sem esta ação não se garante o resultado projetado; não se
cria condições de corrigir distorções nem contempla novas variáveis que certamente
surgem no desenvolvimento de um projeto;
?
Participação do cliente – o envolvimento e a participação do Cliente são de vital
importância ao perfeito desenvolvimento do projeto. Tal participação e envolvimento é a
garantia de se alcançar os resultados por ele esperado. O Cliente deve ser parceiro no
projeto, acompanhando seu andamento e participando ativamente das decisões. Esta ação
está intimamente relacionada com o critério de usabilidade do software a ser
desenvolvido.
14
No tocante à qualidade de um software, de acordo com Rocha (2001), relata que
existem diversas definições sobre o que é qualidade de software, sendo algumas delas:
?
Qualidade é estar em conformidade com os requisitos dos clientes;
?
Qualidade é antecipar e satisfazer os desejos dos clientes;
?
Qualidade é escrever tudo o que se deve fazer e fazer tudo o que foi escrito.
Para Pressman (2000), a qualidade de um software define-se como a
"Conformidade com os requisitos funcionais e de desempenho explicitamente definidos, com
standards de desenvolvimento documentados, com as características implicitamente
expectáveis de software profissionalmente desenvolvido". Esta definição, afirma Pressman
(2000), serve para realçar 3 pontos:
?
Os requisitos do software são a base a partir da qual se pode medir a qualidade. Falta
de conformidade com os requisitos é falta de qualidade;
?
Standards especificados definem um conjunto de critérios de desenvolvimento que
guiam a forma em que o software foi construído. Se os critérios não foram seguidos, o
resultado será seguramente falta de qualidade;
?
Há um conjunto de requisitos implícitos que muitas vezes não são mencionados. Se
apesar de respeitar os requisitos explícitos o software não cumprir os requisitos
implícitos, a qualidade será duvidosa.
Em termos de usabilidade, destacamos que esta se encontra diretamente ligada à
participação do usuário no processo de desenvolvimento do software. O fundamento da
usabilidade de software é facilitar o máximo possível a interação das pessoas com os sistemas,
sejam softwares desktops ou aplicativos de internet. A usabilidade, é atua lmente estudada na
área de Interação Humano Computador - IHC.
A IHC é uma área de pesquisa dedicada a estudar os fenômenos de comunicação
entre pessoas e sistemas computacionais. A IHC teve seu início como disciplina no fim dos
anos 70 e início dos anos 80. Inicialmente começou através de uma aliança entre profissionais
da informática e psicólogos. Agora o tema IHC é bastante diversificado e engloba diversas
15
disciplinas tais como psicologia, ciência da comunicação e da informação, letras, design,
antropolo gia, sociologia, etc. A pesquisa em IHC se preocupa em como se certificar da
usabilidade, o que quer dizer, produtos que são efetivos, eficientes e satisfatórios em seu uso.
Pesquisadores de IHC tentam entender o que os usuários querem fazer e como designers
podem ser ajudados a prover produtos que satisfaçam estas necessidades. (Monk, 2002)
1.2. Motivação
Como descrito anteriormente, existem vários aspectos a serem considerados
durante um PDS.
Garantir que um PDS seja perfeitamente executado não é uma tarefa
simples, posto requerer entrosamento entre a Gerência do Projeto com a Equipe de
Desenvolvedores e o Cliente, sem esquecer a utilização de Ferramentas adequadas.
Para a medição da qualidade de um PDS, deve-se fazer uma definição e seleção de
um conjunto de métricas. De acordo com Rocha (2001), as métricas devem ter por objetivo s:
caracterizar o projeto e seu contexto; medir, avaliar e sugerir melhorias em um processo de
software específico e; realizar estudos empíricos envolvendo medição e avaliação destes
processos.
Atualmente, existem diversas ferramentas que apóiam os PDS e que fazem uso de
métricas, dentre as quais se destacam:
FERRAMENTAS ESTIMATIVAS
?
COSTAR (Softstar Systems, 2003) – Ferramenta de custo de estimativa de software,
baseada no COCOMO1 (Boehm, 1981). Um gerente de projeto de software pode usar
o COSTAR, produzindo estimativas de duração, níveis de “staffing”, esforço e de
custo de um projeto.
?
COSMOS (Structural Research & Analysis Corporation, 2003)- Facilita a tarefa de
estimação para projetos de desenvolvimento de sistemas. O COCOMO permite que se
1
Modelo de estimação de custo COCOMO é usado por milhares de gerentes para projetar software é baseado em um estudo
de contagens de projetos de software.
16
estime o tamanho e o esforço do projeto, usando o Ponto de Função 2 (FPA) e modelos
de COCOMO.
?
Ferramenta de Estimação e de Análise do Software – Ferramenta baseada no Windows
para estimativa do esforço do desenvolvimento do software. Analisa e integra o FPA
com o modelo de COCOMO. Esta ferramenta é um poderoso ambiente que fornece o
feedback, relatórios e ferramentas imediatas para estimação e resolução rápida dos
problemas.
?
KnowledgePLAN
(Software
Productivity
Research,
1985)–
Esta
ferramenta
desenvolve uma estimativa inicial com esforço limitado e guia o usuário com
refinamentos através perguntas, possibilitando estimativas de esforço, programação,
custo, e exigências de recurso.
FERRAMENTAS DE DESENVOLVIMENTO
?
EPOS (Conradi, 1994) – Esta ferramenta possui um planejador inteligente que é
responsável pelo detalhamento de tarefas, gerando automaticamente uma rede de
subtarefas para cada tarefa composta.
?
SMART (Garg, 1994) – Utiliza uma ferramenta com base em conhecimento,
articulador para modelar, analisar e simular processos complexos.
?
ASSIST-PRO (Falbo, 1999a) – Trata-se de um assistente inteligente para apoiar a
definição de processos de software no contexto do meta ambiente TABA3 .
?
DEF-PRO (Machado, 2000a) – definição de um processo de software padrão para uma
organização, com base na Norma ISO/IEC 12207, nos modelos de maturidade (CMM
ou SPICE), em níveis de capacitação, nas características de desenvolvimento de
software da organização e no tipo de Ambiente de Desenvolvimento de Software –
ADS, para o qual está sendo definido o processo.
Conforme exposto, estas ferramentas são de grande valia aos desenvolvedores.
2
3
A técnica FPA quantifica funções contidas dentro do software em termos que são significativos aos usuários.
Projeto da UFRj.
17
Entretanto não se verificou que as ferramentas supracitadas, dessem apoio aos
princípios de usabilidade estudados neste trabalho.
A análise de um PDS sobre os aspectos de usabilidade não é novidade, porém este
trabalho tem a proposta de apresentar uma Matriz Interativa de Avaliação (MIA) que possa
promover a união das etapas de um PDS e os aspectos relacionados à usabilidade. O objetivo
é alcançar a maximização da compreensão de desenvolvedores e usuários (clientes), através
do inter-relacionamento entre as linhas e as colunas da matriz (MIA), no tocante aos
princípios de usabilidade.
Como exemplos de PDS, serão utilizados o Rational Unified Process – RUP e o
Unified Process Interactive – UPi (Sousa, 2002), que é uma derivação do primeiro. Segundo
Kruchten (2003), “o Rational Unifed Process - RUP é um processo de desenvolvimento de software iterativo
e incremental. O ciclo de vida do RUP é constituído por ciclos de desenvolvimento, cada um possuindo as
seguintes fases: concepção, elaboração, construção e transição.
Cada ciclo de desenvolvimento é constituído pela release de um produto executável, que pode ser
um subconjunto da visão completa mas que deve ser útil sob alguma perspectiva de engenharia ou do usuário.
Cada release é acompanhada por artefatos de apoio: planos, descrição da release, documentação do usuário, etc. ”
O Unifed Process Interative – UPi é uma derivação do RUP e tem como principal
diferencial a abrangência dos aspectos de IHC, os quais não são contemplados plenamente no
RUP básico.
18
1.3. Objetivos
1.3.1. Geral
O objetivo geral deste trabalho é apresentar um instrumento para auxiliar a equipe
de desenvolvimento na avaliação de um PDS no tocante aos aspectos relacionados à
usabilidade.
1.3.2. Específicos
Os objetivos específicos podem ser traduzidos da forma como se segue:
a) Reunir aspectos de usabilidade referentes às etapas elementares de um PDS, tais como:
?
Levantamento de Necessidades;
?
Análise;
?
Projeto e
?
Testes e Integração.
b) Integrar estes aspectos com os conceitos envolvidos nas etapas de desenvolvimento de
software, dando ênfase ao Rational Unified Process – RUP e ao Unified Process
Interactive - UPi, e apresentá- los em Matriz Interativa de Avaliação (MIA);
c) Fazer uma análise integrada das etapas de desenvolvimento de software do UPi, e
comparando com o RUP, versus os aspectos ligados à usabilidade, definidos no item
anterior.
19
1.4. Estrutura da monografia
O presente trabalho foi dividido em quatro etapas. Na primeira etapa foi feita uma
Introdução abordando conceitos iniciais, motivação, os objetivos do TCC e a apresentação da
estrutura da monografia.
Na segunda etapa do TCC, será feita uma contextualização a respeito de PDS,
abordando aspectos relativos ao histórico de um PDS, processo de engenharia de software,
principais ciclos de vida, fases de desenvolvimento, qualidade e usabilidade de software,
princípios do RUP, princípios de IHC e princípios do UPi.
A terceira etapa do trabalho contemplará os aspectos relacionados à avaliação da
qualidade de um software incluindo técnicas de avaliação e uma crítica quanto ao seu uso.
A etapa final do trabalho contemplará o instrumento proposto. Nesta etapa,
faremos um histórico do uso da Matriz Interativa de Avaliação – MIA e sua aplicabilidade.
Serão apresentados estudos do RUP e UPi frente aos princípios de Usabilidade, mostrando a
aplicação da MIA.
2- PROCESSO DE DESENVOLVIMENTO DE SOFTWARE – PDS
2.1 – Breve Histórico
O Quadro 1, ilustra as características associadas a cada uma das eras
metodológicas até os dias atuais.
Quadro 1 – Evolução do Processo de Desenvolvimento de Software – PDS
ANOS
ERAS
CARACTERÍSTICAS
? Não cumprimento de cronogramas;
1960 a 1970
Pré –
Metodológica
? Custos estourados;
? Não aplicação de métodos;
? Cliente insatisfeito.
1970 a 1980
Início da era
Metodológica
? Identificação de fases para melhorar o gerenciamento
e desenvolvimento do software;
? Surgimento dos Ciclos de Vida.
? Proliferação de metodologias recomendando o uso de
heurísticas e técnicas para alcançar os melhores
1980 a 1990
Metodológica
produtos e baseadas em ciclos de vida.
? As metodologias tinham diferentes abordagens:
1. estruturada;
2. orientada a objetos;
21
3. modelagem
gráfica
de
informação –
case,
geradores de interface.
Filosofia: “não usar metodologia pode ser uma catástrofe.
Mas a adoção de metodologias não garante o aumento de
1990 a 2004
Pós –
produtividade. Eles rejeitam o desenvolvimento passo-a-
Metodológica
passo e a documentação detalhada. Elas são difíceis,
exigem um skill (habilidade, técnica, perícia) elevado e
pode ser cara aprender usando ferramentas associadas”.
2.1.1 – Fases de um Processo de Desenvolvimento de Software Genérico
Todo e qualquer PDS, deve seguir no mínimo as seguintes etapas: Levantamento
de Necessidades, Análise, Projeto, Implantação, Integração e Avaliação, as quais estão
representadas na Figura 1.
Figura 1 – Representação Gráfica de um PDS Genérico
A tarefa referente ao levantamento de necessidades ou requisitos é uma das mais
complexas dentro do contexto de um PDS. O levantamento deve considerar os requisitos
funcionais (o que o sistema vai fazer) e os requisitos não funcionais (aqueles relacionados
com à qualidade e à usabilidade).
22
Os requisitos não funcionais descrevem as facilidades do sistema; são diretamante
ligados aos fatores psicológicos. A não consideração desses fatores na análise de requisitos
constitui uma das principais razões de uma eventual insatisfação do usuário com relação a um
produto. Dentre os requisitos não funcionais merecem destaque : a Portabilidade (o sistema de
ser portável ou seja rodar em diversas plataformas e/ou dar suporte a vários idiomas), a
Usabilidade (facilidade de aprender e de usar um sistema) e a Segurança (por exemplo, o
sistema não deve permitir o acesso de pessoas não cadastradas, por meio de Login e Senha).
Diversos artefatos e ferramentas de registro e de documentação apóiam o
levantamento de requisitos, dentre os quais temos casos de uso, UML e as ferramentas
Requisit Pro e Rose.
Após o levantamento inicial dos requisitos, surge a etapa de Análise, a qual tem
como foco principal definir o que será feito.
Nesta fase, geralmente, se definem conceitos, faz-se o levantamento das entidades
através dos diagramas de classe, se estabelecem os relacionamentos (estáticos e dinâmicos),
modela-se o diagrama de estados, promove-se o detalhamento dos casos de uso e lança-se
uma proposta da interface do usuário (protótipo).
Na etapa de Projeto, deve-se realizar o detalhamento dos relacionamentos entre as
classes, confeccionar os dia gramas de colaboração e de seqüência, fazer a reavaliação dos
diagramas de estado, definir qual a linguagem de programação a ser utilizada, projetar o
banco de dados, se for o caso, confeccionar as interfaces gráficas reais (protótipos).
Uma vez projetado o sistema, resta implementá-lo. Este é mais um ponto
suscetível a fracassos, dessa vez em função de freqüentes falhas de qualidade. São inúmeros
os sistemas que, embora de concepção impecável, não são postos em produção no prazo (às
vezes nunca) e cujos custos superam o orçamento por conta de bugs e correções infindáveis.
23
Assim como a implementação, a integração do sistema é um tópico que também
merece bastante atenção, pois se o sistema não estiver bem integrado fica passível de diversos
tipos de falhas.
O processo de avaliação pode ser procedido de duas formas. Primeiramente,
através de testes diretamente no ambiente em que foi produzido, seja antes de repassar o
produto ao cliente. Outra forma de avaliação seria realizada por conta do cliente, no estilo de
uma versão para teste.
2.1.2 – Principais Ciclos de Vida
Um ponto de partida importante para a determinação de um processo de
desenvolvimento de software é a escolha do modelo de ciclo de vida.
a) codifica - remenda
É o ciclo de vida mais caótico e mais usado, porém é o menos recomendado. Sua
filosofia é que o desenvolvimento do produto deve se dar de imediato, sem planejamento
algum e a medida que os problemas (erros) forem surgindo, o software é “remendado”.
Nenhum processo definido é seguido, para alguns desenvolvedores, este modelo é
bastante atraente em virtude de não exigir sofisticação nenhuma, seja de âmbito técnico ou
gerencial. Este modelo representa alto risco, não apresenta formas de gerir e nem tão pouco
maneiras de fixar prazos concretos para entrega de produtos.
b) cascata
No modelo cascata (Royce, 1970), os processos são executados catedraticamente
em seqüência. Para que a fase seguinte seja executada, é necessário que o processo anterior
24
tenha sido concluído (ver Figura 2). Em virtude dos processos terem sido bem definidos, é
possível aplicar pontos de controle bem definidos. Estes pontos de controle facilitam ações
gerenciais.
O cascata, é conhecido por ser um ciclo de vida rígido e burocrático em virtude de
não admitir erros. O ciclo de vida em cascata possui a desvantagem de o cliente só ter acesso
ao seu produto no final do projeto, isto o caracteriza como um modelo de baixa visibilidade.
Figura 2 – Representação Gráfica do Ciclo de Vida em Cascata
c) cascata com realimentação
O modelo de ciclo de vida em cascata com realimentação é uma variação do ciclo
de vida em cascata, onde existe a possibilidade de retrocesso a um processo supostamente
concluído no qual a execução de um processo subseqüente detectou-se um erro em decorrente
do processo anterior. Neste ciclo de vida há a possibilidade de retrocesso para concerto de
erros. Isto todavia dificulta as ações gerenciais (ver Figura 3).
25
Figura 3 – Representação Gráfica do Ciclo de Vida em Cascata com Realimentação
d) espiral
Este modelo é baseado em iterações (Boehm, 1988). Cada nova iteração representa
uma volta no espiral (ver Figura 4). Permite a construção de produtos em prazos curtos com
agregação de no vas características e recursos à medida da necessidade.
Figura 4 – Representação Gráfica do Ciclo de Vida em Espiral
26
e) prototipagem evolutiva
Uma variante do modelo espiral com a característica de ser usada para construir
uma série de versões provisórias as quais são denominadas protótipos. Na medida do
desenvolvimento, os protótipos cobrem cada vez mais requisitos, até que atinja o produto
desejado. Definição progressiva dos requisitos. Este modelo apresenta alta flexibilidade e boa
visibilidade p/ clientes. Requer gestão sofisticada e desenho robusto para que não se desvie do
produto desejado.
f) entrega evolutiva
Este modelo é uma combinação dos modelos Cascata e Prototipagem evolutiva.
g) cone
O modelo de ciclo de vida denominado Cone (Furtado, 2001), é um modelo
incremental e iterativo, ou seja é dotado da possibilidade de retorno para reparar erros ou
inconsistências. É muito parecido com o modelo espiral. Todavia a principal diferença entre
os dois é que o modelo Cone na medida em que vão ocorrendo as iterações, va i ocorrendo
concomitantemente, um refino e um afunilamento dos processos.
Figura 5 – Representação Gráfica do Ciclo de Vida Cone
27
2.2 – Princípios do Rational Unified Process – RUP
O RUP, criado pela Rational Software Corporation, é um processo de
desenvolvimento amplo resultante da consolidação das melhores práticas de engenharia de
software. Sua meta é ser a fundação de metodologias de desenvolvimento, que garantam a
produção de software de alta qualidade, dentro dos cronogramas e orçamento previstos. O
RUP descreve como desenvolver software usando técnicas testadas e aprovadas
comercialmente.
O RUP tem sido amplamente utilizado no desenvolvimento de sistemas Java 2
Platform, Enterprise Edition - J2EE, podendo também ser aplicado a qualquer projeto baseado
em um modelo orientado a objetos, bem como em projetos baseados em componentes.
A arquitetura do RUP possui duas dimensões. O eixo horizontal representa os
ciclos de vida do projeto ao longo do tempo. O eixo vertical representa as disciplinas que
agrupam atividades necessárias à consecução de um projeto.
A primeira dimensão representa os aspectos dinâmicos do processo e é expressa
em termos de fases, iterações e marcos. A segunda dimensão representa os aspectos estáticos
do processo e é descrita em termos de componentes, disciplinas, atividades, diagramas,
artefatos, e funções. A Figura 6 ilustra a arquitetura do RUP, onde se verifica que nas
primeiras iterações é gasto mais tempo nos requisitos e, nas iterações mais tardias, é gasto
mais tempo na implementação.
28
Figura 6 - Arquitetura do RUP
Fonte: Rational.com
2.2.1 - Aspectos Dinâmicos
Conforme mencionado anteriormente, os aspectos dinâmicos são compostos pelas
fase desenvolvimento do RUP, que são: fase de Concepção ou Iniciação, fase de Elaboração,
fase de Construção e fase de Transição.
Na fase de Concepção ou Iniciação (Inception), o objetivo maior é alcançar uma
conformidade entre todos os interessados no sistema com relação aos objetivos determinados
ao longo de todo o projeto. A fase de Concepção é de primordial importância nos esforços de
desenvolvimento, aonde existem riscos significativos de negócio e requisitos que devem ser
levantados antes que o projeto possa prosseguir.
Esta fase representa o bloco inicial. Ela envolve a articulação da visão para o
sistema e o estabelecimento de um projeto formal para construir o sistema. Deve ser algo mais
29
do que uma boa idéia rabiscada em um papel de rascunho. Uma visão clara deve ser
expressada e o escopo do projeto definido. Estes itens serão a fundação para a próxima fase.
Do ponto de vista da engenharia de usabilidade, isto significa destacar as
atividades relacionadas à compreensão de quem são os usuários e suas necessidades além da
identificação dos casos de uso de maior relevância para os usuários.
A fase de iniciação muitas vezes também é o momento para explorar o design
conceitual e a criação de protótipo de “prova de conceito”. Isto é verdadeiro quando os
principais riscos do projeto estão relacionados às questões de usabilidade e interface do
usuário. O teste de usabilidade, incluindo o teste de desempenho relacionado à usabilidade,
deve ser iniciado quando houver moldes ou protótipos executáveis da interface do usuário.
Na fase de Elaboração (Elaboration), o domínio do problema é detalhado e o
escopo do projeto é definido em grandes detalhes. Tantos os requisitos funcionais como os
não- funcionais para o sistema devem ser definidos neste ponto. Os requisitos não- funcionais
podem ser encarados como fatores críticos para o sucesso, que descrevem o grau de risco
envolvido no desenvolvimento do sistema.
O resultado final desta fase é a arquitetura base do sistema J2EE e um cronograma
para a produção do sistema. Descrito como uma arquitetura na documentação do RUP,
qualquer mudança feita na fase de construção deve ser mínima.
Como o RUP é um processo iterativo, os artefatos criados na Iniciação são
revisados com os usuários a fim de gerenciar o escopo e garantir que o sistema em
desenvolvimento atenda às necessidades destes.
Nesta fase, a interface conceitual do usuário é definida, e os elementos críticos
e/ou de risco do design da interface do usuário são implementados. Ainda nesta fase, são
merecedoras de destaque as ações de design e modelagem de interface do usuário, referentes
às atividades da disciplina de Requisitos e as atividades de suporte provenientes da disciplina
30
de Análise e Design. Implementação e Teste também estão envolvidos, desde que a conclusão
da Elaboração precise que um sistema executável seja construído para que possa ser avaliado.
O objetivo da fase de Construção (Construction) é elucidar os requisitos
remanescentes e completar o desenvolvimento do sistema baseado na estrutura base da
arquitetura. Na fase de construção a ênfase é colocada na administração dos recursos e no
controle das operações visando otimizar os custos, cronogramas e qualidade. Neste sentido o
processo sofre uma transição do desenvolvimento de um produto intelectual durante as fases
de Concepção e Elaboração, para o desenvolvimento de um produto comercial durante as
fases de Construção e Transição.
A fase de construção começa desenvolvendo os detalhes da arquitetura base e
produz uma arquitetura final. Assim como em outras fases do desenvolvimento, é esperado
que a fase de construção possa envolver múltiplas iterações.
Nesta fase, conforme mencionado, foco é na implementação de mais casos de uso.
Isso envolve adicionar à interface do usuário, sem deixar de se manter fiel ao modelo
conceitual da interface do usuário e ao Guia de Interface do Usuário. O teste de usabilidade
continua sendo muito importante à medida que os novos recursos são adicionados.
A seleção da funcionalidade a ser colocada em cada it eração é baseada no valor
para os usuários.
O foco da fase de Transição (Transition), por sua vez, é o de assegurar que o
software esteja disponível para o usuário final. A fase de Transição se expande sobre várias
iterações, e inclui o teste do produto em preparação para o lançamento, além de pequenos
ajustes baseados nos retornos dos usuários. Neste ponto do ciclo de vida, o retorno do usuário
deve focar-se principalmente no refino do produto. Serão tratadas as questões de
configuração, instalação e utilização. Todas as principais questões estruturais devem ter sido
trabalhadas nas fases iniciais do ciclo de vida do projeto.
31
No final da fase de Transição, os objetivos devem ter sido alcançados, e o projeto
deve estar pronto para ser concluído. Em alguns casos, o final desta fase pode coincidir com o
início de outra fase do mesmo produto, levando a uma próxima geração ou versão do produto.
Para outros projetos, o final da fase de Transição, pode coincidir com a entrega dos artefatos a
terceiros, que podem ser responsáveis pelas operações, manutenção e aprimoramento do
sistema de entrega.
Em um esforço de desenvolvimento centrado no usuário, não se deve esperar até a
fase de Transição para envolver o usuário. Ele deve permanecer envolvido, principalmente
para fornecer feedback. Quando o usuário fica envolvido durante todo o desenvolvimento, o
teste beta e de aceitação formal geralmente é reduzido ou não existe. Assim, o feedback
detalhado do usuário e a aprovação ocorrem durante o esforço de desenvolvimento.
O desenvolvimento do material de treinamento e do material de suporte do sistema
é finalizado na Transição, mas deve ser iniciado nas fases iniciais, se possível, a fim de
permitir o feedback do usuário.
Na transição, existe um sistema de trabalho que pode ser usado pelos usuários
finais. É recomendado planejar pelo menos algumas iterações durante a transição, para que
problemas com a release inicial sejam corrigidos e para que o feedback dos principais
usuários seja incorporado.
À medida que as fases supracitadas são executadas em ordem e em um modelo
cíclico, deve surgir um produto de software usável, mas não necessariamente um produto que
atinge totalmente os requisitos do sistema. O desenvolvimento de software com RUP é como
construir uma casa, e então adicionar a garagem, depois adicionar a piscina, até que no fim se
tenha a casa que inicialmente se imaginava construir.
Este processo iterativo é considerado uma abordagem evolucionária para
desenvolvimento de software. Cada iteração resulta em melhoras e em um produto que está
um passo mais próximo do objetivo de um sistema completo. Cada fase no processo pode
também envolver múltiplas iterações antes que ela seja completada.
32
2.2.2 - Aspectos Estáticos
Nesta seção os aspectos estáticos do RUP serão destacados ressaltando algum
tratamento de usabilidade que seja feito ou recomendado. Estes aspectos são descritos em
termos de componentes, disciplinas, atividades, diagramas, artefatos e funções. As principais
disciplinas (Workflows de Processo) do RUP são Modelagem de Negócio (Business
Modeling), Requisitos (Requirements), Análise e Projeto (Analysis & Design), Implementação
(Implementation), Teste (Test), Implantação/Entrega (Deployment) e as principais disciplinas
de apoio : Configuração e Gerenciamento de Mudanças (Configuration & Change Mgmt),
Gerência de Projeto (Project Management) e Ambiente (Environment).
a) Disciplinas do RUP
Cada uma das quatro fases do RUP é adicionalmente dividida em iterações e
finalizada com um ponto de checagem que verifica se os objetivos daquela fase foram
alcançados. Toda iteração é organizada em termos de disciplinas, que são conjuntos de
atividades realizadas por responsáveis que produzem artefatos. As principais disciplinas são
descritas a seguir:
a1) Modelagem de Negócio: Provê um entendimento comum entre os stakeholders sobre
quais os processos de negócio que devem ser apoiados. A modelagem dos processos de
negócio é feita através dos use cases de negócio.
Quanto aos aspectos de usabilidade, deve-se levar em consideração a participação
efetiva do usuário para o processo de modelagem, haja vista a necessidade de identificar
os envolvidos, descrever as características destes e do ambiente de trabalho.
Os principais objetivos desta atividade são: identificar todos os “papeis” e
“elementos” do negócio; e descrever como as realizações de casos de uso de negócios são
executadas pelos trabalhadores e entidades de negócio.
33
a2) Gerenciamento de Requisitos: Objetiva capturar os requisitos que serão atendidos pelo
produto de software. Nas fases de iniciação e elaboração, a ênfase será maior nesta
disciplina de requisitos, pois o objetivo destas fases é o entendimento e a delimitação do
escopo do produto de software.
Do ponto de vista de usabilidade, a disciplina de Requisitos destaca a compreensão
de quem são os usuários e quais as suas necessidades, além da identificação dos casos de
uso que mais beneficiam os usuários.
Assim como na Modelagem de negócios, a participação do usuário nesta disciplina
deve ser efetiva. Pois se faz necessário compreender as necessidades dos envolvidos
(quais as necessidades reais). Normalmente esta atividade é executada durante as fases de
Iniciação e Elaboração.
A principal atividade da disciplina de requisitos é identificar solicitações dos
envolvidos, usando informações como regras de negócios, solicitações de melhoria,
entrevistas e workshop de requisitos.
Nesta disciplina é que se faz o detalhamento dos casos de uso, com maior
intensidade no final da fase de Iniciação e início da Elaboração. O refinamento destes se
dá ao longo das fases de desenvolvimento do software.
Na disciplina de Requisitos também é prevista a modelagem da Interface do
Usuário e Protótipos da Interface do Usuário.
a3) Análise e Projeto: Objetiva compreender mais precisamente os use cases definidos na
disciplina de requisitos, produzindo um modelo já voltado para a implementação que
deverá estar adequado ao ambiente de implementação. Esta disciplina é bastante utilizada
na fase de elaboração e durante o início da fa se de construção.
34
a4) Implementação: Objetiva a organização do código em termos de implementação de
subsistemas, implementam as classes e objetos em termos de componentes, testa os
componentes em termos de unidades e integra os códigos produzidos. Esta disciplina é
bastante utilizada na fase de construção.
a5) Teste: Objetiva analisar, através de testes, se os requisitos foram atendidos e que os
defeitos serão removidos antes da implantação. Os modelos de testes são criados para
descrever como os testes serão realizados. Sua ênfase é maior no final da fase de
construção e no início da fase de transição.
A disciplina de Testes do RUP contempla os testes de usabilidade, incluindo o
teste de desempenho relacionado à usabilidade. Estes testes devem ser iniciados quando
houver protótipos executáveis da interface do usuário.
a6) Implantação/Entrega: Objetiva produzir releases do produto e entregá- los aos usuários
finais. Isto pode incluir atividades de beta-teste, migração de dados ou software existente
e aceitação formal.
A disciplina de Implantação, embora tenha seu ponto de ápice na fase de
Transição, algumas atividades ocorrem em fases anteriores ao planejamento e à
preparação para a implantação. Dentre estas atividades cita-se o desenvolvimento de
material de suporte, desenvolvimento de material de treinamento, guia de interface do
usuário, etc.
Nesta disciplina muitos aspectos de usabilidade são considerados tendo em vista
ser o marco final do processo de desenvolvimento.
35
A Implantação descreve as atividades que garantem que o produto será
disponibilizado a seus usuários finais, de maneira a atender os aspectos de usabilidade.
b) Disciplinas de Apoio do RUP
O objetivo das disciplinas de apoio é auxiliar a execução das disciplinas principais.
São elas:
b1) Configuração e Gerenciamento de Mudanças: Controla as diversas versões dos artefatos
produzidos durante o projeto, garantindo sua integridade. Ou seja, assegura que os
resultados não sejam conflitantes.
b2) Gerência de Projeto: Fornece um framework para a gerência de projetos, orientações para
planejamento, alocação de recursos e gerência de riscos.
b3) Ambiente: Fornece a descrição para a organização do ambiente de desenvolvimento em
termos de processos e ferramentas.
2.3– Princípios do Unifed Process Interative – UPi
De acordo com Sousa (2002), o UPi possui características bastante similares ao
RUP, porém com algumas particularidades. O RUP foca em controle de escopo e risco,
definição de funcionalidades, projeto, implementação e integração de componentes, testes de
funcionalidade, controle de mudança, documentação, etc. O UPi foca nas características dos
usuários, tarefas que eles realizam, o ambiente onde eles estão e os dispositivos que eles usam
para realizar suas tarefas. Este foco está mais relacionado a fatores humanos, usabilidade,
acessibilidade, aceitabilidade, recomendações ergonômicas e modelagem de interface. Estes
aspectos, quando aplicados a um PDS, podem trazer benefícios como: minimização do tempo
de aprendizagem do sistema, maximização da velocidade em realizar tarefas com o sistema e
maximização da satisfação do usuário com o sistema.
Dentre as seis melhores práticas, adotadas pelo RUP, o UPi apresenta algumas
diferenças, dentre as quais citam-se:
36
2.3.1 - Desenvolvimento do software iterativamente
A grande vantagem do UPi no desenvolvimento do software interativo é que os
aspectos da IHC podem ser aplicados desde cedo dentro do ciclo de vida até que o produto
esteja pronto para a liberação, o que aumenta a qualidade do produto final. Um outro ponto
importante é que os protótipos podem ser gerados aplicando os resultados das técnicas de
modelagem que começam na disciplina de requisitos.
2.3.2 - Gerenciamento dos requisitos
A gerência de requisitos no RUP envolve controlar a func ionalidade requerida e
restrições do sistema. No UPi, vai além disso, incluindo a análise das tarefas dos usuários, do
ambiente onde estão sendo executadas suas tarefas, e dos dispositivos que estão usando. Estes
novos aspectos trazem outros benefícios, tais como, garantir que o software retrate a realidade
dos usuários.
2.3.3 - Uso de arquiteturas baseada em componentes
Assim como o RUP, o UPi adota uma definição modular da arquitetura, mas, mais
especificamente, sugere a adoção da arquitetura do n-camadas, junto com o padrão de projeto
MVC. Eles fornecem o software para ser dividido em camadas independentes, o que fornece a
maior qualidade de ser reutilizável e a maior flexibilidade.
2.3.4 - Modelagem visual de um Software
Os modelos propostos pelo UPi não são limitados aos modelos padrões da UML.
Os modelos propostos no UPi são: usuário, tarefa, contexto, e modelos do domínio. Estes
modelos podem diretamente ser auxiliados por cenários gráficos. Além disso, a UMLi pode
ser usada para modelar os aspectos relacionados a User Interface - UI. Embora a aplicação da
UMLi esteja sujeita à futuros trabalhos.
37
2.3.5 - Verificação continua da qualidade do software
No UPi, a avaliação da qualidade começa também cedo no ciclo de vida e foca em
áreas de maior risco. Diferente do RUP, o UPi possui seu foco voltado a usabilidade,
acessibilidade, e aceitabilidade. Além de focalizar na qualidade do produto, o UPi focaliza
também no processo de qualidade.
2.3.6 - Controle das mudanças no software
O desenvolvimento iterativo permite a flexibilidade no planejamento e na
execução o desenvolvimento do software, e permite a evolução dos requisitos, o UPi propõe
esforços de manutenibilidade para os modelos definidos durante a descoberta dos requisitos.
Além das seis melhores práticas, o UPi possui outras características importantes,
mencionadas a seguir:
-
Os usuários do UPi usam casos de uso para definir o comportamento do sistema. Além
disso, o processo de desenvolvimento é baseado também no usuário, na tarefa, no
contexto, e nos modelos do domínio. A saber as funcionalidades do sistema desejado
pelos usuários não é bastante para satisfazer suas necessidades. Desenvolvendo um
sistema que atenda a suas necessidades reais; de acordo com suas habilidades, tarefas,
e condições do ambiente; é mais próximo da realidade.
-
O UPi é uma estrutura de processo, isto é, pode ser usada como um modelo. Pode ser
ajustado de acordo com as necessidades específicas, e a cultura da organização
adotante. Desde que a IHC seja uma área de estudo que pretende se manter
continuamente a crescer, o UPi necessitará provavelmente de ajuste e sua flexibilidade
permitirá esta evolução.
38
-
O UPi é um processo apoiado por algumas ferramentas sugeridas, desenvolvidas por
grupos de peritos da IHC de todo o mundo. Algumas destas ferramentas são
apresentadas na seção seguinte. A estrutura de processo do UPi é dividida em duas
dimensões, da mesma maneira que o RUP, como descrita na Figura 6: a dimensão
dinâmica e estática. As fases nas dimensões dinâmicas são as mesmas definidas no
RUP. O que muda é a aplicação de aspectos da IHC em cada fase e em sua avaliação
em cada marco. Os elementos na dimensão estática, que são: os papeis, as atividades,
os artefatos, e disciplinas, possuem as mesmas definições e finalidades que essas
definidas no RUP. O que muda é o conteúdo de cada disciplina, isto é, quais
atividades serão executadas e quais artefatos serão produzidos para acomodar aspectos
de IHC e quais serão os papeis.
2.3.7. Aspectos de Usabilidade do UPi
A Disciplina de Modelagem de Negócio foca nas características dos usuários e do
ambiente. O modelo de usuário adiciona a perspectiva humana ao ponto de vista do negócio.
O entendimento dos profissionais do negócio da organização auxilia na definição das tarefas
de negócio. O modelo de contexto de uso auxilia na adaptação da interface do sistema às
restrições do ambiente, por exemplo, uso de desktops em laboratórios de pesquisa e palm tops
para o acompanhamento de produção em indústrias.
A Disciplina de Requisitos foca na geração de interfaces baseada em modelos e
em metas de usabilidade. O modelo de usuário ajuda na adequação do sistema às
características dos usuários e o modelo de tarefa especifica as tarefas executadas pelos
usuários e ajuda a predizer dificuldades dos usuários, avaliar sistemas, medir a complexidade
de sistemas, predizer desempenho de sistemas, etc. As metas de usabilidade dos usuários
diretamente influenciam a qualidade de uso do sistema, como fácil acesso a atalhos,
quantidade de informação que os usuários precisam recordar, etc.
A Disciplina de Análise e Projeto foca nos vários tipos de usuários, estilos de
interação, independência de diá logo e metas de usabilidade. Os diferentes tipos de usuários e
estilos de interação são considerados no aperfeiçoamento do modelo de usuário para tornar o
39
sistema mais acessível a diferentes usuários. A independência de dialogo representa a
separação das camadas de apresentação, controle, regra de negocio e dados durante a
definição da arquitetura do sistema. As metas de usabilidade são consideradas na escolha da
melhor opção do modelo de interface conceitual do sistema.
A Disciplina de Implementação foca na aplicação de recomendações ergonômicas.
As recomendações provêem consistência na interface, aumentam a produtividade do usuário,
minimizam o numero de erros, etc.
A Disciplina de Testes foca na avaliação do produto no ponto de vista do usuário.
Esta avaliação do sistema considera características dos usuários, as tarefas que realizam, o
ambiente onde estão trabalhando e a tecnologia que usam, além das metas de usabilidade.
A Disciplina de Implantação foca nas características dos usuários e em suas
percepções do software instalado. O treinamento e avaliação do sistema são realizados são
importantes para garantir adequação das adaptações aos usuários e acessibilidade e
aceitabilidade do sistema.
A Disciplina de Configuração e Mudança foca na participação ativa dos usuários e
no controle sobre os artefatos relacionados à geração de interface. A participação dos usuários
minimiza os erros de falta de relacionamento entre o sistema e as necessidades dos usuários.
O controle de mudanças nos modelos para geração de interface auxilia na analise de custo e
prazo antes da manutenção.
A Disciplina de Gerencia de Projetos foca nas necessidades do usuário e na garantia
da aplicação de recomendações ergonômicas. O foco nas necessidades do usuário e adquirida
com a aplicação de protótipos para a minimização de riscos no projeto. A aplicação de
recomendações ergonômicas é alcançada com a aplicação do documento de aceitação da
interface, o qual deve ser analisado pelo usuário para garantir que os aspectos avaliados nos
testes estão presentes no sistema.
40
A Disciplina de Ambiente foca na aplicação de recomendações na transição entre
os modelos para gerar interface de acordo com os requisitos dos usuários. O uso de
recomendações de transição garante a consistência entre os modelos e as metas de
usabilidade.
O foco em aspectos de IHC nas disciplinas do UPi trazem benefícios para os
profissionais envolvidos no processo de software e para os usuários. Os primeiros se
beneficiam com a diminuição de re-trabalho devido ao foco nas necessidades dos usuários
durante todo o processo de software. Os segundos se beneficiam com os aspectos de
usabilidade, aceitabilidade e acessibilidade, os quais levam a satisfação, adquirida com a
associação dos aspectos de IHC no processo de software.
Conforme visto ao longo deste capítulo, percebe-se que a evolução e o
aprimoramento dos PDSs são ações constantes. Estas ações se devem principalmente em
virtude dos processos de desenvolvimento estarem cada vez mais voltados para os princípios
de usabilidade.
3 – PRINCÍPIOS DA INTERAÇÃO HUMANO COMPUTADOR (IHC) A SEREM
CONSIDEREADOS NUM PDS
3.1 - Interação Humano Computador – IHC
Como já dito, a IHC é uma área de pesquisa dedicada a estudar os fenômenos de
comunicação entre pessoas e sistemas computacionais. “Teve início como disciplina no fim
dos anos 70 e início dos anos 80. Inicialmente começou através de uma aliança entre
profissionais da informática e psicólogos. Desde sua etnografia, a ergonomia e a teoria de
atividades foram recrutadas para a causa. A pesquisa em IHC se preocupa em como se
certificar da usabilidade, o que quer dizer, produtos que são efetivos, eficientes e satisfatórios
em seu uso. Pesquisadores de IHC tentam entender o que os usuários querem fazer e como
designers podem ser ajudados a prover produtos que satisfaçam estas necessidades (Monk,
2002).”
De acordo com Silva Filho (2003), a Interação Homem-Computador é uma área
multidisciplinar que envolve as áreas de Ciência da Computação, Psicologia, Fatores Humanos, Lingüística,
dentre outras. IHC está voltada para a aplicação do conhecimento destas disciplinas para produzir interfaces
amigáveis (ou “user-friendly”). Não é uma disciplina essencialmente voltada para o estudo de computação ou do
ser humano, mas para a comunicação entre estas duas entidades. Conhecimento sobre as limitações da
capacidade humana e restrições da tecnologia existente devem ser ponderados para oferecer ao usuário um meio
adequado através do qual eles podem interagir com os computadores.
42
Os seres humanos percebem as coisas através de seus sentidos, isto é, visual, auditivo e tato. Estes
sentidos habilitam o usuário de um sistema interativo a perceber a informação, armazená-la (em sua memória) e
processar a informação usando o raciocínio dedutivo ou indutivo. Em IHC, isto ocorre através do sentido da
visão, como por exemplo: relatórios, gráficos, etc. Neste caso, o olho e o cérebro trabalham juntos a fim de
receber e interpretar a informação visual baseada no tamanho, forma, cor(es), orientação e movimento. Muitos
elementos discretos de informação são apresentados simultaneamente para o homem absorver. Assim, uma
especificação apropriada de comunicação visual é o elemento chave de uma interface amigável.
Embora haja uma tendência para se utilizar manipulação/comunicação gráfica no projeto de
interface, muito da informação visual ainda é apresentada na forma textual. A leitura - o processo de extrair
informação do texto - é a atividade chave na maioria das interfaces. Os seres humanos precisam decodificar os
padrões visuais e recuperar o significado das palavras e frases. Neste caso, a velocidade do processo de leitura é
controlada pelo padrão de movimento do olho que escaneia o texto em sacadas do olho feitas em alta velocidade.
Adicionalmente, o tipo de caractere fonte, o comprimento de linha do texto e cor(es) afetam a facilidade na qual
o processo de leitura ocorre.
Quando a informação é extraída da interface, ela deve ser armazenada para ser recuperada
(lembrada) e utilizada posteriormente. Além disso, o usuário precisa lembrar de comandos e seqüências
operacionais de uso. Tais informações são armazenadas na memória humana (que é um sistema complexo)
composto de duas partes: a memória de curta duração que possui capacidade de armazenamento e tempo de
recordação limitados e a memória de longa duração que possui capacidade de armazenamento e tempo de
recordação ma iores e onde se tem o conhecimento do ser humano. Assim, se o projetista de uma interface HC
especifica uma interface que faz solicitações indevidas dessas duas memórias, então o desempenho do usuário do
sistema será degradado.
Finalizando, temos que a maioria das pessoas não aplica raciocínio indutivo ou dedutivo quando se
depara com um problema. Ao invés, é comum aplicar um conjunto de heurísticas (procedimentos, regras,
estratégias) baseadas no conhecimento de problemas similares. Tais heurísticas tendem a ser específicas do
domínio. Como conseqüência, uma interface HC deve ser especificada de modo que habilite o usuário a
desenvolver heurísticas para interação. Todavia, é importante observar que estas heurísticas deveriam
permanecer consistentes em diferentes domínios de interação.
43
3.2 – Princípios da Engenharia da Usabilidade
As fases do processo da engenharia da usabilidade estenderam o ciclo tradicional de
desenvolvimento que começava com a definição do produto e terminava com a entrega. O processo de design
para a usabilidade possui 4 fases: pré-design, design inicial, desenvolvimento interativo e pós-design.
A fase de Pré-design é caracterizada pela busca de informação e conceituação sobre o usuário e seu
contexto de trabalho e sobre sistemas relacionados, padrões de interface, guidelines, ferramentas de
desenvolvimento, etc. A fase de Design visa realizar um protótipo que siga princípios de usabilidade e verificar
empiricamente o design com usuários reais, para assegurar ter atingido as metas estabelecidas. Essa fase está
subdividida em: i) Design inicial, que é assegurada por fazer a especificação inicial da interface e ii)
Desenvolvimento Interativo, onde o desenvolvimento interativo é alimentado por feedback de testes até os
objetivos tenham sido alcançados.
Finalmente tem-se a fase de Pós-design com a Instalação do sistema no local de trabalho do usuário
e acompanhamento com medidas de reação e aceitação do sistema pelo usuário final.
Considerando a importância deste processo de usabilidade, destacamos três
princípios básicos que estão envolvidos nas suas fases: Centralizar Foco no Usuário,
considerar Recomendações Ergométricas (RE) e realizar Testes de Usabilidade.
3.2.1 – Centralização de Foco No Usuário
Segundo Oliveira (2002), para que um sistema atenda às necessidades de uma organização, é
preciso haver um entendimento global das mesmas por parte da equipe desenvolvedora. E, muitas vezes, o
próprio usuário não as conhece ou, mesmo, não sabe expressá-las de maneira clara. Porém, como todo cliente,
ele precisa conhecer bem o produto para que suas expectativas sejam bem atendidas. Este é um grande desafio
para os profissionais da informática, que lidam com produtos personalizados e de difícil fabricação. Para garantir
a satisfação do mesmo, a construção do sistema deve ser feita em sintonia com suas necessidades, através de sua
colaboração efetiva ao longo do projeto. É importante, então, que se estabeleçam critérios para se realizar uma
boa captura destas necessidades.
Um conceito imp ortante tem sido aplicado com sucesso por profissionais da engenharia de
software, o qual retrata a participação efetiva do usuário final no decorrer do processo. Denomina-se
44
Desenvolvimento Centrado no Usuário e se caracteriza pelo envolvimento constante do usuário durante toda a
construção do sistema. Desta forma, eles assegurarão à equipe de desenvolvimento um entendimento amplo de
suas necessidades e expectativas, proporcionando-lhe a criação de um produto com melhor usabilidade, em
tempo e custo reduzidos.
Tradicionalmente, o comportamento das equipes de desenvolvimentos de sistemas exerce pouca
influência sobre a participação contínua do usuário durante o projeto, muitas vezes restringindo-se apenas à fase
de análise dos requisitos. Sabemos, porém, que tal prática pode comprometer a criação de um produto bem
definido, resultando em custos elevados para execução de futuros reparos.
Esta problemática afeta grande parte das equipes, gerando retrabalhos significativos, o que pode
representar um alto prejuízo. Custos com análise, projeto e implementação são consideravelmente ampliados, em
alguns casos inviabilizando todo o esforço para a construção do sistema.
Normalmente, o foco do projeto é voltado para a arquitetura interna e desenvolvimento de código.
Em contrapartida, o desenvolvimento centrado no usuário enfatiza as perspectivas dos usuários finais, analisando
suas experiências, ambientes de trabalho, dificuldades, dentre muitos aspectos que lhes cercam.
Ao contrário do que ocorre em abordagens tradicionais, a necessidade de cooperação
multidisciplinar é característica importante em um desenvolvimento centrado no usuário. Profissionais de
diversas áreas devem atuar no projeto, garantindo excelência ao produto e, consequentemente, a satisfação do
cliente.
Outro importante diferencial entre a abordagem centrada no usuário e a tradicional encontra-se no
processo de validação do sistema pelos usuários. Na primeira isto ocorre iterativamente ao longo de todo o ciclo,
antecipando reparos em custo e tempo bem menores. Na segunda, esta validação normalmente é feita somente
após a entrega inicial do produto. De acordo com Clements (1999), existem cinco princípios que caracterizam o
desenvolvimento centrado no usuário (user-centered design), os quais são descritos a seguir.
a) Princípios do Projeto Centrado no Usuário
1º Princípio: Entender os Usuários
Este princípio é a base de todo o projeto. A equipe de desenvolvimento deve entender bem a
realidade e expectativas dos usuários finais, com o foco voltado para a forma atual de execução de suas
atividades e como irão desempenhá-las no futuro. Para isto, precisará conhecer tais tarefas, ferramentas
45
utilizadas, problemas que enfrentam com elas e as características chaves do ambiente em que executam estas
atividades.
Uma técnica bastante utilizada para o entendimento dos usuários é a modelagem de cenários de
utilização em interação com o ambiente de estudo.
2º Princípio: Projetar toda a Experiência do Usuário
O desenvolvimento do sistema deve direcionar-se para uma solução baseada na experiência dos
usuários, considerando todo o seu contexto a respeito do conhecimento e habilidade com sistemas interativos.
Algumas características devem ser incorporadas ao sistema, tornando-o atraente, intuitivo e fácil de adquirir,
configurar, aprender e utilizar. Isto tornará o software adaptado ao nível dos usuários finais.
Para atingirmos tal característica de sistema adaptativo faz-se necessário o envolvimento de
especialistas de diversas áreas no projeto, como especialistas em fatores humanos da área de Interação HumanoComputador (IHC).
3º Princípio: Avaliar o Projeto
Em processos centrados no usuário, é comum a existência de técnicas que proporcionem avaliações
do projeto, evitando maiores desgastes na construção do sistema. Estes mecanismos asseguram um
desenvolvimento eficaz, pois utiliza o critério de codificar apenas o que fora validado pelo usuário.
A maneira mais apropriada para garantir este feedback do cliente é a utilização de protótipos, que
representam um esboço do produto final. Apesar de não possuírem todas as funcionalidades do sistema,
permitem uma prévia interação do usuário, auxiliando-o no processo de validação.
4º Princípio: Avaliar a Competitividade
Este princípio concentra-se na avaliação da competitividade do novo produto, com um foco para as
soluções antecessoras e concorrentes, identificando o grau de qualidade e aceitação das mesmas pelo usuário, a
fim de colocar a equipe desenvolvedora em sintonia com o mercado existente. Isto permitirá uma anális e
criteriosa de importantes requisitos do sistema. Isto, então, servirá de subsídio para a construção de um produto
com maior nível de aceitabilidade.
46
5º Princípio: Gerenciar Usuários
O último princípio consiste no gerenciamento de usuários. Inclui atividades como:
- despertar o envolvimento dos usuários;
- garantir aos usuários o entendimento com relação à sua participação nas tomadas de decisão;
- escolher os usuários apropriados para a realização de testes em módulos específicos;
- adquirir o conhecimento e necessidades específicas dos usuários;
- motivar os usuários para a definição dos critérios de avaliação.”
3.2.2 – Recomendações Ergonômicas
As Recomendações Ergonômicas também são conhecidas como heurísticas de
usabilidade e princípios ergonômicos, são sugestões de projeto sobre aspectos de interface,
que orientam no desenvolvimento de Sistemas Interativos - SI. Elas permitem determinar a
melhor maneira que as informações devem ser mostradas ao usuário durante sua interação
com o SI (por exemplo, o fato de mostrar somente as informações mais necessárias ou de
permitir ao usuário cont rolar o diálogo com o sistema) (Furtado, 1997).
Vanderdonckt (1999) apresentou a seguinte classificação sobre recomendações:
? Regras para projeto: que compreendem um conjunto de funções e/ou especificações
operacionais que determinam o projeto de uma interface de usuário em particular. São
normalmente apresentadas como regras físicas, formatos de telas e janelas;
? Guidelines: são princípios de avaliação e/ou projeto a serem considerados no projeto
de interface de usuário. Eles são normalmente incorporados em grandes documentados
chamados de “conjunto de guidelines” ou “guias ergonômicos”;
? Padrões ou Normas: compreendem um conjunto de especificações funcionais e/ou
operacionais com o intuito de padronizar o projeto de interfaces de usuário. São
definidos por organizações nacionais ou internacionais que promovem a padronização,
47
como a Associação Brasileira de Normas Técnicas - ABNT no Brasil, a International
Standards Organization - ISO na Europa (partes 14, 16 e 17), que se referem, dentre
outros, a estilos de diálogos (tais como menu, comandos, etc.) e a HFES (Human
Factors and Ergonomics Society) nos Estados Unidos;
? Guias de estilo: são documentos que normalmente são produzidos por uma
organização e disponibilizados comercialmente. Podemos citar como exemplos de
guias de estilo: OSF/Motif; Open Look; VUE da HP; CUA da IBM, entre outros e;
? Algoritmos Ergonômicos: aparecem como componentes de software que objetivam
sistematizar a implementação de um aspecto do projeto de interfaces usando
geralmente regras de produção para representarem as recomendações ergonômicas.
Um conjunto de critérios ergonômicos são normalmente usados em vários métodos
de inspeção da usabilidade (Scapin,1993). Dente eles:
i) Condução, refere-se aos meios disponíveis para aconselhar, orientar, informar e
conduzir o usuário na interação com o computador (mensagens, alarmes, rótulos, etc.);
ii) Carga de trabalho, refere-se à brevidade das apresentações (concisão), às entradas
(ações mínimas) e à densidade informacional visando reduzir a carga do usuário e
melhorar a eficiência do diálogo;
iii) Controle explícito, define-se no caráter explícito das ações do usuário e no controle
que ele tem sobre os processamentos;
iv) Adaptabilidade, refere-se às possibilidades de personalização do sistema que são
oferecidas ao usuário;
v) Gestão de erros, diz respeito a mecanismos que permitem evitar ou reduzir a ocorrência
de erros;
vi) Consistência, refere-se à forma na qual as escolhas na concepção da interface são
conservadas idênticas em contextos idênticos, e diferentes para contextos diferentes;
vii) Significado dos códigos e denominações, avalia se os códigos e denominações são
claros e significativos para os usuários do sistema e;
viii) Compatibilidade, verifica a compatibilidade do sistema com as expectativas e
necessidades do usuário em sua tarefa.
48
3.2.3 – Testes de Usabilidade
Os testes de usabilidade surgiram no lendário laboratório PARC da Xerox e foram
aplicados pela primeira vez pela equipe de cientistas que desenvolveu o computador ALTO,
com o objetivo de definir quantos botões deveriam ser colocados num mouse.
A expressão "teste de usabilidade" na verdade descreve um conjunto de métodos
de avaliação de produtos e designs de produtos que apresentam três características em
comum:
-
Usa-se pessoas representativas da população para as quais o produto é dirigido;
-
Requere-se que estas pessoas realizem tarefas "típicas" ou "críticas" com o produto;
-
Recolhe-se dados sobre esta atividade.
Existem vários tipos de teste de usabilidade, dentre os quais destacam-se:
-
Medição de Performance : Dá-se uma lista de tarefas para o usuário executar em um
ambiente controlado (ou observa-se o usuário em sua rotina diária) e mede-se
grandezas como:
-
?
Tempo gasto para completar cada tarefa
?
Número de erros cometidos pelos usuários
?
Número de comandos e funções nunca utilizados pelos usuários
?
Número de consultas do usuário ao manual do sistema
Pensamento em voz alta (thinking aloud ): Consiste basicamente em fazer um
usuário verbalizar seus pensamentos enquanto utiliza o sistema sob teste (Denning,
1990), anotando-se os pontos onde ocorre um erro ou dificuldade. Há muitas variações
do método básico, como por exemplo:
49
-
Aprendizagem por co-descoberta (Kennedy, 1989): dois usuários usam o sistema
juntos. Captura interações entre usuários e torna mais natural a verbalização.
-
Teste retrospectivo: o usuário é convidado a comentar sua própria atuação, gravada
em vídeo.
-
Protocolo de Pergunta (Kato, 1986): há uma interação explícita (o "treinador") entre
o usuário e o aplicador do teste. O usuário pode perguntar ao treinador, geralmente um
assistente do aplicador ou um usuário experiente, qualquer questão relacionada ao
sistema.
É interessante que os desenvolvedores do produto estejam envolvidos diretamente
no planejamento dos testes, uma vez que os resultados dos mesmos influenciarão nos rumos
de seu trabalho (Dumas, 1989). No caso dos testes de verbalização de pensamento, em
particular, há evidências na literatura de que há ganhos significativos quando os
desenvolvedores/projetistas efetivamente participam do teste (Wright, 1991).
Os testes de usabilidade também têm seus problemas (Holleran, 1991). Como em
todo teste, deve-se prestar atenção aos aspectos de confiabilidade e validade. A confiabilidade
de um teste diz se o mesmo resultado seria conseguido caso o teste fosse repetido e a validade
diz se o resultado do teste reflete realmente o atributo que se queria testar. O que torna essas
grandezas um problema é, por um lado, a grande variabilidade entre os us uários em termos de
habilidade (Egan, 1988) e, por outro lado, descuidos metodológicos por parte dos testadores
(incluir no teste usuários que não são usuários típicos do produto, por exemplo).
Testes com usuários devem incluir uma variada gama de audiências. É importante
mesclar testes com pessoas que têm e que não têm familiaridade com os sistemas, já que os
experts e os novatos demonstram comportamentos diversos e às vezes opostos. O mesmo
ocorre com pessoas de idades e educação diferentes.
Os testes de usabilidade devem ser realizados desde o início do projeto e feitos
individualmente (com uns 3 usuários típicos de cada classe de usuário, um de cada vez) com
acompanhamento de um avaliador da equipe de desenvolvimento o qual deve anotar tudo que
50
acontece (tempo de execução das tarefas, numero de erros, comentários do usuário, etc.) que
for importante para melhorar o produto. Como acontecem muitas coisas ao mesmo tempo, é
recomendado que a avaliação seja filmada para uma analise posterior mais detalhada.
O fato dos testes serem feitos com um acompanhamento sistemático do avaliador,
que logo vai recebendo feedback do usuário para melhorar o produto, e o fato deles serem
feitos desde o início do ciclo de desenvolvimento são importantes para a melhor, mais barata
e mais rápida identificação e correção de problemas.
Uma outra forma de trabalhar a usabilidade é através do Participatory Design
(design participado) que é uma espécie de “brainstorming” onde participam os vários
intervenientes no processo (utilizadores, designers, programadores).
Os testes de usabilidade podem ser registrados em vídeo ou em áudio, onde
usuários interagem com um sistema computadorizado, em laboratórios equipados para checar
a eficiência das interfaces gráficas. Os testes de usabilidade são empregados largamente na
indústria de software dos EUA, no desenvolvimento de websites e na telefonia móvel.
Os testes de usabilidade envolvem a interação com usuários reais, cumprindo
tarefas reais do produto. Se por um lado eles são mais caros e mais complexos que a avaliação
heurística, por outro lado eles permitem captar erros mais sérios e mais difíceis de serem
constatados.
Vale lembrar que heur ísticas de usabilidade são princípios que as interfaces devem
seguir para atingir uma boa usabilidade. De posse de uma interface do usuário (ou um
protótipo ou especificação dela), os próprios projetistas podem fazer uma avaliação de sua
usabilidade (Nielsen, 1993).
A análise heurística pode ser utilizada em qualquer altura do desenvolvimento de
um sistema, no entanto deve ser efetuada na primeira fase do projeto. Pode dar-se aos peritos
51
apenas alguns esboços em papel do futuro sistema e a partir daí poderá ser feita um a primeira
análise heurística da usabilidade. Os problemas descobertos nesta fase inicial poupam
dinheiro porque não é necessário reconceber o sistema, uma vez que ele ainda está só em
papel.
3.3 – Princípios Relevantes de IHC
Apesar da centralização do foco no usuário, a consideração de RE e a realização de
testes de usabilidade, serem os pilares da usabilidade de um produto, é necessário que
consideremos outros princípios fundamentais de usabilidade.
3.3.1 - Sensibilidade ao Contexto
O tema sensibilidade ao contexto é bastante explorado na literatura de IHC existem diversos
trabalhos de desenvolvimento de interfaces sensíveis ao contexto. Um contexto de uso de um Sistema Interativo
(SI) é definido por três classes de entidades (Calvary et al, 2003):
? Os usuários do sistema que têm a intenção de usar (ou quem efetivamente usam) o sistema;
? A plataforma, que corresponde ao hardware (dispositivos de interação) e ao software (toolkit,
sistema operacional) e;
? O ambiente físico, espaço onde a interação acontece.
3.3.2 - Uso de Modelos
A adoção de modelos (como o modelo de casos de uso e o diagrama de colaboração) ajuda os
desenvolvedores a representarem especificações genéricas (como as necessidades dos usuários) e especificações
detalhadas (como a troca de mensagem entre objetos que colaboram), respectivamente. Uma vez representadas
as especificações, é possível fazer a integração entre elas. Outra vantagem de se usar modelos, é a possibilidade
de se fazer matrizes de rastreabilidade, auxiliando na realização de testes, implementação e manutenção de um
SI. Existem na literatura de IHC várias ferramentas que geram interfaces de forma automática ou semiautomática a partir de modelos (tal como: A RTStudio (Thevenin, 2001)), porém ainda não existe nenhuma
ferramenta comercial disponível. A ferramenta CASE ROSE, comercialmente disponível, permite a geração de
scripts de classes a partir dos modelos de dados. Os modelos usados em IHC são os seguintes:
52
?
Cenários
Cenários são narrativas textuais, pictóricas ou encenadas, de situações fictícias, mas plausíveis
(senão desejáveis) de uso situado da aplicação. Devem ser ricos em contextualização e possuir um foco
claro que transmita aos usuários e designers as idéias sendo testadas.
O levantamento de requisitos sobre as tarefas e os usuários pode ser melhor realizado quando os
analistas procuram descrever situações do processo de trabalho. Os métodos baseados em cenários
consistem de uma coleção de narrativas de situações no domínio do problema que permitem a
identificação de componentes de design. Assim, eles são um meio de representação de fácil
compreensão para os usuários envolvidos (muitas vezes de formação bastante heterogênea) que passam
a poder avaliar, criticar e fazer sugestões. Eles permitem a reorganização de componentes e tarefas do
domínio. Isto ocorre porque quando se introduz novas tecnologias, parte do contexto de tarefa de uma
organização é alterado. Nesta reengenharia, novas tarefas e práticas são incorporadas enquanto outras
são eliminadas.
Os cenários também podem ser utilizados para formar uma base de casos (Carey & Rusli, 1995),
que pode ser utilizada tanto no aprendizado de IHC quanto no reuso de designs. Neste caso, ao invés de
se utilizar cenários para tentar prever possíveis situações de uso, os cenários são registros de situações
reais, que podem ser comparadas em diversos níveis, como em desempenho e eficiência de
determinadas escolhas e decisões de design.
?
Storyboard (protótipo abstrato)
Esta técnica envolve a especificação através de imagens de situações de uso. Ela serve para apoiar
o momento que o projetista de interface deve fazer um estudo do sistema sob o ponto de vista do
usuário, verificando para cada cenário, por exemplo, que informações estarão disponíveis para o usuário
durante a realização de uma determinada atividade. Em seguida, ele deve especificar a interface
definindo seus componentes de interação.
Esta técnica está bastante relacionada com cenários. Entretanto, enquanto cenários utilizam
principalmente narrativas para a descrição dos casos de uso, o storyboard utiliza desenhos e ilustrações,
utilizando papel ou computadores (ver Figura 7).
53
Assim, os cenários são mais adequados para a análise das tarefas, enquanto storyboard permite a
validação dos cenários e a elaboração de protótipos não operacionais para designs iniciais. Além disto,
o storyboard é usado de maneira mais livre.
Figura 7 – Exemplo de Storyboard para consulta em uma biblioteca
?
Modelo de tarefa
Para representar as tarefas do usuário identificadas nos cenários, existem na literatura de IHC,
vários modelos de tarefa. Um modelo de tarefa serve para representar tarefas que o usuário realiza
quando interagindo com um sistema interativo.
Um esquema de modelo muito freqüentemente usado é baseado na planificação hierárquica, onde
uma tarefa é composta em sub-tarefas, que por sua vez são compostas por ações, que se situam no nível
mais baixo da hierarquia (ver Figura 8).
Figura 8 – Planificação Hierárquica de Tarefas
54
Uma tarefa é descrita por um objetivo do usuário, uma lista de sub-tarefas (os procedimentos)
necessárias para atingir o objetivo, assim como suas restrições estruturais e temporais. As relações
estruturais são: e- executar todas as sub-tarefas; ou- executar pelo menos uma das sub-tarefas e altexecutar somente uma das sub-tarefas. As relações temporais são: SEQ (sub-tarefas seqüenciais) executar as sub-tarefas seqüencialmente e PAR (sub-tarefas paralelas dependentes) - executar as subtarefas de forma aleatória.
A definição de tarefa é recursiva, visto que uma sub-tarefa é também uma tarefa, distinguindo-as
apenas pelo nível de abstração.
Além disto, pode-se definir características das tarefas que serão relevantes no processo de geração
da interface de usuário, tais como: se a tarefa é disparada pelo usuário (e que tipo de usuário, especificar
seu papel) ou automática (disparada pelo sistema), se a tarefa pede ou mostra informações na tela, se a
tarefa é obrigatória ou facultativa, repetitiva, interrompível, sua importância e freqüência de uso.
A Figura 9 ilustra um exemplo de um modelo de tarefas para um sistema de Manutenção de
pedidos de CD pela WEB. Mais especificamente, para o usuário Comprador realizar a Manutenção do
Pedido, ele pode visualizar o pedido, e em seguida, alterar as quantidades dos CDs ou removê-los;
Figura 9 – Exemplo de Modelo de Tarefa.
55
?
Modelo de Navegação ou Modelo de interface conceitual
O Modelo de Interface Conceitual consiste na representação das interfaces de um sistema a nível
conceitual (Furtado, 1997). Ele é representado por um conjunto de espaços, sub-espaços e objetos de
interação detentores de características particulares e organizados segundo uma ordem apropriada. Os
espaços correspondem cada um a toda a área espacial que o usuário pode observar e/ou interagir. Os
sub-espaços são cada uma das sub-áreas espaciais que constituem um espaço. Os objetos de interação
representam os dispositivos com os quais os usuários podem interagir. A Figura 10 apresenta um
Modelo de Interface Conceitual representando um formulário de identificação de um usuário para
acesso a um curso de educação a distância. Este formulário é composto dos seguintes objetos de
interação: um objeto do tipo entrada de dados para o nome do usuário, outro objeto do mesmo tipo para
a senha do usuário, e um terceiro do tipo clique para a submissão das informações inseridas nos dois
primeiros objetos.
Figura 10 – Modelo de Interface Conceitual de um formulário de identificação
3.3.3 - Desenvolvimento dirigido por pattern
Patterns são componentes de software reutilizáveis que podem ser acessados e integrados a uma
estrutura já existente. O uso de patterns objetiva promover o reuso de soluções anteriormente já usadas e
testadas. Para isto é realizada uma análise dos componentes considerando a especificação de requisitos do
sistema corrente. Durante a realização desta atividade pode ocorrer a modificação de requisitos, caso queira que
os componentes selecionados reflitam os requisitos. Do contrário, a análise é refeita procurando soluções
alternativas antes de se passar para o projeto do sistema com reuso.
Destacam-se na literatura de IHC os patterns de usabilidade, que são oriundos de Recomendações
ergonômicas (RE) .
56
Um exemplo de um pattern é o pattern de arquitetura MVC.
A arquitetura MVC fornece uma maneira de dividir a funcionalidade envolvida na manutenção e
apresentação dos dados de uma aplicação. A arquitetura MVC não é nova e foi originalmente desenvolvida para
mapear as tarefas tradicionais de entrada, processamento e saída para o modelo de interação com o usuário.
Usando o padrão MVC fica fácil mapear esses conceitos no domínio de aplicações multicamadas.
Na arquitetura MVC o modelo representa os dados da aplicação e as regras do negócio que
governam o acesso e a mo dificação dos dados. O modelo mantém o estado persistente do negócio e fornece ao
controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo.
Um componente de visualização renderiza o conteúdo de uma parte particular do modelo e
encaminha para o controlador as ações do usuário; acessa também os dados do modelo via controlador e define
como esses dados devem ser apresentados.
Um controlador define o comportamento da aplicação, é ele que interpreta as ações do usuário e as
mapeia para chamadas do modelo. Em um cliente de aplicações Web essas ações do usuário poderiam ser
cliques de botões ou seleções de menus. As ações realizadas pelo modelo incluem ativar processos de negócio ou
alterar o estado do modelo. Com base na ação do usuário e no resultado do processamento do modelo, o
controlador seleciona uma visualização a ser exibida como parte da resposta a solicitação do usuário. Há
normalmente um controlador para cada conjunto de funcionalidades relacionadas.
A arquitetura de 3 camadas que esta representada na Figura 11 mostra uma implementação do
modelo MVC . O modelo MVC se preocupa em separar a informação de sua apresentação.
Figura 11 – Modelo 3 Camadas - MVC
57
Camada de apresentação ou visualização - Não esta preocupada em como a informação foi
obtida ou onde ela foi obtida apenas exibe a informação.
?
inclui os elementos de exibição no cliente : HTML , XML , ASP , Applets .
?
É a camada de interface com o usuário.
?
É usada para receber a entrada de dados e apresentar o resultado
Camada de lógica da Aplicação - É o coração da aplicação . Responsável por tudo que a
aplicação vai fazer.
?
modela os dados e o comportamento por atrás do processo de negócios
?
se preocupa apenas com o armazenamento , manipulação e geração de dados
?
É um encapsulamento de dados e de comportamento independente da apresentação.
Camada de Controle - determina o fluxo da apresentação servindo como uma camada
intermediária entre a camada de apresentação e a lógica.
?
controla e mapeia as ações
Vantagens do modelo MVC :
1.
Como o modelo MVC gerencia múltiplos visualizadores usando o mesmo modelo é
fácil manter , testar e atualizar sistemas múltiplos
2.
É muito simples incluir novos clientes apenas incluindo seus visualizadores e
controles
3.
Torna a aplicação escalável
4.
É possível ter desenvolvimento em paralelo para o modelo , visualizador e controle
pois são independentes.
Desvantagens do modelo MVC:
1.
Requer uma quantidade maior de tempo para analis ar e modelar o sistema
2.
Requer pessoal especializado
3.
Não é aconselhável para pequenas aplicações
58
3.3.4 - Independência de Dispositivos
Este tópico envolve dois lados: da representação interna, que seria a independência
do dispositivo de armazenamento e da representação externa, que seria a ndependência dos
dispositivos de interação (como: desktop, palm, celular, etc.).
3.4 - Conclusão
Atualmente existe uma grande preocupação por parte dos desenvolvedores de
software, em torná-los cada vez mais “amistosos” aos usuários. Diversos artefatos e princípios
de IHC têm apoiado esta afirmativa dentre os quais citam-se: centralização de foco no
usuário, uso de recomendações ergonômicas, realização de testes de usabilidade, sensibilidade
ao contexto, uso de modelos (em especial Modelo de Tarefas e Modelo conceitual de
Interface), desenvolvimento dirigido por pattern, independência de dispositivos e o uso da
engenharia da usabilidade.
4 – MATRIZ INTERATIVA DE AVALIAÇÃO (MIA)
4.1 – Princípios das MIA
As Matrizes Interativas de Avaliação são utilizadas corriqueiramente em diversas
áreas, seja na engenharia, arquitetura, áreas de saúde, administrativas, legislativas, etc.
As MIAs têm por finalidade facilitar os processos de decisão, através do
cruzamento de diversas variáveis. Por exemplo, na área de Meio Ambiente se faz uma
avaliação entre componentes ambientais (dispostas eixo X) e as etapas do projeto (dispostas
no eixo Y).
O processo de definição e identificação das variáveis não é muito simples e deve
seguir alguns critérios. Dentre os critérios a serem seguidos se destacam: a importância da
variável dentro do contexto geral do projeto, a freqüência de uso da variável, etc.
Na interação (relação) entre as variáveis que formam a matriz de avaliação são
promovidas valorações. Estas valorações podem ser definidas de diversas maneiras. Exemplo:
se a relação Custo X Benefício para certo produto apresentar um valor 2, dentro de uma escala
de valores representada pelos elementos 1, 2 e 3, esta relação pode ser interpretada em
equilíbrio. Notadamente, se for convencionado que para o valor 1 o Custo representar mais
que o Benefício e para o valor 3 o contrário.
60
O modelo de MIA adotado neste trabalho é baseado na matriz interativa
desenvolvida por (Leopold et al., 1971). Embora a matriz desenvolvida por Leopold seja
direcionada para avaliação de impactos ambientais, faremos uma adaptação para análise de
um PDS versus os Princípios de Usabilidade. A Figura 12 ilustra o conceito da matriz de
Leopold e a adaptação proposta para este trabalho.
Figura 12 - Matriz interativa de Leopold
Ao utilizar a matriz de Leopold se deve considerar cada ação e seu potencial de
impacto sobre cada elemento. Quando se prevê um impacto, a matriz aparece marcada com
uma linha diagonal e a célula correspondente com essa interação, esta atividade refere-se ao
primeiro passo a ser tomado no processo de montagem da matriz.
Direcionando a matriz para o caso da avaliação de um PDS, as ações referem-se às
etapas de um PDS, o potencial de impacto é traduzido pela necessidade de possuir ou
contemplar os aspectos relativos à Usabilidade e os elementos são os princípios de
Usabilidade, quando se identificar que certa fase do PDS deva atender certo aspecto de
Usabilidade, a célula da matriz aparece hachurada (colorida), indicando essa interação.
O segundo passo do uso da matriz de Leopold é descobrir a interação em termos
de magnitude e importância. A magnitude de uma interação é sua extensão ou escala e se
descreve mediante a associação de um valor numérico compreendido entre 1 e 10, onde 10
representa a maior magnitude e 1 a menor. Os valores próximos a 5 na escala de magnitude
representam impactos de extensão intermediaria. A associação de um valor numérico da
magnitude de uma interação deve se basear numa valoração objetiva dos fatos relacionados
com o impacto previsto.
61
A importância de uma interação está relacionada com o significado que é, ou com
uma evolução das conseqüências prováveis do impacto previsto. A escala de importância
também varia de 1 a 10, em que 10 representa uma interação muito importante e 1 uma
interação relativa de pouca importância. A associação deste valor numérico de importância
tem caráter subjetivo e pessoal e deve traduzir o pensamento do grupo ou da equipe
multidisciplinar responsável pelo estudo.
Neste Trabalho, não serão avaliados os itens referentes à Magnitude e Importância,
para as interações entre o PDS e os Princípios de Usabilidade. Na realidade será feita uma
avaliação quantitativa referente à intensidade com que ocorre a realização de uma Ação,
dentro de cada Disciplina do PDS. A avaliação segue o padrão de comportamento mostrado
na Figura 6, Capítulo 2. Será utilizada uma escala de 1 a 3. Onde o valor 1 representa baixa
intensidade do uso de artefatos de usabilidade, o valor 2 média intensidade e o valor 3 alta
intensidade. Esta avaliação foi feita apenas na forma interpretativa das curvas daquele gráfico.
Para que se obtenha maior acuracidade, quanto a intensidade do uso dos princípios de
usabilidade, necessário se faz uma pesquisa mais profunda junto aos especialistas em IHC,
bem como desenvolvedores que utilizam os PDSs em pauta.
Um dos aspectos mais atrativos da matriz de Leopold é que ela pode se expandir
ou contrair-se isto é apresenta a possibilidade de se decidir se o número de ações deve
aumentar ou diminuir. As vantagens principais de utilizar a matriz de Leopold consiste em
que é muito útil como instrumento de screening 4 para desenvolver uma identificação de
impactos e pode proporcionar um desenvolvimento visual dos elementos impactados e das
principais ações que causem impactos.
A agregação do número de linhas e colunas que haviam sido indicados com
interações podem ilustrar a evolução do impacto. Podem-se utilizar outras elaborações
adicionais para discutir os resultados de uma matriz de interação simples.
4
screening – refere-se ao processo de seleção, classificação, filtragem, separação.
62
A matriz de Leopold pode utilizar-se também para identificar impactos benéficos e
adversos mediante o uso de símbolos adequados como o (+) e (-) . Adicionalmente, a matriz
de Leopold pode ser empregada para identificar impactos em varias fases temporais de
projeto, por exemplo, para as fases de construção, exploração (operação) e abandono, e para
descrever os impactos associados a vários âmbitos especiais.
No caso da avaliação do PDS sobre os princípios de Usabilidade, os conceitos de
benéfico e adverso serão adaptados para os seguintes:
- Benéfico ? Atende os princípios de Usabilidade (Célula hachurada)
- Adverso ? Não será contemplado.
4.2 – Princípios de Usabilidade a Serem Incorporados Na MIA
Na Matriz Interativa de Avaliação (MIA), serão utilizados os princípios listados a
seguir, os quais são compostos por ações.
-
-
-
Sensibilidade ao Contexto
?
Modelagem do Usuário
?
Definição da Plataforma
?
Definição do Ambiente Físico
Uso de Modelos
?
Construção de Cenários
?
Construção de Storyboard
?
Construção de Modelo de Tarefa
?
Construção de Modelo de Interface Conceitual
Reuso
?
Uso de Patterns
63
?
Guia de Estilos
-
Manter Independência de Dispositivos
-
Engenharia da Usabilidade
?
Considerar Foco no Usuário
?
Envolver o Usuário no PDS
?
Considerar Requisitos de Usabilidade
?
Uso de Recomendações Ergonômicas
?
Realização de Testes de Usabilidade
?
Construção de Protótipos
4.3 – Fases do RUP a Serem Incorporados Na Matriz Interativa de Avaliação
Na MIA, serão utilizadas as fases do PDS listadas a seguir, as qua is são divididas
em fases de Planejamento (Concepção/Iniciação e Elaboração) e Produção (Construção e
Transição).
-
PLANEJAMENTO
?
Concepção/Iniciação
?
Modelagem de Negócios
?
Requisitos
?
Análise e Design
?
Implementação
?
Testes
?
Implantação
?
Gerência de Configuração e Mudanças
?
Gerência de Projeto
64
?
?
-
Ambiente
Elaboração
?
Modelagem de Negócios
?
Requisitos
?
Análise e Design
?
Implementação
?
Testes
?
Implantação
?
Gerência de Configuração e Mudanças
?
Gerência de Projeto
?
Ambiente
PRODUÇÃO
?
?
Construção
?
Modelage m de Negócios
?
Requisitos
?
Análise e Design
?
Implementação
?
Testes
?
Implantação
?
Gerência de Configuração e Mudanças
?
Gerência de Projeto
?
Ambiente
Transição
?
Modelagem de Negócios
?
Requisitos
?
Análise e Design
65
?
Implementação
?
Testes
?
Implantação
?
Gerência de Configuração e Mudanças
?
Gerência de Projeto
?
Ambiente
Conforme mencionado anteriormente, as atividades genéricas das fases do RUP e
do UPi são análogas. Desta forma não será feita a exposição das fases do UPi.
4.4 – Relacionamento Entre os Aspectos de Usabilidade e Fases do RUP e UPi Na MIA
Para se efetuar o relacionamento entre os princípios de Usabilidade e as fases do
RUP e UPi, é necessário que se faça uma análise detalhada, procurando identificar a
necessidade de cada aspecto de Usabilidade, relacionado com cada Fase/Disciplina do RUP e
UPi.
Em primeiro lugar, deve-se fazer um rol incluindo os princípios de Usabilidade a
serem verificados, concomitantemente se deve m relacionar as fases dos processos. Esta etapa
de execução foi apoiada por 2 especialistas em IHC (D.Sc. Elizabeth Sucup ira Furtado e
Kênia Sousa), bem como o trabalho de alunos (Souza et al, 2004) do Mestrado em
Informática Aplicada da UNIFOR.
Cumprida a primeira etapa, deve-se iniciar a análise propriamente dita. Esta
análise, conforme mencionado, tem o propósito de averiguar detalhadamente em qual fase e
em qual disciplina do RUP e do UPi devem ser considerados os princípios de Usabilidade. No
tocante ao UPi, esta etapa foi assistida por Kênia Sousa. Quanto ao RUP, usou-se como base o
trabalho de Souza et al (2004).
66
Como resultado desta análise, serão geradas 2 (duas) MIAs, sendo uma para
comportar a avaliação do RUP e outra para a avaliação do UPi. O número de variáveis
escolhidas para compor o eixo X de cada MIA é 36 as quais representam as Fases (4) e as
Disciplinas (9) tanto para o RUP quanto UPi. Como as fases são compostas por disciplinas,
então temos então 4 (Fases) * 9 (Disciplinas) = 36 (variáveis). O mesmo raciocínio é seguido
para a composição do eixo Y onde foram identificadas 16 variáveis que representam os
Princípios de Usabilidade. Desta forma cada MIA possuirá 576 células, as quais representam
as interações entre as Fase/Disciplinas de um PDS X Princípios de Usabilidade.
Depois de realizada a análise supracitada, é gerado um resumo (Quadros 2 a 9). A
partir deste resumo, deve-se então proceder o preenchimento da MIA. Vale salientar que não
há necessidade de que toda a MIA seja preenchida, e nem seria possível haja vista não
existirem alguns relacionamentos. O preenchimento da MIA é realizado da seguinte maneira:
10 – Caso seja identificado no quadro resumo o relacionamento entre a disciplina do PDS e os
Artefatos/Ações de Usabilidade, a célula da MIA referente a este evento, deve ser
hachurada;
20 – Verificar o valor da intensidade na coluna de mesmo nome e marcar este valor na a célula
da MIA referente a este evento;
30 – Caso não ocorram interações entre as Disciplinas e Princípios de Usabilidade, a MIA
permanece inalterada.
A Figura 13 mostra de forma resumida os passos que deram origem às MIAs
apresentadas neste trabalho, bem como os especialistas envolvidos em cada etapa de
desenvolvimento.
67
Figura 13 – Passos para criação de uma Matriz Interativa de Avaliação
A Figura 14 ilustra um trecho da Matriz Interativa de Avaliação preenchida. As
MIAs preenchidas são apresentadas em Anexo no Capítulo 7.
68
Figura 14 – Matriz Interativa de Avaliação (Exemplo)
69
Quadro 2 – Interações entre Disciplinas da Fase de Iniciação do RUP e Princípios de
Usabilidade
FASES DO RUP
DISCIPLINAS
Modelagem de
Negócios
INICIAÇÃO
Requisitos
Análise e Design
Implementação
Testes
Implantação
Gerência de
Configuração e
Mudanças
Gerência de Projeto
Ambiente
AÇÕES DE
USABILIDADE
Modelagem do Usuário
Considerar Foco no Usuário
Envolver Usuário no PDS
Modelagem do Usuário
Considerar Requisitos de
Usabilidade
Construção de Protótipos
Considerar Foco no Usuário
Envolver Usuário no PDS
Construção de Protótipos
Considerar Foco no Usuário
Envolver Usuário no PDS
Definição da Plataforma
Definição do Ambiente Físico
Considerar Foco no Usuário
Envolver Usuário no PDS
Realização de Testes de
Usabilidade
Envolver Usuário no PDS
Intensidade
3
3
3
3
3
1
3
3
1
1
1
1
1
1
1
1
1
70
Quadro 3 – Interações entre Disciplinas da Fase de Elaboração do RUP e Princípios de
Usabilidade
FASES DO RUP
DISCIPLINAS
Modelagem de
Negócios
ELABORAÇÃO
Requisitos
Análise e Design
Implementação
Testes
Implantação
Gerência de
Configuração e
Mudanças
Gerência de Projeto
Ambiente
AÇÕES DE
USABILIDADE
Intensidade
Modelagem do Usuário
Considerar Foco no Usuário
Envolver Usuário no PDS
Modelagem do Usuário
Considerar Requisitos de
Usabilidade
Construção de Protótipos
Considerar Foco no Usuário
Envolver Usuário no PDS
Construção de Protótipos
Considerar Foco no Usuário
Envolver Usuário no PDS
Definição da Plataforma
Definição do Ambiente Físico
Uso de Padrões
Considerar Foco no Usuário
Envolver Usuário no PDS
Realização de Testes de
Usabilidade
Considerar Foco no Usuário
Envolver Usuário no PDS
3
3
3
3
Envolver Usuário no PDS
2
3
2
3
3
2
3
1
2
2
2
2
1
2
1
1
71
Quadro 4 – Interações entre as Disciplinas da Fase de Construção do RUP e Princípios de
Usabilidade
FASES DO RUP
DISCIPLINAS
Modelagem de
Negócios
CONSTRUÇÃO
Requisitos
Análise e Design
Implementação
Testes
Implantação
Gerência de
Configuração e
Mudanças
Gerência de Projeto
Ambiente
AÇÕES DE
USABILIDADE
Intensidade
Modelagem do Usuário
Considerar Foco no Usuário
Envolver Usuário no PDS
Modelagem do Usuário
Considerar Requisitos de
Usabilidade
Construção de Protótipos
Considerar Foco no Usuário
Envolver Usuário no PDS
Construção de Protótipos
Considerar Foco no Usuário
Envolver Usuário no PDS
Definição da Plataforma
Definição do Ambiente Físico
Uso de Padrões
Considerar Foco no Usuário
Envolver Usuário no PDS
Realização de Testes de
Usabilidade
Considerar Foco no Usuário
Envolver Usuário no PDS
1
1
1
2
Envolver Usuário no PDS
3
2
3
2
1
3
1
1
3
3
3
3
1
3
1
1
72
Quadro 5 – Interações entre as Disciplinas da Fase de Transição do RUP e Princípios de
Usabilidade
FASES DO RUP
DISCIPLINAS
Modelagem de
Negócios
TRANSIÇÃO
Requisitos
Análise e Design
Implementação
Testes
Implantação
Gerência de
Configuração e
Mudanças
Gerência de Projeto
Ambiente
AÇÕES DE
USABILIDADE
Modelagem do Usuário
Considerar Foco no Usuário
Envolver Usuário no PDS
Considerar Foco no Usuário
Envolver Usuário no PDS
Construção de Protótipos
Considerar Foco no Usuário
Envolver Usuário no PDS
Definição da Plataforma
Definição do Ambiente Físico
Uso de Padrões
Considerar Foco no Usuário
Envolver Usuário no PDS
Realização de Testes de
Usabilidade
Considerar Foco no Usuário
Envolver Usuário no PDS
Envolver Usuário no PDS
Intensidade
1
1
1
1
1
1
1
1
1
1
1
1
1
3
3
3
3
73
Quadro 6 – Interações entre as Disciplinas da Fase de Iniciação do UPi e Princípios de
Usabilidade
FASES DO UPI
DISCIPLINAS
Modelagem de
Negócios
INICIAÇÃO
Requisitos
Análise e Design
Implementação
Testes
Implantação
Gerência de
Configuração e
Mudanças
Gerência de Projeto
Ambiente
AÇÕES DE
USABILIDADE
Modelagem do Usuário
Definição do Ambiente Físico
Definição da Plataforma
Considerar Foco no Usuário
Envolver Usuário no PDS
Modelagem do Usuário
Considerar Requisitos de
Usabilidade
Construção de Modelo de Tarefas
Considerar Foco no Usuário
Envolver Usuário no PDS
Construção de Storyboard
Construção de Modelo de Tarefas
Construção de Modelo de
Interface Conceitual
Uso de Padrões
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Recomendações
Ergonômicas
Uso de Padrões
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Recomendações
Ergonômicas
Realização de Testes de
Usabilidade
Envolver Usuário no PDS
Considerar Foco no Usuário
Intensidade
3
3
3
3
3
3
3
2
3
3
1
1
1
1
1
2
2
2
1
1
1
1
1
1
1
1
Envolver Usuário no PDS
1
Uso de Recomendações
Ergonômicas
Uso de Recomendações
Ergonômicas
3
3
74
Quadro 7 – Interações entre as Disciplinas da Fase de Elaboração do UP i e Princípios de
Usabilidade
FASES DO UPI
DISCIPLINAS
Modelagem de
Negócios
ELABORAÇÃO
Requisitos
Análise e Design
Implementação
Testes
Implantação
Gerência de
Configuração e
Mudanças
Gerência de Projeto
Ambiente
AÇÕES DE
USABILIDADE
Modelagem do Usuário
Definição do Ambiente Físico
Definição da Plataforma
Considerar Foco no Usuário
Envolver Usuário no PDS
Modelagem do Usuário
Considerar Requisitos de
Usabilidade
Construção de Modelo de Tarefas
Considerar Foco no Usuário
Envolver Usuário no PDS
Construção de Storyboard
Construção de Modelo de Tarefas
Construção de Modelo de
Interface Conceitual
Uso de Padrões
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Padrões
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Recomendações
Ergonômicas
Realização de Testes de
Usabilidade
Envolver Usuário no PDS
Considerar Foco no Usuário
Envolver Usuário no PDS
Intensidade
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
2
2
3
2
2
1
1
Envolver Usuário no PDS
2
Uso de Recomendações
Ergonômicas
Uso de Recomendações
Ergonômicas
3
3
75
Quadro 8 – Interações entre as Disciplinas da Fase de Construção do UPi e Princípios de
Usabilidade
FASES DO UPI
DISCIPLINAS
Modelagem de
Negócios
CONSTRUÇÃO
Requisitos
Análise e Design
AÇÕES DE
USABILIDADE
Modelagem do Usuário
Definição do Ambiente Físico
Definição da Plataforma
Considerar Foco no Usuário
Envolver Usuário no PDS
Modelagem do Usuário
Considerar Requisitos de
Usabilidade
Construção de Modelo de Tarefas
Considerar Foco no Usuário
Envolver Usuário no PDS
Construção de Storyboard
Construção de Modelo de Tarefas
Construção de Modelo de
Interface Conceitual
Uso de Padrões
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Recomendações
Ergonômicas
Uso de Padrões
Uso de Guia de Estilos
Implementação
Testes
Implantação
Gerência de
Configuração e
Mudanças
Gerência de Projeto
Ambiente
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Recomendações
Ergonômicas
Realização de Testes de
Usabilidade
Envolver Usuário no PDS
Considerar Foco no Usuário
Envolver Usuário no PDS
Intensidade
1
1
1
1
1
2
2
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
2
2
Envolver Usuário no PDS
3
Uso de Recomendações
Ergonômicas
Uso de Recomendações
Ergonômicas
3
3
76
Quadro 9 – Interações entre as Disciplinas da Fase de Transição do UPi e Princípios de
Usabilidade
FASES DO UPI
DISCIPLINAS
Modelagem de
Negócios
TRANSIÇÃO
Requisitos
Análise e Design
Implementação
Testes
Implantação
Gerência de
Configuração e
Mudanças
Gerência de Projeto
Ambiente
AÇÕES DE
USABILIDADE
Modelagem do Usuário
Definição do Ambiente Físico
Definição da Plataforma
Considerar Foco no Usuário
Envolver Usuário no PDS
Modelagem do Usuário
Considerar Requisitos de
Usabilidade
Construção de Modelo de Tarefas
Considerar Foco no Usuário
Envolver Usuário no PDS
Construção de Storyboard
Construção de Modelo de Tarefas
Construção de Modelo de
Interface Conceitual
Uso de Padrões
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Recomendações
Ergonômicas
Uso de Padrões
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Recomendações
Ergonômicas
Realização de Testes de
Usabilidade
Envolver Usuário no PDS
Considerar Foco no Usuário
Envolver Usuário no PDS
Intensidade
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
3
3
3
3
Envolver Usuário no PDS
3
Uso de Recomendações
Ergonômicas
Uso de Recomendações
Ergonômicas
3
3
77
4.5 – Análise dos Processos RUP e UPi, segundo a Intensidade e Uso de Princípios de
Usabilidade
A análise dos processos de desenvolvimento de Software será feita segundo os
critérios identificados na MIA. Levaram-se em consideração as Fases de desenvolvimento,
Iniciação, Elaboração, Construção e Transição. Em cada Fase será feito um comparativo entre
o RUP e UPi, onde serão considerados os Artefatos e as Ações utilizadas, bem como a
intensidade de uso destes. Vale lembrar que a distribuição de intensidade é baseada na Figura
6 - Arquitetura do RUP.
Para cada Fase do RUP e do UPi, serão apresentados um Gráfico de
comportamento e um Quadro comparativo. Nos gráficos, são representas as somatória s das
intensidades do uso de Artefatos e Ações versus as Disciplinas de cada Fase. Vale ressaltar
que tais gráficos possuem apenas caráter ilustrativo e que na confecção destes procurou-se
representar a preocupação de cada PDS com os Princípios de Usabilidade.
78
Quadro 10 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de Usabilidade na
Fase de Iniciação
FASE
DISCIPLINAS
Modelagem de Negócios
Requisitos
AÇÕES DE USABILIDADE
Modelagem do Usuário
3
3
Definição do Ambiente Físico
Definição da Plataforma
-
3
3
Considerar Foco no Usuário
3
3
Envolver o Usuário no PDS
TOTAL
3
9
3
15
Modelagem do Usuário
3
3
Considerar Requisitos de Usabilidade
3
3
Construção de Modelo de Tarefas
Considerar Foco no Usuário
3
2
3
Envolver o Usuário no PDS
3
3
Construção de Protótipos
1
13
14
Construção de Storyboard
-
1
Construção de Modelo de Tarefas
-
1
Construção de Modelo de Interface Conceitual
Uso de Padrões
-
1
1
Uso de Guia de Estilos
-
1
Considerar Foco no Usuário
Envolver o Usuário no PDS
1
1
2
2
Uso Recomendações Ergonômicas
-
2
Construção de Protótipos
TOTAL
1
3
11
Definição da Plataforma
1
-
Definição do Ambiente Físico
1
-
Uso de Padrões
-
1
Uso de Guia de Estilos
Considerar Foco no Usuário
1
1
1
Envolver o Usuário no PDS
1
1
Uso Recomendações Ergonômicas
TOTAL
4
1
5
Realização de Testes de Usabilidade
1
1
Envolver o Usuário no PDS
TOTAL
1
1
2
Considerar Foco no Usuário
-
1
TOTAL
0
1
1
1
1
1
0
3
3
0
3
3
INICIAÇÃO
TOTAL
Análise e Design
Implementação
Testes
Implantação
Gerência de Configuração Envolver o Usuário no PDS
e Mudanças
Gerência de Projeto
Ambiente
Intensidade
RUP UPi
TOTAL
Uso Recomendações Ergonômicas
TOTAL
Uso Recomendações Ergonômicas
TOTAL
79
UPi
Ambiente
Gerência de
Projeto
Ger. Config.
Mudanças
Implantação
Testes
Implementação
RUP
Requisitos
Modelag.
Negócios
Intensidade (Uso de Princípios de
Usabilidade)
16
14
12
10
8
6
4
2
0
Análise e
Design
Fase de Iniciação
Disciplinas
Gráfico 1 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de Usabilidade na
Fase de Iniciação
Ao analisarmos o Gráfico 1 e o Quando 10, percebemos que na Fase de Iniciação
o UPi, dá maior ênfase aos Princípios de Usabilidade.
No que tange a Disciplina de Modelagem de Negócios, o UPi possui a vantagem
de considerar inclusive o Ambiente Físico e a Plataforma de desenvolvimento, além da
Modelagem de Negócios, o Foco no Usuário e a Participação do Usuário.
Na Disciplina de Requisitos, percebe-se que os PDSs estudados, apresentam
abordagem um pouco divergentes. O RUP, utiliza a técnica de Prototipagem, enquanto o UPi
utiliza o Modelo de Tarefas.
No tocante a Disciplina de Análise e Design, percebe-se a grande diferença entre o
RUP e UPi. O UPi apresenta preocupação muito maior com o usuário. Nesta Disciplina o
principal diferencial está na intensidade com que são utilizados os princípios de Usabilidade,
bem como a maior variedade de artefatos e ações que o UPi utiliza.
80
Na Disciplina de Implementação, o RUP e o UPi são praticamente equivalentes.
Todavia a abordagem é um pouco diferenciada. Enquanto o RUP dá ênfase a Plataforma e o
Ambiente Físico, o UPi se preocupa com o Uso de Guias de Estilos, Uso de Padrões e
Recomend ações Ergonômicas. Em ambos os processos a intensidade do o uso dos artefatos e
ações referentes à Usabilidade é baixa.
Em Testes, percebe-se que além do uso de Testes de Usabilidade, o UPi
incrementa esta Disciplina com a Participação do Usuário.
Para as disciplinas Implantação, Gerência e Configuração de Mudanças, Gerência
de Projetos e Ambiente, apenas o UPi, apresenta preocupação com os Princípios de
Usabilidade. A maior intensidade desta preocupação, reside nas Disciplinas de Gerência de
Projeto e Ambiente.
Conforme demonstrado no Quadro 10 e no Gráfico 01, percebe-se que tanto o
RUP quanto o UPi, apresentam maior preocupação para os princípios de Usabilidade, nas
disciplinas de Modelagem de Negócios e Requisitos. Sendo que o UPi faz uso de uma
quantidade maior de Artefatos e Ações.
81
Quadro 11 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de Usabilidade na
Fase de Elaboração
FASE
DISCIPLINAS
AÇÕES DE USABILIDADE
Modelagem do Usuário
Definição do Ambiente Físico
Modelagem de Negócios
Definição da Plataforma
Considerar Foco no Usuário
Envolver o Usuário no PDS
TOTAL
Modelagem do Usuário
Considerar Requisitos de Usabilidade
Construção de Modelo de Tarefas
Requisitos
Considerar Foco no Usuário
Envolver o Usuário no PDS
Construção de Protótipos
TOTAL
Construção de Storyboard
Construção de Modelo de Tarefas
ELABORAÇÃO
Construção de Modelo de Interface Conceitual
Uso de Padrões
Análise e Design
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver o Usuário no PDS
Construção de Protótipos
TOTAL
Definição da Plataforma
Definição do Ambiente Físico
Uso de Padrões
Implementação
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver o Usuário no PDS
Uso de Recomendações Ergonômicas
TOTAL
Realização de Testes de Usabilidade
Testes
Envolver o Usuário no PDS
TOTAL
Considerar Foco no Usuário
Implantação
Envolver o Usuário no PDS
TOTAL
Gerência de Configuração Envolver o Usuário no PDS
TOTAL
e Mudanças
Gerência de Projeto
Ambiente
Uso de Recomendações Ergonômicas
TOTAL
Uso de Recomendações Ergonômicas
TOTAL
Intensidade
RUP UPi
3
3
3
3
3
3
3
3
9
15
3
3
3
3
3
3
3
3
3
2
14
15
3
3
3
3
3
3
3
1
3
2
6
21
2
2
2
3
3
2
2
1
2
3
9
13
2
2
2
2
4
1
1
1
1
2
2
2
2
2
2
3
0
3
3
0
3
82
Fase de Elaboração
20
15
10
5
UPi
Ambiente
Gerência de
Projeto
Ger. Config.
Mudanças
Implantação
Testes
Implementação
RUP
Análise e
Design
Requisitos
0
Modelag.
Negócios
Intensidade (Uso de Princípios de
Usabilidade)
25
Disciplinas
Gráfico 2 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de Usabilidade na
Fase de Elaboração
O comportamento tanto do RUP quanto do UPi, nesta Fase é bastante parecido
com a Fase de Iniciação. As principais diferenças estão nas intensidades dadas ao uso de
Artefatos e Ações realizadas nas Disciplinas de Análise e Design e Implementação.
Ao compararmos o comportamento dos PDSs mostrados no Gráfico 2 e o Quadro
11, percebemos que o UPi, nas Disciplinas de Análise e Design e Implementação apresenta
enfoque bastante superior ao RUP.
Nesta Fase nota-se também a crescente preocupação quanto aos Princípios de
Usabilidade para as disciplinas de Testes e Implantação.
Para as disciplinas Implantação, Gerência e Configuração de Mudanças, Gerência
de Projetos e Ambiente, apenas o UPi, apresent a preocupação com os Princípios de
Usabilidade. A maior intensidade desta preocupação, reside nas Disciplinas de Gerência de
Projeto e Ambiente.
83
Conforme demonstrado no Quadro 11 e no Gráfico 02, percebe-se que tanto o
RUP quanto o UPi, apresentam maior preocupação para os princípios de Usabilidade, nas
disciplinas de Modelagem de Negócios e Requisitos. Sendo que o UPi faz uso de uma
quantidade maior de Artefatos e Ações.
84
Quadro 12 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de Usabilidade na
Fase de Construção
FASE
DISCIPLINAS
AÇÕES DE USABILIDADE
Modelagem do Usuário
Definição do Ambiente Físico
Modelagem de
Negócios
Definição da Plataforma
Considerar Foco no Usuário
Envolver Usuário no PDS
TOTAL
Modelagem do Usuário
Considerar Requisitos de Usabilidade
Construção de Modelo de Tarefas
Requisitos
Considerar Foco no Usuário
Envolver Usuário no PDS
Construção de Protótipos
TOTAL
Construção de Storyboard
Construção de Modelo de Tarefas
CONSTRUÇÃO
Construção de Modelo de Interface Conceitual
Uso de Padrões
Análise e Design
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Recomendações Ergonômicas
Construção de Protótipos
TOTAL
Definição da Plataforma
Definição do Ambiente Físico
Uso de Padrões
Implementação
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Recomendações Ergonômicas
TOTAL
Realização de Testes de Usabilidade
Testes
Envolver Usuário no PDS
TOTAL
Considerar Foco no Usuário
Implantação
Envolver Usuário no PDS
TOTAL
Gerência de
Configuração e
Envolver Usuário no PDS
Gerência de Projeto
Ambiente
TOTAL
Uso de Recomendações Ergonômicas
TOTAL
Uso de Recomendações Ergonômicas
TOTAL
Intensidade
RUP UPi
1
1
1
1
1
1
1
1
3
5
2
2
2
2
3
2
3
1
3
3
10
13
3
3
3
3
3
1
3
1
3
3
3
2
24
3
3
3
3
3
3
3
1
3
3
7
21
3
3
3
3
6
1
2
1
2
2
4
3
3
3
3
3
0
3
3
0
3
85
Fase de Construção
Intensidade (Uso de Princípios de
Usabilidade)
30
25
20
15
10
5
UPi
Ambiente
Gerência de
Projeto
Ger. Config.
Mudanças
Implantação
Testes
Análise e
Design
Implementação
RUP
Requisitos
Modelag.
Negócios
0
Disciplinas
Gráfico 3 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de Usabilidade na
Fase de Construção
Conforme Gráfico 3 e Quando 12 percebe-se que na Fase de Construção, ocorre
maior ênfase dos Princípios de Usabilidade nas Disciplinas de Análise e Design,
Implementação e Testes.
Na Disciplina de Requisitos, percebe-se que o UPi apresenta maior preocupação
com o Foco no Usuário, assim como a participação deste, notadamente quando comparado
com o RUP.
No tocante a Disciplina de Análise e Design, o RUP destaca-se apenas no que diz
respeito ao processo de Prototipagem, o qual o UPi não utiliza. Para os demais Artefatos e
Ações a abordagem do UPi é bem mais completa e apresenta maior intensidade.
Na Disciplina de Implementação, as maiores vantagens do UPi são traduzidas
em termos da consideração da Plataforma, do Ambiente Físico, Uso de Guias de Estilos, a
intensidade da Participação do Usuário e as Recomendações Ergonômicas.
86
Quadro 13 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de Usabilidade na
Fase de Transição
FASE
DISCIPLINAS
AÇÕES DE USABILIDADE
Modelagem do Usuário
Modelagem de Negócios
Definição do Ambiente Físico
Definição da Plataforma
Considerar Foco no Usuário
Envolver Usuário no PDS
TOTAL
Modelagem do Usuário
Requisitos
Considerar Requisitos de Usabilidade
Construção de Modelo de Tarefas
Considerar Foco no Usuário
Envolver Usuário no PDS
TOTAL
Construção de Storyboard
Construção de Modelo de Tarefas
TRANSIÇÃO
Construção de Modelo de Interface Conceitual
Uso de Padrões
Análise e Design
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Recomendações Ergonômicas
Construção de Protótipos
TOTAL
Definição da Plataforma
Definição do Ambiente Físico
Uso de Padrões
Implementação
Uso de Guia de Estilos
Considerar Foco no Usuário
Envolver Usuário no PDS
Uso de Recomendações Ergonômicas
TOTAL
Testes
Realização de Testes de Usabilidade
Envolver Usuário no PDS
TOTAL
Considerar Foco no Usuário
Implantação
Envolver Usuário no PDS
TOTAL
Gerência de Configuração e Envolver Usuário no PDS
TOTAL
Mudanças
Gerência de Projeto
Uso de Recomendações Ergonômicas
TOTAL
Ambiente
Uso de Recomendações Ergonômicas
TOTAL
Intensidade
RUP UPi
1
1
1
1
1
1
1
1
3
5
1
1
1
1
1
1
1
2
5
1
1
1
1
1
1
1
1
1
1
1
3
8
1
1
1
1
1
1
1
1
1
1
5
5
3
3
3
3
6
3
3
3
3
6
6
3
3
3
3
3
0
3
3
0
3
87
UPi
Ambiente
Gerência de
Projeto
Ger. Config.
Mudanças
Implantação
Testes
Análise e
Design
Implementação
RUP
Requisitos
9
8
7
6
5
4
3
2
1
0
Modelag.
Negócios
Intensidade (Uso de Princípios de
Usabilidade)
Fase de Transição
Disciplinas
Gráfico 4 - Comparativo entre o RUP e UPi, quanto ao uso dos Princípios de Usabilidade na
Fase de Transição
De acordo com o Gráfico 4 e o Quando 13, nota-se na Fase de Transição, o maior
foco nos Princípios de Usabilidade é destinado às Disciplinas de Testes e Implantação, tanto
para RUP quanto para UPi.
Na Disciplina de Testes o UPi, um diferencial por incluir a o seu foco na
Participação do Usuário, além dos Testes de Usabilidade, comum a ambos os processos.
No que diz respeito a Disciplina de Implantação, o RUP e o UPi possuem a
mesma abordagem. Ambos preocupam-se com o Foco no Usuário e a Participação deste.
4.6 – Síntese da Análise
Conforme demonstrado ao longo do item 4.5, percebe-se que o UPi possui maior
enfoque nos Princípios de Usabilidades, utilizados neste trabalho, do que o RUP. Merecendo
destaque a Utilização do Modelo de Tarefas, utilizado com maior intensidade nas Fases de
Elaboração e Construção, nas Disciplinas de Requisitos e Análise e Design; a utilização do
88
Modelo de Interface Conceitual, realizado com maior intensidade nas Fases de Elaboração e
Construção, na Disciplina de Análise e Design; Uso de Guias de Estilos com maior
intensidade nas Fases de Elaboração e Construção, Disciplinas de Análise e Design e
Implementação; as Recomendações Ergonômicas, o Foco no Usuário e a Participação deste,
levados em consideração em todas as Fases de desenvolvimento.
5 – CONCLUSÕES
Espera-se este trabalho tenha alcançado o objetivo de tornar mais ágil e fácil o
processo de análise de um PDS. Vale ressaltar que este trabalho não teve por finalidade,
promover ou mesmo desprezar qualquer um dos Processos de Desenvolvimento de Software
envolvidos.
O instrumento (MIA) apresentado neste trabalho mostrou que possui a capacidade
de representação de um PDS versus os Princípios de Usabilidade, de maneira simples e de
fácil compreensão. Conforme descrito anteriormente, as MIAs são extremamente dinâmicas,
ou seja, em uma MIA pode-se representar inúmeros processos. Podem-se desenvolver MIAs
para analisar requisitos de qualidade de um PDS ou mesmo de um software, ou ainda analisar
apenas aspectos ligados aos Requisitos Funcionais ou Não Funcionais de um sistema, etc.
Quanto aos processos analisados, nota-se que o UPi apresentou maior preocupação
no que diz respeito à utilização dos Princípios de Usabilidade, listados neste trabalho. Este
fato era de se esperar tendo em vista que o UPi é um “descendente” do RUP e foi
desenvolvido para suprir as deficiências deste quanto aos Princípios de Usabilidade. A
novidade apresentada aqui diz respeito a representação dos Princípios, sob a forma de uma
matriz, na qual se identifica de forma clara, onde o UPi apresenta diferenças em relação ao
RUP.
90
Durante a evolução deste estudo, pode-se perceber a importância da adoção dos
Princípios de Usabilidade em processos de desenvolvimento de software, o que nos leva a crer
que se for garantido que um PDS cumpra os princípios mínimos de Usabilidade, é bem
provável que os produtos gerados por este, assegurem estes princípios.
Vale ressaltar que o presente trabalho faz parte, apenas, do desenvolvimento inicial
de uma metodologia que ainda pode ser bastante explorada em trabalhos futuros.
6 - BIBLIOGRAFIA
Boehm, Barry W. A spiral model of software development and enhancement. IEEE Computer.
1988.
Choose Technologies. Utilizando o RUP com Análise Essencial. Disponível em:
<http://www.choose.com.br/infochoose/artigos/40art03.htm>. Acesso em: 10/04/2004.
Companhia de Informática do Paraná – CELEPAR. Revista Eletrônica Bate Byte. Edição 104
– Dezembro 2000. Aderência do RUP à Norma ISSO/IEC 12207. Disponível em:
<http://www.pr.gov.br/batebyte/edicoes/2000/bb104/software.htm>, Acesso em: 02/05/2004.
Crosby, Philip. Quality is Free. McGraw-Hill, 1979.
Cybiz
S/A.
Oferta.
RUP
Disponível
<http://www.cybiz.com.br/gcon/Navega.jsp?pIdMenuConteudo=602>,
Acesso
em:
em:
12/05/2004.
Denning, Susan et alli. "The Value of Thinking-Aloud Protocols in Industry: A Case Study at
Microsoft Corporation", in Proceedings of the Human Factors Society 34th Annual Meeting,
Test and Evaluation: Verbal Protocols as a Research Tool in Human Factors, vol. 2, pp. 12851289, 1990.
92
Drumond, Fernanda Paiva. Especificação de Requisitos do Sistema CEP 1.0 - Cálculo de
Esforço em Postes. Relatório Técnico DSE. DCC/UFMG: Belo Horizonte, 1998.
Dumas, Joseph S. "Stimulating Change Through Usability Testing", in ACM SIGCHI
Bulletin, vol. 21, no. 1, pp. 37-44, 1989.
Egan, Dennis E. et alli. "Dealing with Diversity: Approaches to Individual Differences in
Human-Computer Interaction", in Proceedings of ACM CHI'88 Conference on Human
Factors in Computing Systems, pp. 79-81, 1988.
Furtado, Elizabeth – Notas de Aulas: Curso de Engenharia de Software. UNIFOR, 2003.
GARVIN, D..What Does Product Quality Mean?. Sloan Management Review, Nº4- 1984.
Gillies, Alan C., Software Quality: Theory and Management. ITCP, 1992.
Gould, J. D., Boies, S. J. & Lewis, C. "Making Usable, Useful, Productivity-Enhancing
Computer Applications. Communications of the ACM, vol. 34, no. 1, pp. 74-85.
Graham, McLeod; Smith, Derek."Managing Information Technology Projects. ITCP, 1996.
Hix, Deborah & Hartston, H. Rex. Developing User Interfaces; Ensuring Usability Through
Product & Process. John Wiley& Sons, 1993.
Holleran Patrick A. "A Methodological Note on Pitfalls in Usability Testing", Behaviour and
Information Technology, vol. 10, no. 5, pp. 345-357, 1991.
93
IHC Brasil. O que é IHC?. Disponível em: <http://www.sbc.org.br/ihc/index.php>. Acesso
em: 15/04/2004.
Instituto
Do
Software
Do
Ceará.
Qualidade
de
Software.
Disponível
em:
<http://www.insoft.softex.br. Acesso em: 10/04/2004.
ISO/FDIS 9241-11 Ergonomic Requirements for Office Work with Visual Display Terminals
(VDTs) - Part 11: Guidance on Usability. International Standards Organization.
Jeffries, Robin & Desurvire, Heather. "Usability Testing vs. Heuristic Evaluation: Was There
a Contest?", in ACM SIGCHI Bulletin, vol. 24, no. 4, pp. 39-41, 1992.
Kato, Takashi, "What `Question-Asking Protocols' Can Say about the User Interface", in
International Journal of Man-Machine Studies, vol. 25, no. 6, pp. 659-673, 1986.
Kennedy, Sue. "Using Video in the BNR Usability Lab", in ACM SIGCHI Bulletin, vol. 21,
no. 2, pp. 92-95, 1989.
Koivunen, M.; Nieminen, M. & Riihiaho, S. "Launching the Usability Approach: Experience
at Helsinki University of Technology", in ACM SIGCHI Bulletin, vol. 27, no. 2, pp. 54-60,
1995.
Kruchten, Philippe, Rational Unified Process made easy: A practioner’s guide to the RUP,
Addison-Wesley, 2003.
Leopold, L.B.; Clarke, F.S.; Hanshaw, B. et al. A procedure for evaluating environmental
impact. Washington: U. S. Geological Survey, 1971. 13p. (circular 645).
Lund, Arnold M. "Ameritechs Usability Laboratory: from Prototype to Fina l Design", in
Behaviour and Information Technology, vol. 13, nos. 1, 2, pp. 67-80, 1994.
94
Lund, Arnold M. & Tschirgi, J.E. "Designing for People: Integrating Human Factors into the
Product Realization Process", in IEEE Journal on Selected Areas in Communications, vol. 9,
no. 4, pp. 496-500, 1991.
Marconi, Marina de Andrade, Lakatos, Eva Maria. Metodologia Científica. 3. ed. São Paulo:
Atlas, 2000.
Microsoft Corporation. The Windows Interface Guidelines for Software Design. Disponível
em: <http://www.microsoft.com/win32dev/uiguide/>, Acesso em: 01/04/2004.
Myers, Brad A. & Rosson, Mary B. "Survey on User Interface Programming", in Proceedings
of ACM CHIÆ92 Conference on Human Factors in Computing Systems, Tools and
Techniques, pp. 195-202, 1992.
Newsletter. Qualidade de Software (VII). O Modelo de Pressman.
Disponível em:
<http://www.gismedia.pt/newsletter/newsletter.cfm?edinum=20&p=3>.
Acesso
em:
15/04/2004
Nielsen, Jakob. "Guerrilla HCI: Using Discount Usability Engineering to Penetrate the
Intimidation Barrier", in Cost-Justifying Usability. Academic Press, 1994.
Nielsen, Jakob. Usability Engineering. Academic Press, Chestnut Hill, l993.
Oliveira, Rafael Braga de, O Desenvolvimento de Sistemas Interativos Centrado no Usuário e
de Fácil Manutenção Baseado no Processo RUP Usando a UML – Monografia – Fortaleza :
Universidade de Fortaleza, 2002. 62 p. p. 39 - 40
Pádua, Wilson P. F. & Salles, Juliana. PROSE û Processo Padrão para Sistemas de
Engenharia; Projeto CASE. Relatório Técnico DSE. DCC/UFMG, Belo Horizonte, 1997.
95
Pádua, Wilson P. F. Engenharia de Software: Fundamentos, Métodos e Padrões. 2. ed. Rio de
Janeiro: LTC, 2003.
Pádua, Wilson P. F. Manual de Processos Versão 1.0; CASE - Programa de Capacitação em
Sistemas de Engenharia. Relatório Técnico DSE. DCC/UFMG, Belo Horizonte, 1996.
Pressman, Roger S. Engenharia de software. Makron Books, 2001.
Ribeiro JR., Aloísio A. Análise Heurística de Usabilidade; Um Tutorial. Disponível em:
<http://www.dcc.ufmg.br/~aarj/usabilidade/heur.html>, DCC/UFMG, Belo Horizonte, 1998.
Acesso em: 01/04/2004.
Rocha, Ana Regina Cavalcante da, Maldonado, José Carlos, Weber, Kival Chaves. Qualidade
de Software: Teoria e Prática. 1. ed. São Paulo: Prentice Hall, 2001.
Royce, W. W. Managing the developmentof large software systems: concepts and techniques.
In: Proceedings Of Wescon. Ago. 1970.
Silva Filho, Antonio Mendes da - Professor do Departamento de Informática da UEM. Doutor
em Ciência da Computação – Revista Espaço Acadêmico – Ano II – No 25 – Junho 2003.
Sousa, Kênia Soares. UPi – An Approach to Integrate Human-Computer Interaction Aspects
in a Software Development Process. Fortaleza: 2002.
Souza, Gabriela Telles,
Albuquerque, Danielle F., Nunes Francisco José. Uma Análise
Quantitativa e Qualitativa do RUP e MyRUP Quanto aos Aspectos de Usabilidade. Fortaleza:
2004.
Thevenin, David. Adaptation in Human Computer Interaction: the case of Plasticity 21
December 2001. Disponível em:
<http://publications.imag.fr/publications/theses/2001/Thevenin.David/notice-anglais.html>
Acesso em: 02/05/2004.
96
Wright, Peter C. & Monk, Andrew F. "The Use of Think-Aloud Evaluation Methods in
Design",
in
ACM
SIGCHI
Bulletin,
vol.
23,
no.
1,
pp.
55-57,
1991.
7. ANEXOS
A seguir são apresentas as MIAs que representam as Fases do RUP e UPi versus
os Princípios de Usabilidade.