Mod.01.MPS_Engenharia&QualidadeSoftware_V.28.09.06

assegurar que todos os 
requisitos do software sejam atendidos. Recomenda-se que os testes sejam feitos à 
medida que as unidades individuais vão sendo integradas (testes de integração) e que, 
ao final da integração, o sistema completo seja testado novamente (teste de sistema). 
Por esse motivo, muitas vezes a Integração é considerada como parte integrante da 
Implementação. No capítulo 5, seção 5.4, as atividades de Testes serão detalhadas. 
Na etapa de Operação e Manutenção, o sistema é instalado e colocado em 
Operação. Posteriormente, quando erros forem encontrados no sistema ou quando 
forem solicitadas mudanças nos requisitos, o sistema entra numa etapa de 
Manutenção. As atividades dessa etapa serão detalhadas no capítulo 5, seção 5.6. 
Modelos de Ciclo de Vida do Processo de Software 
 
29
Na sua forma mais simples, o modelo cascata não apresenta iterações, como 
visto na Figura 3.1. Na prática, porém, o processo de desenvolvimento de software 
pode ter etapas que são desenvolvidas em paralelo e de forma iterativa (vide Figura 
3.2), pois durante uma determinada etapa, problemas existentes na etapa anterior 
podem ser descobertos (ex: novos requisitos podem ser descobertos durante a 
realização da etapa de projeto, o que implica uma iteração para a etapa especificação 
e análise de requisitos). 
 
Figura 3.2: O Modelo Cascata com Iterações 
Outra limitação do modelo cascata é que o mesmo não contempla atividades que 
são executadas antes do início do ciclo de vida (ex: Estudo de viabilidade), bem como 
atividades que são executadas durante todo o ciclo de vida do software (ex: 
Planejamento e Gerenciamento, Verificação e Validação, Gerência de Configuração e 
Documentação). 
O Estudo de viabilidade deve ser executado antes do início do projeto de 
software e tem por objetivo: delinear o escopo do problema a ser resolvido; identificar 
alternativas de solução; identificar seus custos e tempo para execução; identificar 
potenciais benefícios para o usuário. O ideal é fazer uma análise profunda do 
problema para se produzir um estudo de viabilidade bem fundamentado. Na prática, 
porém, tal análise tem sido superficial devido a limitações de tempo e de custo. Como 
não se tem certeza de que a proposta para a execução do serviço será aceita pelo 
usuário em potencial, torna-se bastante arriscado investir muitos recursos nessa 
etapa. 
 
EDITORA - UFLA/FAEPE – Introdução à Engenharia de Software e Qualidade de Software 
 
30 
O Planejamento de um projeto de software se caracteriza pela definição das 
tarefas a serem realizadas durante o seu desenvolvimento, bem como pela atribuição 
de responsabilidades, custos, prazos, marcos de referência e recursos para a 
realização das mesmas. As atividades de planejamento são executadas desde o início 
do projeto até a sua finalização. 
O Gerenciamento está intimamente relacionado ao planejamento e tem o foco em 
garantir que o desenvolvimento do projeto está ocorrendo de acordo com o planejado. 
Assim, o gerenciamento de um projeto de software gera feedbacks para o 
planejamento e re-planejamento do projeto. Associadas ao gerenciamento do projeto, 
estão atividades de gerência de requisitos (gerencia as mudanças de requisitos e seus 
impactos durante o desenvolvimento do projeto), gerência de configuração (gerencia 
versões do software e as interdependências entre as partes componentes do software 
– ex: documentos e programas) e gerência da qualidade (dos produtos desenvolvidos 
e do processo de desenvolvimento). 
No capítulo 4, as atividades de gerenciamento e planejamento são detalhadas; a 
seção 5.1 apresenta um detalhamento das atividades de gerência de requisitos; a 
seção 5.5 apresenta um detalhamento das atividades de gerência de configuração; e o 
capítulo 6 detalha as atividades de gerência da qualidade. 
As atividades de Verificação e Validação estão relacionadas à gerência da 
qualidade e são responsáveis pelos feedbacks durante o desenvolvimento do software 
para as demais atividades do ciclo de vida. Na Figura 3.2, essas atividades estão 
relacionadas às iterações. 
Basicamente, Verificação investiga, em cada etapa de desenvolvimento, se o 
software que está sendo construído atende aos requisitos especificados. Como 
exemplos de atividades de Verificação, temos os testes unitários, de integração e de 
sistemas, os quais serão detalhados posteriormente na seção 5.4; e as revisões e 
inspeções que serão tratadas no capítulo 6. 
A Validação investiga se as funções oferecidas pelo software são as que o 
usuário realmente quer, pois é possível que os requisitos especificados não atendam 
às reais necessidades dos usuários. As atividades de Validação caracterizam-se por 
contarem com a colaboração direta do usuário em suas execuções. Como exemplos 
de atividades de Validação estão os testes de aceitação, que serão tratados na seção 
5.4 e a validação de requisitos que será tratada na seção 5.1. 
As atividades de Verificação e Validação são executadas durante todo o ciclo de 
vida do software, a fim de que erros e omissões sejam descobertos antes de serem 
propagados de uma etapa para outra. Isso é necessário porque quanto mais tarde 
erros e omissões forem descobertos, mais dispendioso fica para consertá-los. A 
Modelos de Ciclo de Vida do Processo de Software 
 
