impressao (1)

Prévia do material em texto

AULA 2
ANÁLISE E MODELAGEM DE 
PROCESSOS 
Prof. Marcelo Carneiro Gonçalves 
 
 
02 
CONVERSA INICIAL 
Nesta aula, vamos conhecer alguns tipos de modelos de processo de 
software e entender qual a função de cada atividade de processo dentro da 
engenharia de software. Por isso, recordaremos sobre o que são os processos de 
softwares, e, em seguida, falaremos sobre quatro importantes modelos de 
processo de software, a saber: modelo em cascata, modelo incremental, modelo 
de desenvolvimento evolucionário e modelo de engenharia de software baseado 
em componentes. Em sequência, abordaremos as atividades do processo de 
software – sobre a qual já realizamos uma breve introdução na aula anterior –, 
contudo, iremos mais a fundo nesta aula, pois vamos deixar clara a função de 
cada atividade dos processos de software. Portanto, você aprenderá os principais 
conceitos sobre esses temas citados e que os auxiliarão na análise, modelagem 
e gestão de processos. 
CONTEXTUALIZANDO 
Uma empresa da área de desenvolvimento de software, que já atua a mais 
de 20 anos no mercado, apresenta diversas falhas, como gerência de projetos 
primitivos, gerência de requisitos rudimentares e dificuldade para estimar prazos 
de tarefas. 
Essa empresa utiliza duas maneiras de atender os pedidos dos clientes: 
1. Desenvolve um novo produto e, em seguida, identifica as necessidades 
dele. 
2. Depois de contatar o cliente, é apresentado a ele um produto, o qual sofre 
mudanças conforme as necessidades. 
Esse modelo de desenvolvimento de software é adequado? 
Para responder a esse questionamento, é necessário compreendermos 
como estão organizados os modelos e processos de softwares nas empresas. 
TEMA 1 – MODELO EM CASCATA E INCREMENTAL 
1.1 Processo de software 
Antes de iniciarmos esses modelos, vamos relembrar o que são os 
processos de software. 
 
 
03 
O processo de software é composto por um conjunto de atividades que 
originam a produção de um produto de software (Sommerville, 2007). Em geral, 
esses produtos pertencem a uma grande cadeia de sistema de negócios, ou seja, 
fazem parte de modelos de negócios de determinadas empresas que estão no 
aguardo do seu desenvolvimento para concluírem pedidos já firmados com 
clientes. 
Quando tratamos de modelos de negócios, na maioria dos casos, estamos 
falando de um processo que seja flexível e ágil. O mundo dos negócios atualmente 
está cada vez mais exigente, pois as necessidades das empresas e de clientes 
envolvidos no processo mudam quase que corriqueiramente, seja para atender a 
uma determinada demanda incerta, ou mesmo por desejo ou cancelamento de 
pedidos. A maioria dos cancelamentos ocorre pela demora ou atraso absurdo nas 
entregas dos pedidos realizados. Esse é um grande desafio a ser enfrentado pela 
engenharia de software: a demanda versus tempo de entrega. 
Para auxiliar a compreensão, tanto pela parte do cliente quanto pela equipe 
envolvida no projeto, os planejadores utilizam o framework, que são modelos de 
processos (ilustrações), geralmente por meio de fluxograma, para que possa ser 
ampliada a ideia e, consequentemente, adaptada, se for preciso. Discutir sobre o 
planejamento do processo de software é imprescindível para uma boa condução 
do projeto. 
1.2 Modelo em cascata 
No modelo em cascata, o desenvolvimento do software acontece de forma 
sequencial, como o próprio nome já diz, e se assemelha à ideia de uma cascata. 
Logo, cada etapa do processo ocorre de forma sequencial, com origem na 
definição de requisitos e término na operação e manutenção. Na figura 1, 
apresentamos o modelo em cascata (adaptado de Sommerville, 2007). 
 
 
04 
Figura 1 – Modelo em cascata 
 
