Unidade II

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.

3.1 Viso da Engenharia de Software e viso da Interao HumanoComputador

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

A Engenharia de Software surgiu com o objetivo de melhorar o

processo de desenvolvimento de software, bem como a qualidade do
produto de software.

Segundo Rozanski e Haake (2003), Interao Humano-Computador (IHC) tornouse um componente

essencial para todos os profissionais de computao. Cientistas da computao e engenheiros de
software tambm precisam entender os princpios e conceitos de IHC; ainda que no sejam os principais
profissionais responsveis pela compreenso do usurio e pelo projeto da interface, trabalharo com os
profissionais responsveis.

Lembrete

Interao Humano-Computador (IHC) uma disciplina que se preocupa

com o design, a avaliao e a implementao de sistemas computacionais
22
PROJETO DE INTERFACE COM O USURIO

interativos para uso humano e com o estudo dos principais fenmenos que
os cercam (ACM SIGCHI, 1992).

Contudo, as duas reas propem o desenvolvimento de sistemas interativos de forma sistemtica,

definindo modelos de ciclo de vida, mtodos e tcnicas (SILVA et al., 2004).

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.

O quadro a seguir apresenta um resumo das prticas tradicionais da Engenharia de Software e

as melhores prticas no desenvolvimento centrado no usurio da IHC, para o desenvolvimento de
sistemas interativos.

Quadro 1 Prticas em Engenharia de Software e projeto centrado no usurio

Melhores prticas no desenvolvimento centrado no

Prticas tradicionais no desenvolvimento de software
Desenvolvimento dirigido tecnologia.
Foco em componentes de sistema.
Contribuio individual.
Foco nas caractersticas internas da arquitetura.
Qualidade medida por fatores como defeitos de produto e
desempenho (qualidade de sistema).
Implementao antes de validao humana.
Solues so produzidas a partir de requisitos funcionais
(caractersticas e recursos do sistema)
usurio
Dirigido ao usurio.
Foco na soluo para o usurio.
Equipe multidisciplinar, incluindo usurios, clientes,
especialistas em fatores humanos etc.
Foco em atributos externos (interao, aparncia e
funcionamento look and feel)
Qualidade definida por satisfao do usurio e
desempenho (qualidade em uso).
Implementao com base nas avaliaes e aprovaes dos
usurios.
Entendimento do contexto de uso (o usurio, a tarefa e o
ambiente de trabalho).

Adaptado de: Seffah e Metzker (2004, p. 103).

Relevantes autores da rea de Engenharia de Software mostraram a importncia da interface de

usurio. Sommerville (2003) relata que a interface de usurio uma das caractersticas que vm sendo
priorizadas, com enfoque especial no usurio. Os autores Peters e Pedrycz (2001) afirmam que os fatores
humanos, bem como a incluso do usurio no desenvolvimento de interfaces, constituem uma fronteira
relativamente nova da Engenharia de Software. O fato que, atualmente, a interface de usurio vem
ganhando ainda mais importncia nos projetos de sistemas interativos. Entretanto, a incluso do usurio
no desenvolvimento de interfaces, embora j no seja uma fronteira to nova assim na Engenharia de
Software, ainda no acontece consoante sua importncia.
23
 Unidade II

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

O termo design encontrado na literatura sobre IHC como algo mais

amplo em relao ao mesmo termo utilizado na Engenharia de Software.
Entretanto, neste livro-texto, o termo, algumas vezes, aparecer traduzido
para projeto, mesmo quando utilizado nas atividades relacionadas IHC.
24
PROJETO DE INTERFACE COM O USURIO

3.2 Modelos de ciclo de vida de software tradicionais da Engenharia de Software

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

Figura 2 Camadas da Engenharia de Software

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:

Requisitos: esta fase, tambm chamada de Levantamento de Requisitos, visa obter um

conjunto de requisitos de um produto acordado entre cliente e fornecedor. Sua finalidade
definir o que o sistema deve fazer. A identificao de questes relacionadas a algum atributo
de qualidade, tais como desempenho, confiabilidade, disponibilidade e segurana, tambm
faz parte desta fase.
25
 Unidade II

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.

Implementao: na fase de implementao o projeto transportado para uma linguagem de

