UNIVERSIDADE NOVE DE JULHO

TECNOLOGIA DA INFORMAÇÃO

ENGENHARIA DE SOFTWARE

Profº André R. Rivas

andre.rivas@uninove.br

2013
 ENGENHARIA DE SOFTWARE
01 EMENTA

• Estudo do papel da Engenharia de Software para determinação de um

processo adequado de desenvolvimento.
• Conceituação da diferença entre produto e processo de software.
• Aspectos gerais das etapas do processo de desenvolvimento.
• Modelos de desenvolvimento: cascata, evolucionário, iterativos,
engenharia baseada em componentes, processo unificado e
metodologias ágeis.

OBJETIVOS

Apresentar a Engenharia de Software, conceituando os modelos de

processo existentes, de modo a permitir a identificação e determinação das
atividades essenciais em um processo de desenvolvimento.
 ENGENHARIA DE SOFTWARE
02 INTRODUÇÃO

Nos primórdios da era computacional, os programas eram pequenos e

normalmente escritos por uma pessoa, seus utilizadores eram especialistas
na área.
Os problemas eram de natureza técnica, lidando com dados numéricos,
sendo a ênfase colocada na codificação eficiente de algoritmos bem
conhecidos.
Atualmente as aplicações são muito diferentes, sob vários aspectos:
• São grandes e complexas;
• Desenvolvidas por equipes muitas vezes multidisciplinares e durante
períodos longos;
• Os programadores não são os futuros utilizadores e não são peritos na
área em que se insere a aplicação;
• Ambientes cliente-servidor ou centrados na rede.
 ENGENHARIA DE SOFTWARE
02 INTRODUÇÃO

Estas alterações ocorridas no ambiente em que se insere o software, fez

com que as técnicas de programação ficassem claramente para trás, dado
que agora, o software é muito mais extenso e complexo.

Em resultado disso, foram inevitáveis:

• Imprecisões nas estimativas de custos e duração;
• Deficiências na identificação dos requisitos, levando a que as aplicações
não se comportassem como esperado;
• Falta de produtividade das equipes;
• Falta de qualidade e viabilidade do software, sendo muitos erros
detectados após entrega;
• Grande dificuldade de manutenção, dado que a documentação é
deficiente e desatualizada;
• Carência de profissionais competentes no mercado mundial.
 ENGENHARIA DE SOFTWARE
03 PRODUTO DE SOFTWARE

O produto de software é o produto que os engenheiros de software

projetam e constroem. Ele engloba os programas que são executados
dentro de um computador de qualquer tamanho e arquitetura, os
documentos, que englobam formulários virtuais e material impresso
produzido por computador (hard-copy), e dados, que combinam números e
texto, mas também incluem representações de informações em áudio,
vídeo e pictóricas.
O produto de software (ou simplesmente software) é composto de:
• Instruções (os programas de computador) que quando executados
fornecem a função e desempenho desejados;
• Estruturas de dados que permitem aos programas manipular as
informações de forma adequada;
• Documentos que descrevem a operação e uso dos programas.
• O produto de software é o componente lógico de um sistema
informatizado, e não físico.
 ENGENHARIA DE SOFTWARE
03 PRODUTO DE SOFTWARE

São produzidos pelo processo e pelas suas atividades e servem de matéria-

prima para os mesmos. Por exemplo: documento de requisitos, programa
executável.
Hoje, o produto de software tem um papel duplo. Ele é um produto, e ao
mesmo tempo é um veículo para distribuir um produto. Como produto, ele
distribui o potencial computacional personificado através do hardware do
computador. Tanto residindo dentro de um telefone celular ou sendo
executado em um mainframe, o produto de software é um transformador
de informação - produzindo, gerenciando, adquirindo, modificando,
exibindo ou transformando informação.
Como veículo usado para distribuir um produto, o produto de software
atua como base para controle de computadores (sistemas operacionais),
comunicação de informação (softwares de gerenciamento de redes) e
criação e controle de outros programas (ambientes e ferramentas).
 ENGENHARIA DE SOFTWARE
03 PRODUTO DE SOFTWARE

O produto de software distribui o que muitos acreditam ser o mais

