E4_ENSO

Prévia do material em texto

ENGENHARIA DE 
SOFTWARE
Roque Maitino Neto
E-book 4
Neste E-Book:
INTRODUÇÃO ����������������������������������������������������������� 3
SOFTWARE ���������������������������������������������������������������� 5
Evolução de Software ���������������������������������������������������������������5
Manutenibilidade ���������������������������������������������������������������������13
Gestão de mudanças ��������������������������������������������������������������14
Gestão de Projeto de Desenvolvimento de Software �����������23
Pessoas �����������������������������������������������������������������������������������24
Produto ������������������������������������������������������������������������������������25
Processo ����������������������������������������������������������������������������������26
Projeto ��������������������������������������������������������������������������������������27
CONSIDERAÇÕES FINAIS ������������������������������������31
REFERÊNCIAS BIBLIOGRÁFICAS & 
CONSULTADAS ������������������������������������������������������� 33
2
INTRODUÇÃO
A ordem natural das coisas sugere que tudo expe-
rimenta evolução, que pode ser efetivada durante 
milênios ou de uma geração para outra� Se tomar-
mos como exemplo elementos do nosso cotidiano, 
observaremos que o aprimoramento de técnicas, 
processos, meios, métodos e instrumentos aplicados 
às atividades que desempenhamos tem proporciona-
do evolução jamais observada em nossa qualidade 
de vida� Inevitável, essa evolução afeta também as 
características dos seres vivos, as formas de comu-
nicação e nosso modo de vida de uma maneira geral�
Bem, se tudo muda, não haveria motivo para que nos-
sos sistemas permanecessem sem evolução durante 
seu ciclo de vida� Ao contrário do que alguns podem 
imaginar, essa evolução não está apenas atrelada à 
correção de defeitos pela qual um sistema inevita-
velmente passa, mas a uma série de providências 
colocadas em prática para que o produto continue 
atendendo aos requisitos do cliente, que também 
são dinâmicos� Essas providências incluem, por-
tanto, a adaptação a um novo ambiente, a inclusão 
de novas características solicitadas pelo cliente e, 
naturalmente, a correção de defeitos�
Essa evolução, contudo, requer um criterioso plane-
jamento e o devido acompanhamento para que seja 
bem-sucedida� Ao conjunto de providências contidas 
no planejamento, execução e acompanhamento da 
evolução do software daremos o nome de Gestão 
3
de Mudanças e o abordaremos como segundo as-
sunto do nosso conteúdo. Por fim, serão abordados 
elementos do gerenciamento do projeto de desen-
volvimento de um software, e esse tema merecerá 
nossa atenção por um motivo muito simples: assim 
como qualquer empreitada, a criação de um sistema 
requer estimativas, elaboração de cronograma, aná-
lise de riscos e outras providências que visam a dar 
ao gerente do projeto a segurança necessária para 
alcançarem a boa conclusão do trabalho�
Com a discussão desses assuntos, esperamos que 
você compreenda aspectos da evolução de um sof-
tware, tenha contato com os tipos de manutenção 
aplicáveis, e comece a desenvolver habilidade em 
gerir um projeto de desenvolvimento de software�
Bons estudos!
4
SOFTWARE
Será possível afirmarmos que um software envelhece? 
Se essa questão puder ser respondida afirmativamen-
te, como então podemos retardar esse envelhecimento 
e manter nossos sistemas sempre jovens? Quando o 
assunto é evolução de um software, muitos elementos 
devem ser considerados para que ele acompanhe 
o ambiente no qual está inserido e que continue a 
gerar valor� Nesse contexto, a correta gestão das mu-
danças aparece como fator decisivo para o sucesso 
das atividades de manutenção, além de aumentar as 
chances de que a decisão entre investir na manuten-
ção do sistema atual ou iniciar o projeto de um novo 
produto mostre-se correta, no decorrer do tempo� Nas 
próximas páginas, você terá contato com elementos 
conceituais da manutenção, com algumas leis da evo-
lução de um software, com situações que deverão re-
querer boa gestão do processo dessa evolução e, por 
fim, com aspectos do gerenciamento de um projeto 
de desenvolvimento de software� Sigamos adiante!
Evolução de Software
Fica cada vez mais difícil imaginarmos um item do 
nosso cotidiano que não tenha passado por alguma 
transformação, no decorrer dos anos� As roupas que 
usamos, nossos carros e os nossos telefones celu-
lares são alguns poucos exemplos de produtos que 
têm sido transformados desde que os conhecemos� 
As motivações para que seus fabricantes invistam 
5
em evolução são inúmeras, mas todas parecem 
convergir para um ponto: a viabilidade comercial do 
produto� Mais uma vez, essas considerações todas 
servem também para o universo dos sistemas de 
computador que criamos e a evolução desses pro-
dutos será o tema central desta primeira parte do 
nosso conteúdo�
Ao utilizar metodologia adequada para criação do 
software, respeitar as regras de gestão de projetos e 
capacitar continuamente sua equipe, uma empresa 
de desenvolvimento espera que suas entregas sejam 
capazes de satisfazer aos requisitos do cliente� No 
entanto, mesmo com esse aparato técnico, espera-se 
que o software sofra alterações e evolua. Quando o 
produto é colocado em operação, defeitos são des-
cobertos (sobretudo pelo usuário), o ecossistema de 
execução do sistema muda ou, inexoravelmente, os 
requisitos do cliente mudam� Por isso, a manutenção 
é tão necessária e deve receber o mesmo grau de 
atenção que outras fases do projeto�
Mais adiante, teremos oportunidade de tratar as mu-
danças de requisitos como um dos mais justos mo-
tivos para a promoção da evolução de um sistema, 
mas é necessário pontuar desde já que tais mudan-
ças motivam a criação de novas versões do sistema, 
como ação efetiva em prol da sua evolução� Essas 
novas versões incorporam mudanças e atualizações 
ao sistema atual, e nos permite enxergar o processo 
evolucionário como uma espiral em que as atividades 
de requisitos, projeto, implementação e testes estão 
todas presentes, conforme ilustrado na figura 1.
6
Observe que o processo é iniciado com a versão 1 
do sistema� Depois de entregue, essa versão passará 
por mudanças que darão ensejo à criação da sua 
segunda versão, e assim por diante� Embora esteja-
mos tratando dessas versões como um fenômeno 
com certa regularidade temporal, a necessidade de 
evolução do software em questão pode ser detectada 
antes mesmo do lançamento da primeira versão�
Especificação
Início
Versão 2
Versão 3
Versão 1
Especificação
Implementação
Validação
Figura 1: Modelo evolutivo em espiral� Fonte: Sommerville 
(2018, p� 233)
Outra ressalva necessária neste contexto é a que 
relaciona esse modelo de evolução a casos em que a 
mesma organização é responsável pelo sistema em 
toda a sua vida útil� Em situações em que o cliente 
passa a contar com outra empresa para suporte e 
evolução do produto, há chance de que o processo 
evolutivo sofra descontinuidade, já que nem toda 
7
documentação de requisitos e de projeto pode ser 
transferida de uma organização para a outra� Na vi-
são de Sommerville (2018), quando a transição do 
desenvolvimento de um produto para sua evolução 
não é suave, o processo de modificação do software 
recebe o nome de manutenção�
Na Engenharia de Software, o termo manutenção 
está muito associado à evolução do software� A 
manutenção de software é como se denomina, em 
geral, o processo de adaptação e otimização de um 
software já desenvolvido, bem como a correção de 
defeitos descobertos após sua entrega� Uma equipe 
de desenvolvimento não poderá abrir mão da apli-
cação da manutenção em seus produtos, pois essa 
é a forma de preservar sua qualidade ao longo do 
tempo� Caso a manutenção não seja aplicada, haverá 
uma deterioração do valor percebido desse software 
e, portanto, de sua qualidade� (WAZLAWICK, 2013)
FIQUE ATENTO
Qualquer trabalho efetuado para modificar o sis-
tema, depois queele estiver em operação é con-
siderado como manutenção� Muitas pessoas pen-
sam na manutenção de sistema de software como 
pensam na manutenção de hardware: o reparo 
ou a substituição de peças com defeito ou que 
não estão funcionando apropriadamente� Porém, 
a manutenção de software não pode ser vista da 
mesma maneira� (PFLEEGER, 2004, p� 379)
8
Ao invés de se efetivar por meio de meras trocas 
de componentes, a manutenção de um software 
acontece por meio de atividades que se asseme-
lham àquelas empreendidas durante o desenvolvi-
mento do produto, incluindo análise de requisitos, 
elaboração do projeto, a efetiva revisão do código, 
a validação das modificações feitas e a atualização 
da documentação do sistema. Por isso, os profis-
sionais envolvidos na manutenção não devem ser 
apenas os desenvolvedores, embora sejam eles os 
que possuem maior conhecimento do código e da 
estrutura do sistema�
Na visão de Pfleeger (2004), a manutenção enfoca, 
simultaneamente, quatro aspectos principais da evo-
lução de um sistema:
1. manter o controle sobre as funções do cotidiano 
do sistema�
2. manter o controle sobre as modificações realiza-
das no sistema�
3. aperfeiçoar as funções já existentes�
4. tomar medidas preventivas para que o desempe-
nho não sofra decréscimo para níveis não aceitáveis�
Fica claro, então, que a manutenção é indispensável 
para diversas finalidades, incluindo a continuidade do 
atendimento aos requisitos do usuário, a correção de 
falhas, a melhoria do produto entregue, as eventuais 
integrações com outros sistemas, a adaptação a um 
novo ambiente operacional ou simplesmente para re-
tirar o produto de operação� Considerando os quatro 
9
aspectos da evolução do software que a manutenção 
enfoca e, por causa da sua ampla aplicabilidade, ela 
foi categorizada, conforme Pfleeger (2004):
Manutenção corretiva
Em poucas palavras, trata-se da modificação reativa 
em um produto de software, executada após a entre-
ga, com o objetivo de corrigir problemas descobertos� 
Com o sistema já em operação, à medida que os 
defeitos se manifestam, eles são relatados ao pes-
soal de manutenção, que realiza a devida correção 
no código e promove mudanças nos artefatos gera-
dos durante o ciclo de construção do sistema, dos 
requisitos até a documentação� Eventualmente – e 
como forma de sanar uma situação emergencial – o 
reparo inicial pode ser temporário, e incluir alguma 
providência rápida para manter o sistema em fun-
cionamento. Posteriormente, a correção definitiva 
pode ser aplicada posteriormente�
Manutenção adaptativa
Trata-se da modificação aplicada em um produto de 
software após a entrega do produto, com a finalida-
de de manter o software utilizável em um ambiente 
alterado ou em alteração� Tomemos como exemplo 
a seguinte situação: um Sistema de Gerenciamento 
de Banco de Dados (SGBD) em operação é atualizado 
para uma versão mais atual� Por causa dessa atuali-
zação, as rotinas de acesso ao disco necessitam de 
alteração para que continuem executando essa função 
e, em decorrência desse fato, uma adaptação deverá 
ser feita� Essa manutenção adaptativa, portanto, não 
10
foi aplicada para que um defeito fosse corrigido, mas 
para que o sistema continuasse em operação�
Manutenção perfectiva
Nada é tão bom que não possa ser melhorado, não 
é mesmo? A manutenção perfectiva é aplicada em 
um produto de software a fim de melhorar seu de-
sempenho e/ou sua manutenibilidade� A necessidade 
em realizar uma manutenção desse tipo não nasce, 
via de regra, da detecção de defeitos no sistema� 
Um exemplo possível é o de um sistema que de-
pende bastante da velocidade de processamento 
para cumprir seus objetivos adequadamente� Um 
algoritmo mal escrito – com uma série de comandos 
if encadeados, por exemplo – pode fazer com que 
o desempenho seja afetado e, por consequência, a 
percepção dos usuários sobre o sistema�
Manutenção preventiva
Esse último caso está relacionado com a modifica-
ção em um software após a entrega, a fim de reparar 
falhas latentes antes que se tornem efetivas� Embora 
guarde semelhanças com o tipo anterior, essa ma-
nutenção visa a prevenir falhas, antes que elas se 
manifestem� Uma ferramenta de teste de software 
pode ser aplicada no sistema mesmo após sua en-
trega e, nessa ocasião, descobrir potencial falha�
Essa classificação de manutenções é útil também 
para que uma organização possa entender como 
seus esforços de manutenção estão sendo distri-
buídos, sobretudo no que se refere aos custos veri-
11
ficados na atividade. Considerando dados colhidos 
durante mais de 25 anos junto a desenvolvedores dos 
Estados Unidos, um estudo concluiu que a adição 
ou a modificação de funcionalidades já existentes 
responde por 58% dos custos de manutenção, com 
as atividades de adaptação a um novo ambiente e 
reparo de defeitos respondendo pelo restante, con-
forme ilustra a figura 2.
Reparo de
defeitos
(24%)
Adaptação 
ao ambiente 
(19%) Adição ou 
modificação 
de funcionalidades 
(58%)
Figura 2: Distribuição dos custos de manutenção� Fonte: 
Sommerville (2018, p� 247)
Foi possível constatar, portanto, que é mais caro acres-
centar novas características a um sistema durante a 
manutenção do que implementá-las já no desenvol-
vimento inicial� A necessidade de se compreender o 
sistema para, então, realizar a modificação é um dos 
fatores que faz essa atividade ficar mais cara, justa-
mente por demandar mais tempo da equipe�
12
Manutenibilidade
Antes de avançarmos rumo ao próximo item do texto, 
vale a abordagem do que chamamos de manute-
nibilidade de um sistema� Ele expressa o grau de 
facilidade com que um software pode sofrer melho-
ramentos, adaptações ou correções para satisfazer 
os requisitos do sistema� De qualquer modo, ela deve 
ser perseguida durante o processo de desenvolvi-
mento do software, de modo a minimizar os custos 
futuros de manutenção�
Você poderá também encontrar menções à manu-
tenibilidade como uma característica do sistema 
passível de ser medida pelo tempo médio gasto para 
a realização de reparos no sistema� Para que essa 
medição seja possível, Pfleeger (2004) recomenda 
o registro das seguintes informações:
 ● O momento em que o problema é relatado pelo 
