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

JEREMIAS PEREIRA 0030481311023

RENAN PONTES 0030481311033

Sorocaba

Abril/2014

Sumário1. Introdução.....................................................................................................1

2. Definição.......................................................................................................2

2.1. Modelos Clássicos.................................................................................2

2.1.1. Modelo Cascata...............................................................................2

2.1.2. Modelo Espiral.................................................................................4

2.2. Modelos Específicos..............................................................................5

2.2.1. Modelo Estrela.................................................................................5

2.2.2. Modelo de Shneiderman..................................................................6

3. Conclusão...................................................................................................10

4. Referências Bibliográficas..........................................................................11

1. Introdução

Esse trabalho visa a abordagem de modelos de processos para

desenvolvimento de interfaces de softwares, modelos de desenvolvimento é

discutido na matéria de Engenharia de Software, porém é aplicado durante o

desenvolvimento do software e principalmente na IHC, quando se está

desenvolvendo interfaces. Neste trabalho será discutido o que é um “modelo”

de processos de desenvolvimento, como grandes nomes da área como

Pressman, Hix e Hartson e Shneiderman definem um modelo de

desenvolvimento. Também será citados modelos e discutido em quais ocasiões

devem ser adotados, o que devemos analisar na hora de tomarmos tal decisão,

etc.

3

2. Definição

Quando se fornece um serviço ou cria-se um produto, seja desenvolvendo um

software, escrevendo um relatório ou fazendo uma viagem de negócios, segue-

se costumeiramente uma sequência de etapas para completar um conjunto de

tarefas. Estas são realizadas na mesma ordem todas às vezes, 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. Esse conjunto de

tarefas ordenadas 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). Essa é a definição de modelo de processo que Pfleeger diz

em seu livro.

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.

Em vista disto, é imprescindível que o desenvolvimento e aprimoramento de

processos de software evoluam constantemente de forma a atender as

necessidades atuais, bem como sirvam como um arcabouço 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)

2.1. Modelos Clássicos2.1.1. Modelo Cascata

O modelo clássico ou cascata, que também é conhecido por abordagem “top-

down”, foi proposto por Royce em 1970. Até meados da década de 1980 foi o

único modelo com aceitação geral. Esse modelo foi derivado de modelos de

atividade de engenharia com o fim de estabelecer ordem no desenvolvimento

4

de grandes produtos de software. Comparado com outros modelos de

desenvolvimento de software, este é mais rígido e menos administrativo.

O modelo cascata (Figura 1) é um dos mais importantes modelos, e é

referência para muitos outros modelos, servindo de base para muitos projetos

modernos. A versão original deste modelo foi melhorada e retocada ao longo

do tempo e continua sendo muito utilizado hoje em dia. Grande parte do

sucesso do modelo cascata está no facto dele ser orientado para

documentação. No entanto deve salientar-se que a documentação abrange

mais do que arquivo de texto, abrange representações gráficas ou mesmo

simulação.

Uma abordagem incorporando processos, métodos e ferramentas deve ser

utilizada pelos criadores de software. Esta abordagem é muitas vezes

designada de Abordagem do Processo de Desenvolvimento. Existem três

abordagens de modelos de processo de desenvolvimento de software.

Cascata pura

Incremental

Evolucionário

Figura 1- paradigma do ciclo de vida clássico da Engenharia de Software1

Os modelos genéricos de processos de software amplamente utilizados

atualmente são o modelo em cascata, o modelo de desenvolvimento

1 Disponível em <http://centraldaengenharia.wordpress.com/2011/02/08/paradigmas-modelo-cascat/>

5

evolucionário e o modelo de desenvolvimento baseado em componentes.

Estes, não são mutuamente exclusivos e comumente são utilizados em

conjunto, especialmente para desenvolvimento de sistemas de grande porte

(Sommerville 2007).

2.1.2. Modelo Espiral

O modelo espiral foi desenvolvido por Barry Boehm em 1986 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 iterações.

Como podemos ver na Figura 2, as fases são semelhantes as existente no

modelo cascata e podem ser melhor compreendidas lendo o post referente a

esse outro processo.

Figura 2 - Modelo espiral e suas fases2

As iterações tinham tipicamente de 6 meses a 2 anos de duração. Cada fase

