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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

O modelo de Shneiderman Interface com o Usuário

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

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

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