usuário�
 ● Eventual tempo perdido devido ao atraso de outros 
setores envolvidos na manutenção�
 ● O tempo exigido para que a equipe de manutenção 
analise o problema�
 ● O tempo necessário para especificar quais mu-
danças deverão ser feitas no sistema�
 ● O tempo necessário para que essas mudanças 
sejam, de fato, efetivadas�
 ● O tempo necessário para documentar as mudan-
ças feitas�
13
É certo que esse conjunto de dados, quando reunido 
e compilado corretamente, será útil para tomadas 
de decisões relacionadas ao grau de manutenibili-
dade de um sistema� No entanto, haverá ocasiões 
em que outros tipos de decisões serão necessários 
e, para isso, a força de trabalho responsável pela 
evolução do sistema deverá contar com alguém com 
habilidade de gestão de situações� É justamente da 
gestão aplicada às mudanças que trata nossa pró-
xima seção�
Gestão de mudanças
Embora inevitáveis, as mudanças nem sempre são 
simples de serem implementadas. Quando realizadas 
em um software, elas podem ser mais complexas ain-
da, considerando a grande quantidade de elementos 
que o compõe e as associações entre eles� Este fato, 
por trivial que seja, já serve para compor o conjunto 
de fatores que justificam a necessidade de que essas 
mudanças sejam gerenciadas�
Nesse sentido, uma das primeiras avaliações que o 
gestor (ou responsável pelo sistema) deve fazer é 
a real necessidade de se aplicar uma determinada 
manutenção, considerando a comparação entre o 
tempo (e esforço) para executá-la e o tempo neces-
sário para um novo desenvolvimento. Pfleeger (2004) 
propõe que essa comparação tenha como base os 
tempos de desenvolvimento e de manutenção de 
outros projetos, a fim de que o gestor possa ter ideia 
de quanto tempo a fase evolutiva do sistemadurará�
14
Outra avaliação, que também deve ser feita por um 
gestor, é aquela que coloca em perspectiva a evolu-
ção de um sistema com o seu declínio. Quando um 
sistema passa a requerer mudanças contínuas e 
complexas, o gestor deve decidir entre implementar 
essas mudanças ou também o substituir por um ou-
tro sistema� Essa decisão pode ser amparada pelas 
seguintes análises, de acordo com Pfleeger (2004):
 ● O custo de manutenção é muito alto?
 ● A confiabilidade do sistema é aceitável?
 ● O sistema não pode mais se adaptar a mudanças 
