Sei sulla pagina 1di 13

Uma Reflexo sobre a Qualidade na Engenharia de Software e na

Interao Humano-Computador
Resumo: A rea de Interao Humano-Computador (IHC) objetiva projetar e
desenvolver sistemas com alta usabilidade. Do mesmo modo, a rea de Engenharia de
Software (ES) objetiva projetar e desenvolver sistemas com alta qualidade. A fim de se ter um
processo de desenvolvimento de software com qualidade bem como o produto desenvolvido
com usabilidade, importante se discutir o que qualidade representa em cada uma destas
reas. Mais especificamente, este artigo visa mostrar que necessrio integrar os princpios,
tcnicas de ES e IHC em um integrado processo de desenvolvimento de sistemas.
Palavras-chaves: Princpios de desenvolvimento de sistemas. Qualidade em ES.
Qualidade em IHC.
Abstract: Human-Computer Interaction (HCI) aims to design and develop highusability software. Analogously, Software Engineering (SE) aims to design and develop highquality systems. In order to achieve both software usability and software process quality, it is
paramount to discuss what quality is for each area. More specifically, this work aims to show
that it is necessary to integrate HCI and ES principles and techniques into a same
development process of systems.
Key words: Principles of software development; Quality in ES; Quality in HCI.
Tipo do artigo : trabalho tcnico

1. Introduo
Na comunidade profissional de desenvolvedores de software, estudos realizados na rea de
Engenharia de Software (ES) (como: os processos e linguagens unificados com diretrizes de
acompanhamento) auxiliam a garantir a qualidade de um processo de desenvolvimento de um
sistema. Porm, estudos realizados na rea de Interao Humano-Computador (IHC) (como:
fatores humanos, que ajudam a definir o contexto de uso de um sistema pelo usurio,
recomendaes ergonmicas, que permitem determinar formas adequadas de apresentao de
informao nas telas, etc.) e as prticas existentes (como: projeto participativo, centrado no
uso (Constantine et al, 2003)) vm atraindo cada vez mais ateno da comunidade acadmica.
Isto devido ao fato da rea de IHC objetivar projetar, avaliar e implementar sistemas
interativos para uso humano com foco na usabilidade qualidade de uso tal como percebida
pelo usurio, e.g. facilidade de uso e aprendizado (Furtado & Barbosa, 2003). Enquanto que, a
rea de ES objetiva projetar, avaliar e implementar sistemas interativos com qualidade,
concentrando-se em cronograma, oramento, comunicao e produtividade (Boggs, 1999).
Para se atingir estes dois objetivos, as comunidades envolvidas esto consciente de que
mtodos, modelos e ferramentas especficos de cada rea deveriam ser integrados.
Diversas iniciativas (UPi (Sousa & Furtado, 2003), (Xerre 2003), (Paula & Barbosa, 2003))
so voltadas integrao destes estudos e prticas em um processo integrado de
____________________________________________________________________________

desenvolvimento de software, que atinja no apenas a qualidade do ponto de vista do sistema,


mas a qualidade de uso deste sistema do ponto de vista de seus usurios.
O objetivo deste trabalho no de mostrar mais uma soluo de um processo integrado de
desenvolvimento de software. O objetivo mostrar o que significa desenvolver um produto
com sucesso, para as duas reas, respeitando a conceituao de cada uma. Alm disto, se quer
mostrar que possvel haver esta integrao atravs da aceitao dos princpios adotados em
cada rea, mas que os desafios ainda so grandes. Este texto est organizado da seguinte
maneira: aps uma breve conceituao sobre sistemas interativos e sobre as duas reas em
estudo, ser feita uma reflexo sobre a integrao de ES e IHC para se obter sistemas com
mais qualidade e mais usveis.
2. Conceituao
2.1. Software e Sistema Interativo
Um software um conjunto de programas de computador e a documentao associada
(Sommerville, 2003). A noo de Sistema Interativo (SI), comumente usada em IHC, abrange
este conceito, mas dar nfase no fato de que os programas so manipulados pelo usurio,
havendo assim interao entre o ser humano e o computador. O sucesso desta interao
depende da forma como os componentes de um SI so modelados. Estes componentes so: a
aplicao e interface. A aplicao se refere parte no interativa do sistema (como os dados e
as funes que regem as regras de negcio do sistema sendo modelado). A Interface se refere
parte interativa do sistema (como os dados e as funes responsveis de permitir a interao
entre o usurio e o sistema).
2.2.