implementao em forma de cdigo-fonte. O objetivo desta fase traduzir a soluo em cdigo.
A concluso desta fase somente ocorre quando todo o cdigo est escrito e documentado,
compilado, livre de erros e seguindo o padro do projeto. Alm disso, at o final desta fase, um
plano de testes (descrevendo quando e como testar cada parte do cdigo) deve ser traado.

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.

Implantao: tem a finalidade de assegurar uma transio bem-sucedida do sistema desenvolvido

para seus usurios. Consiste na instalao do produto de software no ambiente designado e
a reviso e teste de aceitao por parte do cliente do produto de software (installation of the
software product in the target environment and the acquirers acceptance review and testing
of the software product). Nesta fase esto includos artefatos como material de treinamento e
procedimentos de instalao.

Essas fases podem se sobrepor ou podem ser executadas iterativamente (IEEE, 1990).

Os principais e mais tradicionais modelos de ciclo de vida de software so:

cascata;

incremental;

espiral;

prototipagem.

26
PROJETO DE INTERFACE COM O USURIO

Observao

A Engenharia de Software apresenta vrios modelos de ciclo de vida

de software. Os modelos abordados por meio de conceitos bsicos neste
livro-texto so para fazer um paralelo com os modelos da IHC que sero
apresentados nas prximas pginas.

Saiba mais

Para saber mais sobre os modelos de ciclo de vida de software

apresentados pela Engenharia de Software, consulte tambm:

PRESSMAN, R. S. Engenharia de software. 7. ed. Porto Alegre: AMGH, 2011.

SOMMERVILLE, I. Engenharia de software. 8. ed. So Paulo: Pearson, 2007.

3.2.1 Modelo em Cascata

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

Figura 3 O Modelo em Cascata

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

atividades fundamentais. O desenvolvimento de uma fase deve terminar antes de a prxima

comear. Desse modo, s quando todos os requisitos forem enunciados pelo cliente, analisados
e documentados, que a equipe de desenvolvimento poder realizar as atividades de projeto de
sistema (PFLEEGER, 2004; PRESSMAN, 2006; SOMMERVILLE, 2003).

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.

3.2.2 Modelo Incremental

O Modelo Incremental, conforme apresentado na figura a seguir, combina as vantagens do Modelo

em Cascata com as vantagens do modelo evolucionrio (PRESSMAN, 2006; SOMMERVILLE, 2003). Neste
modelo, que tem o objetivo de apresentar um produto operacional a cada incremento, os requisitos
e conceitos de software e sistema so, primeiro identificados em um esboo pelos clientes, e, em
seguida, definida uma srie de estgios de entrega, com cada estgio fornecendo um subconjunto das
funcionalidades do sistema. Esses estgios so repetidos cada vez que h uma nova verso do software.

Definir esboo dos Atribuir requisitos aos Projetar arquitetura

requisitos incrementos do sistema

Desenvolver Validar incremento Integrar incremento Validar sistema

incremento do sistema Sistema
final
Sistema incompleto

Figura 4 Desenvolvimento incremental

Os primeiros incrementos j oferecem aos usurios condies de coloc-los em operao, bem

como de experimentar o sistema, possibilitando o esclarecimento e a definio de requisitos para os
prximos incrementos.

3.2.3 Modelo Espiral

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

Prottipo 2 Prottipo 3 Prottipo

Anlise operacional
de risco
Reviso Prottipo1
Plano de requisistos Simulao Modelos Benchmarks
Plano de ciclo de vida Conceito de
operao Requisitos
S/W Design do
Projeto
produto
Plano de Validao de detalhado
desenvolvimento requisitos Cdigo
Teste de
Integrao e Projeto
unidade
plano de testes V&V Teste de
Teste de integrao
Planejar a prxima fase aceitao Desenvolver, veriificar
Operao produto do prximo nvel

Figura 5 Modelo Espiral

O modelo abrange de forma clara o gerenciamento de riscos e se aplica ao desenvolvimento de

sistemas e software de grande porte (BOEHM, 1988).

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.

Os prottipos de software so produzidos com funcionalidade e desempenho limitados (PETERS;

PEDRYCZ, 2001), cobrindo cada vez mais requisitos, at que se atinja o produto desejado. Pfleeger (2004,
p. 42) compara o modelo de prototipagem com o prottipo de engenharia. Segundo o autor, o objetivo
o mesmo, ou seja, eficaz quando os requisitos ou projeto necessitam de investigaes repetidas para
garantir que desenvolvedor, usurio e cliente cheguem a um consenso sobre o que necessrio e o que
proposto.

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