adicionais em um período razoável?
 ● O desempenho do sistema ainda está fora das 
restrições prescritas?
 ● As funções do sistema têm utilidade limitada?
 ● Outros sistemas realizam o mesmo trabalho, 
de forma mais ágil, segura e consumindo menos 
recursos?
 ● O custo de manutenção do hardware é alto o su-
ficiente para justificar sua substituição por um har-
dware mais novo e barato? 
Se a resposta for afirmativa para a maioria (ou a 
totalidade) das questões, há que se considerar um 
novo sistema para substituir o atual� Tomar uma 
decisão relacionada à manutenção de um sistema 
estará atrelada, normalmente, ao conhecimento que 
a equipe acumulou ao longo do tempo sobre outros 
sistemas, que já sofreram manutenção e experimen-
taram evolução� Foi possível, no entanto, agregar 
15
conclusões sobre a evolução de sistemas em geral e 
dar a esse conjunto de comportamentos o nome de 
Leis da Evolução dos Sistemas ou Leis de Lehman� 
Sem a intenção esmiuçá-las, apresentaremos as três 
primeiras do conjunto:
1. Mudança contínua: essa lei estabelece que um 
programa em constante utilização deve passar por 
mudanças contínuas, sob pena de se tornar menos 
útil progressivamente� A mudança – ou o declínio – 
continuará até que a substituição do sistema apre-
sente uma relação custo-benefício mais vantajosa� 
Os sistemas nunca estão completos, especialmente 
os de grande porte e, por isso, devem sempre evo-
luir� Os sistemas experimentam expansão quando 
a equipe responsável adiciona a ele mais recursos, 
mais funcionalidades ou quando passam a se inte-
grar a outros sistemas� Mudanças de ambientes e 
mudanças de plataforma também são fatores que 
provocam evolução em sistemas� (PFLEEGER, 2004)
2. Aumento de complexidade: essa segunda lei es-
tabelece que, quando um sistema em evolução é 
continuamente modificado, sua estrutura acaba se 
deteriorando� Por causa disso, sua complexidade au-
mentará, exceto por alguma ação que vise a reduzi-la 
ou mantê-la� A correta documentação das alterações 
pode contribuir para a redução dessa complexidade� 
Vale ainda o registro de que o termo “deteriorar” não 
tem o mesmo sentido físico quando aplicado nesse 
nosso contexto�
3. Autorregulação: o processo de evolução do sof-
tware é autorregulado próximo à distribuição normal 
16
com relação às medidas de produtos e atributos de 
processos� Em outras palavras, os sistemas de sof-
tware exibem comportamentos e tendências regu-
lares, que podem ser medidas e previstas�
Uma das preocupações próprias da gestão da ma-
nutenção (ou gestão das mudanças) é manter sob 
controle os problemas inerentes à atividade� Em re-
sumo, aplicar manutenções é uma atividade difícil e 
não é exatamente por meio dela que um profissional 
espera conseguir reconhecimento dos seus pares� 
Do ponto de vista dos usuários, o profissional da 
manutenção é aquele que pode solicitar interrupção 
no uso do sistema por vários minutos e que, não 
raramente, é apontado por eles como o “culpado” 
pelo problema manifestado no sistema�
A boa gestão da manutenção deverá equilibrar a dis-
ponibilidade do sistema aos usuários com a neces-
sidade inadiável de paradas em sua operação� Essa 
realidade é aceitável quando aplicada a um ambiente 
em que uma interrupção não ocasiona maiores danos 
à operação da organização� No entanto, como proce-
der quando o sistema em questão serve como supor-
te à vida de pacientes em um hospital? É necessário, 
portanto, que boas práticas de gerenciamento sejam 
colocadas em prática para que se implemente as 
mudanças sem graves consequências ao ambiente�
Outra situação com potencial para dificultar o pro-
cesso de evolução de um sistema (e que, portanto, 
precisa de gestão) é a falta de conhecimento do pes-
17
soal de desenvolvimento em relação à estrutura e ao 
código do sistema� Caso o pessoal que desenvolveu 
o sistema não esteja mais a serviço da organização, 
é possível que os desenvolvedores atuais encontrem 
dificuldades em compreender a documentação ou 
outros materiais disponíveis, o que pode atrasar o 
procedimento de manutenção. Afinal, registros em 
documentos de software nem sempre são claros e 
a disponibilidade de tempo para entendê-los pode 
ser pequena�
O gerenciamento das mudanças em um sistema deve 
também equilibrar recursos entre a evolução dos 
sistemas existentes e a criação dos novos� Conforme 
nos ensina Pfleeger (2004), é comum que os geren-
tes considerem a manutenção e o aprimoramento 
de um sistema como sendo mais importantes do 
que a construção de novas aplicações, o que pode 
revelar uma tendência da organização em dar con-
tinuidade aos procedimentos habituais, ao invés de 
buscar novas alternativas de produtos� No entanto, 
o desejo dos atuais clientes pode estar relacionado 
a novas funcionalidades e a novos produtos, o que 
pode gerar certo conflito de interesses. Mais uma 
vez, a gestão da situação se faz necessária�
A falta de tempo (e, por vezes, de recurso humano) 
para a aplicação de testes e validações nas mudan-
ças provocadas pela manutenção é outra situação 
que requer um delicado gerenciamento� Mais uma 
vez, a equipe pode se deparar com condição adversa 
para propor paradas na operação do sistema, sim-
plesmente pela sua necessidade de estar disponível 
18
o tempo todo� Além disso, a equipe de manutenção 
pode não dispor de dados para prever os efeitos das 
mudanças no código e, com efeito, preparar-se para 
eles� A gestão desta última situação requer acom-
panhamento e registro das atividades, além da pre-
paração para a contingência� 
Há outro elemento nesse contexto que não pode 
ser desconsiderado e que, nessa condição, deve-
rá requerer também esforços de gerenciamento: o 
custo da evolução de um sistema� Um gestor deve 
dispensar ainda maior atenção a esse fator quando 
o sistema considerado no processo de evolução fizer 
parte de outros sistemas em uso na organização� 
Nesse caso, não será possível considerar as mudan-
ças em apenas um sistema, já que haverá a neces-
sidade de avaliar como tais mudanças afetarão os 
outros sistemas aos quais o primeiro está integrado� 
(SOMMERVILLE, 2018)
De fato, a quantidade de circunstâncias e fatores 
que demandam gerenciamento em um processo de 
mudança é elevada e a elas incrementaremos agora 
os sistemas legados. Essa denominação identifica 
sistemas que, embora antigos e provavelmente ul-
trapassados, ainda permanecem em atividade em 
uma organização por causa da sua importância na 
operação dos negócios. Conforme a definição de 
Sommerville (2018), os sistemas legados são mais 
antigos e se baseiam em linguagens e tecnologias 
não mais usadas no desenvolvimento de novos sis-
temas. É comum que a grande quantidade de modifi-
cações feitas durante os anos de sua operação tenha 
19
degradado sua estrutura� Um esquema contendo a 
composição de elementos de um sistema legado é 
proposto na figura 3.
Software
de aplicação
Políticas e regras 
e negócio
Software
de apoio
Dados de
aplicação
Processos 
de negócio
Hardware 
de sistema
Usa
É execu-
tado no
É execu-
tado no
UsaUsa
Incorpora
conhecimento de
Restringe
Figura 3: Elementos de um sistema legado� Fonte: 
Sommerville (2018, p� 238)
Em resumo, os obstáculos que esses elementos re-
presentam podem ser assim descritos:
1. Hardware do Sistema: para a execução desses 
sistemas pode ser necessário um hardware que não 
se encontra mais, de manutenção dispendiosa ou que 
simplesmente estão fora do padrãoatual de aquisi-
ções da organização� 
2. Software de Apoio: o software legado pode de-
pender de outros sistemas para seu funcionamen-
to, que incluem sistema operacional específico ou 
drivers não mais encontrados ou que não são mais 
suportados pelo fabricante�
20
3. Software de Aplicação: o sistema que efetivamen-
te realiza o processamento diário das transações da 
empresa pode ser composto por programas desen-
volvidos em momentos e circunstâncias diferentes 
e cuja manutenção é muito complexa�
4. Dados de Aplicação: em um sistema que opera 
há muito tempo, os dados por ele gerados podem 
se apresentar em um volume imenso, apresentarem 
inconsistência ou estarem espalhados por bases de 
dados diversas�
5. Processos de Negócio: alguns dos processos de 
negócios modelados e implementados nesses siste-
mas podem não mais corresponder aos processos 
atuais da empresa�
6. Políticas e Regras do Negócio: esse item asse-
melha-se ao anterior e pode sofrer as restrições im-
postas pelos processos de negócios implementados 
no sistema legado�
A pergunta mais imediata a ser feita é: por qual moti-
vo as empresas não se apressam em substituir esses 
sistemas por equivalentes mais modernos e mais 
fáceis de serem mantidos? A resposta, que também 
é imediata, sempre mencionará que essa operação 
seria cara e arriscada demais, na maioria das circuns-
tâncias� Descartar um sistema legado que, apesar 
de obsoleto, ainda funciona, abre possibilidades para 
que as coisas passem a não corresponder tão bem 
às expectativas (SOMMERVILLE, 2018)� E, com isso, 
novamente estamos diante de uma situação que 
requer gestão relacionada à mudança�
21
As decisões associadas aos sistemas legados ten-
dem a ser complexas, mas uma análise desprovida 
de subjetividade (sim, a retirada de um sistema lega-
do pode despertar sentimentos de perda na organi-
zação) pode ajudar a mitigar esse cenário intrinca-
do� Nesse sentido, Sommerville (2018) sugere uma 
avaliação realista do sistema legado em atividade 
e a posterior elaboração de uma estratégia para li-
dar com esse sistema� Essa avaliação pode levar o 
gestor a tomar uma das quatro providências abaixo:
 ● Descartar completamente o sistema, que será a 