Fonte: Adaptado de Sommerville, 2007. 
Na aula anterior, apresentamos os conceitos iniciais sobre esse assunto, 
contudo, nesta seção, vamos estudar de forma detalhada o que cada atividade de 
processo representa dentro de cada modelo, iniciando com o modelo em cascata. 
1.2.1 Análise e definição de requisitos 
Nesta fase, os planejadores entram em contato com o usuário do sistema 
buscando saber responder “o que” deve ser desenvolvido, ou seja, o que o cliente 
está demandando como serviço. Essa etapa é crucial para o bom 
desenvolvimento das outras seguintes, pois, falhando nesta, todas as atividades 
subsequentes conterão erros graves. 
O objetivo dessa etapa é capturar todos os requisitos para o software que 
será desenvolvido, independentemente do método que será utilizado. Busca-se 
uma correta compreensão sobre a dimensão, ou seja, qual a abrangência, o 
funcionamento do processo na organização e os dados que ela utiliza. Por meio 
dessas informações, o planejador poderá garantir um subsídio para um software 
bem-sucedido. Logo, o planejamento, a coleta de informações e análise detalhada 
do problema é fundamental para o processo nessa etapa. 
 
 
05 
É aqui também que os usuários definem as restrições associados à 
especificação do produto de software. Além disso, eles tentam informar o máximo 
de características inerentes ao serviço a ser realizado com suporte pelo software. 
É necessário definir claramente os desejos dos usuários. 
Segundo Tonsig (2008), na análise e definição dos requisitos é feito um 
levantamento macro a respeito do software a ser desenvolvido, investigando os 
recursos que serão necessários e avaliando a viabilidade de desenvolvimento, 
focando nos seguintes aspectos: técnico, econômico e operacional. Quando o 
autor referencia aspectos técnicos, ele se refere a recursos de hardware e 
software, por exemplo, computadores, licenças de softwares, banco de dados etc. 
Em relação a aspectos econômicos, refere-se à estimativa de custos que serão 
utilizados considerando todos os recursos necessários, e por fim, em relação ao 
aspecto operacional, refere-se ao impacto que causará na empresa, podendo, 
nessa etapa, até mesmo reprovar o desenvolvimento do produto de software. 
Por fim, essa fase gera uma documentação formal, registrando o 
entendimento da realidade. 
1.2.2 Projeto de sistemas de software 
Após concluída a fase de análise e definição de requisitos, inicia-se a etapa 
de projeto a qual se busca realizar uma especificação técnica do software. Nessa 
especificação deve-se considerar como será feita a interface com o usuário e o 
armazenamento de dados. 
Segundo Pressman (2007), o processo de desenvolvimento do projeto 
busca traduzir as exigências do usuário numa representação do software que 
pode ser avaliada quanto à qualidade antes que a codificação se inicie. 
Nessa fase, o desenvolvedor analisa “como” transformar os desejos do 
cliente em um projeto. 
O desenvolvedor analisa a estrutura de dados e como o projeto será 
traduzido numa linguagem de programação, bem como os testes que devem ser 
realizados. Em resumo, a etapa de projeto busca traduzir os requisitos do software 
em um conjunto de representações, podendo ser de forma gráfica, tabulares, ou 
em linguagem, que visam descrever a estrutura de dados, o procedimento 
algorítmico e as características de interface com o usuário (PRESSMAN, 2007). 
Assim como na etapa de requisitos, o projeto gera uma documentação 
formal e torna-se parte da configuração do software. 
 
 
06 
1.2.3 Implementação e teste da unidade 
Nesta etapa, as representações do projeto obtidas da etapa anterior devem 
ser convertidas numa linguagem que resulte em instruções que possam ser 
executadas pelo computador (Pressman, 2007). 
Em seguida, nessa etapa, agrupa-se um conjunto de programas, que 
Sommerville (2007) denomina “unidades de programas”, com a finalidade de 
testar separadamente cada unidade, para checarse o software possui defeitos de 
função ou lógica. Em caso de detecção de algum erro, é feito imediatamente o 
reparo dele. 
1.2.4 Integração e teste do sistema 
Concluído o primeiro teste de unidades individuais, deve-se testar agora as 
unidades em conjunto, ou seja, considerando o sistema como um todo, pois pode 
ser que problemas novos possam ser detectados. 
Além disso, o desenvolvedor deve checar se há necessidade de alguma 
integração com outros sistemas, para então adaptá-lo com os procedimentos 
necessários (Tonsig, 2008). 
1.2.5 Operação e manutenção 
Nesta fase, o sistema já foi testado e está pronto para ser liberado para 
utilização, ou seja, o sistema é colocado em produção. Em geral, essa fase inicia-
se com o treinamento dos usuários do sistema e todo grupo de pessoas 
envolvidas com a finalidade de que adquiram a cultura e entendam as 
funcionalidades do sistema que vão utilizar (Tonsig, 2008). 
Acoplado a essa etapa, temos a fase de manutenção, que acontece em 
paralelo à operação, pois, para que sejam descobertas necessidades de realizar 
manutenção, é preciso que o sistema já esteja em operação pelos usuários. 
Dessa forma, de acordo com Pressman (2007), a manutenção concentra-
se em três esferas: 
a. Correção: corresponde às mudanças necessárias para a correção dos 
possíveis erros. Mesmo que o desenvolvedor utilize garantia de qualidade 
nas atividades, é muito provável que o cliente descubra defeitos no 
software. 
 
 
07 
b. Adaptação: corresponde a adaptações no software que, com o passar do 
tempo, podem ser necessárias, por questões de mudanças de CPU, 
sistemas operacionais e periféricos. Logo, o software que foi desenvolvido 
para uma realidade ultrapassada deve ser adaptado. 
c. Aprimoramento: corresponde a aprimoramentos no software, 
representados por exigências dos usuários, motivados pelo desejo de 
adicionar funções que lhe oferecerão benefícios. 
1.2.6 Vantagens e desvantagens de um modelo em cascata 
Assim como qualquer modelo de processo de software, o modelo em 
cascata apresenta seus prós e contras a serem pensados antes de serem 
implementados. 
Como vantagens, destacamos que o modelo em cascata gera uma 
documentação após o término de cada fase, permitindo organização do projeto. 
Além disso, ele possui fácil aderência a outros modelos, pois como foi um dos 
modelos clássicos originados da literatura, em geral, foi o precursor dos modelos 
subsequentes. 
Como desvantagens, esse modelo possui divisão inflexível. Uma vez que 
as atividades são totalmente separadas (dispostas de forma sequencial, ou em 
cascata), dificulta flexibilizar determinada atividade. Em consequência disso, ele 
proporciona uma difícil reação às mudanças e compromete a evolução do projeto 
(aprimoramento decorrentes de mudanças). 
Portanto, esse modelo em cascata é sugerido para ser aplicado em 
cenários de baixa incerteza, ou seja, quando os requisitos são bem 
compreendidos e favoreçam o mínimo de mudanças futuras possíveis. 
1.3 Modelo incremental 
Este modelo de processo de software é uma variante do modelo em 
cascata estudado anteriormente. No entanto, nele a fase de projeto foi 
decomposta em projeto lógico e projeto físico (Tonsig, 2008). 
Portanto, por meio dessa abordagem é permitido que o planejador 
decomponha as atividades da fase do projeto, e por consequência, essas 
atividades podem ser executadas em paralelo. 
Com as atividades podendo ser executadas em paralelo, permite que o 
tempo dispendido na fase de projeto consiga uma redução. Logo, o tempo total 
 
 
08 
de desenvolvimento do produto software pode ser reduzido, ou investido esse 
tempo em atividades que exijam maior atenção do planejador. 
Na figura 2, é apresentado o modelo incremental, proposto em Tonsig 
(2008). 
Figura 2 – Modelo incremental 
 