Do ponto de vista da Engenharia de Software, a prototipagem parte fundamental do processo de

projeto de interface com o usurio (PFLEEGER, 2004; SOMMERVILLE, 2003).

O paradigma de prototipagem pode ser dividido em evolucionrio e descartvel (throw-away). Na

prototipagem evolucionria, o planejamento de prottipos mais cuidadoso, isto porque os prottipos
no sero descartados. Neste modelo a equipe de desenvolvimento trabalha com os stakeholders os
aspectos mais visveis do sistema, normalmente a interface de usurio, sendo especialmente til quando
os usurios possuem dificuldade para expressar os requisitos do sistema.

Na prototipagem evolucionria, executamse simultaneamente as fases de anlise, projeto

e implementao a fim de desenvolver, de forma rpida, uma verso simplificada do sistema
proposto e apresentla aos stakeholders para avaliao e retorno de informaes, conforme
apresentado na figura a seguir (DENNIS; WIXOM; ROTH, 2014). Caso existam requisitos que ainda
necessitem ser refinados, uma nova iterao ser realizada. Neste caso, a equipe de projeto
novamente analisa, projeta e volta a implementar outro prottipo, com novos recursos e correo
das deficincias encontradas.

Planejamento

Anlise

Prottipo do
Projeto sistema Implementao

Implementao

Sistema

Figura 6 O Modelo de Prototipagem

A prototipagem descartvel (throw-away) consiste na construo de prottipos utilizados para

explorar as alternativas de projeto, entender melhor os requisitos do sistema e reduzir riscos.

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

Figura 7 Modelo de prototipagem descartvel

O prottipo gerado nesse modelo no tem o objetivo de ser um sistema funcional. Depois de cumprir
com seu propsito, ele ser descartado.

3.3 Modelo de ciclo de vida de design de interface de usurio

3.3.1 Modelo Estrela

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).

Anlise das tarefas/

Implementao anlise funcional

Avaliao

Requisitos/
Prototipao especificao

Projeto conceitual/
representao formal do
design

Figura 8 Modelo Estrela

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).

3.3.2 Engenharia de Usabilidade

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.

Segundo Brown (1996), Engenharia de Usabilidade um modelo com foco principal em

conhecer o usurio e suas tarefas, bem como testar com os usurios os prottipos de um produto
em desenvolvimento.

O usurio e o projetista de interface so os membros fundamentais nesta metodologia. No

entanto, esta metodologia no apresenta uma relao definida entre o projetista de interface e o
engenheiro de software.

Na figura a seguir so ilustradas as fases e o fluxo das atividades no modelo de Engenharia de

Usabilidade proposto por Nielsen (1992, 1993) e sumarizado por Rocha e Baranauskas (2003). O modelo
possui trs fases: pr-projeto, projeto e ps-projeto.

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

Figura 9 Modelo de Engenharia de Usabilidade

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.

A fase do projeto comporta o projeto inicial e o desenvolvimento iterativo. O projeto inicial

constitudo da especificao inicial da interface. O design participativo realizado, e o uso de guidelines
recomendado. O projeto coordenado (desenvolvimento paralelo da funcionalidade, da interface, do
help e do material de treinamento) faz parte desta fase. O uso de padres aumenta o reso de cdigo
e facilita a documentao. O desenvolvimento iterativo alimentado por feedback de testes at que
os objetivos tenham sido alcanados. Os objetivos dessa fase so produzir um prottipo com princpios
de usabilidade e verificar empiricamente, com usurios reais, se as metas foram atingidas. O design
rationale, alm de manter a memria do processo de projeto, ajuda a manter a consistncia ao longo
das diferentes verses do produto.

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.

Nielsen (1992) reconhece que frequentemente oramentos ou restries de tempo no

permitiro o uso de todas as atividades do Modelo de Engenharia de Usabilidade. No entanto,
recomenda um mnimo:

visite os locais de trabalho do cliente antes do incio do projeto;

33
 Unidade II

faa um projeto iterativo com mtodos participativos;

use prototipao e testes empricos com usurios reais.