Engenharia de Software

Engenharia de software a disciplina da engenharia que se ocupa dos aspectos da produo


de um software, principalmente aqueles obtidos durante o desenvolvimento sistemtico do
software (como as caractersticas de um software que satisfariam s necessidades de um
usurio) e o gerenciamento do processo de desenvolvimento (como o controle de mudanas
de requisitos). Esta disciplina disponibiliza modelos, tcnicas e ferramentas para dar apoio
produo de software. Estes recursos devem ser disponibilizados, de maneira organizada, para
facilitar sua aplicao e utilizao. Diante desta necessidade, surgem os processos de
software.
Um Processo de Desenvolvimento de Software (PDS) um conjunto de atividades descritas
com o objetivo de desenvolver ou manter um software. As atividades devem ser
desempenhadas por uma equipe, que aplica tcnicas e faz uso de modelos e ferramentas,
quando disponveis.
Um mtodo de desenvolvimento de software aplicado em uma empresa, por exemplo, pode
ser visto como uma instncia de um PDS, fornecendo uma estruturao prpria que envolve
um conjunto de tarefas, tais como: anlise de requisitos, projeto, construo de programa,
____________________________________________________________________________

teste, e manuteno. Alm disto, um mtodo inclui um conjunto de princpios bsicos, regras,
recomendaes de projeto e diretrizes de processos, que ajudam a bem definir os requisitos
para um software. Alguns requisitos no-funcionais que contribuem para a qualidade de um
software construdo so os seguintes: confiabilidade, funcionalidade, usabilidade,
manutenibilidade, desempenho e portabilidade.
As ferramentas que promovem um suporte automtico ou semi-automtico para processos e
mtodos so conhecidas como ferramentas CASE (Computer-aided software engineering) e
combinam software, hardware e base de dados para a gerao de um ambiente de engenharia
de software.
De uma forma geral, durante um PDS, algumas questes devem ser respondidas:
-

Qual o problema a ser resolvido?

Quais as caractersticas do produto (tcnicas ou de outra ordem), que so


utilizadas para resolver o problema?

Como esse produto ser construdo de forma a garantir qualidade no


processo?

Como descobrir erros, que foram cometidos no projeto e na construo do


produto, sem ultrapassar o cronograma e oramentos pr-estabelecidos?

O Rational Unified Process (RUP) (Kruchten, 2000) um exemplo de processo voltado para a
qualidade de software, que auxilia desenvolvedores a responderem estas questes. Este
processo se baseia nas melhores prticas de desenvolvimento de software (tais como:
desenvolver software de forma iterativa, gerenciar requisitos, utilizar arquiteturas baseadas
em componentes) consideradas como tal por serem utilizadas comumente em organizaes
bem sucedidas.
Entretanto, seguir estas prticas e estratgias no garante a usabilidade. Prticas devem ser
adotadas que integrem mtodos, modelos e tcnicas estudados em IHC com aqueles estudados
em ES.

2.3.

Interao Humano-Computador

a disciplina preocupada com o projeto, avaliao e implementao de um SI para o uso


humano e com o estudo dos principais fenmenos ao redor dele, como a rea de aplicao, o
contexto de uso do usurio, etc. (Rocha & Baranauskas, 2003). A qualidade do uso de um SI
est ligada a trs conceitos: Utilidade, capacidade e usabilidade (Constantine & Lockwood,
1999).
Utilidade significa que o sistema realiza algo de valor para o usurio, ou seja, algo que
justifica o investimento no desenvolvimento do sistema. Vale ressaltar que pesquisas em ES,
____________________________________________________________________________

mais especificamente na engenharia reversa, tm sido feitas aplicando mtricas de usabilidade


