2009.

Testes de Software
INF0524

Prof. José Guilherme

MANUTENCAO DE SOFTWARE

 Características de manutenção
 Manutenibilidade
 Tarefas de manutenção
 Efeitos colaterais
Características de manutenção

 A manutenção do software existente pode ser

responsável por mais de 70 % de todo o
esforço despendido por uma organização de
software.
 A porcentagem continua a se elevar à medida
que mais software é produzido.
 No horizonte, podemos prever uma
organização de software “baseada na
manutenção” que não mais pode produzir
novo software, porque está gastando todos
os seus recursos disponíveis mantendo um
software antigo.
Características de manutenção

A Mudança é inevitável quando se

constroem sistemas baseados em
computador; portando, devemos
desenvolver mecanismos para avaliar,
controlar e fazer modificações
“A manutenção de software é, certamente,
bem mais do que consertar erros”.
Características de manutenção

 Para entender as características da

manutenção de software, consideremos o
tema a partir de três pontos de vista:
 1. As atividades exigidas para realizar a fase de
manutenção e o impacto de uma abordagem (ou
falta dela) de engenharia de software sobre a
eficácia de tais atividades;
 2. Os custos associados à fase de manutenção;
 3. Os problemas que são frequentemente
encontrados quando à manutenção de software é
realizada.
Características de manutenção

 Se existir uma configuração de software

completa, a tarefa de manutenção inicia-se
com uma avaliação da documentação de
projeto;
 As características estruturais, de
desempenho e de interface importantes do
software são determinadas;
 O Custo da manutenção de software tem
aumentado firmemente durante os últimos 20
anos.
Características de manutenção

A maioria dos problemas associados à

manutenção de software pode remeter-
se a deficiências na maneira segundo a
qual o software foi planejado e
desenvolvido. Aplica-se aqui a clássica
situação do “pague agora ou pague
muito mais depois”.
 Podemos definir a manutenção
descrevendo quatro atividades que são
levadas a efeito depois que um programa
é liberado para uso:
1 - manutenção corretiva
 2 - Manutenção adaptativa

 3 - Manutenção perfectiva

 4 - Manutenção preventiva
1 - manutenção corretiva

 Não é razoável presumir que a atividade

de testes de software descobrirá todos os
erros latentes num grande sistema de
software. Durante o uso de qualquer
programa grande, erros ocorrerão e serão
relatados ao desenvolvedor.
 inclui o diagnóstico e a correção de um ou
mais erros.
2 - Manutenção adaptativa

 A vida dos aplicativos pode facilmente

ultrapassar 10 anos, vivendo mais do que o
ambiente de sistema para qual foram
originalmente desenvolvidos.
 A manutenção ocorre por causa da rápida
mudança que é encontrada em cada aspecto
da computação.
 Novas gerações de hardwares parecem ser
anunciadas num ciclo de 18 meses;
 Novos sistemas operacionais ou novos
lançamentos de antigos aparecem regularmente;
 Equipamentos periféricos e outros elementos de
sistema são frequentemente atualizados ou
modificados.
3 - Manutenção perfectiva

 Ocorre quando um pacote de software é

bem-sucedido.
 Á medida que o software é usado,
recomendações de novas capacidades, de
modificações em funções existentes e de
ampliações gerais são recebidas dos usuários.
 Essa atividade é responsável pela maior parte
de todo o esforço despendido em
manutenção de software.
4 - Manutenção preventiva

 Ocorre quando o software é modificado

para melhorar a confiabilidade ou a
manutenibilidade futura, ou para oferecer
uma base melhor para futuras ampliações.
 É caracterizada pelas técnicas de engenharia
reversa e reengenharia.
 Alguns profissionais da área de software
preocupam-se com a inclusão da segunda e
terceira atividade como parte de uma
definição de manutenção.
 As tarefas que ocorrem como parte da
manutenção adaptativa e perfectiva são as
mesmas tarefas aplicadas durante a fase de
desenvolvimento do processo de engenharia
de software.
 Para adaptar ou aperfeiçoar, devemos
determinar novos requisitos, reprojetar, gerar
código e testar o software existente.
Manutenibilidade

 Facilidade com que um programa pode