3.3.3 Projeto centrado no usurio

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.

Os princpios do projeto centrado no usurio, ou User-Centered Design (UCD), so focalizar

desde o incio os usurios e as tarefas que desenvolvem num determinado ambiente, medir a
utilizao do produto observando a interao do usurio com ele e utilizar um processo de design
iterativo, no qual o design possa ser modificado aps as fases de prototipao ou testes (SOUZA;
COSTA; SPINOLA, 2006).

Projeto centrado no usurio uma atividade multidisciplinar que

incorpora fatores humanos e conhecimento de ergonomia e tcnicas
com o objetivo de aumento da eficcia e eficincia, melhorando as
condies humanas de trabalho, segurana, desempenho e evitar
possveis efeitos contra a sade do homem (BEVAN, 1999 apud SOUZA;
COSTA; SPINOLA, 2006, p. 5).

3.3.4 Design Participativo

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.

A incluso do usurio final no processo de desenvolvimento se deve ao seu conhecimento das

rotinas de trabalho, alm de servir como fonte de informao. Desta forma, por meio de sua participao
ativa, o usurio proporciona contribuies efetivas em todas as fases do processo de desenvolvimento,
que refletem suas perspectivas e necessidades, no somente da etapa de testes e avaliao (ROCHA;
BARANAUSKAS, 2003).

34
PROJETO DE INTERFACE COM O USURIO

De acordo com Brown (1996), o DP no defende uma metodologia em particular. O argumento

de que, do ponto de vista dos defensores do DP, para a fabricao de um bom produto de software
no necessria uma metodologia como foco, e sim a qualidade da comunicao entre o usurio e
os projetistas. No DP so definidos os tipos de comunicao desejados e mtodos que podem auxiliar
usurios e projetistas a realizarem um projeto melhor.

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).

3.3.5 Customizao de um modelo de ciclo de vida destinada a projeto de interface

para dispositivos mveis

medida que as tecnologias mveis comeam a fazer parte da infraestrutura de Tecnologia da

Informao (TI) das organizaes e do dia a dia das pessoas, altamente importante, ao se construir uma
estratgia de desenvolvimento de aplicaes mveis, ter um entendimento aprofundado da interao
do usurio com os dispositivos mveis (SOUZA; COSTA; SPINOLA, 2006).

Novas plataformas de computao e comunicao criam a possibilidade

para novos modelos de negcios e novas aplicaes que tm influncia na
vida das pessoas. No entanto, novas plataformas tambm exigem a reviso
dos mtodos e princpios de projetos da atualidade. Os dispositivos mveis
esto abrindo novas oportunidades de negcios para empresas e usurios
e novos desafios de projeto de software (HOLTZBLATT, 2005 apud SOUZA;
COSTA; SPINOLA, 2006, p. 7).

Os desafios tecnolgicos em desenvolvimento de sistemas mveis so significativos, e o

avano da computao mvel fez surgir novos modelos de interface e exibies de informao. A
interface com o usurio j tinha grande importncia no processo de desenvolvimento de sistemas
interativos; agora, nos projetos de software para computao mvel, a interface um desafio
ainda maior.

Diante desse cenrio, verifica-se a grande importncia de se facilitar a forma de utilizao

desses dispositivos computacionais mveis, isto , de disponibilizar uma interface bemplanejada,
visando facilidade de aprendizagem, simplicidade de uso e satisfao do usurio ao interagir
com o sistema.

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

Figura 10 Modelo de processo de desenvolvimento de aplicaes mveis

A figura representa o modelo de processo de desenvolvimento de aplicaes mveis. O modelo tem

como base o projeto centrado no usurio, fundamentado na norma ISO 13407: Processo de Projeto
Centrado no Usurio para Sistemas Interativos. A aplicao da norma em conjunto com a ISO 9241-11
e a ISO 9126-1 tem o objetivo de resultar em interfaces de usurio de software de dispositivos mveis
com nveis maiores de usabilidade.

Entretanto, a diversidade e as restries intrnsecas dos dispositivos mveis tm aumentado de

maneira significativa a dificuldade e a complexidade do projeto de interface de usurio. A compreenso
correta do contexto de uso mvel, ou seja, identificar e compreender as caractersticas dos usurios e
seus diferentes nveis de conhecimento, o ambiente de uso e as tarefas que sero executadas com o
produto desde as fases iniciais do processo de desenvolvimento, um fator determinante na usabilidade
do produto final e fundamental para o sucesso de uma aplicao 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.

