Faculdade de Tecnologia de Sorocaba

Tecnologia em Análise e Desenvolvimento de Sistemas

INTERAÇÃO HUMANO-COMPUTADOR: MODELOS PARA O

DESENVOLVIMENTO DE INTERFACES

ATIVIDADE 8

Prof.º Sergio Moraes

Disciplina: Interação Humano-Computador

Bruno Felipe Do Amaral Gurgel 0030482023041

Douglas Patrick Santos 0030482023009
Mayara Sabrina Dos Santos 0030482123009

Sorocaba
OUTUBRO/2021

1
SUMÁRIO

1. Introdução....................................................................................... 3
2. Definição......................................................................................... 4
2.1 Modelos Clássicos............................................................ 5
2.2 Modelo Cascata................................................................... 5
2.3 Modelo Espiral.................................................................... 5
3. Métodos Específicos.................................................................... 12
3.1 Modelo Estrela de Hix e Hartson....................................... 12
3.2 Modelo de Shneiderman.................................................... 14
4. Conclusão....................................................................................... 16
5. Referências...................................................................................... 17

2
 1. Introdução

Neste módulo abordamos modelos para o desenvolvimento de interfaces, entres

eles dois modelos clássicos, o Modelo Cascata e o Modelo Espiral, e os modelos
mais específicos, o Modelo estrela de Hix e Hartson e o modelo proposto por
Shneiderman, todos eles tem como objetivo utilizar uma metodologia para organizar
atividades, ações e tarefas necessárias para desenvolver um software , assim
criando um roteiro que ajudará na criação de um produto de alta qualidade e dentro
do prazo estabelecido.

3
 2. Definição

Ao fornecer um serviço ou quando se cria um produto, seja desenvolvendo um

software, escrevendo um relatório ou fazendo uma viagem de negócios, é seguido
uma sequência de etapas para completar um conjunto de tarefas. Elas são
realizadas de maneira assíncrona e repetitiva sempre, por exemplo: não se reboca
uma parede sem antes colocar a tubulação necessária; não se assa um bolo sem
antes misturar todos os ingredientes, ou seja, este conjunto de tarefas pode ser
considerado um processo: uma série de etapas que envolvem atividades, restrições
e recursos para alcançar a saída desejada (Pfleeger 2004).

Embora não exista um processo de software ideal, existe espaço para o

aprimoramento (Sommervile 2007). Devido à crescente demanda por softwares de
qualidade, cada vez mais processos de desenvolvimento de software eficazes
tornam se necessários. Portanto é imprescindível que o desenvolvimento e
aprimoramento de processos de software evoluam constantemente de forma
a atender as necessidades atuais, bem como sirvam como uma carcaça de
conhecimentos para a elaboração de novos processos e metodologias de
desenvolvimento de software, mais eficientes e adaptáveis. Efetivamente, a
elaboração de software de computador é um processo de aprendizado, e o
resultado, é a incorporação de conhecimentos coletados, destilados e
organizados à medida que o processo é conduzido. Processo é o alicerce da
engenharia de software. É ele que permite o desenvolvimento racional e
oportuno de softwares de computador (Pressman 2006).

4
 2.1 Modelos Clássicos

Os Modelos Clássicos São os modelos mais conhecidos para esmiuçar a tentativa

de por em ordem todo o processo caótico de criação de um software ou sistema,
onde o método adotado é separado em pequenas partes para que possam ser
melhor administrados, resolvidos e explicados ao ponto de uma melhor
compreensão e correção se necessário.

Um modelo de processo de software é uma representação abstrata de um processo

de software. Cada modelo de processo representa um processo a partir de uma
perspectiva particular, de uma maneira que proporciona apenas informações
parciais sobre o processo (SOMMERVILLE 1995).

2.2 Modelo Cascata

O modelo clássico ou cascata, que também é conhecido por abordagem “top down”,
foi proposto por Royce em 1970.

É um dos mais importantes modelos e é referência para muitos outros modelos,