Fonte: Adaptado de Tonsig, 2008. 
Esse modelo é uma adaptação do modelo mais antigo, o modelo de 
cascata, por isso denominado modelo clássico. Apesar das fases estarem citadas 
com nomes diferentes (pois se trata de uma visão de autores diferentes) a ideia 
permanece a praticamente a mesma. Como é natural de acontecer no ramo de 
sistemas de informação, as tecnologias mudam, são atualizadas, com isso não é 
fácil manter o mesmo modelo que já foi usado por muitas décadas. 
Um grande incoerente do modelo clássico consiste em especificar todos os 
requisitos de um software imediatamente no início do processo (o que contradiz a 
realidade, pois, em geral, durante o ciclo de vida do processo há a necessidade 
de acrescentar mais informações). Além disso, na fase de teste, caso aconteça 
algum problema de programação, é necessário voltar à etapa de codificação para 
rever os códigos, o que muitas vezes pode acarretar um grande tempo de revisão 
e, por consequência, um atraso no cronograma do projeto. Por isso, um modelo 
de fluxo sequencial pode não representar a realidade dos processos de softwares. 
Portanto, o modelo incremental inicia essa mudança ao adicionar 
subatividades em paralelo na fase de projeto. 
 
 
09 
TEMA 2 – MODELO DE DESENVOLVIMENTO EVOLUCIONÁRIO E BASEADO EM 
COMPONENTES 
2.1 Modelo de desenvolvimento evolucionário 
Segundo Sommerville (2007), este modelo desenvolve-se em paralelo às 
atividades de especificação, desenvolvimento e validação. O processo inicia-se 
com um desenvolvimento simplificado baseado nas especificações (requisitos) do 
cliente. Em seguida, esse sistema é refinado com essas entradas solicitadas pelo 
cliente para produzir um sistema que satisfaça às necessidades. 
A figura 3 ilustra esse modelo. 
Figura 3 – Desenvolvimento evolucionário 
 