a um SI para verificar se justifica o investimento no reprojeto deste sistema (Silva et al, 2003).
Capacidade significa que o sistema realiza o que o usurio espera que ele realize, ou seja, as
funcionalidades do sistema devem estar de acordo com as tarefas que o usurio precisa
realizar. Na ES, este conceito atingido atravs de um processo contnuo de verificao e
validao das funcionalidades do sistema (Sutcliffe, 2002).
Usabilidade significa que o sistema dispe de funcionalidades que so fceis de aprender,
usar e tambm significa que o sistema agradvel de forma que o usurio fica satisfeito ao
us-lo. Tal conceito definido na ISO 9241-11, que descreve uma maneira para medir o
desejado nvel de usabilidade. A maioria das tcnicas existentes em IHC (como prototipagem,
cenrios) e princpios (como princpios ergonmicos) tem nfase na obteno deste conceito.
Como por exemplo, a utilizao de cenrios durante o desenvolvimento de um SI objetiva
captar com realismo os detalhes da interao do usurio com o sistema em desenvolvimento,
como: o contexto de uso deste. Os trabalhos realizados em ES quase que ignoram esta
percepo.
Em geral, estes trs conceitos agem diretamente sobre a aceitabilidade de um SI pelo usurio
e/ou cliente. Eles so importantes para que os desenvolvedores percebam que projetar
sistemas com qualidade, antes de tudo, considerar os usurios, o uso que eles faro dos
sistemas (as tarefas) e o contexto de uso (condies ambientais) e no somente as
funcionalidades dos sistemas. Para as aplicaes mais modernas, como as mveis, a
aceitabilidade depende tambm da avaliao da mobilidade do equipamento, como o peso e
resistncia a choques.
Quanto s ferramentas que apiam o processo automtico ou semi-automtico de gerao de
interfaces de usurio, destacam-se:
Geradores de interface - que apiam a especificao grfica das interfaces e o
tratamento dos eventos sobre os objetos, como por exemplo, mdulos contidos nos
ambientes de programao, como Delphi.
Tecnologias open-source dentre elas, destacam-se os frameworks da linguagem
Java: struts, que apia a especificao conceitual das interfaces (sem detalhes de
visualizao), e suas relaes de navegao e composio fazendo uso de padres
de projeto, e o Java server Faces, que apia a seleo dos objetos interativos das
interfaces, o tratamento dos eventos sobre os objetos, e o suporte
internacionalizao e acessibilidade do sistema sendo construdo.
Para se obter a qualidade em IHC, do ponto de vista dos trs conceitos acima, durante a
realizao de um PDS, algumas questes devem ser respondidas, como:
-

Quais as necessidades do usurio e/ou cliente? Dentre elas se incluem as


necessidades de usabilidade, que se referem s user experience goals (como

____________________________________________________________________________

a necessidade que o usurio tem que o sistema seja agradvel, divertido, etc.)
(Preece, 2002).

2.4.

Quais as caractersticas do SI, que so utilizadas para atender os requisitos de


usabilidade?

Como as possibilidades de interao do SI sero construdas de forma a


garantir a usabilidade? Que modelos de IHC podem ser usados para esta
construo?

Como descobrir erros de usabilidade, que foram cometidos no projeto e na


construo do produto? Que tcnicas de avaliao de IHC podem ser usadas?

Anlise Comparativa

A tabela 1 ilustra uma comparao que abrange as duas reas citadas. A necessidade de se
estudar aspectos relativos ao desenvolvimento sistemtico de um software e o gerenciamento
do seu processo de desenvolvimento surgiu na dcada de 70. Enquanto que a disciplina de
IHC surgiu uma dcada depois, objetivando resolver problemas de usabilidade. A qualidade
para ES est diretamente ligada ao gerenciamento do processo para que se obtenha produtos
com mais qualidade. No entanto, um processo com qualidade no garante a qualidade do
produto gerado. Para IHC, o foco est na qualidade de uso.
Os modelos desenvolvidos em ES dizem respeito modelagem das entidades e funes da
aplicao, enquanto que em IHC, os modelos so mais concretos, representando
caractersticas pertinentes interao entre um usurio e um SI (tais como: suas tarefas,
estrutura navegacional entre as telas, etc.). Isto porque, usurios preferem modelos que
possam ser capazes de faz-los entender o impacto que o novo sistema ter sobre eles.
Enquanto em ES, desenvolvedores requerem modelos abstratos que possam ajud-los a saber
o que implementar. Quanto s caractersticas do produto, na ES pretende-se desenvolver um
produto que atenda todos os requisitos estabelecidos, enquanto que em IHC, deve-se atender
os requisitos de usabilidade levando-se em considerao os padres de usabilidade prexistentes.
Quanto aos modelos de ciclo de vida, na ES destacam-se os modelos em cascata (Royce,
1970), que evidencia a seqncia em cascata de uma fase para outra e o espiral (Boehm,
1988), que representa um PDS em muitos loops permitindo a avaliao e reduo de riscos.
Em IHC, existem dois modelos: modelo em estrela (Hix & Hartson, 1993), cuja atividade
central a avaliao e o incio de um PDS pode acontecer por qualquer uma das demais
atividades (projeto, implementao, etc.) e o modelo de engenharia da usabilidade (Mayhew,
1999), que composto de trs fases: iniciao, desenvolvimento e transio. Na primeira fase,
um guia de estilo j definido. Durante as diversas iteraes na fase de desenvolvimento, este