servindo de base para muitos projetos modernos, ele parte do princípio de etapas a
serem seguidas nas quais o próximo passo é dependente do anterior, onde uma
fase deve ser terminada para a outra começar, na primeira vez que uma fase de
desenvolvimento é completada, o desenvolvimento prossegue para a próxima fase e
não há retorno.

A vantagem do desenvolvimento cascata é que ele permite controle departamental e

gerencial. Um planejamento pode ser atribuído com prazo final para cada estágio de
desenvolvimento e um produto pode prosseguir no processo de desenvolvimento,
teoricamente ser entregue no prazo. O desenvolvimento move do conceito, através
do projeto (design), implementação, teste, instalação, descoberta de defeitos e
termina com a operação e manutenção. Cada fase de desenvolvimento prossegue
em uma ordem estrita, sem qualquer sobreposição ou passos iterativos.
(PRESSMAN, 2006)

5
Peters (2001) aponta vantagens e desvantagens: Vantagens: Permitir a gerência do
baseline, que identifica um conjunto fixo de documentos produzidos como resultado
de cada fase do ciclo de vida. Desvantagens: não é capaz de estabelecer como
efetuar engenharia reversa de um sistema existente e faltam noções de prototipação
rápida e desenvolvimento incremental.

Pressman (1995) aponta alguns problemas identificados neste ciclo de vida:

• Os projetos reais raramente seguem o fluxo sequencial que o modelo

propõe. Alguma iteração sempre ocorre e traz problemas na aplicação do
paradigma.

• Muitas vezes é difícil para o cliente declarar todas as exigências

explicitamente. O ciclo de vida clássico exige isso e tem dificuldade de
acomodar a incerteza natural que existe no começo de muitos projetos

• O cliente deve ter paciência. Uma versão de trabalho dos programas não
estará disponível até um ponto tardio do cronograma do projeto. Um erro
crasso, se não for detectado até que o programa de trabalho seja revisto,
pode ser desastroso. Peters (2001) aponta vantagens e desvantagens:
Vantagens: Permitir a gerência do baseline, que identifica um conjunto fixo de
documentos produzidos como resultado de cada fase do ciclo de vida.
Desvantagens: não é capaz de estabelecer como efetuar engenharia reversa
de um sistema existente e faltam noções de prototipação rápida e
desenvolvimento incremental.

A desvantagem do desenvolvimento em cascata é que ele não permite muita

flexibilidade ou revisão. A primeira vez que uma aplicação está em estágio de
teste é muito difícil retornar e mudar alguma coisa que não foi bem pensada
no estágio conceitual.

6
Figura 1. MODELO DE PROCESSO CASCATA

Depois de aplicado o método (Modelo) ele passa por um processo de

prototipação assim como todos os outros, A abordagem de prototipação tem um
número de vantagens importante a oferecer.

• Primeira os requisitos de sistema não têm que ser completamente

determinados antecipadamente e pode mesmo ser trocada durante o
curso do projeto.

• Segundo a entrega de prototipação clara, definições de sistema entendível

e especificações para o usuário final.

Como consequência, o envolvimento e satisfação do usuário final são fortemente

aumentados. Finalmente, prototipação faz isso possível para rapidamente testar
o ambiente de desenvolvimento voltado para a funcionalidade, performance,
interface com banco de dados, etc. (IBM, 2002).

7
 2.3 Modelo Espiral

O modelo Espiral foi desenvolvido por Barry Boehm em 986 em seu artigo “Um
Modelo Espiral de Desenvolvimento de Software e Valorização”. Este modelo
não foi o primeiro modelo para discutir o desenvolvimento interativo, mas foi o
primeiro a explicar a importância das interações, onde abrange as melhores
características tanto no ciclo de vida clássico como na prototipação. O modelo define
quatro importantes atividades representadas por quatro quadrantes:
• Planejamento: determinação dos objetivos, alternativas e restrições.
• Análise de riscos: análise de alternativas e identificação/resolução de riscos.
• Engenharia: desenvolvimento do produto no “nível seguinte”.
• Atualização feita pelo cliente: avaliação dos resultados da engenharia.

