Você está na página 1de 14

Faculdade de Tecnologia de Sorocaba Tecnologia em Anlise e Desenvolvimento de Sistemas

INTERAO HUMANO-COMPUTADOR: MODELOS PARA O DESENVOLVIMENTO DE INTERFACES

ATIVIDADE 8

Prof. Sergio Moraes Disciplina: Interao Humano-Computador

JEREMIAS PEREIRA RENAN PONTES

0030481311023 0030481311033

Sorocaba Abril/2014

Sumrio
1. Introduo .................................................................................................... 1 2. Definio ...................................................................................................... 2 2.1. Modelos Clssicos ................................................................................ 2 Modelo Cascata .............................................................................. 2 Modelo Espiral ................................................................................ 4 Modelo Estrela ................................................................................ 5 Modelo de Shneiderman ................................................................. 7 2.1.1. 2.1.2. 2.2. 2.2.1. 2.2.2.

Modelos Especficos ............................................................................. 5

3. Concluso .................................................................................................. 11 4. Referncias Bibliogrficas ......................................................................... 12

1. Introduo
Esse trabalho visa a abordagem de modelos de processos para

desenvolvimento de interfaces de softwares, modelos de desenvolvimento discutido na matria de Engenharia de Software, porm 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. Tambm ser citados modelos e discutido em quais ocasies devem ser adotados, o que devemos analisar na hora de tomarmos tal deciso, etc.

2. Definio
Quando se fornece um servio ou cria-se um produto, seja desenvolvendo um software, escrevendo um relatrio ou fazendo uma viagem de negcios, seguese costumeiramente uma sequncia de etapas para completar um conjunto de tarefas. Estas so realizadas na mesma ordem todas s vezes, por exemplo: no se reboca uma parede sem antes colocar a tubulao necessria; no se assa um bolo sem antes misturar todos os ingredientes. Esse conjunto de tarefas ordenadas pode ser considerado um processo: uma srie de etapas que envolvem atividades, restries e recursos para alcanar a sada desejada (Pfleeger 2004). Essa a definio de modelo de processo que Pfleeger diz em seu livro. Embora no exista um processo de software ideal, existe espao para o aprimoramento (Sommervile 2007). Devido crescente demanda por softwares de qualidade, cada vez mais processos de desenvolvimento de software eficazes tornam-se necessrios. Em vista disto, imprescindvel que o desenvolvimento e aprimoramento de processos de software evoluam constantemente de forma a atender as necessidades atuais, bem como sirvam como um arcabouo de conhecimentos para a elaborao de novos processos e metodologias de desenvolvimento de software, mais eficientes e adaptveis. Efetivamente, a elaborao de software de computador um processo de aprendizado, e o resultado, a incorporao 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 Clssicos

2.1.1. Modelo Cascata O modelo clssico ou cascata, que tambm conhecido por abordagem top down, foi proposto por Royce em 1970. At meados da dcada de 1980 foi o nico modelo com aceitao geral. Esse modelo foi derivado de modelos de
2

atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software. Comparado com outros modelos de desenvolvimento de software, este mais rgido e menos administrativo. O modelo cascata (Figura 1) um dos mais importantes modelos, e referncia para muitos outros modelos, servindo de base para muitos projetos modernos. A verso 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 documentao. No entanto deve salientar-se que a documentao abrange mais do que arquivo de texto, abrange representaes grficas ou mesmo simulao. Uma abordagem incorporando processos, mtodos e ferramentas deve ser utilizada pelos criadores de software. Esta abordagem muitas vezes designada de Abordagem do Processo de Desenvolvimento. Existem trs abordagens de modelos de processo de desenvolvimento de software. Cascata pura Incremental Evolucionrio

Figura 1- paradigma do ciclo de vida clssico da Engenharia de Software

Os modelos genricos de processos de software amplamente utilizados atualmente so o modelo em cascata, o modelo de desenvolvimento