Fonte: Adaptado de Sommerville, 2007. 
A “descrição do esboço” representa o resultado dos pedidos do usuário, e, 
então, esses pedidos são enviados às atividades de especificação, 
desenvolvimento e validação, que atuam simultaneamente. A cada saída é 
atualizado o sistema, gerando, assim, uma versão. A versão inicial é a primeira 
após ser executado o primeiro processo (nesse caso, um ciclo, que compreende 
desde a “descrição do esboço” até a etapa de validação). Na sequência, é 
executado um novo ciclo, contudo, mais refinado que o primeiro, que ao término 
também gera uma nova versão (representada pelas versões intermediárias). 
Então, esse processo se repete até que o sistema esteja completamente 
adequado e satisfaça a todas as necessidades do usuário. Em seguida, gera-se 
a versão final. 
 
 
010 
O fato de as atividades de especificação, desenvolvimento e validação 
serem intercaladas possibilita um feedback mais rápido entre as atividades. 
O modelo de desenvolvimento evolucionário para a produção de software 
é mais eficaz que a abordagem de cascata na produção de sistemas que 
satisfaçam as necessidades imediatas dos clientes (Sommerville, 2007). 
2.2 Vantagens e desvantagens do Modelo de desenvolvimento 
evolucionário 
A vantagem desse modelo é que a atividade de especificação pode ser 
desenvolvida de forma incremental, ou seja, a medida que os usuários vão 
compreendendo o sistema, eles podem sugerir modificações direto no sistema (de 
maneira incremental). 
A desvantagem desse modelo é realizar mudanças contínuas, pois utiliza 
várias versões e a tendência é de essas alterações corromperem a estrutura do 
software. Por isso, a incorporação de mudanças torna-se mais difícil (Sommerville, 
2007). 
Esse modelo é recomendado para sistemas de pequeno e médio porte, ou 
seja, sistemas com até 500 mil linhas de código. Todavia, para sistemas grandes 
e complexos, fica mais difícil utilizar essa abordagem, pois será difícil estabelecer 
uma arquitetura estável do sistema e integraras contribuições das equipes de 
trabalho. 
2.3 Caso prático 
Sommerville (2007) sugere que, para sistemas de grande porte, seja 
utilizado um mix entre as abordagens de cascata e evolucionária, ou seja, nas 
etapas em que o processo tem baixa incerteza, utiliza-se a abordagem em 
cascata, e, nas etapas de especificação (nas quais, em geral, é difícil para o 
cliente informar todas as necessidades em um primeiro encontro), poderia então 
usar a abordagem evolucionária. 
2.4 Modelo de engenharia de software baseado em componentes 
A abordagem baseada em componentes é uma das mais utilizadas 
atualmente, pois parte do princípio de que não precisamos desenvolver do zero o 
software, ou seja, se em parte do processo de desenvolvimento do sistema já 
 
 
011 
conhecemos um componente que desenvolve uma ação semelhante, fazemos 
apenas uma adaptação e o incorporamos ao próprio sistema. Em outras palavras, 
reusamos um determinado código de um sistema similar, o que nos proporciona 
ganho de agilidade no processo. 
Atualmente há empresas que desenvolvem componentes para serem 
integrados a sistemas e framework de auxílio para a integração, por exemplo, 
funcionalidade de formatação de texto, cálculo numérico etc. 
O modelo genérico é apresentado na figura 4 a seguir. 
Figura 4 – Modelo de engenharia de software baseado em componentes 
 