4.1 A usabilidade e a NBR ISO 9241-11

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

Embora a norma NBR 9241-11 se aplique ao trabalho de escritrio com

computadores, ela tambm pode ser aplicada a outras situaes nas quais
o usurio est interagindo com um produto para alcanar seus objetivos
(ABNT, 2002, p. 2), por exemplo, smartphones e tablets.

A figura a seguir ilustra a estrutura de usabilidade apresentada por esta norma.

resultado
usurio pretendido objetivos

tarefa Usabilidade: medida na qual objetivos so

alcanados com eficcia, eficincia e satisfao.

equipamento
eficcia
resultado
ambiente de uso
eficincia
Contexto de uso
satisfao
produto
Medidas de usabilidade

Figura 11 Estrutura de usabilidade

Segundo a norma, a partir da identificao dos objetivos e da decomposio de eficcia,

eficincia, satisfao e componentes do contexto de uso em subcomponentes com atributos
37
 Unidade II

mensurveis e verificveis, possvel especificar ou medir a usabilidade. Para tanto, so necessrias

as seguintes informaes:

uma descrio dos objetivos pretendidos;

uma descrio (suficientemente detalhada, de modo que aqueles aspectos que possam ter
uma influncia significativa sobre a usabilidade possam ser reproduzidos) dos componentes do
contexto de uso (existente ou uma especificao dos contextos pretendidos), incluindo usurios,
tarefas, equipamento e ambientes;
valores reais ou desejados de eficcia, eficincia e satisfao para os contextos pretendidos.

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).

4.2 A usabilidade e a NBR ISO/IEC 9126-1

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).

Esta norma categoriza os atributos de qualidade de software em seis caractersticas (funcionalidade,

confiabilidade, usabilidade, eficincia, manutenibilidade e portabilidade). Cada caracterstica , ainda,
subdividida em subcaractersticas, que, por sua vez, podem ser medidas por meio de mtricas externas
e internas.

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

Capacidade do produto de software de possibilitar ao usurio compreender

se o software apropriado e como ele pode ser usado para tarefas e
condies de uso especficas. [...]

6.3.2 Apreensibilidade

Capacidade do produto de software de possibilitar ao usurio aprender sua

aplicao. [...]

6.3.3 Operacionalidade

Capacidade do produto de software de possibilitar ao usurio oper-lo e

control-lo. [...]

6.3.4 Atratividade

Capacidade do produto de software de ser atraente ao usurio.

NOTA Isto se refere a atributos de software que possuem a inteno de

tornar o software mais atraente para o usurio, como o uso de cores e a
natureza do projeto grfico.

6.3.5 Conformidade relacionada usabilidade

Capacidade do produto de software de estar de acordo com normas,

convenes, guias de estilo ou regulamentaes relacionadas usabilidade
(ABNT, 2003, p. 9-10).

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

Capacidade do produto de software de permitir que usurios atinjam metas

especificadas com acurcia e completude, em um contexto de uso especificado.

7.1.2 Produtividade

Capacidade do produto de software de permitir que seus usurios

empreguem quantidade apropriada de recursos em relao eficcia obtida,
em um contexto de uso especificado. [...]
39
 Unidade II

7.1.3 Segurana

Capacidade de um produto de software de apresentar nveis aceitveis de

riscos de danos a pessoas, negcios, software, propriedades ou ao ambiente,
em um contexto de uso especificado. [...]

7.1.4 Satisfao

Capacidade de um produto de software de satisfazer usurios, em um

contexto de uso especificado (ABNT, 2003, p. 12).

Qualidade
em uso

Eficcia Produtividade Segurana Satisfao

Figura 12 Modelo de qualidade para 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.

4.3 A norma ISO 13407 (Processo de Projeto Centrado no Usurio para

Sistemas Interativos)

O propsito de projetar um sistema interativo satisfazer as necessidades de usurios,

ou seja, prover qualidade em uso (BEVAN, 1999), que (ou pelo menos deveria ser) o meio
para alcanar qualidade nos produtos de software (BEVAN; BOGOMOLNI, 2000).

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.