Ele usa uma abordagem “evolucionária” à engenharia de software, capacitando o

desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O
modelo espiral usa a prototipação como um mecanismo de redução de riscos, mas,
o que é mais importante, possibilita que o desenvolvedor aplique a abordagem de
prototipação em qualquer etapa da evolução do produto. Ele mantém a abordagem
de passos sistemáticos sugerida pelo ciclo de vida clássico, mas incorpora-a numa
estrutura iterativa que reflete mais realisticamente o mundo real. O modelo espiral
exige uma consideração direta dos riscos técnicos em todas as etapas do projeto e,
se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem
problemáticos (Pressman, 2006).

O modelo em espiral parte do princípio de que a forma do desenvolvimento de

software não pode ser completamente determinada de antemão. (Pressman, 2006).
A prototipação é vista como um meio de redução de riscos, a permitir que se
descubram os problemas potenciais antes de se comprometer com um sistema
completo. O modelo caracteriza-se como um gerador de modelo de processo. Cada
ciclo do modelo em espiral possui quatro atividades principais:

8
1. Definição de objetivos: onde são definidos os objetivos para essa fase

do projeto, identificando as restrições e preparando um plano de

gerenciamento detalhado que inclui todos os possíveis riscos do projeto;

2. Avaliação e redução de riscos: para cada risco identificado é feita uma

“Análise de Risco” detalhada com o objetivo de identificar estratégias para

reduzi-lo ou evitá-lo. Por exemplo, caso exista uma dificuldade em

especificar claramente um requisito, isso significa que existe um “risco de

requisitos inadequados” e para amenizá-lo será preciso desenvolver um

protótipo para apresentar ao cliente a fim de colher sugestões para refinar

os requisitos. (Um protótipo é uma simulação do sistema, podendo ser

desenhado em papel ou programado de forma simples e não funcional

para que o cliente tenha uma ideia melhor do que o engenheiro entendeu

de seus requisitos. Mais informações sobre prototipagem será fornecida

em um artigo exclusivo sobre Interface Humano-Computador);

3. Implementação e validação: com as estratégias definidas, é escolhido

um modelo de desenvolvimento, como por exemplo, o “Modelo em

Cascata”, “Modelo Incremental”, etc. Pode-se utilizar modelos diferentes

em cada volta de implementação, conforme a necessidade;

4. Planejamento e Especificação: o projeto todo é analisado para verificar

o que foi realizado e planejar quais serão os próximos passos para iniciar

novas voltas do espiral ou concluir o sistema.

9
Figura 2. MODELO EM ESPIRAL E AS FASES DO PROCESSO

Diferente do Modelo Incremental, que entrega partes prontas uma de cada vez,
o Modelo Espiral é mais iterativo e tenta fazer sucessivos refinamentos. Outras
novidades são os novos conceitos de Prototipagem e Gerenciamento de
Riscos.

10
Figura 2.1 MODELO EM ESPIRAL PROCESSO INTEIRO

• Como o modelo exige a consideração dos riscos técnicos em todos os

estágios de evolução, se for aplicado adequadamente, reduzirá os riscos
antes que se tornem problemáticos;

• As estimativas se tornam mais realistas e o tempo de implementação é

reduzido;

• Mais versátil para testar e lidar com mudanças;

• Não faz distinção entre desenvolvimento e manutenção.

11
 3. Métodos Específicos

Elaborados para terem um processo fixado em um ciclo de vida bem

desenvolvido e definidos para as atividades de usabilidade. Mayhew (1999) e
Hix e Hartson (1993) construiu esses modelos de usabilidade para
correlacionar um conjunto de atividade e como elas se ligam entre si.

Desta forma o estudo de relações entre as atividades de usabilidade, torna

um processo de usabilidade mais dinâmico, obtendo um processo mais
comunicativo, pois há um conexão onde pode-se ir e voltar de uma tarefa
para outra sem que as partes se interrompam.