____________________________________________________________________________

guia de estilo melhorado e validado, atravs de prottipos. Na ltima fase, o produto


entregue ao usurio final.
Ambas as reas tm em comum o uso de padres, que representam solues j bem aceitas na
comunidade para resolver um certo problema. Para IHC, os padres so de projeto da
interao, e objetivam mostrar, por exemplo, como definir os objetos de uma tela destinada
para a realizao de tarefas de manuteno (Pribeanu & Vanderdonckt, 2003). Estes padres
so definidos de acordo com diversos tipos de recomendaes ergonmicas expressas em
padres ou normas (como a ISO (International Standards Organization) na Europa e a HFES
(Human Factors and Ergonomics Society) nos Estados Unidos) e em guias de estilo, que so
documentos que normalmente so produzidos por uma organizao e disponibilizados
comercialmente (Vanderdonckt, 1999). Em ES, os padres so de projeto de sistemas
(chamados design patterns (Gamma et al, 1995)). Eles objetivam mostrar solues para
realizar a modelagem da aplicao de forma a garantir sua flexibilidade, portabilidade e
extensibilidade. O uso de design patterns est bem difundido porque ferramentas de
modelagem, como o ROSE, permitem a integrao de classes, que descrevem um padro de
projeto, em um diagrama de classes da aplicao descrito em UML. No entanto, os padres de
IHC ainda no possuem uma nica terminologia nem ferramentas capazes de permitirem seu
uso.
Tabela 1 - Comparao entre ES e IHC
Fatores

Engenharia de software

Interao HumanoComputador

Origem

Dcada de 70

Dcada de 80

Foco

Qualidade do processo e do Qualidade do uso


produto
(Utilidade, capacidade e
usabilidade)

A modelagem recai sobre

as entidades e funes da
aplicao

as tarefas, a navegao, a
interao

Modelos de ciclos de vida

Cascata, espiral

Estrela e de Usabilidade

Caractersticas do produto

Devem atender requisitos


Devem atender requisitos de
funcionais e no-funcionais usabilidade

Uso de Padres

De Projeto (apoio
modelagem e
implementao da
aplicao)

De Usabilidade (apoio
ergonmico modelagem
das interfaces)

____________________________________________________________________________

A seguir, ser feita uma reflexo sobre a integrao de princpios de ES e IHC para se obter
sistemas com mais qualidade e mais usveis.
3. Reflexo sobre a Integrao da Engenharia de Software e Interao HumanoComputador
3.1.

Princpios aplicados ao Processo

Existem princpios em ES e em IHC que regem as pesquisas e estudos para se desenvolver


