Interface Com o Usuário Técnicas de Projeto Técnicas de Projeto de Software

Interface Com o Usuário Técnicas de Projeto

Técnicas de Projeto de Software

Interface com o Usuário 2

O projeto de software tenta relacionar: A forma e função de um sistema de software

à estrutura do processo que produz esse sistema.

A tradição herdada de princípios da engenharia apresenta uma abordagem à problemática da crise de software da década de 60, que se baseia na crença de que um processo rigoroso de transformação de requisitos em sistemas é a chave para um projeto confiável.

Técnicas de projeto


O processo de projetoO processo de projeto em Engenharia de Software (ES) parte de três pressupostos básicos:

O resultado do projeto é um produto, seja ele um artefato, máquina ou sistema;

O produto é derivado de especificações fornecidas pelo cliente; e

Uma vez que o cliente e o projetista concordaram com as especificações, há pouca necessidade de contato entre eles até a entrega do produto..


Modelos de ciclo de vida

Em um processo de desenvolvimento de software, o ponto de partida para a arquitetura de um sistema é a escolha de um modelo de ciclo de vida;Existem vários modelos em utilização atualmente


Ciclo “codifica-remendaO ciclo de vida mais caótico. Partindo apenas de uma especificação (ou nem isso), os desenvolvedores começam imediatamente a codificar, remendando à medida que os erros vão sendo descobertos.Nenhum processo definido é seguido.


DeficiênciasO modelo de ciclo “codifica-remenda” é provavelmente o ciclo de vida mais usado. Para alguns desenvolvedores, esse modelo é atraente porque não exige nenhuma sofisticação técnica ou gerencial. É um modelo de alto risco;Impossível de gerir ; e Não permite assumir compromissos confiáveis.


Modelo em cascataOs principais subprocessos são executados numa seqüência estrita, o que permite demarca-las com pontos de controle bem definidos. Esses pontos de controle facilitam a gestão dos projetos.Esse processo é, em princípio, confiável e utilizável em projetos de qualquer escala.


Deficiências do modeloSe interpretado literalmente, é um processo rígido e burocrático, em que as atividades de requisitos, análise e projeto têm de ser muito bem dominadas.Não são permitidos erros. O modelo de cascata puro é de baixa visibilidade para o cliente, que só recebe o resultado final do projeto.É impossível entender completamente e expressar os requisitos do usuário antes que algum projeto tenha sido feito. As possibilidades de mudanças no software a partir da etapa de manutenção são mínimas, em função dos comprometimentos e custos envolvidos ao longo da cadeia.


Modelo sashimiÉ sempre melhor permitir que, em fases posteriores, haja revisão e alteração de resultados das fases anteriores. Por exemplo:

Os modelos e documentos de especificação e projeto podem ser alterados durante a implementação, na medida em que problemas vão sendo descobertos.


Vantagens e desvantagens do modelo

Vantagem:Permite superposição entre fases e a realimentação de correções.Entretanto essa vantagem leva a uma desvantagem::A superposição das fases torna difícil gerenciar projetos baseados nesse modelo de ciclo de vida.


Modelo em espiralEsse modelo é completamente diferente dos anteriores.O produto é desenvolvido em uma série de iterações. Cada nova iteração corresponde a uma volta na espiral. Permite construir produtos em prazos curtos, com novas características e recursos que são agregados na medida em que a experiência descobre sua necessidade. As atividades de manutenção são usadas para identificar problemas; seus registros fornecem dados para definir os requisitos das próximas liberações.


Desvantagens

Embora ainda use os mesmos processos do modelo sashimi:

Análise, Projeto; e Implementação

E seja orientado ao produto, o modelo espiral já mostra que várias interações são necessárias e introduz a idéia de prototipagem para maior entendimento dos requisitos.


Modelo de prototipagem evolutiva

Corresponde a uma variação do modelo em espiral. Neste modelo, a espiral é usada não para desenvolver o produto completo, mas para construir uma série de versões provisórias que (os protótipos).Os protótipos cobrem cada vez mais requisitos, até que atinja o produto desejado. Os requisitos são definidos progressivamente.Alta flexibilidade.Alta visibilidade para os clientes.


Desvantagens do modelo

A prototipagem evolutiva também requer gestão sofisticada.O projeto deve ser de excelente qualidade, para que a estrutura do produto não se degenere ao longo dos protótipos.


Modelo de entrega por estágios

Difere do modelo de cascata, pela entrega ao cliente de liberações parciais do produto.Aumenta a visibilidade do projeto, o que geralmente é um fator muito importante no relacionamento com o cliente. Entretanto, apresenta os demais defeitos do modelo em cascata.


Modelo de entrega evolutiva

Corresponde a uma combinação dos modelos de cascata e de prototipagem evolutivaPermite que os usuários possam avaliar partes do produto e fornecer realimentação quanto às decisões tomadas. Facilita também o acompanhamento do progresso de cada projeto, tanto por parte de seus gerentes como dos clientes.


Desvantagem do modelo