3.1 Modelo Estrela de Hix e Hartson

As avaliações devem constantemente serem feitas durante todo o ciclo de

avaliação de design esperando os resultados e a partir desses pontos fazer uma
evolução gradativa. O modelo Estrela derivou do trabalho empírico de entender os
problemas causados pelos design de Interação Humano Computador, dessa forma
são observados dois pontos importantes, o analítico – tem uma visão do sistema
para a visão do usuário – e o sintético – tem uma visão do usuário para a visão do
sistema.

No Modelo Estrela, não tem uma sequência para ser seguida, as atividade e os
desenvolvimentos podem ir de um campo para o outro desde que passe pela fase
de uma avaliação dos fatos, posteriormente continuar a desenvolver outro campo:

12
 Proposto por Hix e Hareton em 1989, esse modelo nos dá a abertura para as
diferentes ligações de uma tarefa a outra bem como seu desenvolvimento ligando as
interfaces, design de uma forma em conjunto ou sendo mesmo partes especificas.

Pode-se dizer que neste modelo não é elaborado um roteiro de atividade para
ser seguido. Qualquer parte do processo pode ser estudado a qualquer momento
sem dependência exclusivamente do outro, para isso é obrigatório ter um processo
de avaliação antes de iniciar o estudo ou retomar o estudo de outra atividade.

Para Mayhew (1999) oferece uma descrição detalhada para o estudo dos testes
da engenharia da usabilidade, a primeira parte são as análises de requisitos.

• Análise do perfil do usuário: Os projetistas devem conhecer os atributos

pessoais e suas habilidades para cada tipo de usuário identificado.

• Análise do contexto da tarefa: Os projetistas devem conhecer os objetivos

e resultados, a estrutura, duração, custos e etc. de cada tarefa a ser
realizada.

• Análise das possibilidades e restrições da plataforma: Verificar quais são

as possibilidades e restrições em termos de equipamentos, sistemas
operacionais e etc.

13
 • Análise dos princípios gerais para o projeto: Atividade relacionada à
pesquisa e catalogação dos conhecimentos de ergonomia disponível para
a concepção da interface no tipo de contexto de uso.

A segunda parte é a especificação das metas de usabilidade para a elaboração

do futuro sistema. Os ciclos devem ter 3 níveis de uma interface, tendo herança da
etapa de projetos, testes e implementações. O 1 nível é a interface desenvolvida
conceitualmente. O 2 nível são as definições em termos de estilos da interface. O 3
nível interações e componentes estão relacionados com os contextos das tarefas
especiais.

A terceira parte refere-se à instalação do sistema bem como após o usuário tiver
um conhecimento da interface, dar o feedback para o processo de interface
elaborada.

3.2 Modelo de Shneiderman

O modelo de Shineiderman é baseado em 3 pilares

Modelo de desenvolvimento de interfaces proposto por Shneiderman é composto

por três colunas

14
 Primeiramente o designer deve gerar um conjunto de Guidelines. Depois é o
momento em que é criado o protótipo do sistema, como ele deve ser, e submete a
aprovação do usuário ou grupo de usuários finais, sendo que os protótipos
devem ser feitos rapidamente, para economizar no tempo e no custo, provendo
feedback o mais rápido possível.
E finalmente, o designer deve verificar a consistência do sistema, no que diz
respeito a falhas, através de um conjunto de massa de testes, etc.
Shneiderman (2005) também explica 8 regras de ouro para o desenvolvimento
de interfaces de qualidade.
• Mantenha a consistência
Sequências consistentes de ações devem ser usada em situações
similares. Use terminologia idêntica em prompts, menus e telas de ajuda.
Comandos devem ser utilizados da mesma maneira ao longo da interface.

• Ofereça atalhos aos usuários experientes

Ao mesmo tempo que a frequência de uso de uma interface aumenta, o
desejo do usuário é reduzir o número de interações e aumentar o
compasso da 9 interação. Abreviações, teclas de função, comando
ocultos e facilidades de macros ajudarão o usuário mais experiente.

