Engenharia de Software I

Aula 9
Atividades do Processo de Desenvolvimento –
Implantação e Manutenção

l.bertholdo@ifsp.edu.br
Conteúdo
• Implantação de Software
• Projeto de Implantação

• Manutenção de Software
• Previsão de Manutenção
• Reengenharia de Software
• Manutenção Preventiva por Refatoração

l.bertholdo@ifsp.edu.br
Implantação de Software
• Na fase de implantação, o software é instalado no ambiente de
produção do cliente, ficando disponível para operação dos usuários.

• A implantação pode envolver configurações no sistema para que

fique compatível com o ambiente do cliente, a transferência de
dados dos sistemas que serão substituídos, bem como a preparação
da documentação de produto e o treinamento de usuários.

• Nessa fase, também pode ser necessário reconfigurar outros

sistemas do ambiente, para que possam se integrar com o novo
sistema.

l.bertholdo@ifsp.edu.br
Implantação de Software
• Muitas vezes, os problemas encontrados durante os testes de
aceitação não impedem a implantação de um sistema.

Há casos em que o cliente precisa usar o software o quanto antes, devido

aos benefícios imediatos de sua implantação. Ele pode ter comprado novos
equipamentos, treinado seu pessoal e alterado seus processos. Pode estar
disposto a aceitar o software, porque os custos do “não uso” do software
são maiores do que os custos de seu uso, ainda que com alguns problemas.

• Nesses casos, o cliente pode propor uma aceitação condicional, para

que a implantação do sistema possa ser feita. O fornecedor do
sistema se compromete então a entregar uma versão com os
problemas mais urgentes sanados e, tão logo seja possível, a entregar
uma nova versão com todos os ajustes e correções.

l.bertholdo@ifsp.edu.br
Implantação de Software
• Embora, a princípio, pareça uma etapa simples, muitas dificuldades
podem surgir durante a implantação.

Os dados existentes O ambiente do cliente pode não ser tão As interfaces com
podem exigir limpezas uniforme como havia sido previsto pelos outros sistemas
extensas e partes dos desenvolvedores do sistema. E adaptar podem estar mal
dados podem estar o sistema para lidar com diversos documentadas, ou
faltando. ambientes de usuário pode ser difícil. sem documentação.

Um sistema deve ser projetado para incluir recursos que simplifiquem

sua implantação no ambiente do cliente, e que permitam verificar
possíveis erros no sistema e omissões em sua configuração.

l.bertholdo@ifsp.edu.br
Projeto de Implantação
• A implantação envolve configurar o software para funcionar em um
ambiente operacional, instalar o sistema nos computadores deste
ambiente e configurar o sistema para cada computador específico.

A configuração pode ser simples e envolver apenas a definição de alguns

parâmetros internos do software para que reflitam as preferências do
usuário. Porém, às vezes, ela é complexa e exige a definição específica de
regras de negócio que afetam a execução do software.
l.bertholdo@ifsp.edu.br
 Projeto de Implantação
• Na fase de implantação, pode ocorrer a introdução acidental de
vulnerabilidades no software.

Durante a instalação, o sistema é configurado com uma lista de usuários permitidos, que pode conter
logins de administrador genéricos, como “admin” e uma senha padrão, como “senha”. Nesse caso, um
invasor que conheça o login padrão pode ter acesso privilegiado ao sistema. Para evitar essa situação,
muitos sistemas exigem a configuração de novos nome de login e senha no primeiro acesso.

• Muitas vezes, a implantação e a configuração são vistas como

problemas de administração de sistema e, por isso, são consideradas
fora do escopo dos processos de engenharia de software.
• No entanto, os arquitetos devem projetar o software pensando
também em sua implantação. Um sistema que fornece suporte para
implantação reduz a probabilidade de os administradores do sistema
(ou usuários) cometerem erros ao configurá-lo.
l.bertholdo@ifsp.edu.br
Projeto de Implantação
• Recomendações para incorporar o suporte de implantação em um
sistema:

1) Incluir suporte para visualização e análise de configurações

Um sistema deve ter recursos que permitam aos administradores examinarem a
configuração atual do sistema. Surpreendentemente, esse recurso não consta da
maioria dos sistemas, e os usuários têm dificuldade em encontrar as definições de
configuração. Idealmente, uma tela de configuração deveria destacar os aspectos
potencialmente não seguros da configuração, como uma senha que não foi definida.

2) Minimizar privilégios default (padrão)

A configuração padrão de um sistema deve fornecer poucos privilégios, a fim de
limitar possíveis danos causados por intrusos. Por exemplo, a autenticação default
de administrador de sistema só deve permitir acesso à funcionalidade para
configuração de suas novas credenciais, impedindo-o de acessar qualquer outro
recurso do sistema enquanto ele não configurar suas próprias credenciais.