sistemas mais confiveis e mais usveis, como: princpio da independncia do dilogo,
projeto centrado no uso e no usurio, gerao do software baseado em modelos e processo
interativo, incremental e evolutivo.
Princpio de independncia do dilogo
Geralmente, problemas de desenvolvimento e de manuteno de um SI so, em grande parte,
devido m estruturao da modelagem das especificaes (dados e funes de um sistema).
Para atenuar estes problemas, vrios mtodos de desenvolvimento apiam esta modelagem,
como a modelagem CRC (Ambler, 1997). No entanto, esses mtodos falham por no
especificarem claramente como respeitar o princpio da independncia do dilogo humanocomputador, isto , como modelar a aplicao de forma independente da interface. O objetivo
deste princpio garantir, por exemplo, que uma funo da aplicao associada a um objeto
interativo no realize clculos relevantes aplicao e interface. Assim, se uma estrutura da
aplicao ou da interface for modificada somente os aspectos interativos ou no interativos
associados a esta estrutura respectivamente, devem ser modificados.
A utilizao de modelos de arquitetura auxilia desenvolvedores a respeitarem este princpio,
pois tais modelos permitem a organizao dos sistemas segundo um determinado padro. O
modelo de arquitetura PAC (Coutaz, 1994), oriundo de IHC, auxilia na estruturao de um SI
atravs de agentes, garantindo sua modularidade. A adoo de processos centrados na
arquitetura, como o RUP, favorece a utilizao destes tipos de modelos de arquitetura,
evidenciando oportunidades de integrao de IHC em ES.
Projeto centrado no usurio e Projeto centrado no uso
O projeto centrado no usurio enfatiza que o propsito do sistema atender as necessidades
do usurio atravs da participao. O PDS iterativo e dirigido pelas caractersticas do
usurio, suas tarefas e de seu contexto de uso, que so usadas para guiar o projeto de um SI.
Depois do projeto definido, os usurios avaliam o prottipo fornecendo sugestes. Este
princpio est descrito na ISO 13470.
O projeto centrado no uso representa uma mudana deste foco, pois no o usurio que
precisa ser conhecido, mas o uso que ele faz do SI que interage (Constantine & Lockwood,
____________________________________________________________________________

1999). Neste princpio, o envolvimento dos usurios seletivo, ou seja, existe a necessidade
de comunicao entre usurios e projetistas, que precisam entender os usurios para definirem
como acontecer o uso do sistema. Depois, os projetistas, e no os usurios, fazem a validao
dos modelos e a inspeo de usabilidade atravs da aplicao de mtricas de qualidade. O
PDS possui uma abordagem sistemtica, iterativa e dirigida por modelos.
A escolha entre estes princpios depende dos tipos de usurios em questo e da habilidade dos
projetistas de envolverem os usurios durante um PDS e/ou para modelarem um SI. Existem
problemas com relao participao do usurio (tais como: usurios podem no ser
conhecidos e/ou acessveis, eles podem ter dificuldade de comunicao com os projetistas,
etc.). Mas existem tambm dificuldades na aplicao do projeto centrado no uso. As mtricas
de qualidade devem ser baseadas em princpios ergonmicos, muitos projetistas no verificam
facilmente a aplicao destes princpios e preferem que os usurios, eles mesmos, testem o
prottipo.
Gerao de um SI baseada em modelos
Existem algumas formas de se gerar um SI, as quais destacam-se a gerao baseada em
cdigo e a gerao baseada em modelos. No primeiro caso, distinguem-se duas pocas. A
poca dos anos 70, em que um PDS era dirigido pela experincia e talento do desenvolvedor
tendo como foco a implementao, e a poca atual, em que se destacam os processos geis.
Num processo gil, como Extreme Programming - XP (Beck, 1999), se privilegia a fase de
projeto depois da realizao das fases de levantamento de requisitos, teste e codificao, onde
gerada uma verso ou prottipo do sistema. Enfim, primeiro se testa e valida com o cliente o
que foi levantado e depois se faz o projeto, verificando o que tem a ser acrescentado verso
anterior. No existe a prtica de realizar modelos.
Mesmo que existam na literatura, iniciativas bem sucedidas de processo gil, verifica-se que
elas no tm foco na usabilidade. O foco est na viso pragmtica de colaborao com
diversos stakeholders (equipe de desenvolvimento, cliente, usurio), a fim de atender as
necessidades do cliente dentro de prazos e oramento que vo se definindo medida que um
PDS vai sendo realizado. Fazer um projeto iterativo e incremental (ver prx. item), bem como
usar prottipos podem melhorar esta situao. Outra caracterstica que dificulta a adoo
desses processos diz respeito dificuldade de equipes, que no participaram da construo de
um SI, em suportarem a evoluo deste sistema, devido pouca especificao formal das
decises de projeto.
A adoo de modelos (como modelo de casos de uso e diagrama de colaborao) ajuda
desenvolvedores a representarem especificaes genricas (como as necessidades dos
usurios) e especificaes detalhadas (como a troca de mensagem entre objetos que
colaboram), respectivamente. Uma vez representadas as especificaes, possvel fazer a
integrao entre elas. No prximo item, sero mostrados os modelos de ES que podem ser
____________________________________________________________________________