ser corrigido, se um erro é encontrado,
adaptado, se o seu ambiente se
modifica, ou aperfeiçoado, se o cliente
deseja uma modificação nos requisitos.
MTTC

 Não há modo de medir a manutenabilidade

diretamente.
 Uma métrica simples orientada a tempo é
Tempo Médio Para Modificações (Mean
Time to Changes – MTTC), que é o tempo
despendido para analisar o pedido de
modificação, projetar uma modificação
adequada, implementar a modificação, testá-
la e distribuí-la para todos os usuários.
 Programas manuteníveis terão um MTTC
mais baixo do que programas não-
manuteníveis para tipos equivalentes de
modificações.
SMI

 O índice de maturidade de software (SMI)

fornece uma indicação da estabilidade de um
produto de software, com base nas
modificações.
 Sendo:
 MT = número de módulos na versão corrente
 Fc = número de módulos na versão corrente que
foram modificados
 Fa = número de módulos na versão corrente que
foram adicionados
 Fd = número de módulos na versão anterior que
foram descartados na versão corrente.
 SMI = [MT – (Fa + Fc + Fd)]/MT
Engenharia Reversa

 Origem no mundo do hardware.

 Uma empresa desmonta um produto
competidor, em um esforço para entender os
“segredos” do projeto e a fabricação do
concorrente.
 Esses segredos poderiam ser facilmente
entendidos se fossem obtidas as
especificações do projeto e da fabricação,
mas esses documentos são privados e não
estão disponíveis à empresa que está
fazendo a engenharia reversa.
Engenharia Reversa

A engenharia reversa bem sucedida

deriva uma ou mais especificações de
projeto e de fabricação de um produto
pelo exame de espécimes reais do
produto.
Engenharia Reversa

A engenharia reversa de software é

semelhante. Na maioria dos casos, no
entanto, o programa a passar pela
engenharia reversa não é do
concorrente. Os “segredos” a serem
descobertos são obscuros por não
existir nenhuma especificação
desenvolvida.
Engenharia Reversa

 Engenharia reversa de software é o processo

de análise de um programa, em um esforço
para representá-lo em uma abstração mais
alta do que o código-fonte. A engenharia
reversa é um processo de recuperação de
projeto. As ferramentas de engenharia
reversa extraem informação de projeto de
dados, arquitetural e procedimental de um
programa existente.
Engenharia Reversa

O processo inverso a Engenharia

Progressiva, caracterizado pelas
atividades retroativas do ciclo de vida,
que partem de um baixo nível de
abstração para um alto nível de
abstração.
Engenharia Reversa

 Quais os documentos utilizados para

realizar engenharia reversa ?
 documentação existente (manual de
usuário, manual de sistema,DFDs,
fluxogramas, etc.)
 código fonte

 informações de usuários e/ou analista

Engenharia Reversa

 Reuso é uma atividade que se destina a

identificar software reutilizável.
 Envolve também a correta importação,
reconfiguração e adaptação deste software para
uma nova aplicação em um sistema de
computação.
 O processo de reuso é descrito por meio das
atividades:
 Reconhecimento,
 Decomposição,
 Classificação (para povoar as bibliotecas de reuso);
 Seleção,
 Adaptação
 Composição
 Técnicas de engenharia reversa
disputam o papel principal no apoio a
esses passos, contudo, o foco principal
é nos três primeiros passos.
Reengenharia

 “o exame e a alteração de um sistema para

reconstituí-lo de uma nova forma, seguida
pela sua implementação“
 Sinônimos de Reengenharia:
 melhoramento,
 renovação,
 modernização,
 engenharia de re-desenvolvimento,
 engenharia de reuso
Passos para se realizar reengenharia

1 - Engenharia Reversa
 2 - Estudo das possibilidades existentes

 Reengenharia
 semmudança de funcionalidade,
 mudança parcial de funcionalidade,

 mudança total de funcionalidade

Engenharia de Requisitos

 A realização da Engenharia de
Requisitos destaca-se como sendo uma
área particularmente afetada pelas
dificuldades envolvidas em projetos de
manutenção.
Engenharia de Requisitos

 Uma grande quantidade de projetos de