Essa norma define um conjunto de princpios que incorporam a perspectiva do usurio

no processo de desenvolvimento de software.
40
PROJETO DE INTERFACE COM O USURIO

Distribuio apropriada de funo entre usurio e sistema: determina quais aspectos

do trabalho ou da tarefa devem ser controlados por software e hardware.

Envolvimento ativo de usurios: utiliza as pessoas que tm maiores conhecimentos

no contexto em que a aplicao ser usada, visando, com isso, a um aumento no
compromisso de participao no desenvolvimento do software.

Repetio de solues de projeto: requer a avaliao contnua nas fases iniciais dos
usurios finais por tcnicas de prototipao diferentes.

Equipes multidisciplinares: alimentam um processo de desenvolvimento colaborativo

com o envolvimento de especialistas de vrias reas, cada um cooperando e
compartilhando seus conhecimentos.

De acordo com a norma, h quatro principais atividades, apresentadas na figura a

seguir, que devem ser empregadas para incorporar requisitos de usabilidade ao processo de
desenvolvimento de software centrado no usurio.

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

Figura 13 Processo de projeto centrado no usurio

Compreender e especificar o contexto de uso: o objetivo obter as informaes sobre as

caractersticas dos usurios, o ambiente de uso e as tarefas que sero executadas com o produto,
alm de fornecer uma base para as atividades de avaliaes posteriores.

Especificar os requisitos do usurio e da organizao: determinar os critrios de sucesso para a

usabilidade do produto em termos de tarefas realizadas pelos usurios, bem como diretrizes e
limitaes do projeto.

41
 Unidade II

Produzir solues de projeto: incorporar conhecimentos de interface

homemcomputador s solues de projeto. As possveis solues de projeto so
exploradas, sendo descritas por meio da utilizao de prottipos. As primeiras
solues de projeto podem ser baseadas em experincias anteriores ou utilizao de
normas e guias, que so refinadas por feedback do usurio.

Avaliar projetos em relao aos requisitos do usurio: a usabilidade do projeto deve

ser avaliada em relao s tarefas dos usurios, tendo como objetivo confirmar o nvel
em que os requisitos da organizao e dos usurios foram alcanados, fornecendo
tambm informaes para o refinamento do projeto.

O ciclo dessas atividades termina quando a avaliao do projeto em relao aos

requisitos do usurio executada com um resultado satisfatrio.

Os benefcios da usabilidade atravs do projeto centrado no usurio orientados pela

norma ISO 13407 podem incluir o aumento da produtividade, aumento na qualidade de
trabalho, redues de custos em treinamento e aumento da satisfao do usurio.

O relatrio tcnico ISO TR 18529, de 2000, sobre Ergonomia de Interao

HomemSistema - Descries sobre o Ciclo de Vida Centrado no Usurio, contm uma
definio e uma estrutura formalizada do processo centrado no usurio descrito na
ISO 13407. O modelo de maturidade de usabilidade descrito na ISO TR 18529 pode ser
utilizado em conjunto com a ISO 15504, Avaliao de Processo de Software, para avaliar
a capacidade de uma organizao na utilizao do processo de desenvolvimento centrado
no usurio (ISO STANDARDS, 2006).
Fonte: Souza, Costa e Spinola (2006, p. 5-7).

Saiba mais

Diversas normas internacionais foram desenvolvidas para definir

os princpios gerais de projeto centrado no usurio. Um estudo mais
aprofundado sobre aplicao das normas ISO pode ser encontrado em:

BEVAN, N. International standards for HCI and usability. International

Journal of Human Computer Studies, Londres, v. 55, n. 4, p. 533-52, out.
2001. Disponvel em: <http://www.nigelbevan.com/papers/HCI-Usability_
standards.pdf>. Acesso em: 2 mar. 2015.

42
PROJETO DE INTERFACE COM O USURIO

Resumo

Vimos que a Engenharia de Software tem o foco voltado para o

produto e seu processo de desenvolvimento, enquanto a Interao
Humano-Computador tem o foco voltado interao do ser humano e
da mquina. No entanto, as duas reas estabelecem mtodos e processos
de desenvolvimento de sistemas interativos. Enquanto a Engenharia de
Software tem o foco no projeto e na especificao da funcionalidade
interna do sistema, bem como em sua arquitetura, visando qualidade
estrutural do produto de software final, a IHC focaliza a interao e o design
de interface do usurio, levando em conta as necessidades, os valores e as
expectativas dos usurios, visando qualidade de uso da soluo projetada.
Portanto, ambas as reas tratam da qualidade do produto final, no entanto
sob perspectivas e focos diferentes.