importante produto de século XXI - a informação.
Produtos de Software podem ser desenvolvidos para um cliente específico
ou para o mercado.
Produtos de software podem ser:
• Genéricos-produzidos e vendidos no mercado a qualquer cliente.
• Produtos sob encomenda (ou personalizados), encomendados por um
cliente em particular (especificação é desenvolvida e controlada pela
organização que está comprando o software).
Os custos de software em geral dominam o custos do sistema.
Normalmente o custo do software é maior do que o custo do hardware.
Em software, custa-se mais para manter do que para desenvolver. Para
sistemas de vida útil longa, os custos de manutenção podem ser várias
vezes mais que o custo de desenvolvimento.
 ENGENHARIA DE SOFTWARE
04 CRISE DO SOFTWARE

A crise do software foi um termo utilizado nos anos 1970, quando a

engenharia de software era praticamente inexistente. O termo expressava
as dificuldades do desenvolvimento frente ao rápido crescimento da
demanda por software, da complexidade dos problemas a serem resolvidos
e da inexistência de técnicas estabelecidas para o desenvolvimento de
sistemas que funcionassem adequadamente ou pudessem ser validados.

As causas da crise do software estão ligadas a complexidade do processo

de software e a relativa imaturidade da engenharia de software como
profissão. A crise se manifesta de varias formas:

• Projetos estourando o orçamento;

• Projetos estourando o prazo;
• Software de baixa qualidade;
• Software muitas vezes não atingiam os requisitos;
• Projetos ingerenciaveis e o código difícil de manter.
 ENGENHARIA DE SOFTWARE
05 ASPECTOS DA ENGENHARIA DE SOFTWARE

• Engenharia de software é uma área da computação voltada à

especificação, desenvolvimento e manutenção de sistemas de software,
com aplicação de tecnologias e práticas de gerência de projetos e outras
disciplinas, visando organização, produtividade e qualidade.
• Atualmente, essas tecnologias e práticas englobam linguagens de
programação, banco de dados, ferramentas, plataformas, bibliotecas,
padrões, processos e a questão da qualidade de software.
• As economias de todas as nações desenvolvidas são dependentes de
software, cada vez mais sistemas são controlados por software.
• A engenharia de software se preocupa com teorias, métodos e
ferramentas para o desenvolvimento de software profissional, orientada
a uma boa relação custo-benefício.
• Gastos com Engenharia de Software representa uma fração significativa
de todos os países desenvolvidos
 ENGENHARIA DE SOFTWARE
05 ASPECTOS DA ENGENHARIA DE SOFTWARE

• Os fundamentos científicos para a engenharia de software envolvem o

uso de modelos abstratos e precisos que permitem ao engenheiro
especificar, projetar, implementar e manter sistemas de software,
avaliando e garantindo suas qualidades. Além disso, a engenharia de
software deve oferecer mecanismos para se planejar e gerenciar o
processo de desenvolvimento de um sistema de informação.
• Não deve ser confundida com engenharia de computação, engenharia
informática ou ciência da computação.
• O termo foi criado na década de 1960 e utilizado oficialmente em 1968
na NATO Science Committee. Sua criação surgiu numa tentativa de
contornar a crise do software e dar um tratamento de engenharia (mais
sistemático e controlado) ao desenvolvimento de sistemas de software
complexos.
 ENGENHARIA DE SOFTWARE
05 ASPECTOS DA ENGENHARIA DE SOFTWARE

Segundo o SWEBOK (Corpo de Conhecimento da Engenharia de Software),

versão 2004, as áreas de conhecimento da Engenharia de Software são:
• Requisitos (Requirements) de Software
• Projeto (Design) de Software
• Construção (Construction) de Software
• Teste (Testing) de Software
• Manutenção (Maintenance) de software
• Gerência de Configuração de Software
• Gerência de Engenharia de Software
• Processos de Engenharia de Software
• Ferramentas e Métodos de Engenharia de Software
• Qualidade (Quality) de Software

A Engenharia de Software (ES) é uma tecnologia em camadas e o foco é

orientado a qualidade do software desenvolvido. Portanto, é interessante
estudarmos a ES em suas camadas de Processo, Métodos e Ferramentas.
 ENGENHARIA DE SOFTWARE
06 SISTEMAS LEGADOS

Considerando a literatura, há certa convergência quanto à definição de

sistema legado:

• É um sistema de missão crítica, desenvolvido em algum momento do