software são cancelados ou fracassam
por não atenderem completamente as
necessidades dos clientes e excederem
o prazo e o orçamento estimados;
 Deficiências nos requisitos dos
sistemas como uma das principais
causas de fracassos em projetos de
software.
Engenharia de Requisitos

 Engloba todas as atividades envolvidas na

descoberta, documentação e manutenção de
um conjunto de requisitos para um sistema
computacional;
 O uso do termo “engenharia” implica que
técnicas sistemáticas e repetíveis devem ser
utilizadas para garantir que os requisitos do
sistema sejam completos, consistentes e
relevantes.
 (Espindola, 2006)
Sistemas Legados (SL)

 A manutenção de software pode ser

necessária mesmo em sistemas que
acabaram de ser entregues ao seu usuário.
Entretanto, é a atividade de manutenção em
sistemas legados que apresenta os maiores
desafios.
 SL é 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;
 essencial para a continuidade dos negócios da
organização e, portanto, o sistema deve estar
permanentemente operacional.
Requisitos de SL

 Compreender os requisitos de sistemas

legados torna-se importante para:
 Melhorar o sistema legado;
 Integrá-lo com o restante dos sistemas de
informação;
 Realizar a reengenharia do sistema.
Requisitos de SL

 Em muitas circunstâncias o
conhecimento preciso sobre o sistema
foi há muito perdido.
 fontes de informação sobre o que e
porque o sistema faz:
O sistema em si;
 Seus códigos-fonte;
 Aqueles que o usam.
Como as dificuldades
afetam manutenção de SL?

 Dificuldades no Processo de
Engenharia de Requisitos;
 Dificuldades na Gerência de
Requisitos.
Elicitação de Requisitos

 Elicitar – Elicitar requisitos é o nome

usualmente atribuído à atividade voltada para
descobrir (identificar, deduzir, extrair, evocar,
obter) os requisitos de um sistema, através
de entrevistas com os interessados pelo
sistema, de documentos do sistema existente
(manual ou automatizado), da análise do
domínio do problema ou de estudos de
mercado.
Elicitação de Requisitos
Processo de ER

 Impacto na Atividade de Elicitação

dos Requisitos;
 Impacto na Análise e Negociação dos
Requisitos;
 Impacto na Documentação dos
Requisitos;
 Impacto na Validação dos Requisitos.
Processo de ER

 Impacto na Atividade de Elicitação dos

Requisitos
 Muitas vezes a única alternativa para a
recuperação dos requisitos do sistema é a
pesquisa no código-fonte.
 Recuperar os requisitos de um sistema a partir do
código-fonte é difícil,
 é preciso reconhecer decisões tomadas pelos projetistas
e distinguir estas decisões dos requisitos reais.
Processo de ER

 Impacto na Análise e Negociação dos

Requisitos
É necessário que a análise contemple:
 Descoberta de conflitos,
 Sobreposições e
 Inconsistências.
 Tanto entre os requisitos do projeto de
manutenção quanto entre estes e os requisitos
originais do sistema (caso existam ou possam
ser recuperados).
Processo de ER

 Pode ser difícil esclarecer as

motivações por trás destes requisitos,
tornando a tarefa de resolução de
eventuais conflitos particularmente
delicada e sujeita a erros.
 Stakeholders responsáveis pelos requisitos
originais podem não estar mais
disponíveis.
Processo de ER

 Um dos Fatores Críticos de Sucesso

(FCS) em manutenção de software
estabelece que a operação de
manutenção deve pelo menos
preservar, senão melhorar, a
funcionalidade do sistema em
manutenção.
O usuário não deve receber, após a
manutenção, menos funcionalidades do
que tinha antes dela.
Processo de ER

É difícil garantir durante a análise de

requisitos que a modificação proposta
não viola este FCS sem conhecer os
requisitos funcionais originais do
sistema.
Processo de ER

 Alternativa:
 Uma alternativa para realizar esta
verificação, na ausência dos requisitos,
seria realizar testes comparativos de todas
as funcionalidades apresentadas pelo
sistema antes e depois da modificação, o
que pode ser um procedimento caro e
ineficiente.
Processo de ER

 Impacto na Documentação dos

