IHC - Modelos para o Desenvolvimento de Interfaces

INTERAÇÃO HUMANO-COMPUTADOR:

Modelos para o Desenvolvimento de Interfaces

ATIVIDADE 8

Prof.º Sergio Moraes

Disciplina: Interação Humano-Computador

Sorocaba

Sumário

1. INTRODUÇÃO 3

2. MÉTODOS CLÁSSICOS 3

2.1. MODELO CASCATA 3

2.2. MODELO ESPIRAL 5

3. MÉTODO ESPECÍFICOS 7

3.1. MODELO ESTRELA DE HIX E HARTSON 7

3.2. MODELO DE SHNEIDERMAN 8

4. CONCLUSÃO 8

5. REFERÊNCIA BIBLIOGRÁFICAS 9

1. INTRODUÇÃO

Neste módulo abordamos modelos para o desenvolvimento de interfaces, entres eles dois modelos clássicos, o Modelo Cascata e o Modelo Espiral, e os modelos mais específicos, o Modelo estrela de Hix e Hartson e o modelo proposto por Shneiderman, todos eles tem como objetivo utilizar uma metodologia para organizar atividades, ações e tarefas necessárias para desenvolver um software , assim criando um roteiro que ajudará na criação de um produto de alta qualidade e dentro do prazo estabelecido.

2. MÉTODOS CLÁSSICOS

Os seguinte modelos são os mais conhecidos para representar uma tentativa de colocar em ordem todo o processo caótico de uma criação de software ou sistema, separando-os por pequenas etapas para que sejam melhores administrados e resolvidos.

2.1. MODELO CASCATA

O Modelo Cascata também conhecido como ciclo de vida clássico é utilizado principalmente quando os requisitos de um determinado problema são bem compreendidos, como por exemplo quando é necessário fazer aperfeiçoamentos e adaptações em um processo devido a mudanças ou criação de uma lei, ou então o software necessita de uma nova funcionalidade.

Neste modelo a abordagem é sequencial, assim deve-se começar levantando os requisitos e necessidades com o cliente, o próximo passo é o planejamento, onde definimos estimativas, cronograma e acompanhamento; na sequência se faz a modelagem, depois a construção onde codificamos e testamos; e então passamos para a implantação onde se efetua a entrega; e após temos o suporte e feedback do software concluído como segue na imagem abaixo:

O modelo Cascata tem uma variação chamada Modelo V, e nela se descreve a ação entre a garantia de qualidade e as ações associadas a comunicação e construções iniciais. Ele fornece uma forma de visualizar como a verificação e as ações as validações são aplicadas ao trabalho de engenharia anterior.

Como pode-se ver na imagem abaixo, ele tem o formato de um V, e a medida que a equipe desce em relação ao lado esquerdo do V, os problemas vão sendo refinados e mais bem detalhados. E ao descer completamente, ou seja, após a geração do código, a próxima etapa é subir o lado direito do V, assim realizando vários testes validando cada um dos modelos criados.

O modelo cascata é o paradigma mais antigo da Engenharia de Software, que ao longo das décadas com tantas críticas ao processo, fez com que até os seus mais ardentes defensores duvidassem de sua eficácia.

Pressman evidencia alguns problemas ao aplicar o modelo cascata:

• Os projetos de software reais construídos e evoluídos na indústria de software raramente seguem o fluxo sequencial que o modelo prega. Apesar de que esse modelo em forma sequencial possa conter iterações, onde poderíamos passar diversas vezes pelas mesmas atividades, ele o faz indiretamente. Como resultado tem-se que mudanças podem provocar bastante confusão na medida em que a equipe de projeto prossegue.

• É muito raro e difícil para o cliente saber e estabelecer explicitamente todas as suas necessidades. O modelo cascata é muito fortemente baseado nisso e tem dificuldade para adequar a incerteza natural que existem no início dos projetos.

• O cliente precisa ter muita paciência, o que raramente acontece. Uma versão operacional (pronta para ser executada no cliente) não estará disponível até estarmos próximo ao final do projeto. Se tivermos um erro grave nas etapas iniciais, como uma especificação mal compreendida e mal especificada, podemos ter um resultado desastroso.

Ao utilizar este método, alguns membros da equipe têm que aguardar os outros completarem as tarefas para que possam dar continuação ao processo e este gasto na espera poderia ser gasto com tarefas produtivas. O trabalho com software tem um ritmo acelerado e está sujeito a mudanças, e o modelo cascata é inapropriado para tal, mas ele é muito útil em situações em que os requisitos são fixos e o trabalho deve ser realizado de forma linear até sua conclusão.

2.2. MODELO ESPIRAL

O modelo Espiral é representado como o nome diz em uma espiral, em que ele não faz uma sequência de atividades de uma etapa para outra é voltado para a área de riscos, foi proposto por Boehm em 1988 e é utilizado até hoje.

O processo se inicia do centro da espiral com um conceito do projeto a ser iniciado e termina com uma interação direta com o cliente no fim da linha da espiral do lado externo, como mostra a imagem abaixo:

No início as interações são menores e restritas, e ao decorrer do projeto elas aumentam e se tornam mais abrangentes. Cada volta na espiral representa uma fase do processo de desenvolvimento, e elas não são fixas, ou seja, cada volta na espiral é