passado, que ainda é usado e vem sendo modificado ao longo do tempo
sem submeter-se a ações sistemáticas de melhoria.
• Um sistema antigo, frequentemente mal projetado ou documentado,
mas que é crítico para o negócio e deve ser suportado por vários anos.
• Na maioria dos casos, os sistemas legados foram escritos para hardware
de mainframe, que possuem manutenção dispendiosa e pode não ser
compatível com as atuais políticas organizacionais de compras na área
de TI.
 ENGENHARIA DE SOFTWARE
06 SISTEMAS LEGADOS

Há um risco significativo de negócio em simplesmente descartar sistemas

legados e substituí-los por um sistema que foi desenvolvido utilizando uma
tecnologia moderna:

• Raramente existe uma especificação completa do sistema legado.

• Se existir uma especificação, é pouco provável que ela incorpore todas
as mudanças que foram feitas no sistema.
• Os processos corporativos e o modo como os sistemas legados operam
estão sempre intrinsecamente entrelaçados.
• Importantes regras corporativas podem estar inseridas no software e
podem não estar documentadas em nenhum outro lugar.
• O desenvolvimento de um software novo é arriscado, uma vez que
podem ocorrer problemas inesperados com um novo sistema.
 ENGENHARIA DE SOFTWARE
06 SISTEMAS LEGADOS

O sistema deve mudar para permanecer útil. No entanto, alterar um

sistema legado é muitas vezes dispendioso:
• Diferentes partes do sistema foram implementadas por diferentes
equipes. Portanto, não há um estilo de programação consistente.
• O sistema pode utilizar uma linguagem de programação obsoleta.
• Frequentemente, a documentação do sistema é inadequada e
desatualizada.
• Em geral, muitos anos de manutenção podem ter corrompido a
estrutura do sistema.
• O sistema pode ter sido otimizado para melhorar a utilização de espaço
ou a velocidade de execução, em vez de ter sido escrito para facilitar a
compreensão.
• Os dados processados pelo sistema podem estar armazenados em
diferentes arquivos, que podem ter estruturas incompatíveis.
 ENGENHARIA DE SOFTWARE
06 SISTEMAS LEGADOS

Atualmente, as organizações deparam-se com um grande dilema relevante

aos sistemas legados:

• Se continuarem utilizando os sistemas legados e fazendo alterações,

seus custos aumentarão.

• Se decidirem substituir seus sistemas legados por novos sistemas, isso

será dispendioso.

• Muitas empresas estão examinando técnicas de engenharia de software

que ampliem o tempo de duração dos sistemas legados e que reduzam
os custos de manter esses sistemas em uso, como a evolução de
produtos de software e a reengenharia de software.
 ENGENHARIA DE SOFTWARE
06 SISTEMAS LEGADOS

Componentes (estrutura) dos sistemas legados:

 ENGENHARIA DE SOFTWARE
06 SISTEMAS LEGADOS

Hardware de sistema – na maioria dos casos, os sistemas legados foram

escritos para hardware de mainframe, que possui uma manutenção
dispendiosa e pode não ser compatível com as atuais políticas
organizacionais de compras na área de TI.
 ENGENHARIA DE SOFTWARE
06 SISTEMAS LEGADOS

Software de apoio – são produtos de apoio que vão desde sistemas

operacionais e utilitários fornecidos pelo fabricante de hardware até os
compiladores utilizados para o desenvolvimento do sistema. Esses produtos
podem estar obsoletos e não possuir mais assistência técnica de seus
fornecedores originais.
Software de aplicação – fornece serviços de negócios e são compostos por
vários programas separados desenvolvidos em épocas diferentes.
 ENGENHARIA DE SOFTWARE
06 SISTEMAS LEGADOS

Dados de aplicação – são dados processados pelo sistema de aplicação. Na

maioria dos sistemas legados, um imenso volume de dados se acumulou
durante o tempo de duração do sistema. Esses dados podem ser
inconsistentes e podem estar duplicados em diferentes arquivos.

Processos de negócios – são os processos utilizados nas empresas a fim de

atingir algum objetivo de negócio.
 ENGENHARIA DE SOFTWARE
06 SISTEMAS LEGADOS

Políticas e regras de negócios – são as definições de como a empresa deve

ser conduzida e as restrições às quais ela deve se submeter.
O uso de um sistema legado de aplicação pode estar inserido nessas
políticas e regras. Os sistemas legados são, na maioria das vezes, vitais para
o funcionamento da empresa. Frequentemente são grandes, monolíticos,
difíceis de modificar e não se integram facilmente com outros aplicativos
modernos.
 ENGENHARIA DE SOFTWARE
