Sumrio

1) Introduo..............................................................................2
2) Mtodos Clssicos..................................................................3
2.1 Modelo cascata..................................................................................... 3
2.2 Modelo espiral....................................................................................... 5
3) Mtodos Especficos................................................................7
3.1 Modelo Estrela de Hix e Hartson...........................................................7
3.2 Modelo de Shneiderman.......................................................................8
4) Concluso...............................................................................9
5) Referncias Bibliogrficas.....................................................10

1) Introduo
A Interao Humano-Computador tem como base as metodologias de
desenvolvimento de Interfaces, que so estratgias de desenvolvimento que abrem
caminhos a serem explorados e executados pelos desenvolvedores, a fim de obterem
resultados positivos quanto interao da mquina com o usurio.
Portanto, apresentaremos as quatro metodologias, sendo duas consideradas
clssicas, que so os modelos em cascata e modelo espiral, que so mais designadas
engenharia de software (sem se preocupar diretamente com a interface) e duas
metodologias especficas, diretamente relacionadas com interfaces, que so o Modelo
Estrela de Hix e Hartson e o modelo proposto por Shneiderman.

2) Mtodos Clssicos
2.1 Modelo Cascata
O Modelo Cascata (waterfall) tornou-se conhecido na dcada de 70 e
referenciado na maioria dos livros de engenharia de software ou manuais de padres de
software. Nele as atividades do processo de desenvolvimento so estruturadas como em
uma cascata, onde a sada de uma atividade atua como entrada para a prxima.
Pressman (1995), relaciona os itens (todos a partir da Engenharia de Sistemas) a seguir
de acordo com o seu modelo:

Estudo de viabilidade - Anlise.

Anlise e especificao de requisitos Anlise/Projeto.
Design da arquitetura - Projeto.
Design detalhado - Projeto.
Codificao e testes de unidades - Codificao.
Integrao e teste do sistema - Teste.
Entrega e instalao - Manuteno.
Manuteno.
Modelo Cascata apresentado por Pressman(1995):

Este modelo, quando proposto, introduziu importantes qualidades ao

desenvolvimento. A primeira chama a ateno de que o processo de desenvolvimento
deve ser conduzido de forma disciplinada, com atividades claramente definidas,
determinada a partir de um planejamento e sujeitas a gerenciamento durante a
realizao.
Outra qualidade define de maneira clara quais so estas atividades e quais os
requisitos para desempenh-las. Por fim, o modelo introduz a separao das atividades
da definio e design da atividade de programao que era o centro das atenes no
desenvolvimento de software.
O modelo Cascata tambm criticado por ser linear, rgido e monoltico.
Inspirados em modelos de outras atividades de engenharia, este modelo argumenta que
cada atividade apenas deve ser iniciada quando a outra estiver terminada e verificada.
Ele considerado monoltico por no introduzir a participao de clientes e usurio
durante as atividades do desenvolvimento, mas apenas o software ter sido implementado
e entregue. No existe como o cliente verificar antecipadamente qual o produto final
para detectar eventuais problemas, fazendo deste mtodo apenas uma referncia de
como situar o desenvolvedor desenvolver o software com escassa interface de
satisfao do usurio final.

2.2 Modelo Espiral

O modelo espiral para a engenharia de software foi desenvolvido para
abranger as melhores caractersticas tanto do ciclo de vida clssico como da
prototipao, acrescentando, ao mesmo tempo, um novo elemento a anlise de riscos
que falta a esses paradigmas (Pressman, 1995). Este modelo no foi o primeiro
modelo para discutir o desenvolvimento iterativo (atravs da repetio de aes), mas
foi o primeiro modelo a explicar por que as iteraes so importantes (melhor
eficincia, maior familiaridade com o funcionamento do sistema, facilidade de
aprendizado, etc).
Modelo proposto por Pressman (1995) :

A abordagem em espiral implementa os sistemas baseado no conceito de maior

necessidade. Ela entrega o sistema em verses. Os quatro quadrantes do modelo podem
ser classificados por:
Planejamento: determinao dos objetivos, alternativas e restries;
Anlise de riscos: anlise de alternativas e identificao/resoluo dos
problemas;
Engenharia: desenvolvimento;
Avaliao feita pelo cliente;
5

O Planejamento baseado totalmente no levamentamento dos resultados obtidos

nas conversas com o usurio final, at o seu feito final. Com isso, feito a Anlise dos
Riscos baseada na reao do cliente e, ento, o desenvolvimento dos prottipos do
softwares so feitos em cima dos comentrios. Por fim, o cliente avalia a engenharia
feita para que ento volte no Planejamento e, assim, repete o ciclo.
Os partidrios da abordagem em espiral frequentemente usam um conceito de
time-box (caixa de tempo) para regular o desenvolvimento. Um time-box um perodo
determinado, frequentemente, de trs meses, dentro do qual os desenvolvedores devem
completar cada verso. No h especificaes de produtos, porque satisfazer a estas
especificaes pode ser impossvel dentro do tempo permitido. Em vez disso, os
desenvolvedores agregam caractersticas pela ordem de prioridade at que o tempo se
esgote. Ento eles liberam a nova verso.
Uma alternativa para o time-box envolve o planejamento de cada verso, tanto
quanto possvel, no comeo do projeto. De fato, isto divide o projeto em subprojetos
menores, cada um administrado mais facilmente do que o projeto principal e cada um
fornecendo um produto em funcionamento e pronto para a entrega. Ao final de cada
projeto, os subprojetos restantes so redefinidos considerando o feedback do usurio.
A abordagem em espiral entrega o produto rapidamente. No h documentao
trabalhosa das especificaes, porque os usurios podem revisar o produto em verses
posteriores. Os usurios podem ver o progresso e julgar quanto tempo passar at que o
sistema em desenvolvimento satisfaa suficientemente suas necessidades para que possa
substituir o sistema existente.