evolucionrio e o modelo de desenvolvimento baseado em componentes. Estes, no so mutuamente exclusivos e comumente so 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 Valorizao. Este modelo no foi o primeiro modelo para discutir o desenvolvimento interativo, mas foi o primeiro a explicar a importncia das iteraes. Como podemos ver na Figura 2, as fases so semelhantes as existente no modelo cascata e podem ser melhor compreendidas lendo o post referente a esse outro processo.

Disponvel em <http://centraldaengenharia.wordpress.com/2011/02/08/paradigmas-modelo-cascat/>

Figura 2 - Modelo espiral e suas fases

As iteraes tinham tipicamente de 6 meses a 2 anos de durao. Cada fase inicia com um objetivo esperado e termina com a anlise do cliente, que avalia o progresso at o momento. Anlise e esforos de engenharia so aplicados em cada fase do projeto, visando o objetivo final do projeto. 2.2. Modelos Especficos

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 usveis pelas pessoas. O nfase em prototipao rpida, metodologias alternadas analtica (top-down) e sinttica (botom-up), e avaliao ao mesmo tempo centrada no usurio e realista. To importantes como o prprio processo de design so as representaes do sistema que so empregadas ao longo dele, (veja Figura 3).

Disponvel em <http://apdzdeti.blogspot.com.br/2011/02/modelo-espiral.html>

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

Para alguns propsitos, modelos tais como esboos, cenrios, e prottipos sero mais apropriados, enquanto para outros propsitos, notaes formais sero mais adequadas. Diretrizes, regras prticas e checklists so teis conjuntamente ao longo de todo o processo, assim como os resultados oriundos da Engenharia Cognitiva que orientam no sentido de produzir sistemas mais prximos do modelo mental que o usurio tem dos mesmos. O modelo em estrela sugere que a ordenao das atividades inapropriada. Esta concluso derivou da vasta experincia de equipes de grandes centros de P&D na rea de IHC. O modelo prega, principalmente, a necessidade de prototipao rpida e avaliao, de forma mais visceral do que em qualquer outra abordagem. A avaliao central neste mtodo. Todos os aspectos do desenvolvimento esto sujeitos a constante avaliao por especialistas em IHC e pelos usurios. O modelo em estrela tambm promove ondas alternadas de abordagem ao projeto de sistemas. Enquanto a maioria das metodologias adotam a abordagem top-down ou analtica, o modelo em estrela reconhece que esta abordagem deve ser complementada pela abordagem inversa, ou bottom-up.

O modelo em estrela tambm destaca a importncia da prototipao incremental ao longo do desenvolvimento do produto. Embora os rtulos das fases sejam diferentes, elas representam atividade semelhantes s do modelo em cascata: Anlise (anlise de tarefas / anlise funcional); Especificao de requisitos; Design (conceitual e formal); Implementao.

Mas o processo envolve muita mais iterao. A prototipao e a avaliao so apresentadas como novas atividades, embora elas possam fazer parte de qualquer um dos estgios. 2.2.2. Modelo de Shneiderman O modelo de Shineiderman baseado em 3 pilares como mostrado na Figura 4:

Figura 4 - Modelo de desenvolvimento de interfaces proposto por Shneiderman composto por trs colunas

Primeiramente o designer deve gerar um conjunto de Guidelines. Depois o momento em que criado o prottipo do sistema, como ele deve ser, e submete a aprovao do usurio ou grupo de usurios finais, sendo que os prottipos devem ser feitos rapidamente, para economizar no tempo e no custo, provendo feedback o mais rpido possvel.

E finalmente, o designer deve verificar a consistncia do sistema, no que diz respeito a falhas, atravs de um conjunto de massa de testes, etc. Shneiderman (2005) tambm explica 8 regras de ouro para o desenvolvimento de interfaces de qualidade. So elas: I. Mantenha a consistncia

Sequncias consistentes de aes devem ser usadas em situaes similares. Use terminologia idntica em prompts, menus e telas de ajuda. Comandos devem ser utilizados da mesma maneira ao longo da interface. II. Oferea atalhos aos usurios experientes