06 SISTEMAS LEGADOS

Sistema sociotécnico

Em tese, é possível fazer alterações

em uma camada sem afetar qualquer
uma das camadas adjacentes, na
prática isso raramente funciona,
algumas das razões encontram-se
abaixo:

• A modificação de uma camada pode introduzir novos recursos e as

camadas superiores podem ser modificadas para se beneficiarem
desses recursos.

• A modificação do software pode torná-lo mais lento, de modo que um

novo hardware é necessário, a fim de melhorar o desempenho.
 ENGENHARIA DE SOFTWARE
07 PROCESSO DE SOFTWARE

Processo de software pode ser definido pelo conjunto de atividades que

leva à produção de um produto de software. Embora existam muitos
processos de software diferentes, algumas atividades fundamentais são
comuns a todos eles, como:
• Especificação de Software;
• Projeto e Implementação;
• Validação de Software;
• Evolução de Software.
Os processos de software podem ser aprimorados por meio da
padronização e utilização de modelos.
A padronização é um passo inicial e importante na introdução de novos
métodos e técnicas de engenharia de software, também quanto a
utilização de suas boas práticas.
 ENGENHARIA DE SOFTWARE
08 MODELOS DE PROCESSO DE SOFTWARE

Um modelo de processo de desenvolvimento de software pode ser visto

como uma representação, ou abstração dos objetos e atividades envolvidas
no processo de software. Além disso, oferece uma forma mais abrangente
e fácil de representar o gerenciamento de processo de software e
consequentemente o progresso do projeto.
Exemplos de alguns modelos de processo de software:
• Cascata - com fases distintas de especificação, projeto e
desenvolvimento;
• Evolucional ou Prototipação - especificação, projeto e desenvolvimento
de protótipos;
• Espiral - ciclos completos de especificação, projeto e desenvolvimento;
• Iterativo e incremental - evoluções subsequentes iterativamente;
• Componentizado - reuso através de componentes já existentes;
• Ágil.
 ENGENHARIA DE SOFTWARE
08 MODELOS DE PROCESSO DE SOFTWARE

Seleção de modelos de ciclo de vida

A escolha de um modelo de ciclo de vida deve considerar as características
do contexto de projeto ao qual será aplicado. Estas são algumas questões
que devem ser respondidas para a seleção de um modelo de ciclo de vida:
1. Qual o nível de compreensão do usuário e desenvolvedores em relação aos requisitos no
início do projeto? É provável que a compreensão mude significativamente durante o
desenvolvimento do projeto?
2. Qual o nível de compreensão dos desenvolvedores em relação a arquitetura do sistema? É
provável que mudanças na arquitetura do sistema ocorram no meio do caminho?
3. Qual nível de confiança é necessário?
4. O quanto é necessário planejar e projetar durante o projeto prevendo mudanças em
versões futuras?
5. Qual o nível de riscos implícitos no projeto?
6. Pode ser limitado em um cronograma?
7. É necessário habilidade para realizar correções no meio do projeto?
8. É necessário mostrar ao cliente o progresso durante o projeto?
9. É necessário demonstrar ao usuário aspetos gerenciais durante o projeto?
 ENGENHARIA DE SOFTWARE
09 MODELO CASCATA

O modelo em cascata é um modelo de desenvolvimento de software

sequencial no qual o desenvolvimento é visto como um fluir constante para
frente (como uma cascata) através das fases de análise de requisitos,
projeto, implementação, testes (validação), integração, e manutenção de
software.
O modelo em cascata move-se para a próxima fase
somente quando a fase anterior está completa e
perfeita.
O desenvolvimento de fases no modelo em
cascata são discretas, e não há pulo para
frente, para trás ou sobreposição entre elas.

Há vários modelos em cascata

modificados que podem ser
incluídos como variações maiores ou
menores deste processo.

Figura - Modelo em cascata (estático)

 ENGENHARIA DE SOFTWARE
09 MODELO CASCATA