l.bertholdo@ifsp.edu.br
Projeto de Implantação
• Recomendações para incorporar o suporte de implantação em um
sistema:

3) Organizar a localização de definições de configuração

Ao projetar funcionalidades para configuração de sistema, é preciso garantir que
tudo o que afeta a mesma parte de um sistema seja configurado no mesmo lugar. Se
as informações de configuração não forem fáceis de localizar, o usuário poderá se
esquecer de configurá-las ou, em alguns casos, nem mesmo estar ciente de que
alguns recursos de proteção estão disponíveis no sistema.

4) Fornecer maneiras fáceis de corrigir vulnerabilidades de proteção

Um sistema deve incluir mecanismos simples de atualização, a fim de corrigir
vulnerabilidades de proteção descobertas. Eles podem incluir a verificação
automática de atualizações, ou o download dessas atualizações assim que estiverem
disponíveis. O ideal é impedir que os usuários possam ignorar esses mecanismos,
pois eles, inevitavelmente, os considerarão pouco importantes e adiáveis.

l.bertholdo@ifsp.edu.br
Manutenção de Software
• O desenvolvimento de software não é interrompido quando o sistema
é entregue, mas continua por toda a vida útil do sistema.

• A evolução do software é essencial, pois as empresas investem

grandes quantias em seus softwares e são muito dependentes deles.

• Por isso, a maioria das grandes empresas gasta mais na manutenção de

sistemas existentes do que no desenvolvimento de novos sistemas.

Sistemas de software muitas vezes têm uma vida útil muito longa. Por exemplo, sistemas
militares ou de infraestrutura de grande porte, como sistemas de controle de tráfego
aéreo, podem ficar em operação por 30 anos ou mais. Sistemas de gestão de negócios
com mais de dez anos de idade são comuns. Como os softwares custam muito dinheiro,
uma empresa pode usar um sistema por muitos anos para ter retorno de seu investimento.

l.bertholdo@ifsp.edu.br
Manutenção de Software
• A manutenção de software é o processo
de mudança em um sistema depois que
ele é implantado. Existem três diferentes
tipos de manutenção: Distribuição
geral dos custos
de manutenção

Correção de defeitos: Erros de codificação são os mais baratos para serem corrigidos. Erros de projeto
são mais caros, pois podem implicar reescrever vários componentes de software. Erros de requisitos
são os mais caros para se corrigir devido ao extenso reprojeto de sistema que pode ser necessário.

Adaptação de ambiente: Esse tipo de manutenção é necessário quando algum aspecto do ambiente
do sistema, como o hardware, a plataforma do sistema operacional ou outro software de apoio sofre
mudança. Nesse caso, o sistema deve ser modificado para se adaptar a essas mudanças de ambiente.

Adição ou modificação de funcionalidade: Esse tipo de manutenção é necessário quando os requisitos

de sistema mudam em resposta às mudanças organizacionais ou de negócios. O volume de mudanças
necessárias no software é, normalmente, muito maior do que para os outros tipos de manutenção.
l.bertholdo@ifsp.edu.br
 Manutenção de Software
• A adição ou a modificação de funcionalidades em sistemas que estão
em operação é cara por várias razões:
Estabilidade da equipe: Quando um sistema é
implantado, a equipe de desenvolvimento pode
ser desmobilizada e as pessoas remanejadas
para novos projetos. A nova equipe de
manutenção do sistema precisará investir
tempo para compreender o sistema existente.
Qualificações de pessoal: A manutenção é
vista como um processo menos qualificado do
que o desenvolvimento e, às vezes, é atribuída
a pessoas inexperientes. Além disso, os
sistemas legados podem ser escritos em
linguagens obsoletas e pouco conhecidas,
exigindo que a equipe tenha que aprendê-la.
Más práticas de desenvolvimento: O contrato
de manutenção pode ser dado a uma empresa
diferente da empresa que vai desenvolver o
sistema original. Com o tempo, a manutenibili-
dade do software pode ser prejudicada, já que
será outra empresa que fará a manutenção.
Idade do software e estrutura: A estrutura de
um sistema tende a se degradar com as
mudanças. Assim, torna-se mais difícil entendê-
la e alterá-la. Muitos sistemas foram
desenvolvidos sem técnicas modernas de
engenharia de software e suas documentações
podem ter se perdido ou estar inconsistentes.
l.bertholdo@ifsp.edu.br
Manutenção de Software
• O uso de boas técnicas de engenharia de software e o investimento
de esforços durante o projeto e a implementação do sistema
reduzem os custos gerais durante a vida útil do sistema.
Para o Sistema 1, o custo extra de desenvolvimento de 25 mil dólares
é investido para tornar o sistema mais manutenível. Em comparação
com o Sistema 2, isso resulta em uma economia de cem mil dólares
em custos de manutenção durante a vida útil do sistema.
US$ 25.000 US$ 100.000