Ao mesmo tempo que a frequncia de uso de uma interface aumenta, o desejo do usurio reduzir o nmero de interaes e aumentar o compasso da
8

interao. Abreviaes, teclas de funo, comando ocultos e facilidades de macros ajudaro o usurio mais experiente. III. Oferea feedbacks informativos

Para cada operao do usurio deve haver algum tipo de feedback do sistema. Oferea respostas discretas quando as aes so frequentes ou de menor importncia e respostas com maior prioridade para aes incomuns ou mais importantes. IV. Apresente as etapas do processo

Sequncias de aes devem ser organizadas em grupos com incio, meio e fim. O feedback informativo ao completar um grupo de aes d ao usurio satisfao de realizao, senso de distino e uma indicao que o caminho claro para se preparar para o prximo conjunto de aes. V. Oferea uma forma simples de correo de erros

Tanto quanto possvel, o design do sistema no deve permitir que o usurio cometa erros graves. Se um erro for cometido, o sistema deve ser capaz de detectar e oferecer um mecanismo simples e compreensvel para a soluo. VI. Permita fcil reverso de aes

Esta funcionalidade diminui a ansiedade, desde o momento que o usurio toma conhecimento que um erro grave pode ser desfeito. Isso potencializa a explorao de funes desconhecidas. As unidades de reversibilidade podem ser de uma nica ao, de uma entrada de dados ou uma sequncia completa de aes. VII. O controle do sistema do usurio

Usurios experientes desejam ter a noo de que controlam o sistema e este que responde aos seus comandos. O sistema deve ser projetado para deixar os usurios como iniciadores das aes ao invs de reagentes. VIII. Reduza a carga de memria curta do usurio
9

Este princpio est relacionado limitao humana de processamento de informao na memria de curta durao. O sistema deve ser projetado para que haja o menor esforo possvel do usurio em memorizar ou relacionar elementos na interface.

10

3. Concluso
Para ganharmos tempo e qualidade no desenvolvimento de interfaces, vimos que existem modelos, ou seja, padres que so discutidos por grandes nomes da Engenharia de Software e da IHC, ento sabemos que se adotarmos um padro de qualidade, resultaremos em um trabalho de qualidade, podemos adotar esses princpios desde a fase em que estamos desenhando os fluxos, interfaces e interaes. Certamente o produto ser muito mais eficiente ao cliente e, ao mesmo tempo, poupar inmeros ajustes que s seriam descobertos na fase de avaliao. Modelos possui uma grande importncia na hora do desenvolvimento, principalmente quando falamos de interfaces, importante ganharmos tempo, e utilizando modelos (j prontos) e com eficincia comprovada, poderemos investir preocupaes em outros aspectos e lugares. Existem diversos tipos de modelos, desde os clssicos como cascata e espiral, discutido por Pressman (2006) e Sumerville (2007), mas tambm temos outros modelos especficos, como o exemplo do modelo proposto por Hix e Hartson (1993) e tambm o modelo de Shneiderman (2005), todos possuem seus aspectos positivos e suas situaes especficas para implementao.

11

4. Referncias Bibliogrficas

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 Edio. So Paulo: Mcgraw Hill, 2006. SOMMERVILLE, Ian. Engenharia de Software. 8 Edio. So Paulo: Pearson Education, 2007. Pfleeger, Shari Lawrence. Engenharia de Software - Teoria e Prtica. 3 edio. So Paulo, Pearson Educarion, 2004 Paradigmas da Engenharia de Software [Parte 1]. Disponvel em

<http://centraldaengenharia.wordpress.com/2011/02/08/paradigmas-modelocascat/>, acesso em 21 de abril de 2014 Processos de Software. Disponvel em <

http://www.tiespecialistas.com.br/2011/06/processos-de-software/#_ftnref2>, Acesso em 21 de abril de 2014

12