opção no caso de o sistema não mais contribuir efe-
tivamente para os processos do negócio�
 ● Manter o sistema como está e continuar com a 
manutenção, ideal para sistemas ainda estáveis e 
que recebem poucas solicitações de mudanças por 
parte dos usuários�
 ● Promover a reengenharia do sistema, de modo a 
aumentar sua manutenibilidade� Essa alternativa é 
apropriada para sistemas que ainda suportam melho-
rias (como uma nova interface de comunicação com 
o cliente) e incremento de novas funcionalidades�
 ● Substituir todo ou parte do sistema por um sistema 
novo, nos casos em que a continuidade do sistema 
legado esteja perto da inviabilidade�
Na sequência, abordaremos aspectos do gerencia-
mento de um projeto de desenvolvimento de um 
produto de software�
22
Gestão de Projeto de 
Desenvolvimento de Software
Na última seção desse módulo, trataremos de um 
aspecto de elevada importância no contexto do de-
senvolvimento de sistemas: a gestão do projeto que 
deverá conduzir a equipe até a sua entrega� Conforme 
mencionamos na parte introdutória deste documento, 
o desenvolvimento de um software deve ser tratado 
como um projeto de qualquer outra natureza, respei-
tadas as especificidades do produto que irá criar. A 
despeito da necessária adoção de uma metodologia 
de desenvolvimento, as atividades de planejamento 
de tarefas e controle de pessoas, de processos e 
de eventos devem estar presentes no cotidiano da 
elaboração do sistema�
Conforme nos ensinam Pressman e Maxim (2016), o 
gerenciamento do processo de desenvolvimento de 
um software tem suas bases estabelecidas em qua-
tro elementos, todos iniciados com a letra P: Pessoa, 
Produto, Processo e Projeto, nessa ordem� Nas próxi-
mas linhas, teremos a oportunidade de discutirmos 
melhor cada um deles, mas uma menção especial 
ao elemento Pessoa deve ser feita desde já: é nas 
pessoas que todo o trabalho é baseado e para elas é 
dirigido� O esforço humano é o que move um projeto 
e o gerente que pretende alcançar o sucesso deverá 
sempre se lembrar dessa verdade� Iniciemos, pois, a 
análise desses elementos�
23
Pessoas
Não é de hoje que estudiosos de projeto de software 
concordam que manter a motivação do pessoal de 
desenvolvimento em alta é um dos caminhos mais 
seguros para o sucesso de um projeto� Nesse sen-
tido, o Instituto de Engenharia de Software (ou SEI 
– Software Engineering Institute) desenvolveu um 
modelo de maturidade de capacitação de pessoas 
– o People-CMM e, por meio dele, estabeleceu que 
toda organização precisa aprimorar continuamen-
te sua habilidade de atrair, desenvolver, motivar, or-
ganizar e reter a força de trabalho necessária para 
atingir os objetivos estratégicos dos seus negócios� 
(PRESSMAN; MAXIM, 2016)
Esse modelo define que a formação de equipe, a 
comunicação, o bom ambiente de trabalho, o geren-
ciamento de desempenho, o treinamento, a compen-
sação e o desenvolvimento da carreira são suas prá-
ticas-chave relacionadas às pessoas em um contexto 
de projeto� Ele também sugere que organizações 
que conseguem níveis de maturidade excelentes no 
desenvolvimento de pessoas têm chances maiores 
de implementar práticas eficazes de gerenciamento 
de projetos de software, o que estabelece um círculo 
virtuoso no ambiente de desenvolvimento�
24
FIQUE ATENTO
Pressman e Maxim (2016) apresentam os envolvi-
dos (ou stakeholders) em um projeto de software 
em cinco grupos, a saber: gerentes seniores, ge-
rentes técnicos de projeto, profissionais técnicos, 
clientes e usuários�
Produto
Embora possa ter outras finalidades, é a geração de 
um produto que motiva a criação de um projeto de 
software em boa parte dos casos� Por isso, antes 
de delinearem um plano de projeto, os envolvidos 
devem estabelecer os objetivos do produto e seu 
escopo, além de levantar soluções alternativas e as 
restrições técnicas para a elaboração desse produto� 
Na ausência de informações precisas sobre esses 
aspectos do produto, a equipe terá sérias dificuldades 
em fazer estimativas de custo, avaliação de riscos, 
estabelecimento de cronograma e o controle do pro-
gresso dos trabalhos�
Os objetivos do produto equivalem às suas metas 
gerais, e não há obrigatoriedade de se definir como 
essas metas serão atingidas na oportunidade em 
que os objetivos são definidos. Bem, mas e qual se-
ria o objetivo de um produto, na prática? Descrito de 
forma simples e objetiva, um exemplo possível para 
um objetivo seria: “O sistema deverá permitir que os 
alunos solicitem a matrícula e a efetivem por meio 
do pagamento da primeira mensalidade do curso”� 
25
Já o escopo identifica os principais dados, funções 
e comportamentos que caracterizarão o produto, 
além de limitar as fronteiras desses dados, funções 
e comportamentos� (PRESSMAN; MAXIM, 2016)
Uma vez definidos os objetivos e o escopo do pro-
duto, a equipe deve passar a levantar soluções alter-
nativas para esse produto� Dessa forma, os gestores 
terão meios de selecionar a melhor estratégia, con-
siderados os prazos de entrega, limitações financei-
ras, disponibilidade de mão de obra, familiaridade da 
equipe com determinada tecnologia, disponibilidade 
do cliente para participar das decisões e tantos ou-
tros fatores que influenciam qualquer outro projeto. 
Processo
Nesse item, no qual trataremos do terceiro elemento 
do gerenciamento de um projeto de desenvolvimento 
de software, nada melhor do que lembrarmos o con-
ceito de um processo aplicado à criação de software� 
De acordo com Schach (2019), o processo de softwa-
re é a maneira pela qual produzimos software� Ele 
abrange a metodologia – com seu modelo de ciclo de 
vida – e técnicas subjacentes, além das ferramentas 
utilizadas e, acima de tudo, os indivíduos que estão 
criando o software. A definição de Pressman e Maxim(2016) para esse item estabelece que um processo 
de software fornece a metodologia por meio da qual 
pode ser estabelecido um plano de projeto para o 
desenvolvimento de um software�
26
No entanto, um processo não precisa (e não deve) 
ser executado de forma rígida e sem a possibilidade 
de adaptações, já que cada projeto apresenta suas 
particularidades� Nem todas as atividades metodoló-
gicas têm aplicabilidade imediata a todos os projetos 
de software, ainda mais se considerarmos tamanhos 
e complexidades diferentes de cada projeto� Assim, 
as formas de controle do projeto, suas tarefas, os 
artefatos intermediários gerados e os critérios de 
qualidade específicas de uma metodologia podem 
ser adequados às características próprias de certo 
projeto� (PRESSMAN; MAXIM, 2016)
Projeto
Usar as melhores práticas de gerenciamento de pro-
jetos em uma empreitada de criação de um sistema 
não é exatamente uma mera opção para as equipes� 
Na verdade, a aplicação dessas técnicas de projeto 
permite que possamos administrar a complexidade 
envolvida na criação de um produto de software� No 
entanto, mesmo com aplicação de boas práticas, os 
projetos podem não ficar livres de atrasos, excesso 
de gastos ou desvios de seus objetivos� A ocorrên-
cia dessas falhas pode ser mitigada com a adoção 
de controles rigorosos no projeto, o que não seria 
possível sem um bom gerenciamento�
Feitas essas considerações conceituais, iniciamos 
o tratamento de aspectos mais específicos de ges-
tão de um projeto de desenvolvimento de software� 
Nesse sentido, vale a pena voltarmos nossa atenção 
27
para o entendimento de como produto e processo 
são combinados, tomando como base o contexto do 
que acabamos de discutir sobre ambos� Pressman 
e Maxim (2016) sustentam que um projeto começa 
com a junção de um produto com o processo em que 
ele se baseará e que essa simbiose se manifesta em 
cada uma das funções do produto que serão desen-
volvidas pelas atividades próprias da metodologia�
Vamos imaginar que uma empresa que desenvolve 
software adote uma metodologia em que as fases 
de comunicação, planejamento, modelagem, cons-
trução e entrega sejam usadas em seu processo de 
software� Imagine agora que essa empresa esteja 
construindo um processador de texto, cujas funções 
estão parcialmente representadas nas linhas da pri-
meira coluna da figura 4. Observe que as fases da 
metodologia estão colocadas nas colunas subse-
quentes e que, dessa forma, a figura assume uma 
forma matricial�
Figura 4: Integração do problema com o processo� Fonte: 
adaptado de Pressman e Maxim (2016)
28
A função de um gerente de projeto de software – 
com o auxílio de outros envolvidos – é a de estimar 
quantos e quais recursos cada célula da matriz irá 
precisar� Além disso, ele deve também projetar pra-
zos para as tarefas e os artefatos a serem produzidos 
ao término de cada uma delas� Em qualquer caso, 
a equipe deve ter flexibilidade no momento de ado-
tar seu processo de software, da mesma forma que 
poderá escolher outro meio – diferente desse que 
propusemos – para determinar prazos, recursos e 
artefatos do projeto�
Tomaremos a etapa de Comunicação para exem-
plificarmos como o porte do projeto pode afetar as 
formas com que as tarefas são desenvolvidas� Em 
um projeto pequeno, as tarefas relacionadas à co-
municação podem ser assim distribuídas, segundo 
Pressmann e Maxim (2016):
1. Criar uma lista de questionamentos sobre alguns 
pontos do projeto�
2. Promover reunião com os envolvidos que possam 
esclarecer tais questionamentos�
3. Com a ajuda de alguns envolvidos seleciona-
dos, desenvolver uma primeira versão do escopo 
do projeto�
4. Promover a revisão dessa primeira versão do 
escopo�
5. Promover alterações com base na revisão feita�
29
Um projeto mais complexo (e, portanto, provavelmen-
te maior e com mais envolvidos) poderia requerer 
outras atividades realizadas nesse mesmo contexto, 
por exemplo, preparação de cronogramas para as 
diversas reuniões e previsão de miniespecificações 
para cada requisito de maior importância e comple-
xidade� Mesmo que a atividade metodológica seja a 
mesma (a Comunicação, no caso), os esforços, no 
primeiro caso, serão menores do que no segundo 
caso, em que o projeto é de maior porte�
30
CONSIDERAÇÕES FINAIS
Encerramos assim mais um módulo de estudos� Durante 
o tempo que permanecemos juntos, tivemos a oportu-
nidade de discutir questões interessantes sobre uma 
atividade que costuma ser vista como pouco popular 
(para evitar a referência “desinteressante”) entre os de-
senvolvedores� A evolução de um software não é ape-
nas mais uma das etapas de algum procedimento de 
software� Na verdade, ela é o motivo da continuidade 
da existência comercialmente viável de um produto de 
software e, nessa condição, não pode ser negligenciada�
A fim de cumprirmos os objetivos desta leitura, tra-
tamos de aspectos conceituais da evolução e da 
manutenção de um sistema, o que preparou o ca-
minho para que pudéssemos abordar elementos da 
crucial tarefa de gerenciar as inevitáveis mudanças 
em um produto� Sem um efetivo gerenciamento, o 
que deveria ser a aplicação de melhorias pode se 
transformar em mais complexidade embutida em 
um sistema. Como assunto final, analisamos itens 
que fazem parte do processo de desenvolvimento 
de um sistema e que estão relacionados à gestão 
do projeto que conduzirá a equipe a entrega de um 
produto de qualidade�
Esperamos que seu aproveitamento do conteúdo tenha 
sido excelente e recomendamos que continue se apro-
fundando nos assuntos da Engenharia de Software�
Bons estudos e boa sorte, sempre!
31
Referências Bibliográficas 
& Consultadas
COHN, M� Desenvolvimento de software com scrum: 
aplicando métodos ágeis com sucesso� Porto Alegre: 
Bookman, 2011� [Minha Biblioteca]
PAULA FILHO, W� P� Engenharia de software: funda-
mentos, métodos e padrões� 3� ed� Rio de Janeiro: 
LTC, 2009� [Minha Biblioteca]
PFLEEGER, S� L� Engenharia de software: teoria e prá-
tica� 2� ed� São Paulo: Prentice Hall, 2004� [Biblioteca 
Virtual]
PRESSMAN, R�; MAXIM, B� Engenharia de software: 
uma abordagem profissional. 8. ed. Porto Alegre: 
AMGH, 2016� [Minha Biblioteca]
SBROCCO, J� H� T� C�; MACEDO, P� C� Metodologias 
ágeis: engenharia de software sob medida� São 
Paulo: Érica, 2012� [Minha Biblioteca]
SCHACH, S� R� Engenharia de software: os paradig-
mas clássico e orientados a objetos� 7� ed� Porto 
Alegre: AMGH, 2009�
SOMMERVILLE, I� Engenharia de software� 10� 
ed� São Paulo: Pearson Education do Brasil, 2018� 
[Biblioteca Virtual]
VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de requi-
sitos: software orientado ao negócio� Rio de Janeiro: 
Brasport, 2016� [Biblioteca Virtual]
WAZLAWICK, R� S� Engenharia de software: conceitos 
e práticas� Rio de Janeiro: Elsevier, 2013�
	Introdução
	Software
	Evolução de Software
	Manutenibilidade
	Gestão de mudanças
	Gestão de Projeto de Desenvolvimento de Software
	Pessoas
	Produto
	Processo
	Projeto
	Considerações finais
	Referências Bibliográficas & Consultadas