l.bertholdo@ifsp.edu.br
Previsão de Manutenção
• Após implantar um software, deve-se tentar prever várias questões
relacionadas à manutenção.

l.bertholdo@ifsp.edu.br
 Previsão de Manutenção
• Para acompanhar a manutenibilidade de um sistema implantado,
pode-se usar dados do software em produção. Exemplos de métricas
que podem ser usadas para indicar queda na manutenibilidade:

Número de solicitações de manutenção Tempo médio gasto para implementar uma

corretiva: O aumento no número de bugs e solicitação de mudança: O aumento do tempo
falhas pode indicar que mais erros estão sendo necessário para modificar o sistema e sua
introduzidos do que corrigidos durante as documentação pode indicar que as mudanças
manutenções do sistema. estão ficando mais onerosas.

Tempo médio necessário para a análise de Número de solicitações de mudança pendentes:

impacto: O aumento deste tempo pode indicar O aumento no número de pendências de
que cada vez mais componentes de software manutenção ao longo do tempo pode indicar
estão sendo afetados pela mudança. uma demanda anormal por mudanças.

l.bertholdo@ifsp.edu.br
Reengenharia de Software
• Sistemas legados mais velhos, muitas vezes, são difíceis de serem
compreendidos e modificados. Para torná-los mais fáceis de serem
mantidos, é preciso aplicar uma reengenharia nesses sistemas.
• A reengenharia pode envolver a redocumentação do sistema, a
refatoração da arquitetura de sistema, a mudança de linguagem de
programação e modificações na estrutura e nos dados do sistema,
sendo que as funcionalidades do software não são alteradas.

Benefícios da reengenharia, em vez da substituição do software

Risco reduzido: Existe um alto risco em desenvolver “do zero” um software crítico de
negócios. Podem ocorrer erros na especificação do sistema ou falhas de desenvolvimento.
Atrasos no início do novo software podem significar perdas e custos adicionais.
Custo reduzido: Com as novas tecnologias, o custo de reimplementação “do zero” é
provavelmente inferior ao custo da época em que o software foi criado, mas ainda
superior aos custos da reengenharia.

l.bertholdo@ifsp.edu.br
 Reengenharia de Software
O código do software é analisado e as
informações são extraídas a partir dele.
Isso ajuda a documentar sua estrutura
e funcionalidades. Esse processo
também pode ser automatizado.
Usando uma ferramenta de
tradução, o software é
convertido de uma linguagem
de programação antiga para
uma versão mais moderna da
mesma ou de outra linguagem.
Partes relacionadas do software são
agrupadas e, quando possível, redundâncias
são eliminadas. Diferentes repositórios de
dados podem ser centralizados em um único
repositório. Esse é um processo manual.
Processo genérico
de reengenharia
de software
Os dados processados
pelo software são
alterados para refletir as
mudanças. Isso pode
incluir a reestruturação do
banco de dados existente.
Ferramentas podem dar
suporte a esta tarefa.
A estrutura do software é analisada e modificada
para que se torne mais fácil de ler e entender. Isso
normalmente exige intervenção manual.
l.bertholdo@ifsp.edu.br
Manutenção Preventiva por Refatoração
• Refatoração é o processo de melhorar a estrutura de um software,
reduzir sua complexidade e torná-lo mais compreensível, visando
diminuir a degradação resultante das mudanças no sistema.
• Ao refatorar um software, não se deve adicionar funcionalidades, mas
sim concentrar-se na melhoria dele. Portanto, pode-se pensar em
refatoração como uma manutenção preventiva.
• Conceitualmente, reengenharia e refatoração são diferentes. A
reengenharia ocorre em sistemas legados, cujos custos de manutenção
aumentaram. Já a refatoração é um processo contínuo de melhoria ao
longo do processo de desenvolvimento e da evolução do sistema.

A refatoração é uma parte inerente dos métodos ágeis. No processo do

eXtreme Programming, os desenvolvedores frequentemente refatoram
seus softwares para reduzir a velocidade de sua degradação.
l.bertholdo@ifsp.edu.br
Manutenção Preventiva por Refatoração
• Por fim, existem situações chamadas de “code smells” (cheiro de
código) nas quais o software pode ser melhorado. Exemplos de
situações que podem ser tratadas por meio de refatoração:

Código duplicado: O mesmo código é repetido em diferentes lugares de um

programa. Nesse caso, ele pode ser removido e implementado em um único método.

Métodos longos: Se um método contiver muito código, ele deve ser dividido em
métodos menores.

Replicação de dados: Ocorre quando um mesmo conjunto de dados de uma

entidade de negócio aparece em vários lugares de um programa. Muitas vezes, eles
podem ser substituídos por um objeto que encapsule todos os dados desta entidade.

l.bertholdo@ifsp.edu.br
Referências
• PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software: uma
abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.

• SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson

Prentice Hall, 2011.

l.bertholdo@ifsp.edu.br