integrados aos modelos de IHC, para a descrio de requisitos. Outra vantagem de se usar
modelos, a possibilidade de se fazer matrizes de rastreabilidade, auxiliando na realizao de
testes, implementao e manuteno de um SI. Existem na literatura de IHC vrias
ferramentas que geram interfaces de forma automtica a partir de modelos (tal como:
ARTStudio (Thevenin 2001)), porm ainda no existe nenhuma ferramenta comercial
disponvel. A ferramenta CASE ROSE permite a gerao de scripts de classes a partir dos
modelos de dados.
Processo iterativo, incremental e evolutivo
J consenso nas reas em estudo, que um PDS deve ser iterativo (com ciclos, compostos de
fases de um PDS, sendo realizados diversas vezes) e incremental (a cada ciclo, novas
funcionalidades so acrescidas verso anterior). Diante disto, estes tipos de modelos de
ciclos de vida (como espiral, cone (Furtado & Soares, 2003)) tm influenciado na descrio
de processos, como RUP e UPi (Sousa & Furtado, 2003) respectivamente.
Alm disto, os processos devem garantir a possibilidade de se realizar mudanas de forma
contnua, em tempo hbil e mantendo a coerncia com as outras decises j tomadas. Isto
porque existe atualmente uma necessidade para se assegurar continuamente a qualidade de um
SI j entregue ao cliente, devido s mudanas tecnolgicas e do contexto organizacional e
devido evoluo das necessidades do usurio. A evoluo das necessidades do usurio
(como uma mudana de prtica e mtodo de trabalho) pode envolver modificaes das
caractersticas do sistema, como por exemplo, de decises de projeto.
No prximo item, sero mostradas iniciativas que integram artefatos e tcnicas de IHC e ES
durante somente as atividades de modelagem e de validao de requisitos para gerar
interfaces. Esta restrio se deu devido s limitaes de tamanho deste artigo.
3.2.

Uma reflexo sobre a integrao de IHC e ES para gerar interfaces considerando


requisitos funcionais

3.2.1. Definio de Requisitos Funcionais


Durante o levantamento de requisitos, as necessidades dos usurios so levantadas (como suas
razes para requerer o projeto). Em seguida, elas so associadas a um ou mais requisitos, os
quais se referem a fatores, que especificam o que ser o produto desejado (de acordo com um
requisito de usabilidade, que especifica por exemplo que um SI tem que ser agradvel) e
como ele funcionar (de acordo com os requisitos funcionais). Estes requisitos funcionais
devem ser analisados e documentados usando diferentes tcnicas (modelagem de tarefas, de
casos de uso, etc.) e artefatos vindas de IHC e ES. A seguir, sero analisados os artefatos mais
usados e que so capazes de expressarem os objetivos do usurio e suas tarefas. So eles:
cenrios, storyboards, casos de uso e tarefas.
____________________________________________________________________________

cenrio, que se refere a uma narrativa que descreve situaes sobre as pessoas (seu
papel, caractersticas) realizando atividades dentro de um ambiente para
alcanarem seus objetivos. O uso de cenrios se trata de uma metfora facilmente
aceita pelos usurios que os encoraja a participar de um PDS. Assim, facilitando a
validao de suas necessidades;
storyboard, que um esquema ilustrativo para representar uma seqncia de
comportamentos de um sistema em desenvolvimento com uma descrio
contextual. Isto permite a explorao e discusso de diferentes escolhas de projeto
das interfaces conceituais (Furtado, 1999);
caso de uso; dentre as definies existentes em ES, destaca-se que um caso de uso
representa a funcionalidade que um SI tem que realizar para retornar um resultado
de valor para um ator (tais como: um usurio, ou outro sistema) e;
tarefa; na concepo de interfaces, uma tarefa especifica o conjunto de atividades
que o usurio e/ou o SI deve executar para que um determinado objetivo seja
alcanado. A estrutura organizacional hierrquica dos modelos de tarefa permite
acompanhar claramente a seqencialidade e concorrncia entre as tarefas.
3.2.2. Iniciativas que integram IHC e ES para gerar interfaces considerando requisitos
funcionais
Iniciativas existentes de gerao de interfaces considerando requisitos funcionais descrevem
formas diferentes de se usar cenrios, storyboards, casos de uso e tarefas. Estas formas dizem
respeito como estes artefatos so integrados, especificando que informaes de um so
mapeadas em outro artefato e em que atividades de um PDS eles so usados. A seguir, sero
descritas algumas iniciativas.
Sutcliffe (2002) descreve um mtodo para fazer a modelagem e validao de requisitos
baseada em cenrios. O objetivo desta fase identificar os requisitos com a participao do
usurio, numa abordagem de projeto centrado no usurio. Os requisitos identificados atravs
dos cenrios so discutidos e expressos em storyboards. O prximo passo analisar a
viabilidade dos requisitos de usabilidade fazendo um estudo sobre as opes de projeto
usando rvores de deciso. Em seguida, prottipos so usados para facilitar na validao dos
requisitos.
Numa abordagem centrada no uso, Constantine e seus colegas (2003) propem um mtodo
gil com o objetivo de gerar rapidamente a interface a partir de requisitos modelados em task
case ou caso de uso essencial Este conceito se refere, principalmente, a uma simplificao do
conceito de caso de uso, no que diz respeito descrio do fluxo de eventos. Nesta descrio,
expressas em cartes, devem constar, de forma sucinta, as intenes do usurio com as
____________________________________________________________________________

