Atividade 8

Prévia do material em texto

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 Santos de Pádua Carneiro 0030481713036
Caique Carara Reimberg 0030481623010
Felipe de Queiroz 0030481723003
Sorocaba
Junho/2018
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.
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)
Modelos Clássicos
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 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 Software[1: Disponível em <http://centraldaengenharia.wordpress.com/2011/02/08/paradigmas-modelo-cascat/>]
Os modelos genéricos de processos de software amplamente utilizados atualmente são o modelo em cascata, o modelo de desenvolvimento 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).
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 fases[2: Disponível em <http://apdzdeti.blogspot.com.br/2011/02/modelo-espiral.html>]
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.
Modelos Específicos
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.
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.
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 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çãodo 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:
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.
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 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.
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.
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.
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/>, Processos de Software. Disponível em < http://www.tiespecialistas.com.br/2011/06/processos-de-software/#_ftnref2>,