Professional Documents
Culture Documents
Unidade II
3 ENGENHARIA DE SOFTWARE E INTERAO HUMANO-COMPUTADOR
A Engenharia de Software tem o foco voltado para o produto e seu processo de desenvolvimento. A
Interao Humano-Computador tem o foco voltado interao do ser humano e da mquina. As duas
reas, no entanto, estabelecem mtodos e processos de desenvolvimento de sistemas interativos.
Existe uma diferena fundamental entre as abordagens adotadas pelos engenheiros de software e
pelos especialistas em Interao Humano-Computador. Segundo Brown (1996), enquanto os engenheiros
de software tm o foco voltado para o produto e seu processo (centrado em sistema), os especialistas
em Interao Humano-Computador tm o foco mais direcionado aos aspectos de interao do ser
humano e da mquina (centrado no usurio). Em sua pesquisa, Brown (1996) relata que as metodologias
de Engenharia de Software so teis para especificar e construir os aspectos funcionais de um sistema
de software. No entanto, especialistas em Interao Humano-Computador mostram uma compreenso
melhor do usurio, priorizando um entendimento aprofundado das caractersticas deste usurio e uma
conscincia das tarefas que um usurio tem de executar. Especialistas de Interao Humano-Computador
testam ideias de design em usurios reais e usam tcnicas de avaliao formais, substituindo o design
da interface guiado pela intuio.
Lembrete
Lembrete
interativos para uso humano e com o estudo dos principais fenmenos que
os cercam (ACM SIGCHI, 1992).
Paula, Barbosa e Lucena (2005) alertam para a importncia da comunicao entre as reas de IHC
e Engenharia de Software. Os projetistas de IHC precisam levar suas preocupaes e decises de forma
clara aos engenheiros de software e vice-versa, para que, juntos, cheguem soluo final. Ainda segundo
os autores, ambas as reas tratam da qualidade do produto final, no entanto sob perspectivas e focos
diferentes. A IHC focaliza interao e design de interface do usurio, levando em conta as necessidades,
os valores e as expectativas dos usurios, visando qualidade de uso da soluo projetada. A Engenharia
de Software tem foco no projeto e na especificao da funcionalidade interna do sistema, bem como em
sua arquitetura, visando qualidade estrutural do produto de software final.
Existem vrios modelos de ciclo de vida para o desenvolvimento de sistemas interativos apresentados
na literatura de IHC. Segundo Rocha e Baranauskas (2003), os modelos de ciclo de vida de design em IHC
envolvem desde uma discusso crtica dos ciclos de vida clssicos para o desenvolvimento de software,
originais da Engenharia de Software, at modelos mais especficos do ciclo de vida de design, como, por
exemplo, o modelo estrela, que ser apresentado posteriormente.
No entanto, os modelos de ciclo de vida apresentados pela IHC no discutem as etapas para o desenvolvimento
e a implementao do sistema e de suas funcionalidades, diferentemente dos modelos de ciclo de vida da
Engenharia de Software. Estes modelos enfocam o desenvolvimento da interao com o usurio.
De acordo com Sharp, Rogers e Preece (2005), o termo design no deve ser confundido com o design
comumente traduzido como projeto e utilizado pela comunidade de Engenharia de Software para uma
fase do modelo de ciclo de vida de software. Do mesmo modo, Leite (1998), destaca que a atividade de
design da interface do usurio no deve ser confundida com a atividade de especificao da maneira
proposta na Engenharia de Software, nem com o processo de construo do software.
Segundo Souza et al. (1999), o design de interfaces de usurio uma atividade que requer anlise dos
requisitos dos usurios e suas tarefas, concepo, especificao e prototipao da interface, e avaliao
da utilizao do prottipo pelos usurios.
Observao
Requisitos de software so caractersticas, propriedades e
comportamentos desejveis para um produto de software. Eles podem ser
divididos em (SWEBOK, 2004):
Requisitos funcionais: esto diretamente ligados funcionalidade do
software. Descrevem as funes que o software deve executar.
Requisitos no funcionais: expressam as restries a que o software
deve atender ou as qualidades especficas que o software deve ter. s
vezes so conhecidos como restries ou requisitos de qualidade.
No entanto, para Marcus (2002), o design de interface de usurio ainda no tem uma definio
consolidada. Para ele, deveria ser chamado de desenvolvimento de interface de usurio, semelhante
ao desenvolvimento de software, adotado pela Engenharia de Software.
Observao
Segundo Pressman (2006), nos ltimos cinquenta anos, o software programas, dados e documentos
evoluiu. Passou de um ferramental especializado em soluo de problemas e anlise de informaes
para um produto de indstria. No entanto, ainda h problemas em produzir software de alta qualidade
e dentro do prazo e do oramento estabelecido. Desse modo, o intuito da Engenharia de Software
fornecer uma estrutura para a construo de software com alta qualidade.
O Institute of Electrical and Electronic Engineers (IEEE) definiu Engenharia de Software como: (1) A
aplicao de uma abordagem sistemtica, disciplinada e quantificvel, para o desenvolvimento, operao
e manuteno do software; isto , a aplicao da engenharia ao software. (2) O estudo de abordagens
como as de (1) (IEEE, 1990).
Ferramentas
Mtodos
Processos
Foco na Qualidade
Segundo Pressman (2006), a Engenharia de Software uma tecnologia composta por camadas,
conforme apresentado na figura. uma disciplina que tem como base de apoio o foco na qualidade. A
camada de processos assegura a juno das camadas de tecnologia e proporciona o desenvolvimento
racional e oportuno de software de computador. Os mtodos de Engenharia de Software fornecem a
tcnica de como fazer para construir software. As ferramentas de Engenharia de Software fornecem
apoio automatizado ou semiautomatizado para os processos e para os mtodos.
De acordo com estas definies, a Engenharia de Software surgiu com o objetivo de melhorar o
processo de desenvolvimento de software, bem como a qualidade do produto de software.
A Engenharia de Software prope vrios modelos de ciclo de vida de software (tambm conhecidos
como paradigmas de processo ou modelos de processo de software).
A partir de IEEE (1990), Paula Filho (2008), Pressman (2006), Schmidt (2000), Sommerville (2003) e
Swebok (2004), podemse apresentar as fases tipicamente utilizadas nos modelos de ciclo de vida da
engenharia de software, aplicveis maioria dos projetos de software. A seguir, apresentase a descrio
resumida de casa fase:
Anlise: nesta fase o objetivo detalhar, estruturar e validar os requisitos de software levantados
durante a fase de Requisitos, de forma que estes possam ser usados como base para planejamento
e acompanhamento detalhados da construo do produto. Enquanto o Levantamento de Requisitos
focaliza a viso que os usurios tm dos requisitos do software, a Anlise dos Requisitos focaliza a
viso dos desenvolvedores, ainda considerando apenas o que fazer, sem entrar no espao das solues.
Projeto (Design): sua finalidade principal decidir como o sistema ser implementado. Uma
arquitetura de software definida durante esta fase e estabelece a estrutura com que o produto
de software dever ser implementado para satisfazer os requisitos. A arquitetura inclui o projeto
do banco de dados e o desenho interno que modela as partes lgicas e fsicas do software, bem
como suas interconexes e comunicaes com softwares externos. Durante a fase de projeto,
decises tticas e estratgicas so tomadas para atender aos requisitos funcionais e de qualidade
de um sistema.
Testes: nesta fase o objetivo integrar e testar o sistema. Durante a fase de testes, o sistema
verificado para certificar-se de que os requisitos especificados anteriormente foram todos
implementados corretamente. O cdigo gerado deve ser testado rigorosamente baseado nos
requisitos analisados.
Essas fases podem se sobrepor ou podem ser executadas iterativamente (IEEE, 1990).
cascata;
incremental;
espiral;
prototipagem.
26
PROJETO DE INTERFACE COM O USURIO
Observao
Saiba mais
Um dos primeiros modelos propostos foi o Modelo Cascata, tambm chamado de Ciclo de Vida
Clssico, apresentado na figura a seguir:
Requisitos
Anlise
Projeto
Inplementao
Testes
Implantao
O Modelo em Cascata sugere uma abordagem sistemtica e sequencial fases (ou estgios)
de desenvolvimento so apresentadas em sequncia para o desenvolvimento de software. O
processo comea com a especificao dos requisitos pelo cliente e progride ao longo das outras
27
Unidade II
O problema do Modelo em Cascata sua diviso rgida do projeto nesses estgios distintos. Estabelecer
acordos e requisitos bemdefinidos no estgio inicial do processo uma tarefa difcil, pois os requisitos
do cliente, por natureza, sempre se modificam. Outro problema a baixa visibilidade para o cliente, que
somente ver o resultado no final do projeto.
O Modelo Espiral, apresentado na figura a seguir, originalmente proposto por Boehm (1988),
um modelo evolucionrio de processo de software que combina a natureza iterativa da prototipagem
com os aspectos controlados e sistemticos do Modelo em Cascata (PRESSMAN, 2006). O processo
representado como uma espiral, e no como uma sequncia de atividades, com algum retorno de uma
atividade para outra (SOMMERVILLE, 2003). O produto desenvolvido em uma srie de iteraes, de
forma que cada nova iterao corresponde a uma volta na espiral. Desse modo, possvel construir
produtos em prazos curtos, com novas caractersticas e recursos que so agregados medida que a
experincia descobre sua necessidade (PAULA FILHO, 2008).
28
PROJETO DE INTERFACE COM O USURIO
Determinar objetivos,
alternativas e Avaliar alternativas;
restries identificar e resolver riscos
Anlise de risco
Anlise de risco
Anlise de risco
3.2.4 Prototipagem
A prototipagem (ou prototipao) permite que todo o sistema, ou parte dele, seja construdo
rapidamente para que questes sejam entendidas ou esclarecidas.
De acordo com Sharp, Rogers e Preece (2005), os prottipos so muito teis quando se est discutindo
ideias com stakeholders, so dispositivos que facilitam a comunicao entre os membros das equipes e
que consistem em uma maneira eficaz de testar as ideias para voc mesmo.
Uma vantagem desse modelo solucionar o problema da espera no Modelo em Cascata, ou seja, no
necessrio esperar at o final do ciclo de desenvolvimento para poder obter uma verso operacional
do software (PETERS; PEDRYCZ, 2001). Outra vantagem desse modelo deixar o usurio mais tranquilo
ao ver o progresso do desenvolvimento do sistema.
29
Unidade II
Planejamento
Anlise
Prottipo do
Projeto sistema Implementao
Implementao
Sistema
Conforme apresentado na figura a seguir, a prototipagem descartvel tem uma fase de anlise
mais minuciosa, usada para analisar os requisitos e desenvolver ideias para a concepo do sistema.
Entretanto, sugestes e solicitaes de novos recursos pelos usurios e questes tcnicas complexas
podem no ter sido bemcompreendidos pela equipe de projeto. Para que se tenha, portanto, o correto
entendimento, essas questes so examinadas pela anlise, concepo e construo de um prottipo de
design (DENNIS; WIXOM; ROTH, 2014).
30
PROJETO DE INTERFACE COM O USURIO
Planejamento
Anlise
Projeto
Anlise
Prottipo do
Projeto sistema Implementao
Implementao
Sistema
O prottipo gerado nesse modelo no tem o objetivo de ser um sistema funcional. Depois de cumprir
com seu propsito, ele ser descartado.
Proposto por Hix e Hartson em 1989, o Modelo Estrela, apresentado na figura a seguir, emergiu de
um trabalho emprico realizado por ambos, observando como os projetistas de interface trabalhavam
(SHARP; ROGERS; PREECE, 2005).
Avaliao
Requisitos/
Prototipao especificao
Projeto conceitual/
representao formal do
design
31
Unidade II
Segundo Costabile (2001), enquanto o modelo em Cascata sugere uma abordagem top-down
(descendente, partindo da viso do sistema para a do usurio mais formal), o modelo estrela
reconhece que esta abordagem precisa ser complementada por uma abordagem bottom-up
(ascendente, partindo da viso do usurio para a do sistema mais criativa). Diferentemente dos
modelos propostos pela Engenharia de Software, o modelo estrela no especifica ordenamento
algum das atividades.
Um projeto pode comear de qualquer atividade (ponta na estrela) e seguir por qualquer outra,
no entanto, deve sempre passar pela atividade de avaliao. Ou seja, o modelo possui uma avaliao
central e, sempre que uma atividade for completada, seu trabalho dever ser avaliado. Desse modo, os
requisitos, o projeto e o produto evoluem gradualmente.
No entanto, esse modelo apresenta como desvantagem uma baixa viso gerencial para os gerentes
e desenvolvedores. Uma explicao pode estar no fato do modelo estrela ser extremamente flexvel
(SHARP; ROGERS; PREECE, 2005).
Engenharia de Usabilidade, segundo Rocha e Baranauskas (2003), um termo usado para definir o
processo de projeto de sistemas computacionais que visam facilidade de aprendizado e de uso, e que
sejam agradveis para as pessoas. Alm disso, prope a aplicao de mtodos empricos ao projeto de
sistemas baseados em computador.
32
PROJETO DE INTERFACE COM O USURIO
Pr-projeto
Conhecer o usurio
Caractersticas individuais
Tarefa atual
Anlise competitiva
Metas de usabilidade
Projeto
Mtodos participativos
Guidelines
Projeto coordenado
Padres Identidade do produto
Desenvolvimento iterativo
Prototipao
Teste
Design rationale
Ps-Projeto
Feedback de estudo de campo
Na fase de pr-projeto, o objetivo a busca de informaes para compreenso do usurio, das suas
atividades e do seu contexto de trabalho, alm das funcionalidades a serem implementadas no sistema.
Tambm nessa fase so realizados estudos para uma anlise comparativa de produtos existentes e testes
com usurios no uso desses produtos. As metas de usabilidade so definidas ainda nesta fase.
Por fim, a ltima fase, ps-projeto, tem como objetivo conduzir estudos de campo do produto em
uso a fim de obter dados para prximas verses e produtos futuros.
A IHC enfatiza a necessidade de uma abordagem centrada no usurio. Segundo Sharp, Rogers
e Preece (2005), o fio condutor do desenvolvimento de um produto deveria ter como base os
usurios reais e suas metas, no apenas a tecnologia. Desse modo, para se ter um sistema
bemprojetado, os projetistas deveriam extrair o mximo da habilidade e dos julgamentos
humanos mais importantes para o trabalho em questo. Portanto, deveriam apoiar o usurio, e
no limitar suas aes.
Para Faulkner e Culwin (2000), as necessidades do usurio devem ser consideradas desde as fases
iniciais do projeto, e o produto (interface do usurio) deve ser construdo por meio da abordagem
centrada no usurio.
O Design Participativo (DP) uma abordagem que envolve ativamente o usurio. Segundo Sharp,
Rogers e Preece (2005), a ideia dessa abordagem surgiu na Escandinvia, no final dos anos 1960 e incio
dos 1970. Sua inteno consiste em fazer que os usurios se tornem parceiros como os outros na equipe
de projeto, participando de todas as atividades de desenvolvimento.
34
PROJETO DE INTERFACE COM O USURIO
Embora uma metodologia no seja enfatizada, no DP existem mtodos que so vistos mais como um
recurso para os projetistas usarem como julgarem mais apropriado (BROWN, 1996).
Esses mtodos se caracterizam pelo uso de tcnicas simples e pelo pouco comprometimento
com recursos. As tcnicas mais utilizadas so: brainstorming, storyboarding e workshops (ROCHA;
BARANAUSKAS, 2003).
35
Unidade II
Restries
intrnsecas dos ISO/IEC 9126-1 ISO 13407
dispositivos ISO 9241-11
mveis
Contexto Processo de
de uso desenvolvimento
Anlise do usurio
Anlise do ambiente Anlise da tarefa mvel
4 A USABILIDADE E AS NORMAS
Uma interface bemprojetada deve ser a mais amigvel possvel, possibilitando ao usurio extrair todo
o poder computacional de uma aplicao e utiliz-la de forma confortvel, proporcionando uma interao
homem-computador transparente. Entretanto, uma interface malprojetada pode se transformar em um ponto
decisivo na rejeio de um sistema, independentemente de sua funcionalidade, podendo provocar, ainda, a
falha de uma aplicao que tenha sido bemprojetada e desenvolvida (SOUZA; COSTA; SPINOLA, 2006).
Algumas normas NBR e ISO estabelecem definies, orientaes e recomendaes sobre usabilidade
que visam produo de sistemas interativos com interfaces de usurio com qualidade.
Equivalente norma ISO 9241-11, de 1998, a norma NBR ISO 9241-11, de 2002, sobre Requisitos
Ergonmicos para Trabalho de Escritrios com Computadores, consiste de dezessete partes que abordam
diferentes aspectos referentes ao ambiente de trabalho e a prticas do projeto de dilogo utilizado.
36
PROJETO DE INTERFACE COM O USURIO
Para a norma (ABNT, 2002, p. 3), o objetivo de projetar e avaliar computadores buscando usabilidade
proporcionar que usurios alcancem seus objetivos e satisfaam suas necessidades em um contexto
particular de uso. Desse modo, em sua Parte 11, Orientaes sobre usabilidade, esclarece os benefcios
de medir usabilidade em termos de desempenho e satisfao do usurio e define usabilidade como:
medida na qual um produto pode ser usado por usurios especficos para alcanar objetivos especficos
com eficcia, eficincia e satisfao em um contexto especfico de uso, em que:
eficcia definida como a acurcia e a completude com as quais usurios alcanam objetivos
especficos;
eficincia definida como os recursos gastos em relao acurcia e abrangncia com as quais
os usurios atingem os objetivos;
satisfao definida como a ausncia do desconforto e s atitudes positivas para com o uso de
um produto;
contexto de uso definido como usurios, tarefas, equipamentos (hardware, software e materiais),
e os ambientes fsico e social nos quais o produto usado.
Observao
resultado
usurio pretendido objetivos
equipamento
eficcia
resultado
ambiente de uso
eficincia
Contexto de uso
satisfao
produto
Medidas de usabilidade
A definio de usabilidade apresentada pela NBR ISO 9241-11 tambm depende das qualidades
de software que so distintas da usabilidade definidas na ISO/IEC 9126, tais como funcionalidade,
confiabilidade e eficincia do computador. Embora, de fato, estas qualidades de software contribuam para
a qualidade do sistema de trabalho em uso, a norma NBR ISO 9241-11 defende uma abordagem ampla
na qual se encontram as necessidades de usurios reais desenvolvendo tarefas reais em um ambiente
organizacional, tcnico e fisicamente real. Para a norma, a usabilidade definida em termos de qualidade
de um sistema de trabalho em uso depende, necessariamente, de todos os fatores que podem influenciar
no uso de um produto do mundo real (ABNT, 2002, p. 19). Fatores organizacionais, como as prticas de
trabalho e a localizao ou a aparncia de um produto, bem como diferenas individuais entre usurios
do produto, incluindo aquelas decorrentes de fatores culturais e preferncias, so elementos citados pela
norma que podem influenciar a usabilidade de um produto (ABNT, 2002, p. 19).
Equivalente norma ISO/IEC 9621-1, de 2001, a norma NBR ISO/IEC 9126-1, de 2003, Engenharia
de Software: Qualidade de Produto uma norma que descreve um modelo de qualidade do produto de
software (ABNT, 2003, p. 2).
Observao
Exemplos de mtricas internas e externas so apresentados na ISO/IEC
9126-3 e na ISO/IEC 9126-2, respectivamente.
Usabilidade, para essa norma, um atributo de qualidade de software, sendo apresentada como
a capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao
usurio, quando usado sob condies especificadas (ABNT, 2003, p. 7). , ainda, subdividida em
cinco subcaractersticas:
38
PROJETO DE INTERFACE COM O USURIO
6.3.1 Inteligibilidade
6.3.2 Apreensibilidade
6.3.3 Operacionalidade
6.3.4 Atratividade
Esta norma traz ainda o conceito de qualidade em uso que definido como capacidade do
produto de software de permitir que usurios especificados atinjam metas especificadas com eficcia,
produtividade, segurana e satisfao em contextos de uso especificados (ABNT, 2003, p. 12) e
categoriza seus atributos em quatro caractersticas: eficcia, segurana, produtividade e satisfao,
conforme apresentado a seguir:
7.1.1 Eficcia
7.1.2 Produtividade
7.1.3 Segurana
7.1.4 Satisfao
Qualidade
em uso
Embora seja mais ampla, esta definio similar definio de usabilidade da NBR 9241-11 e
tambm faz referncia ao contexto de uso. A norma ressalta que a qualidade em uso sob a perspectiva
do usurio e medida em termos de resultado de uso do software no ambiente especificado, e no em
funo das propriedades do prprio software (SOUZA; COSTA; SPINOLA, 2006).
O relacionamento entre a NBR ISO 9241-11 e a NBR ISO/IEC 9126-1 mostra que os requisitos de
usabilidade para um produto esto relacionados com o contexto de uso, dependendo, portanto, do
usurio, das tarefas e do ambiente.
Segundo Bevan (2001), as definies de usabilidade abordadas pelas duas normas so complementares
e precisam ser combinadas durante o processo de projeto de desenvolvimento.
A norma ISO 13407, de 1999, sobre Processo de Projeto Centrado no Usurio para
Sistemas Interativos fornece orientaes sobre as atividades de projeto centrado no usurio
que acontecem ao longo do ciclo de vida de sistemas interativos computacionais (ISO, 1999).
Descreve um ciclo de desenvolvimento iterativo no qual as especificaes de requisitos de
produto esclarecem corretamente os requisitos do usurio e da organizao, bem como
especificam o contexto no qual o produto ser usado.
Repetio de solues de projeto: requer a avaliao contnua nas fases iniciais dos
usurios finais por tcnicas de prototipao diferentes.
Planejar o processo
centrado no usurio
Compreender e especificar
o contexto de uso
Especificar os requisitos
Avaliar os projetos em Atendeu aos requisitos do usurio e os requisitos
relao aos requisitos organizacionais
Produzir solues de
projeto
41
Unidade II
Saiba mais
42
PROJETO DE INTERFACE COM O USURIO
Resumo
43
Unidade II