inicia com um objetivo esperado e termina com a análise do cliente, que avalia

o progresso até o momento. Análise e esforços de engenharia são aplicados

em cada fase do projeto, visando o objetivo final do projeto.

2.2. Modelos Específicos2 Disponível em <http://apdzdeti.blogspot.com.br/2011/02/modelo-espiral.html>

6

2.2.1. Modelo Estrela

O ciclo de vida em estrela (Hartson e Hix, 1989, 1993) é orientado

primeiramente pela demanda particular de desenvolver sistemas interativos

que sejam usáveis pelas pessoas.

O ênfase em prototipação rápida, metodologias alternadas analítica (top-down)

e sintética (botom-up), e avaliação é ao mesmo tempo centrada no usuário e

realista.

Tão importantes como o próprio processo de design são as representações do

sistema que são empregadas ao longo dele, (veja Figura 3).

Figura 3 - O CICLO DE VIDA ESTRELA (ADAPTADO DE HIX E HARTSON, 1993)

Para alguns propósitos, modelos tais como esboços, cenários, e protótipos

serão mais apropriados, enquanto para outros propósitos, notações formais

serão mais adequadas.

Diretrizes, regras práticas e checklists são úteis conjuntamente ao longo de

todo o processo, assim como os resultados oriundos da Engenharia Cognitiva

que orientam no sentido de produzir sistemas mais próximos do modelo mental

que o usuário tem dos mesmos.

O modelo em estrela sugere que a ordenação das atividades é inapropriada.

Esta conclusão derivou da vasta experiência de equipes de grandes centros de

P&D na área de IHC.

7

O modelo prega, principalmente, a necessidade de prototipação rápida e

avaliação, de forma mais visceral do que em qualquer outra abordagem.

A avaliação é central neste método. Todos os aspectos do desenvolvimento

estão sujeitos a constante avaliação por especialistas em IHC e pelos usuários.

O modelo em estrela também promove ondas alternadas de abordagem ao

projeto de sistemas. Enquanto a maioria das metodologias adotam a

abordagem top-down ou analítica, o modelo em estrela reconhece que esta

abordagem deve ser complementada pela abordagem inversa, ou bottom-up.

O modelo em estrela também destaca a importância da prototipação

incremental ao longo do desenvolvimento do produto. Embora os rótulos das

fases sejam diferentes, elas representam atividade semelhantes às do modelo

em cascata:

Análise (análise de tarefas / análise funcional);

Especificação de requisitos;

Design (conceitual e formal);

Implementação.

Mas o processo envolve muita mais iteração.

A prototipação e a avaliação são apresentadas como novas atividades, embora

elas possam fazer parte de qualquer um dos estágios.

2.2.2. Modelo de Shneiderman

O modelo de Shineiderman é baseado em 3 pilares como é mostrado na Figura

4:

8

Figura 4 - Modelo de desenvolvimento de interfaces proposto por Shneiderman é composto por três colunas

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. São elas:

I. Mantenha a consistência

Sequências consistentes de ações devem ser usadas 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.

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

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

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

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

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

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

VIII. Reduza a carga de memória curta do usuário

10

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.

11

3. Conclusão

Para ganharmos 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 diversos 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.

12

4. Referências Bibliográficas

SHNEIDERMAN, Ben; PLAISANT, Catherine. Designing the user interface:

strategies for effective human-computer interaction. 4ª ed. Universidade de

Mariland, College Park: Pearson Education, Inc, 2005.

PRESSMAN, Roger S. Engenharia de Software. 6ª Edição. São Paulo: Mcgraw

Hill, 2006.

SOMMERVILLE, Ian. Engenharia de Software. 8º Edição. São Paulo: Pearson

Education, 2007.

Pfleeger, Shari Lawrence. Engenharia de Software - Teoria e Prática. 3ª

edição. São Paulo, Pearson Educarion, 2004

Paradigmas da Engenharia de Software [Parte 1]. Disponível em

<http://centraldaengenharia.wordpress.com/2011/02/08/paradigmas-modelo-

cascat/>, acesso em 21 de abril de 2014

Processos de Software. Disponível em <

http://www.tiespecialistas.com.br/2011/06/processos-de-software/#_ftnref2>,

Acesso em 21 de abril de 2014

13