responsabilidades do sistema associadas. Uma vez validadas estas descries, usurios,


clientes e projetistas devem construir juntos um prottipo abstrato da interface (prottipos no
operacionais) usando post-id e um quadro branco. S ento os prottipos interativos so
construdos.
Suarez (2004) descreve um mtodo de desenvolvimento de SI baseado em modelos, em que o
objetivo gerar um prottipo abstrato da interface (modelo de interao) a partir de requisitos
modelados em tarefas, precedidos ou no por uma modelagem de caso de uso. Durante a
passagem de um modelo de tarefa para um modelo de interao, este trabalho faz uso do
conceito de cenrios, que so compostos de cenas, que por sua vez, so compostas de aes.
Atravs da modelagem de cenrios foi possvel para os autores organizarem as tarefas que
iro ser realizadas dentro de uma tela, por exemplo.
A partir desta anlise, percebeu-se que estes tipos de tcnicas e artefatos podem ser usados
atravs de diferentes combinaes, pois cada tcnica mais apropriada para um certo tipo de
modelagem. Como cenrios no so apropriados para capturarem todos os conjuntos de
requisitos, mas de oferecerem vises particulares de certas situaes, o uso de storyboard
poderia ser til, dada sua capacidade de explorar diferentes opes de projeto.
Embora casos de uso sejam focados nos objetivos de usurios, sua nfase est na interao
entre usurio e sistema antes que nas tarefas do usurio em si (Preece at al, 2002). Isto
porque eles contm certas especificaes sobre a interface e o tipo de interao para ser
projetado incluindo aspectos tecnolgicos. Casos de uso essenciais (Constantine and
Lockwood, 1999) tentam evitar estas especificaes, definindo somente que usurios so
responsveis (suas intenes) e o que o sistema tem que fazer. Representando casos de uso
genricos, estas especificaes poderiam ser expressas em modelos de tarefas, que so mais
estruturados.
A combinao entre estas tcnicas tambm importante porque inexiste uma mesma
terminologia envolvendo os conceitos usados nos artefatos das duas reas. Isto se deve em
parte devido dificuldade em integrar conceitos de IHC, que so embasados em diversas
disciplinas como a comunicao, ergonomia, com os modelos abstratos da ES, centrados na
implementao de um SI.
A reflexo realizada foi limitada modelagem de requisitos, mas so necessrias ainda outras
iniciativas para se refletir sobre alternativas para elaborar todo um processo integrado de
desenvolvimento de sistemas interativos. Enquanto isto, a autora deste artigo concorda com a
seguinte afirmao de Sutcliffe (2002): o sucesso de um SI depende da complexa relao
entre os requisitos modelados sendo validados no projeto, requisitos estes que podem evoluir,
e o grau de satisfao do usurio em adquirir o produto desejado.

____________________________________________________________________________