Abordamos que a Interao Humano-Computador tornouse um

componente essencial para todos os profissionais de computao.
Desenvolvedores, projetistas e engenheiros de software tambm precisam
entender os princpios e conceitos de Interao Humano-Computador;
ainda que no sejam os principais profissionais responsveis pela
compreenso do usurio e pelo projeto da interface, trabalharo com os
profissionais responsveis.

Aprendermos que a interface de usurio vem ganhando ainda mais

importncia nos projetos de sistemas interativos. Entretanto, a incluso
do usurio no desenvolvimento de interfaces, embora j no seja uma
fronteira to nova assim na Engenharia de Software, ainda no acontece
consoante sua importncia.

Durante os estudos, vimos que a Engenharia de Software prope vrios

modelos de ciclo de vida de software. As fases tipicamente utilizadas neles,
aplicveis grande maioria dos projetos de software, so: Requisitos,
Anlise, Projeto (Design), Implementao, Testes e Implantao. Estas fases
podem se sobrepor ou podem ser executadas iterativamente. Os principais
e mais tradicionais modelos de ciclo de vida de software so: cascata,
incremental, espiral e prototipagem.

Abordamos ainda que a prototipagem (ou prototipao) permite que

todo o sistema, ou parte dele, seja construdo rapidamente para que
questes sejam entendidas ou esclarecidas. O paradigma de prototipagem
pode ser dividido em evolucionrio e descartvel (throw-away). Na
prototipagem evolucionria, a equipe de desenvolvimento trabalha com

43
 Unidade II

os stakeholders os aspectos mais visveis do sistema, normalmente a

interface de usurio, sendo muito especialmente til quando os usurios
possuem dificuldade em expressar os requisitos do sistema. A prototipagem
descartvel (throw-away) consiste na construo de prottipos utilizados
para explorar as alternativas de projeto, entender melhor os requisitos
do sistema e reduzir riscos. O prottipo gerado nesse modelo no tem o
objetivo de ser um sistema funcional. Depois de cumprir com seu propsito,
ele ser descartado.

Vimos que a IHC tambm apresenta modelos de ciclo de vida para o

desenvolvimento de sistemas interativos. No entanto, os modelos de ciclo de
vida apresentados pela IHC no discutem as etapas para o desenvolvimento
e a implementao do sistema e suas funcionalidades, diferentemente
dos modelos de ciclo de vida da Engenharia de Software. Esses modelos
enfocam o desenvolvimento da interao com o usurio. Os principais
so os Modelos Estrela, Engenharia de Usabilidade, Projeto Centrado no
Usurio e Design participativo.

Tivemos a oportunidade de estudar e aprender sobre a importncia das

normas no processo de desenvolvimento de interface de usurio. Algumas
normas NBR e ISO estabelecem definies, orientaes e recomendaes
sobre usabilidade que visam produo de sistemas interativos com
interfaces de usurio com qualidade. De acordo com a NBR ISO
924111, sobre Requisitos Ergonmicos para Trabalho de Escritrios com
Computadores, a partir da identificao dos objetivos e da decomposio
de eficcia, eficincia, satisfao e componentes do contexto de uso em
subcomponentes com atributos mensurveis e verificveis, possvel
especificar ou medir usabilidade. A definio de usabilidade apresentada
pela NBR ISO 9241-11 tambm depende das qualidades de software, que
so distintas daquelas definidas na ISO/IEC 9126, tais como funcionalidade,
confiabilidade e eficincia do computador. A NBR ISO/IEC 9126-1,
Engenharia de Software: Qualidade de Produto, uma norma que descreve
um modelo de qualidade do produto de software. O relacionamento entre
as normas NBR ISO 9241-11 e 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.

A norma ISO 13407, 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. Os benefcios da usabilidade por meio
do projeto centrado no usurio orientados pela norma ISO 13407 podem
incluir o aumento da produtividade, aumento na qualidade de trabalho,
redues de custos em treinamento e aumento da satisfao do usurio.
44