Interface Com o Usuário
Técnicas de Projeto
Técnicas de Projeto de Software
Técnicas de projeto
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.
Interface com o Usuário
2
O processo de projeto
O 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..
Interface com o Usuário
3
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
Interface com o Usuário
4
Ciclo “codifica-remenda
O 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.
Interface com o Usuário
5
Deficiências
O 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.
Interface com o Usuário
6
Modelo em cascata
Os 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.
Interface com o Usuário
7
Deficiências do modelo
Se 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.
Interface com o Usuário
8
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.
Interface com o Usuário
9
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.
Interface com o Usuário
10
Modelo em espiral
Esse 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.
Interface com o Usuário
11
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.
Interface com o Usuário
12
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.
Interface com o Usuário
13
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.
Interface com o Usuário
14
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.
Interface com o Usuário
15
Modelo de entrega evolutiva
Corresponde a uma combinação dos modelos de
cascata e de prototipagem evolutiva
Permite 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.
Interface com o Usuário
16
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
Interface com o Usuário
17
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.
Interface com o Usuário
18
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.
Interface com o Usuário
19
Objetivos do PCH
Produzir 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.
Interface com o Usuário
20
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.
Interface com o Usuário
21
O modelo em estrela
Esse 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.
Interface com o Usuário
22
O modelo de Shneiderman
As 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.
2.
3.
No início do processo o projetista deve gerar (ou requerer) um
conjunto de especificações;
O segundo pilar é composto de ferramentas de prototipagem;
e
O terceiro pilar é dedicado a testes de usabilidade – avaliação
por especialistas e testes com usuários.
Interface com o Usuário
23
O modelo de Shneiderman
Interface com o Usuário
24
O modelo LUCID
Pode-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.
Interface com o Usuário
25
Escolha de um modelo
Vá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.
2.
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.
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.
Interface com o Usuário
26
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.
2.
3.
4.
5.
Escolha um domínio no qual muitas pessoas estão
envolvidas;
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?
Defina software que imite padrões de ação incluindo
funções que não poderiam ser feitas manualmente;
Crie protótipos o mais cedo possível e observe como as
pessoas reagem, o que “quebra” a experiência delas; e
Mantenha comunicação com eles.
Interface com o Usuário
27