4. Concluso
Este artigo objetivou iniciar uma discusso sobre a qualidade na Engenharia de Software e na
Interao Humano-Computador considerando os conceitos, princpios, tcnicas e artefatos
usados em cada rea. Mostrou-se que a integrao destas reas vem acontecendo, mesmo que
ainda de forma to restrita, devido falta de ferramentas e de envolvimento entre as equipes,
s formas diferentes de se modelar informaes, no convergncia de princpios, etc.
Props-se que iniciativas sejam realizadas para se pensar sobre um PDS totalmente integrado.
Estas iniciativas poderiam se manifestar de diversas formas, como atravs de workshops e de
artigos cientficos publicados, havendo a apresentao de exemplos prticos e com resultados
concretos para a qualidade e usabilidade, bem como o envolvimento de empresas e da
academia
Estas iniciativas poderiam ajudar desenvolvedores a tirarem suas prprias concluses, em
funo das especificidades de cada projeto a ser desenvolvido, sobre as seguintes questes:
Que tipos de modelos e tcnicas de IHC e ES podem ser considerados num processo
integrado de desenvolvimento de software? Quando e como pode ser realizada esta
integrao? Como esta integrao pode contribuir para se obter softwares mais usveis e um
processo com mais qualidade? Quais so as vantagens e desvantagens deste processo
integrado de desenvolvimento de software? Como fazer com que os envolvidos (analistas,
ergonmos, web designers) participem mais e integrem suas atividades?
Referncias Bibliogrficas
Ambler, S.W. (1997). Anlise e projeto Orientados a objeto. IBPI Press.
BECK, K. C. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley
Pub Co; 1st edition.
Boehm, B.W. (1988). A spiral model of software development and enhancement. IEEE
Computer, 21(5).
Boggs W., (1999). Mastering UML with rational Rose, Sybex.
Constantine L., Windls, H., Nolbe, J., Lockwood. L. (2003). From abstraction to realization
in User Interface Designs: Abstract Prototype Based on Canonical Abstract Components.
Working paper on Tutorial Usage-centered Software Engineering. ICSE03. Portland.
Oregon.
Coutaz J., (1994). A reference model for the software design of interactive systems.
Ferre X., (2003). Integration of Usability Techniques into the Software Development Process.
In ICSE03 (International Conference on Software Engineering). Portland, Oregon. May.
Furtado, E., Barbosa S., (2003). Reflexo sobre a Integrao de Modelos, Tcnicas e Mtodos
de IHC e ES em um Processo de Desenvolvimento de Software. In WIHC-ES2003.

____________________________________________________________________________

Furtado, E., Soares, S. K., (2003). Furtado, Elizabeth; Sousa, Kenia. A User Interface
Generation Process Based on the RUP and Represented in a New Spatial Organization.
Available in: <http://ead.unifor.br>. Accessed in: October 15, 2003.
Gamma et al, (1995). Gamma, E; Helm, R; Johnson, R; Vlissides, J. Design Patterns
Elements of Reusable Object-Oriented Software. London: Addison-Wesley, 1995.
Hix D., Hartson, R. (1993). Developing User Interfaces. Wiley.
Kruchten, P. (2000). The Rational Unified Process: An Introduction. 2 ed. New Jersey:
Addison-Wesley,
Mayhew D.J. (1999). The usability engineering lifecycle. San Francisco: Morgan Kaufmann.
Paula, M. Barbosa, S.D. J., (2003). Interaction Modeling as a Resource for Software
Specification. In WIHC-ES2003. Rio de janeiro. Agosto.
Pimenta, M.S. Vedoato R., (2003). Use cases and Scenarios: a teleological approach aiming
the integration of HCI and SE perspectives. In WIHC-ES2003. Rio de janeiro. Agosto.
Preece J., Interaction Design: Beyond Human-computer interaction. 2002.
Pribeanu, Costin; Vanderdonckt, Jean. A Pattern-Based Approach to User Interface
Development. In: Proc. Of 9th Conf. On Human-Computer Interaction HCI International
2003, Vol. 4, Lawrence Erlbaum Associates, 2003, pp. 1524-1528.
Rocha H. V., Baranauskas, C., (2003). Design e Avaliao de Interfaces HumanoComputador. Unicamp SP.
Royce, W.W. (1970). Managing the development of lage software systems: concepts and
tecnhiques. Proc. IEEE Weston, Los Angeles, CA.
Silva J., Olher M., Jnior, S. (2003). Virtual reality and Reengineering: Challenges for the
software process based on a single vision of SE and HCI. In WIHC-ES2003. Rio de janeiro.
Agosto.
Soares, S. K., Furtado, E.. (2003). A Unified Process for Interactive Systems. In WIHCES2003. Rio de janeiro. Agosto.
Sommerville I.,(2003). Engenharia de Software, 6 edio. Addison Wesley.
Suarez P. R. (2004). Gesto do conhecimento no processo de concepo de IHC e uma nova
abordagem para a obteno de uma especificao conceitual da interao. Dissertao de
mestrado. UFCg.
Sutcliffe, A, (2002). User-Centred requirements engineering. Theory and Practice. SpringerVerlag. London.
Thevenin D. (2001). Adaptation en Interaction Homme-machine: le cas de la plasticit. Phd
Thesis of the University Joseph-Foureier Grenoble I.
Vanderdonckt J., (1999). Developing Milestones toward a Tool For Working With
Guidelines. Interacting with Computers 12, 2. (pp 81-118).

____________________________________________________________________________

Potrebbero piacerti anche