Interface Com o Usuário Técnicas de Projeto

Apresentação em tema: "Interface Com o Usuário Técnicas de Projeto"— Transcrição da apresentação:

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

2 Interface com o Usuário
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

3 Interface com o Usuário
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

4 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

5 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

6 Interface com o Usuário
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

7 Interface com o Usuário
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

8 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

9 Interface com o Usuário
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

10 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

11 Interface com o Usuário
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

12 Interface com o Usuário
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

13 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

14 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

15 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

16 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

17 Interface com o Usuário
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

18 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

19 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

20 Interface com o Usuário
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

21 Interface com o Usuário
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

22 Interface com o Usuário
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

23 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”: 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

24 O modelo de Shneiderman
Interface com o Usuário

25 Interface com o Usuário
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

26 Interface com o Usuário
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: 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

27 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: 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