Fonte: Adaptado de Pressman, 2007. 
Nesse modelo, as fases de especificação de requisitos e validação de 
sistemas são semelhantes aos sistemas anteriormente já explicados. Dessa 
forma, vamos focar a explicação apenas nas fases intermediárias. 
1. Análise de componentes. Nessa etapa, já foi realizada a definição dos 
requisitos, ou seja, já sabemos o que o cliente deseja, logo, partimos para 
uma busca sobre os componentes que sejam compatíveis com o sistema 
que estamos desenvolvendo. Em geral, não encontramos correspondência 
exata, contudo, uma vez o código fonte disponível, podemos fazer 
adaptações. 
2. Modificação de requisitos. Nessa etapa, devemos voltar à etapa de 
requisitos, pois como estamos adicionando um novo componente, que em 
geral não fornece exatamente o que precisamos, e sim funções similares, 
precisamos realizar uma adaptação nos requisitos sem que afete muito os 
desejos do usuário. Caso note-se que o projeto está mudando 
demasiadamente, ou seja, é impossível de implementar, o componente é 
descartado e a busca é realizada novamente. 
 
 
012 
3. Projeto de sistema com reuso. Nessa etapa, é desenvolvido um modelo de 
trabalho, ou seja, um framework que vai auxiliar a integração desse 
componente com o sistema. 
4. Desenvolvimento e integração. Nessa etapa, é desenvolvido o software do 
sistema e integrado os componentes que foram aceitos para criar um novo 
sistema com os conceitos do reuso (Pressman, 2007). 
2.3 Vantagens de desvantagens do modelo de engenharia de software 
baseado em componentes 
A vantagem desse modelo é que reduz a quantidade de software a ser 
desenvolvido, uma vez que buscamos implementar componentes que exerçam 
atividades similares e auxiliem no sistema que está em desenvolvimento. 
Outra vantagem é que reduz os custos e riscos de falhas na execução do 
sistema, ou erros no código e sua funcionalidade. 
Além disso, a entrega do produto de software é acelerada, pois o tempo 
que seria gasto com o desenvolvimento do software por inteiro é reduzido quando 
resolvemos integrar componentes. 
Contudo, como desvantagem, nota-se que eles comprometem os requisitos 
definidos inicialmente com os clientes, pois é preciso realizar pequenas 
modificações. 
Outra desvantagem é que isso pode comprometer a evolução dos sistemas 
se os componentes reusáveis não estiverem sob total controle da equipe do 
projeto, uma vez que não foram os autores de parte dos componentes 
(Sommerville, 2007). 
TEMA 3 – ATIVIDADE DE ESPECIFICAÇÃO DE SOFTWARE 
Como já conversamos sobre alguns modelos de softwares existentes e 
sabemos sobre as suas finalidades, agora trataremos das atividades genéricas 
que compõe basicamente todos esses processos, ou seja, em geral, os modelos 
de softwares foram baseados nessas atividades para originarem-se em modelos. 
Na aula 1 apresentamos uma ilustração proposta por Sommerville (2007) 
com as atividades genéricas do software. 
 
 
013 
Figura 5 – Atividades genéricas do software 
 
 
Fonte: Adaptado de Sommerville, 2007. 
Portanto, cada atividade genérica da figura 5 apresenta um conjunto de 
subatividades, as quais serão estudadas nas seções a seguir. 
3.1 Especificação de software 
A atividade de especificação de software busca compreender e definir quais 
serviços os clientes estão solicitando. Além disso, nessa atividade são 
identificadas todas as restrições de operação e de desenvolvimento de sistemas. 
De acordo com Pressman (2007), o processo de especificação pode ser 
divido em fases, apresentadas na figura 6. 
Figura 6 – Especificação de software 
 