Os nomes dados a cada passo variam, assim como varia a definição exata
de cada um deles, mas basicamente o ciclo de vida começa com a análise
de requisitos movendo-se de seguida para a fase de desenho, codificação,
implementação, teste e finalmente manutenção do sistema.
Uma das grandes falhas deste modelo é o fato dos requisitos estarem
constantemente a mudar já que os negócios e ambiente em que se inserem
mudam rapidamente. Isto significa que não faz sentido parar os requisitos
durante muito tempo, enquanto o desenho e implementação do sistema
são completados.
No modelo em cascata original de Royce (1970), as seguintes fases são
seguidas em perfeita ordem:
1) Levantamento de requisitos
2) Projeto 5) Teste e depuração
6) Instalação
3) Construção (implementação ou codificação)
7) Manutenção
4) Integração
 ENGENHARIA DE SOFTWARE
09 MODELO CASCATA

Análise e definição dos requisitos

Nesta etapa, estabelecem-se os requisitos do produto que se deseja

desenvolver, o que consiste usualmente nos serviços que se devem
fornecer, limitações e objetivos do software.

Sendo isso estabelecido, os requisitos devem ser definidos de uma maneira

apropriada para que sejam úteis na etapa seguinte.

Esta etapa inclui também a documentação e o estudo da facilidade e da

viabilidade do projeto com o fim de determinar o processo de início de
desenvolvimento do projeto do sistema; pode ser vista como uma
concepção de um produto de software e também como o início do seu ciclo
de vida.
 ENGENHARIA DE SOFTWARE
09 MODELO CASCATA

Projeto do sistema
O projeto do sistema é um processo de vários passos que se centraliza em
quatro atributos diferentes do sistema: estrutura de dados, arquitetura do
software, detalhes procedais e caracterização das interfaces. O processo de
projeto representa os requisitos de uma forma que permita a codificação
do produto (é uma prévia etapa de codificação). Da mesma maneira que a
análise dos requisitos, o projeto é documentado e transforma-se em uma
parte do software.

Implementação
Esta é a etapa em que são criados os programas. Se o projeto possui um
nível de detalhe elevado, a etapa de codificação pode implementar-se
automaticamente. A princípio, sugere-se incluir um teste unitário dos
módulos nesta etapa; nesse caso, as unidades de código produzidas são
testadas individualmente antes de passar a etapa de integração e teste
global.
 ENGENHARIA DE SOFTWARE
09 MODELO CASCATA

Teste do sistema
Concluída a codificação, começa a fase de teste do sistema. O processo de
teste centraliza-se em dois pontos principais: as lógicas internas do
software e as funcionalidades externas. Esta fase decide se foram
solucionados erros de “comportamento” do software e assegura que as
entradas definidas produzam resultados reais que coincidam com os
requisitos especificados.

Manutenção
Essa etapa consiste na correção de erros que não foram previamente
detectados, em melhorias funcionais e de preferência e outros tipos de
suporte. A etapa de manutenção à parte do ciclo de vida do produto de
software e não pertence estritamente ao seu desenvolvimento.
 ENGENHARIA DE SOFTWARE
10 MODELO EVOLUCIONÁRIO

Proposto por Boehm, em 1986, com o objetivo de integrar os diversos

modelos existentes na época, eliminando suas dificuldades e explorando
seus pontos fortes.
Assume que o processo de
desenvolvimento ocorre em
ciclos, cada um contendo
fases de avaliação e
planejamento onde a opção
de abordagem para a próxima
fase é determinada.

É um modelo cíclico e não

linear que visa aproveitar as
qualidades dos ciclos de vida
clássico e de prototipagem
com a inclusão de um novo
elemento: a Análise de Riscos.
 ENGENHARIA DE SOFTWARE
10 MODELO EVOLUCIONÁRIO

O desenvolvimento evolucionário baseia-se na ideia de uma

implementação inicial, expondo o resultado aos comentários do usuário e
refinando-o por meio de versões até que um sistema adequado venha a ser
construído. Existem dois tipos fundamentais de desenvolvimento
evolucionário:
• Desenvolvimento Exploratório;
A partir de propostas do cliente/usuário.

• Prototipação;
Um protótipo exploratório é projetado para ser como um pequeno
"experimento“, a fim de testar algumas suposições importantes sobre o
projeto. Ele pode ser tanto pequeno quanto algumas centenas de linhas de
código, criadas para testar o desempenho de um software. Caracteriza-se
também por uma maneira de esclarecer os requisitos.
 ENGENHARIA DE SOFTWARE