• Ofereça feedbacks informativos

Para cada operação do usuário deve haver algum tipo de feedback do
sistema. Ofereça respostas discretas quando as ações são frequentes ou
de menor importância e respostas com maior prioridade para ações
incomuns ou mais importantes.

• Apresente as etapas do processo

Sequências de ações devem ser organizadas em grupos com início,
meio e fim. O feedback informativo ao completar um grupo de ações
dá ao usuário satisfação de realização, senso de distinção e uma
indicação que o caminho é claro para se preparar para o próximo conjunto
de ações.

15
• Ofereça uma forma simples de correção de erros
Tanto quanto possível, o design do sistema não deve permitir que o
usuário cometa erros graves. Se um erro for cometido, o sistema deve ser
capaz de detectar e oferecer um mecanismo simples e compreensível
para a solução.

• Permita fácil reversão de ações

Esta funcionalidade diminui a ansiedade, desde o momento que o usuário
toma conhecimento que um erro grave pode ser desfeito. Isso potencializa
a exploração de funções desconhecidas. As unidades de reversibilidade
podem ser de uma única ação, de uma entrada de dados ou uma
sequência completa de ações.

• O controle do sistema é do usuário

Usuários experientes desejam ter a noção de que controlam o sistema e
este é que responde aos seus comandos. O sistema deve ser projetado
para deixar os usuários como iniciadores das ações ao invés de
reagentes.
• Reduza a carga de memória curta do usuário
Este princípio está relacionado à limitação humana de processamento de
informação na memória de curta duração. O sistema deve ser projetado
para que haja o menor esforço possível do usuário em memorizar ou
relacionar elementos na interface.

16
4. Conclusão

Para se ganhar tempo e qualidade no desenvolvimento de interfaces, vimos

que existem modelos, ou seja, padrões que são discutidos por grandes nomes da
Engenharia de Software e da IHC, então sabemos que se adotarmos um padrão de
qualidade, resultaremos em um trabalho de qualidade, podemos adotar esses
princípios desde a fase em que estamos desenhando os fluxos, interfaces e
interações. Certamente o produto será muito mais eficiente ao cliente e, ao mesmo
tempo, poupará inúmeros ajustes que só seriam descobertos na fase de avaliação.

Modelos possui uma grande importância na hora do desenvolvimento,

principalmente quando falamos de interfaces, é importante ganharmos tempo, e
utilizando modelos (já prontos) e com eficiência comprovada, poderemos investir
preocupações em outros aspectos e lugares. Existem inúmeros tipos de modelos,
desde os clássicos como cascata e espiral, discutido por Pressman (2006) e
Sumerville (2007), mas também temos outros modelos específicos, como é o
exemplo do modelo proposto por Hix e Hartson (1993) e também o modelo de
Shneiderman (2005), todos possuem seus aspectos positivos e suas situações
específicas para implementação.

17
5.Referências:

https://fga.unb.br/articles/0000/7823/TCC2_Jonatas_Rodrigo_final.pdf

SHNEIDERMAN, Ben; PLAISANT, Catherine. Projetando a interface do usuário:

estratégias para uma interação humano-computador eficaz. 4ª ed. Universidade de
Mariland, College Park: Pearson Education, Inc, 2005

SOMMERVILLE, I. Software Engineering (International Computer Science Series).

5a Edição. Reading: Addison-Wesley, 1995.

PRESSMAN, ROGER S., Engenharia de Software- (6ª edição), São Paulo, Ed.
McGrawHill, 2006.

PRESSMAN, ROGER S., Engenharia de Software- (3ª edição), São Paulo, Ed.
Makron Books, 1995.

PETERS, JAMES F., Engenharia de Software: Teoria e Prática, Rio de Janeiro,

Editora Campus, 2001.

IBM; Practicing Object-Oriented Analysis and Design- ERC2.2.; IBM Education and
Training; 2002L.

18