Fonte: Adaptado de Sommerville, 2007. 
Especificação
Desenvolvimento
Validação
Evolução
 
 
014 
A especificação do software é um estágio crítico, pois a partir dela podem 
ser conduzidos problemas posteriores no projeto e na implementação do sistema. 
Vamos explicar cada atividade dessa etapa de especificação proposta por 
Sommerville (2007): 
• Estudo de viabilidade. Nessa etapa, buscamos verificar se a empresa 
possui recursos disponíveis para oferecer o serviço ao cliente. Esses 
recursos abrangem tanto software quanto hardware na empresa. Além 
disso, é verificado se o custo do sistema será viável para comercializar. 
• Elicitação e análise de requisitos. Nessa etapa, é realizado o 
desenvolvimento de modelos (ou mesmo protótipos) que auxiliam os 
usuários a compreenderem o resultado do produto de software. 
• Especificação de requisitos. Nessa etapa, é realizada a tradução das 
informações coletadas do usuário. Nesse momento, é gerado dois 
relatórios: o requisito para o usuário, que é uma apresentação simplificada 
dos requisitos do sistema para o usuário; e o requisito para o sistema, que 
é uma descrição minuciosa da funcionalidade que o sistema vai oferecer. 
• Validação dos requisitos. Essa atividade está relacionada ao senso crítico 
sobre o documento de requisitos. São analisados o realismo, a consistência 
e a abrangência do sistema proposto. Nessa fase, muitos erros são 
detectados durante o processo. 
É importante ressaltar que as atividades do processo de especificação não 
são sequenciais, pois novos requisitos podem aparecer ao longo do processo; 
elas são, então, intercaladas. 
Nessa seção, estudamos a atividade de especificação e vimos quais são 
suas subatividades. Cada modelo de processo de software possui essa fase 
inicial, visto que é uma das etapas mais importantes e críticas de um processo de 
software. 
TEMA 4 – ATIVIDADES DE PROJETO E IMPLEMENTAÇÃO DE SOFTWARE 
Nessa seção, vamos explicar a segunda atividade genérica de software, 
que se trata do projeto e implementação de software ou projeto e implementação 
do desenvolvimento de software. Nessa fase, é realizada a conversão de todo o 
assunto levantado durante a especificação de sistema para torna-se um sistema 
executável, ou seja, é o processo de converter as necessidades do usuário em 
um programa de computador. 
 
 
015 
Nessa etapa, são descritos a estrutura de software a ser implementada, os 
dados do sistema, as interfaces e os algoritmos (Sommerville, 2007). Na figura 7, 
apresentamos o modelo de processo de projeto. 
Figura 7 – Processo do projeto 
 
Fonte: Adaptado de Sommerville, 2007. 
Nesse modelo são apresentadas as atividades de projetoe os produtos de 
projeto. As atividades são: especificação de requisitos, projeto de arquitetura, 
especificação abstrata, projeto de interface, projeto de componente, projeto de 
estrutura de dados, projeto de algoritmo. Os produtos são: arquitetura de sistema, 
especificação de software, especificação de interface, especificação de 
componentes, especificação de estrutura de dados e especificação de algoritmos. 
Portanto, cada atividade gera um produto, e esse produto passa a ser a 
entrada para a atividade subsequente. Os resultados finais dessa etapa consistem 
nos algoritmos e nas estruturas de dados que serão implementados (Sommerville, 
2007). 
TEMA 5 – VALIDAÇÃO E EVOLUÇÃO DE SOFTWARE 
5.1 Validação 
A fase de validação de software, conhecida por outros autores como fase 
de verificação e validação (V&V), corresponde às últimas fases do projeto de 
desenvolvimento do software. Nessa etapa é verificado se o sistema está em 
conformidade com o que foi requerido pelo cliente na fase de especificação, visto 
anteriormente. A etapa de validação é uma das mais importantes para o projeto, 
pois nela vamos verificar se o produto do software atende às expectativas dos 
usuários (Sommerville, 2007). 
 
 
016 
O processo de validação, na verdade, está presente em cada estágio do 
processo de software. 
A figura 8 apresenta o processo de teste. 
Figura 8 – Processo de teste 
 