Requisitos
O principal impacto na documentação dos
requisitos está relacionado à forma como
são documentadas as dependências entre
os requisitos definidos no projeto de
manutenção e os requisitos originais do
sistema.
Processo de ER

 Dependendo da abordagem utilizada para

lidar com esta questão, alguns problemas
podem surgir:
 Caso estas dependências não sejam
documentadas os novos requisitos, bem como as
modificações solicitadas, podem ficar fora de
contexto;
 Caso o contexto seja documentado diretamente
no documento de requisitos, sem o devido
cuidado para diferenciar o que deve ser
modificado do que já está implementado.
Processo de ER

É necessária uma documentação

adequada das dependências e do
rastreamento entre os requisitos para
garantir que o projeto seja corretamente
dimensionado e que as modificações
propostas fiquem claramente
contextualizadas como parte de um
sistema já implementado.
Processo de ER

 Impacto na Validação dos Requisitos

O sucesso desta atividade está
intimamente ligado com o sucesso da
atividade de análise, pois os problemas
decorrentes de documentação inadequada
ou ausente e de indisponibilidade dos
stakeholders originais que não são
resolvidos durante a análise também não
são resolvidos durante a validação.
Processo de ER

 Alternativa (a mesma do impacto na

Análise) :
 Uma alternativa para realizar esta
verificação, na ausência dos requisitos,
seria realizar testes comparativos de todas
as funcionalidades apresentadas pelo
sistema antes e depois da modificação, o
que pode ser um procedimento caro e
ineficiente.
Gerência de Requisitos

 Impacto na Identificação e
Armazenamento dos Requisitos;
 Impacto na Gerência de Mudança dos
Requisitos;
 Impacto no Rastreamento dos
Requisitos.
Gerência de Requisitos

 Impacto na
Identificação e
Armazenamento dos Requisitos
 Podem ser prejudicados em abordagens
onde os requisitos são vinculados ao
escopo do projeto, ao invés do produto.
 todos os requisitos devem possuir algum tipo
de identificador único;
 garante a unicidade de identificação ao longo
do ciclo de vida completo do sistema.
 Solução Simples: BD
Gerência de Requisitos

 Impacto na Gerência de Mudança dos

Requisitos
 Pode ser prejudicada em circunstâncias
onde não está disponível uma
documentação adequada dos requisitos do
sistema, pois não é viável tentar gerenciar
mudanças em algo que é desconhecido.
Dificuldades
 Análise do problema:
 a análise dos requisitos originais não pode ser realizada
nestes casos. Em alguns casos será difícil determinar se
existe realmente um problema ou se o comportamento
apresentado pelo sistema está de acordo com os
requisitos originais do sistema, os quais não estão
disponíveis para análise.
 Análise e orçamento das modificações:
 para realização satisfatória desta análise são necessárias
informações que permitam identificar os requisitos
diretamente e indiretamente afetados pela modificação.
A ausência das informações pode levar a orçamentos
incorretos, pois não será possível determinar com
precisão o impacto da modificação sobre as
especificações do sistema.
 Implementação das modificações no documento
de requisitos:
 na ausência da documentação original, não existe o que
ser modificado. A implementação das modificações dos
requisitos ficará restrita a descrever qual o comportamento
Gerência de Requisitos

 Impacto no Rastreamento dos Requisitos

 Idealmente, o mantenedor deveria ser capaz de:
 Determinar, para cada manutenção solicitada, quais os
requisitos direta e indiretamente afetados pela
modificação;
 Qual a origem de cada um destes requisitos para
estender a modificação até estas fontes;
 Determinar todos os artefatos afetados pela mudança de
cada umas das informações afetadas pela modificação;
 sejam estas informações representadas por requisitos,
requisitos dependentes ou as origens dos requisitos.
Gerência de Requisitos

A ausência destas informações pode

gerar dificuldades para:
 Estimar o custo da manutenção;
 Estimar o tempo necessário para realizar a
manutenção;
 Estimar o risco envolvido na manutenção;

 Garantir o atendimento aos FCS em

projetos de manutenção.
Gerência de Requisitos

 Existem no mercado diversas

ferramentas CASE com as
funcionalidades necessárias, bem como
ferramentas especializadas em
gerência de requisitos, que podem dar
suporte ao processo