3) Mtodos Especficos
3.1 Modelo Estrela de Hix e Hartson
O modelo de vida estrela uma proposta que no especifica um ordenamento
das atividades, mas sua flexibilidade exige que uma avaliao sempre seja feita antes de
iniciar uma nova atividade. Este modelo surgiu das observaes de Hartson e Hix que
verificaram que dois processos eram utilizados por designers de interface como modelos
de ciclo de vida.
O Analtico, com caracterstica de organizao, formalidade e com uma viso
que partia do sistema para a viso do usurio e o Sinttico caracterizado pela
criatividade, livre pensamento e improviso com a viso que partia do usurio para a do
sistema.
Este modelo inclui a implementao e a anlise de tarefas. As outras atividades
vo de encontro com as atividades bsicas dos projetos de interao: 1) necessidade e
requisitos, 2) verses alternativas (projeto conceitual), 3) prottipos e avaliao.

Fig.3 - Esquema do desenvolvimento baseado no mod estrela (BARANAUSKAS,2003)

A figura acima ilustra o modelo estrela, na qual conseguimos identificar que no
h uma ordem de execuo dos processos, ou seja, o desenvolvimento pode comear em
qualquer etapa do modelo, ao final de cada etapa realizada a avaliao e a partir desta
seleciona-se a prxima etapa, o desenvolvimento muito iterativo e flexvel.
Os processos so parecidos com o modelo cascata apresentado, porm h mais
centralizao na avaliao e mais flexibilidade.
7

3.2 Modelo de Shneiderman

O Modelo de Shneiderman baseado em 3 pilares:
1. No incio do processo, o designer deve gerar um conjunto de guidelines.
2. O segundo pilar composto de ferramentas de prototipagem.
3. O terceiro pilar dedicado a testes de usabilidade (avaliao com experts e
testes com usurios).

1. Guidelines: gerado um conjunto de guidelines pelo designer no incio do

processo. As guidelines so mtodos que orientam o designer na tomada de decises
consistentes atravs dos elementos que constituem o produto, e devem ser entendidas e
aplicadas de forma contextualizada, ou seja, aplicveis.
2. Ferramentas de prototipagem: Momento em que o designer cria o prottipo
do sistema, como ele deve ser, e submete a aprovao do usurio ou grupo de usurios
finais, sendo que o ideal que esses prottipos sejam feitos rapidamente, para
economizar no tempo e no custo, provendo feedback imediato.
3. Inspeo de usabilidade: O terceiro pilar do modelo de Shneiderman que
trata da inspeo de usabilidade, a fase onde o designer verifica a consistncia do
sistema, no que diz respeito a falhas, atravs de um conjunto de massa de testes, etc.

4) Concluso
Antes de dar incio ao desenvolvimento de um software, se faz necessria a
deciso de qual mtodo deve ser utilizado durante o desenvolvimento levando em
considerao as caractersticas de cada modelo de acordo com as necessidades do
projeto.
A metodologia cascata a nica entre todas apresentadas que tem como foco
principal o desenvolvimento baseado em prototipao da aplicao, ou seja, no design
do sistema. Todas as outras metodologias apresentadas tem como foco principal a
prototipao, que facilita a identificao de erros, reduz o retrabalho e traz a anlise do
cliente para o desenvolvimento do projeto, melhorando a identificao de erros de
requisitos.
Independente de qual seja a metodologia adotada para o desenvolvimento do
software, o projeto ganha inmeras chances de ter um resultado melhor do que um
simples desenvolvimento sem o uso de metodologias. A abordagem feita pelas
metodologias e a padronizao no desenvolvimento do projeto garantem um bom
resultado e diminuio nos prejuzo e um projeto que atender ao mximo o que foi
desejado pelo cliente.

10

5) Referncias Bibliogrficas
BARANAUSKAS, Maria Cecilia Calani, ROCHA, Helosa Vieira. Design e Avaliao
de Interfaces Humano-Computador, Campinas: NIED/Unicamp, 2003

HARTSON, Rex. HIX, Deborah. Introduction to human-computer interaction,

Virginia-Tech, 1999.

PRESSMAN, Roger S. Engenharia de Software, 3 Edio. So Paulo: Pearson

Education do Brasil, 1995.

SHNEIDERMAN, Ben. Designing the User Interface: Strategies for effective

human-computer interaction: Addison-Wesley, 1998.

11