10 MODELO EVOLUCIONÁRIO

Vantagens em relação ao cascata

• Logo que se coleta os requisitos, inicia-se o desenvolvimento e
implementação.

Desvantagens
• A documentação é mais pobre, o próprio projeto é praticamente a
documentação, obrigando os ingressantes na equipe a ter que estudar o
código para compreender o projeto.

Pontos de atenção
• A prototipação não é indicada para projetos longos onde a equipe pode
ser alterada constantemente.
• Deve-se evitar protótipos descartáveis quando se tem problemas com
cronograma.
 ENGENHARIA DE SOFTWARE
11 MODELO ESPIRAL

O modelo Espiral foi proposto por Barry Boehm, reúne características dos
modelos Cascata e Prototipação acrescentando ainda em sua base a análise
de riscos. Consiste em agregar funcionalidades ao sistema de forma
evolutiva, apresentando resultados parciais em relação à meta desejada
(final do desenvolvimento do sistema).

Cada giro na espiral (iniciando a partir do centro e avançando para fora)

representa uma nova fase. Esse processo evolutivo permite que novas
versões possam ser construídas progressivamente. Os resultados que são
apresentados devem ser operacionais, isto é, devem ser implantados para
utilização do cliente. Esse tipo de ciclo de vida permite, ainda, que sejam
adaptados novos métodos ao longo do desenvolvimento do sistema.

A adoção do modelo Espiral proporciona algumas vantagens. Teoricamente,

quanto mais tempo e recursos forem destinados, ou seja, quanto mais
iterações na espiral, menor serão os riscos sobre o projeto.
 ENGENHARIA DE SOFTWARE
11 MODELO ESPIRAL

Outra vantagem em relação a modelos sequenciais é a execução de

atividades de verificação presentes ao final de cada iteração que permitem
um melhor controle gerencial sobre o projeto.
Uma desvantagem do
modelo refere-se a
situações em que o
projeto é considerado
simples e os riscos são
modestos. Neste caso
os projetos podem
não demandar a
flexibilidade e/ou
gerenciamento dos
riscos proporcionados
pelo modelo.
 ENGENHARIA DE SOFTWARE
11 MODELO ESPIRAL

PRESSMAN apresenta o modelo divido em 6 regiões: comunicação com o

cliente, planejamento, análise de riscos, engenharia, construção e evolução
e avaliação do cliente. O número de tarefas por regiões pode variar
conforme o tamanho e complexidade do projeto. Desta forma, o modelo
pode ser adaptado conforme as características do projeto.
 ENGENHARIA DE SOFTWARE
12 PROTOTIPAÇÃO

Muitas vezes, o cliente define um conjunto de objetivos gerais para o

software, mas não identifica requisitos de entrada, processamento e saída
detalhados. Em outros casos, o desenvolvedor pode não ter certeza da
eficiência de um algoritmo, da adaptabilidade de um sistema operacional
ou da forma que a interação homem-máquina deve assumir. Nessas, e em
muitas outras ocasiões, uma abordagem de prototipação à engenharia de
software pode representar a melhor abordagem.
O modelo pode assumir uma das três formas:
• Operacionais – quando aprovados pelo usuário, estão prontos para
utilização (geração de produtos acabados. Exemplo: access).
• Semioperacionais – quando são necessárias poucas modificações no
protótipo.
• Não operacionais – quando são voltados para análise de pontos
específicos.
 ENGENHARIA DE SOFTWARE
12 PROTOTIPAÇÃO

Como todas as abordagens ao desenvolvimento de software, a

prototipação inicia-se com a coleta dos requisitos. O desenvolvedor e o
cliente reúnem-se e definem os objetivos globais para o software,
identificam as exigências conhecidas e esboçam as áreas em que uma
definição adicional é obrigatória.
Ocorre, então, a elaboração de um "projeto
rápido“ que concentra-se na representação
daqueles aspectos do software que serão
visíveis ao usuário (isto é, abordagens de
entrada e formatos de saída). O projeto
rápido leva à construção de um protótipo que
é avaliado pelo cliente/usuário e é usado
para refinar os requisitos para o software a
ser desenvolvido.
Um processo de interação ocorre quando é feita a "sintonia fina"
do protótipo, capacitando, ao mesmo tempo, o desenvolvedor a
compreender melhor aquilo que precisa ser feito.