1 - lafayette b. melo – análise e projeto de sistemas para a internet – noções de engenharia...

11 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – Noções de Engenharia de Software COINFO – CEFET-PB - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – Noções de Engenharia de Software COINFO – CEFET-PB

O PROCESSO DO DESIGN DE INTERAÇÃOO PROCESSO DO DESIGN DE INTERAÇÃO

• Um modelo de ciclo de vida para os nossos projetos

• O design de interação é uma área preocupada em projetar produtos interativos que forneçam suporte às atividades cotidianas das pessoas, seja no lar ou no trabalho

• O design é um plano ou esquema concebido na mente com o intuito de posteriormente ser executado

• Ao se construir uma estrada o que deve ser levado em conta neste plano?


• O design de interação também trata de:

– Equilibrar necessidades conflitantes• Através da experiência• Desenvolvendo e avaliando soluções alternativas

– Comunicar adequadamente o plano• Linguagem natural• Diagramas• Protótipos

– Fazer com que os designs alternativos possam ser gerados, captados e avaliados pelos usuários de uma forma que eles possam interagir


• QUATRO atividades básicas do design de interação

1) Identificar necessidades e estabelecer requisitosFoco em usuários-alvo

2) Desenvolver designs alternativosDesign conceitual:

O que o produto deve fazer, como se comportar e com o O que o produto deve fazer, como se comportar e com o que parecerque parecer

Design físico:Cores, sons, imagens, design do menu e dos íconesCores, sons, imagens, design do menu e dos ícones

3) Construir versões interativas dos designs

4) Avaliar designsDeterminar usabilidade e aceitabilidade

Número de erros, atração, preenchimento dos requisitosNúmero de erros, atração, preenchimento dos requisitos


• TRÊS características básicas do design de interação

– Foco no usuário

– Objetivos específicos da experiência com o usuário

– Iteração

• QUATRO questões na prática do design de interação

– Quem são os usuários? (definição de stakeholders)– O que se entende aqui por necessidades?– Como criar designs alternativos?– Como escolher um dentre os vários designs alternativos?


• Há um modelo de ciclo de vida simples para o design de interação

66 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – Noções de Engenharia de Software COINFO – CEFET-PB - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – Noções de Engenharia de Software COINFO – CEFET-PB Noções de Engenharia de Software Noções de Engenharia de Software

3.3. Como identificar requisitos?Como identificar requisitos?

• Objetivo: mostrar o papel da análise de requisitos de sistemas e as principais atividades relacionadas


3.1 CONSIDERAÇÕES GERAIS SOBRE REQUISITOS3.1 CONSIDERAÇÕES GERAIS SOBRE REQUISITOS

• Podem surgir de várias formas...

• ... mas não implicam simplesmente escrever uma lista de desejos das características pretendidas retirados da cabeça do usuário

• A atividade de entender o que o produto pode realizar já recebeu várias denominações– Coleta de requisitos ou captura de requisitos– Elicitação de requisitos– Análise de requisitos– Engenharia de requisitos– No design de interação é ESTABELECIMENTO DE REQUISITOS

(interpretação + coleta)


• E o que são requisitos?– Declaração sobre um produto pretendido que especifica o que

ele deveria fazer ou como deveria operar

• Objetivos do estabelecimento de requisitos– Especificidade– Retirar ambiguidades– Clareza

• Exemplos de requisitos para um site:– “Tempo de download de uma página completa em 5 s”– “Os adolescentes devem achar o site atrativo”– “Tempo de resposta rápido”– “Estrutura de menu fácil de utilizar”


3.2 TIPOS DE REQUISITOS3.2 TIPOS DE REQUISITOS

– Requisitos funcionais – dizem o que o sistema deve fazer. Exs.:• Suporte a formatações

• Formatação por parágrafo

• Formatação por caractere

– Requisitos não-funcionais – indicam as limitações no sistema e em seu desenvolvimento

• Ser executado em várias plataformas• Funcionar em um computador com 64 Mb de RAM• Estar pronto em seis meses


• Tipos de requisitos não funcionais

– Requisitos de dados

– Requisitos ambientais• Ambiente físico• Ambiente social• Ambiente organizacional• Ambiente técnico

– Requisitos do usuário

– Requisitos de usabilidade


..3.3 CUIDADOS NA ANÁLISE DE REQUISITOS 3.3 CUIDADOS NA ANÁLISE DE REQUISITOS

– Se perguntar não sobre COMO deve ser feita alguma tarefa para construir o sistema, mas sobre O QUE é exigido

– Estar preparado para ambiguidades:• “sei que você acredita que entendeu o que acha que eu

disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer…”

– Etapas que antes eram construídas posteriormente devem ser pensasadas em conjunto com a análise:

• Construção do manual do usuário• Plano dos testes de usabilidade


– Um analista deve exibir nos seus esforços traços característicos…• Compreensão de conceitos abstratos• Absorver fatos pertinentes• Entender o ambiente do usuário• Aplicar elementos do sistema aos elementos do usuário• Comunicar-se bem nas formas escrita e verbal• Capacidade de “ver as florestas entre as árvores”

– … e coordenar cada uma das tarefas associadas à análise de requisitos de software


– Primeira lei da engenharia de sistemas

• “Não importa onde se esteja no ciclo de vida do sistema, o sistema se modificará, e o desejo de mudá-lo persistirá ao longo de todo o ciclo” (Bersoff)

1414 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – Noções de Engenharia de Software COINFO – CEFET-PB - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – Noções de Engenharia de Software COINFO – CEFET-PB Noções de Engenharia de Software Noções de Engenharia de Software