31
diferença entre os dois conceitos pode ser mais bem entendida através da definição 
dada por Boehm [Boehm1981]: 
“Verificação: Estamos construindo o produto da maneira certa?” 
“Validação: Estamos construindo o produto certo?” 
A principal desvantagem do modelo cascata é que boa parte do sistema não 
estará disponível até um ponto adiantado no cronograma do projeto e, geralmente, é 
difícil convencer o usuário de que é preciso paciência. Além disso, existe a dificuldade 
de acomodação das mudanças depois que o processo está em andamento. Portanto, 
esse modelo é mais apropriado quando os requisitos são bem entendidos. No entanto, 
há também algumas vantagens associadas ao modelo, pois ele oferece uma maneira 
de tornar o processo mais visível, fixando pontos específicos para a escrita de 
relatórios e, didaticamente, é uma maneira mais fácil de introduzir os principais 
conceitos de Engenharia de Software. Por esse motivo, as atividades do ciclo de vida 
do software serão detalhadas nos capítulos 4 e 5 com base neste modelo de ciclo de 
vida. 
3.2 O MODELO DE DESENVOLVIMENTO EVOLUCIONÁRIO 
O Modelo de Desenvolvimento Evolucionário (vide Figura 3.3) subdivide-se em 
dois: Programação Exploratória e Prototipagem Descartável. 
Figura 3.3: O Modelo de Desenvolvimento Evolucionário 
3.2.1 O Modelo de Programação Exploratória 
O objetivo desse modelo é o desenvolvimento da primeira versão do sistema o 
mais rápido possível. Os sistemas desenvolvidos com esse modelo caracterizam-se 
por não terem o escopo claramente definido, ou seja, a especificação do escopo é feita 
de forma intercalada ao desenvolvimento. Após o desenvolvimento de cada uma das 
EDITORA - UFLA/FAEPE – Introdução à Engenharia de Software e Qualidade de Software 
 
32 
versões do sistema, ele é mostrado aos usuários para comentários. Modificações 
sucessivas são feitas no sistema até que o mesmo seja considerado adequado. A 
principal diferença dos outros modelos é a ausência da noção de programa correto. 
Esse modelo tem sido usado com sucesso para o desenvolvimento de Sistemas 
Especialistas, no contexto da Inteligência Artificial (ex: sistemas de reconhecimento de 
voz, sistemas de diagnóstico médico etc.). 
3.2.2 O Modelo de Prototipagem Descartável 
O objetivo principal desse modelo é entender os requisitos do sistema. Tem sido 
usado com sucesso para validar partes do sistema (Interface Gráfica e aspectos do 
sistema relacionados à arquitetura – ex: performance, portabilidade etc.). Como na 
programação exploratória,