Fonte: Adaptado de Sommerville, 2007. 
Este processo é divido em três etapas, definidas por Sommerville (2007): 
• Teste de componente. Nessa etapa, os componentes (funções, classes de 
objetos, grupos de entidades) são testados separadamente com a 
finalidade de saber se estão operando corretamente. 
• Teste de sistema. Nessa etapa, os componentes são integrados ao sistema 
para serem testados em conjunto. 
• Teste de aceitação. Essa é a última etapa antes da aceitação do sistema. 
Nesse momento, os dados fornecidos pelos clientes são testados no 
sistema ao invés de serem simulados. 
Essa etapa de validação é importante também para encontrar erros, seja 
de componentes, seja do sistema integrado. A medida que os erros são 
descobertos, é iniciado o processo de correção, ou seja, de depuração do erro. 
Logo, inicia-se o processo de debugging. A figura a seguir apresenta a rotina 
desse processo. 
Figura 9 – Processo de debugging 
 
Fonte: Adaptado de Sommerville, 2007. 
 
 
017 
Inicialmente localiza-se o erro, e, em seguida, projeta-se o reparo desse 
erro, verificando os recursos necessários para isso. Posteriormente, realiza-se o 
reparo do erro, e uma vez corrigido, o programa é retestado; em caso de 
ocorrência de erro, o processo é refeito. 
5.2 Evolução 
A evolução de um software é muito mais barata que a evolução em 
hardware. Quando tratamos aqui o termo evolução, estamos nos referindo à 
mudança, adaptação requerida pelo cliente, atualização de versão etc. Essa 
flexibilidade do software é um dos principais motivos pelos quais cada vez mais 
estão se investindo em estudos e planejamento de software. 
Essa etapa de evolução trata diretamente das mudanças que são 
necessárias para o software, seja por obsolescência de uma versão, seja por 
mudanças nos requisitos. Caracteriza-se por ser a etapa mais cara para o 
processo de software, pois as mudanças quase sempre ocorrerão, então no ciclo 
de vida do processo, a evolução, em geral, é a maior. Apesar de ser a mais cara, 
caracteriza-se como a menos desafiadora para os programadores, pois a etapa 
de desenvolvimento “já passou”, em outras palavras, a parte mais difícil, de 
planejamento e desenvolvimento do software, já foi realizada. 
Atualmente, a linha que separa a fase de evolução da fase de manutenção 
(validação) está cada vez mais tênue, ou seja, essa diferença tem se tornado cada 
vez mais irrelevante. Logo, é mais prático considerar essas fases como contínuas 
ao invés de separadas. Portanto, na engenharia de software é mais cômodo 
analisar o processo evolutivo de forma dinâmica, em que, à medida que o cliente 
solicita mudanças, o processo passa por uma evolução, em resposta. A figura 10 
apresenta o processo de evolução. 
Figura 10 – Processo de evolução 
 
Fonte: Adaptado de Sommerville, 2007. 
 
 
018 
FINALIZANDO 
Fica claro que a empresa analisada no início de nossa apresentação não 
tem processos de desenvolvimento de software bem definidos, pois não 
estabelece padrões que não se assemelham nem a abordagem mais clássica que 
conhecemos (modelo cascata). 
Em síntese, com essa aula tivemos uma ideia de como funciona um 
processo de software, por meio de um conjunto coerente de atividades. 
Aprendemos também quatro modelos de processo de software importantes para 
o gerenciamento de projetos, e por fim, as atividades de processos de softwares 
que são utilizadas na engenharia de software. 
Saiba mais 
Assista ao vídeo informativo sobre metodologias ágeis (processos de 
desenvolvimento de software ágeis). 
Disponível em: <https://www.youtube.com/watch?v=tz5_-dDeq4Y>. 
Acesso em: 28 set. 2017. 
 
 
 
019 
REFERÊNCIAS 
PRESSMAN, R. S. Engenharia de software. São Paulo: Pearson Makron, 2007. 
SOMMERVILLE, I. Engenharia de software, 8. ed. São Paulo: Pearson Addison-Wesley, 
2007. 
TONSIG, S. L. Engenharia de software – análise e projeto de sistemas. 2. ed. revista e 
ampliada. Rio de Janeiro: Ciência Moderna, 2008.