4.4. Como escolher os dados e Como escolher os dados e fazer a coleta adequada?fazer a coleta adequada?

• Objetivo: mostrar técnicas de coleta de dados


• Um encontro pode estabelecer desconcerto entre as partes, mas algumas etapas podem ser iniciadas:

– Perguntas livres do contexto (direcionadas ao cliente)• Quem está por trás do pedido deste trabalho?• Quem usará a solução?• Qual é o benefício econômico de uma solução?• Há outra fonte para a solução exigida?

– Compreensão do problema (verbalização do cliente sobre uma percepção da solução)

• Como você caracterizaria um bom resultado?• Qual problema essa solução resolverá?• Você pode mostrar o ambiente?• Existem questões de desempenho ou restrições especiais?


– Metaperguntas (efetividade do encontro)• Você é a pessoa certa? Suas respostas são oficiais?• Minhas perguntas são pertinentes ao problema que você

tem?• Estou fazendo perguntas demais?• Há mais alguém que possa fornecer informações adicionais?• Existe algo mais que devo perguntar-lhe?

• Após o encontro, desenvolvedores e clientes escrevem a requisição do produto com uma lista de objetos, suas restrições e desempenho, podendo ser feitas mini-especificações


• Revisão da especificação– Nível macroscópico

• Metas e objetivos permanecem consistentes?• Interfaces foram descritas?• O fluxo e a estruura são adequados?• Os diagramas são claros?• As funções estão no escopo?• O comportamento é consistente com informação e funções?• As restrições são realísticas?• Qual é o risco tecnológico?• Requisitos foram considerados?• Critérios de validação foram detalhados?• Há inconsistência, omissão, redundância?• Contato com o cliente é completo?• Protótipo ou manual foram revisados?• Estimativas foram afetadas?


• Revisão detalhada– Enunciados da especificação

• Olhar o porquê de conectivos persuasivos– Por exemplo, certamente, obviamente, claramentePor exemplo, certamente, obviamente, claramente

• Procurar termos vagos– Algum, às vezes, usualmente, o mais, na maior parteAlgum, às vezes, usualmente, o mais, na maior parte

• Identificar listas incompletas– Etc, assim po diante, daí pra frente, tal comoEtc, assim po diante, daí pra frente, tal como

• Limites declarados com pressuposições não declaradas– ““códigos variam de 0 a 100” (inteiro, real…)códigos variam de 0 a 100” (inteiro, real…)

• Cuidado com pronomes pendentes• Pedir prova das declarações com certeza• Evitar outras definições para um mesmo termo• Estrutura descrita em parágrafos (gráfico? Figura?)• Quando houver cálculo, criar 2 exemplos


4.1 TÉCNICAS DE COLETA DE DADOS4.1 TÉCNICAS DE COLETA DE DADOS

• Pesquisas em arquivos, manuais de procedimentos operacionais, administrativos e outros, bem como a verificação de todos os tipos de registros de informações existentes

• Questionários– Podem ter apenas respostas como SIM/NÃO– Podem ter um conjunto de respostas pré-estabelecidas– Podem ser eletrônicos– Podem atuar junto com outras técnicas

• Entrevistas– A entrevista deve ser planejada, desenvolvida sem divergência

e com controle da arrogância


• Planejamento da entrevista (todos os pontos devem ser obedecidos)

– 1) Marcação de data e horário

– 2) Preparação do entrevistador – com preparação dos itens e sua sequênca, com alguma documentação e registro

– 3) Comportamento do entrevistador – adequação ao local, atenção ao entrevistado, interesse em resolver os problemas que lhe atingem, sem desviar a atenção para outros assuntos

– 4) Linguagem – evitar termos técnicos e só expressar elogios de forma honesta

– 5) Distinção entre fatos e opiniões

– 6) Necessidades do usuário – cuidado com o raciocínio em termos pessoais e o pedido antecipado de relatórios ou inclusão de recursos não necessários


• Considerações gerais sobre as entrevistas

– A entrevista pode ser dividida em três partes de forma que seja imperceptível para o usuário

– Perguntas abertas são bem vindas

– Princípios: não criticar a empresa, o trabalho do entrevistado, o sistema existente ou qualquer funcionário

– Relatório após deve ser feito com máxima urgência, para não esquecer os detalhes, mesmo que tenha gravado ou filmado

– Alguns princípios não tradicionais, sociais e situados podem ser observados para se fazer uma entrevista proveitosa


• Grupo focal e workshop

• Observação natural

• Estudo de documentação

4.2 COMO ESCOLHER A TÉCNICA ADEQUADA4.2 COMO ESCOLHER A TÉCNICA ADEQUADA

• Deve-se definir a natureza da técnica e a tarefa a ser estudada

• Aspectos:– Tempo– Conhecimento do analista sobre processos cognitivos básicos


• Escalas de realização das tarefas a serem estudadas:– Conjunto de passos ou subtarefas que se sobrepõem?– Alto ou baixo conteúdo de informação?– Realizadas por um leigo ou por alguém com domínio da tarefa?

• Diretrizes básicas– Concentrar-se na identificação das necessidades dos

stakeholders– Envolver o grupo de stakeholders– Envolver mais de um representante– Usar uma combinação de técnicas– Oferecer apoio às sessões– Executar uma sessão-piloto– Conscientizar-se da necessidade de tempo e da falta de

recursos– A forma de registro dos dados pode trazer grandes diferenças

1 - lafayette b. melo – análise e projeto de sistemas para a internet – noções de engenharia...

Documents