A principal dificuldade continua a ser: A realização do projeto inicial: O projeto inicial deve produzir uma

arquitetura de produto robusta; Esta arquitetura deve se manter íntegra ao

longo dos ciclos de liberações parciais


O que leva a um bom projeto de SW?

Esta é uma pergunta freqüente na área de desenvolvimento de sistemas de software.No sentido de achar uma resposta, alguns pesquisadores entrevistaram projetistas de bons sistemas e observaram que suas respostas estavam longe da cultura da ES convencional. O processo de projeto em engenharia oferece pouca relação entre ações do projetista e as necessidades dos usuários, produzindo uma “cegueira” no domínio de ações na qual os usuários vivem e trabalham.


O modelo baseado em pessoas

Outros modelos de ciclo de vida foram desenvolvidos como forma de reação ao problema do projeto centrado no produto. Projeto Centrado no Humano (PCH), do inglês Human Centered Design - HCD, foi um modelo desenvolvido na década de 80, que se fundamenta no entendimento do domínio de trabalho no qual as pessoas estão engajadas e no qual interagem com computadores.Pressupostos do PCH:

O resultado de um bom projeto é a satisfação do cliente; O processo de projeto envolve uma colaboração entre

projetistas e clientes – o projeto evolui e se adapta aos seus interesses (que também mudam);

Esse processo é que produz uma especificação como subproduto. Fundamentalmente o cliente e o projetista estão em constante

comunicação durante todo o processo.


Objetivos do PCHProduzir sistemas fáceis de aprender e usar;Seguros e efetivos em facilitar as atividades do usuário. Testes freqüentes com o usuário usando representações informais e prototipagem.O aspecto central do PCH é o envolvimento efetivo de usuários ao longo do processo de projeto, não apenas para “comentar” decisões do projetista.


O modelo de EasonÉ um outro modelo de processo que se destaca, pelo fato do processo de projeto ser representado como um processo de natureza cíclica centrado em pessoas, trabalho e tecnologia sendo um processo ordenado.


O modelo em estrelaEsse modelo apresenta uma abordagem ao desenvolvimento como “ondas alternantes”.As atividades são similares às do modelo cascata, mas a avaliação é central e o início do processo pode acontecer em qualquer uma das demais atividades.


O modelo de ShneidermanAs abordagens da ES e da IHC possuem forças e fraquezas complementares; juntas formam uma nova disciplina: arquitetura de software. Alguns pesquisadores propuseram um modelo para projeto baseado metaforicamente em 3 “pilares”:1. No início do processo o projetista deve gerar (ou

requerer) um conjunto de especificações; 2. O segundo pilar é composto de ferramentas de

prototipagem; e 3. O terceiro pilar é dedicado a testes de usabilidade –

avaliação por especialistas e testes com usuários.


O modelo de Shneiderman


O modelo LUCIDPode-se dizer que parece já haver um consenso de que qualquer metodologia de DCH deve mesclar-se à metodologia da ES. O modelo LUCID (Logic User-Centered Interface Design), antigamente chamado QUE (Quality Usability Engineering) representa um esforço para esse consenso. O modelo é representado por uma seqüência de 6 fases:

1. Desenvolver o conceito do produto; 2. Realizar pesquisa e análise das necessidades – usando

construção de cenários, projeto participativo, fluxo e seqüência de tarefas;

3. Criar conceitos e protótipos de telas – usando especificações, guias de estilo e metáforas para o projeto;

4. Projeto iterativo e refinamento – expandindo o protótipo para sistema completo; inclui a avaliação por especialistas e testes de usabilidade;

5. Implementação do software; e 6. Suporte.


Escolha de um modeloVários aspectos influenciam e devem ser considerados na escolha do modelo de projeto de IHC:O tipo do sistema a ser desenvolvido, em termos do tamanho, complexidade e propósito. Considerar também se está sendo tratado:1. O projeto de sistema completamente novo, nesse caso há o

problema de selecionar entre um grande conjunto de opções e diferentes implicações no projeto.

2. Ou de re-projeto de sistema já existente, aqui a liberdade do projetista é severamente restringida por decisões anteriores de projeto original, linha do produto etc.

Considerar, ainda as restrições inerentes ao sistema, suas condições de contorno, sistemas críticos em relação à segurança, por exemplo.


O que leva a um bom projeto?

Das respostas de uma entrevista feita com projetistas bem sucedidos à questão de “o que leva a um bom projeto”, foram sintetizadas as seguintes sugestões:1. Escolha um domínio no qual muitas pessoas estão

envolvidas;2. Estude a natureza das ações dessas pessoas naquele

domínio, especialmente em ações repetitivas; o que eles reclamam mais? Que ações gostariam de realizar?

3. Defina software que imite padrões de ação incluindo funções que não poderiam ser feitas manualmente;

4. Crie protótipos o mais cedo possível e observe como as pessoas reagem, o que “quebra” a experiência delas; e

5. Mantenha comunicação com eles.

Documents

Interface Com o Usuário Técnicas de Projeto Técnicas de Projeto de Software