MANUTENIBILIDADE DE SOFTWARE

VALÉRIO BRUSAMOLIN

Instituto Científico de Ensino Superior e Pesquisa – ICESP

http://brusamolin.sites.uol.com.br e-mail: brusamolin@yahoo.com

RESUMO

Manutenibilidade é uma das características de qualidade de software, determinando o grau de

facilidade com que o mesmo pode ser corrigido ou aperfeiçoado. Um software com alto índice
de manutenibilidade necessita de menos tempo e pessoas para ser modificado. Este artigo
busca identificar os fatores que afetam a manutenibilidade de um artefato de software e suas
métricas.

ABSTRACT

Maintainability is one of the software characteristics of quality, determining how easy it can be
corrected or improved. A software with a high maintainability grade needs less time and people
to be modified. This article aims to identify factors that affect the maintainability of a software
artifact and it metrics.

Keywords: software maintainability, software quality, maintainability metrics, software

maintenance.

1 INTRODUÇÃO utilizem uma mesma linguagem. Para esse

fim, estabelece um ciclo de vida padrão
A atividade de manutenção de software composto pelos seguintes processos
é dispendiosa e consome tanto ou mais fundamentais:
recursos do que o desenvolvimento: entre
40 e 60 por cento do custo total de um a) Aquisição;
projeto (COLEMAN, ASH, 1994). b) Fornecimento;
Entretanto, as equipes de desenvolvimento c) Desenvolvimento;
são premidas por cronogramas e d) Operação;
orçamentos, descartando trabalhos que e) Manutenção:
poderiam reduzir custos futuros de
manutenção. No próprio levantamento de Segundo a mesma norma, o processo
requisitos, não é prática usual se de manutenção é ativado quando o produto
especificar ou verificar itens de qualidade de software é submetido a modificações no
que facilitem futuras manutenções, sejam código e na documentação associada
elas corretivas, adaptativas ou perfectivas. devido a um problema, ou à necessidade
de melhoria ou adaptação. O objetivo é
Este trabalho visa relacionar os modificar um produto de software existente,
conceitos, práticas e idéias que visem a preservando a sua integridade.
produção de software com maior índice de
manutenibilidade, estabelecendo um ponto Thomas Pigoski (1996, p.37-50) é de
de partida para a investigação mais parecer que este e outros ciclos de vida
aprofundada de como atuar efetivamente levam a uma interpretação equivocada do
no ciclo de desenvolvimento de software de processo de manutenção, pois tem início
forma a facilitar as necessárias correções e apenas após o produto já estar pronto e em
evoluções futuras. produção. Não se concebe a participação
do pessoal de manutenção nos processos
2 CICLOS DE VIDA DO SOFTWARE iniciais do ciclo.

A Norma NBR ISO/IEC 12207 - Pigoski sugere que o processo de

Processos do Ciclo de Vida do Software - manutenção inicie juntamente com o
tem como principal objetivo fornecer uma desenvolvimento. Dessa forma,
estrutura comum para que os envolvidos especialistas em manutenção poderiam
com o desenvolvimento de software atuar de forma a se obter um produto com

Revista Digital Online – www.revdigonline.com Vol 2 – Janeiro/2004

10
arquitetura propícia a reparos mais rápidos 5 MANUTENIBILIDADE
e baratos.
Manutenibilidade de software diz
3 CONCEITO DE MANUTENÇÃO respeito à facilidade com que o mesmo
pode ser modificado para satisfazer
Existem várias definições para requisitos do usuário ou ser corrigido
manutenção de software. Pigoski sintetiza quando deficiências são detectadas
em uma definição a sua opinião de como (PIGOSKI, 1996).
deveria ser o processo de manutenção:
“Manutenção de software é a totalidade de O IEEE (1993), estabelece que
atividades necessárias para prover, manutenibilidade é a facilidade com que
minimizando o custo, suporte a um sistema um sistema de software ou componente
de software. As atividades são executadas pode ser modificado para corrigir falhas,
tanto nos estágios pré-entrega quanto nos melhorar performance ou outros atributos,
pós-entrega. As atividades de pré-entrega ou adaptado para uma mudança de
incluem o planejamento para entrada em ambiente.
operação, suportabilidade e definição de
logística. As atividades de pós-entrega Se os softwares forem manuteníveis,
incluem modificação do software, diminui a demanda por desenvolvimento,
treinamento e operação de um help-desk” na medida que os softwares atuais podem
(PIGOSKI, 1996, p.46) evoluir para atender novas necessidades.
Por outro lado, aumentam as solicitações
4 TIPOS DE MANUTENÇÃO de manutenção (GLASS, 1993).

Segundo E. B. Swanson (1976), existem 6 MANUTENIBILIDADE E QUALIDADE

três tipos de manutenção:
A norma ISO/IEC 9126-1 (ISO/IEC
a)Corretiva: modificações necessárias 9126-1) - modelo de qualidade, classifica
para corrigir erros; os atributos de qualidade de software em
b)Adaptativa: qualquer esforço seis características. Uma delas é a
desencadeado como resultado de manutenibilidade, que é definida como o
modificações do meio ambiente em que esforço necessário para fazer modificações
o software deve operar; específicas no software. A referida norma
c)Perfectiva: todas as mudanças feitas desdobra a manutenibilidade ainda, em
para atender a evolução das cinco subcaracterísticas (ROCHA et Al,
necessidades do usuário. 2001, p. 117), (MARTINS, VOLPI, 2002):

A figura 1 mostra os percentuais de a)Analisabilidade: atributos do software

esforço aplicados em cada tipo de que evidenciam o esforço necessário para
manutenção. É equivocada a idéia de que deiagnosticar deficiências ou causas de
um sistema ideal, com nenhum erro, não falhas, ou para identificar partes a serem
teria manutenção. Os requisitos do usuário modificadas;
evoluem, tentando adquirir vantagens em
relação a concorrentes, reduzir custos b)Modificabilidade: atributos do software
operacionais ou simplesmente se adequar que evidenciam o esforço necessário para
a mudanças na legislação e processos. modificá-lo,remover seus defeitos ou
adaptá-lo a mudanças ambientais.

c)Estabilidade: atributos do software

Corretiva que evidenciam o risco de efeitos
20%
inesperados ocasionados por modificações.
Perfectiva
55% Adaptativa d)Testabilidade: atributos do software
25% que evidenciam o esforço necessário para
validar o software modificado.

e)Conformidade: atributos do software

que o tornam consonantes com padrões ou
Figura 1 - Percentuais de esforço convenções relacionadas à portabilidade.
de manutenção (PIGOSKI, 1996)

Revista Digital Online – www.revdigonline.com Vol 2 – Janeiro/2004

11
 7 FATORES QUE IMPACTAM positivo do uso de linguagens orientadas a
NA MANUTENIBILIDADE objetos é grande, pois modificações mais
localizadas levam a menor degradação do
a) Arquitetura código. A degradação ocorre em função do
número de linhas acrescidas ou
O design da arquitetura influencia mais modificadas (LAND, 2003); logo,
na manutenibilidade do que o design do manutenção com feita com menos código
algoritmo (ROMBACH, 1990, p. 22). significa menos entropia. Entropia pode ser
definida como a diferença entre o todo e
A Companhia de informática do Paraná, suas partes.
no intuito de definir recomendações para o
seu processo de desenvolvimento de c) Documentação
sistemas, elaborou várias versões de um
mesmo software, com arquiteturas Quando documentação ou
diferentes e verificando os resultados de especificações de design do software não
qualidade obtidos (MARTINS, VOLPI, estão disponíveis, o mantenedor tem de
2002). investir muito tempo para compreender o
produto antes de modificá-lo (PIGOSKI,
A experiência da empresa paranaense 1996, p. 276).
baseou-se no processo unificado, na UML
e na tecnologia de componentes da d) Compreensibilidade do Programa
Microsoft (COM). Foram utilizadas as
mesmas tecnologias, variando-se apenas a Existem estimativas de que os
arquitetura em seis experimentos, que programadores ficam entre 47% e 62% do
iniciaram com uma solução em duas tempo de trabalho tentando entender a
camadas até várias arquiteturas de n documentação e lógica dos programas
camadas multithreadeds. (PIGOSKI, 1996, p.276). Portanto, a
compreensibilidade dos programas deve
Como resultado, verificou-se que o ser aumentada se desejarmos diminuir os
investimento em arquitetura de software custos de manutenção.
aprimora, entre outras características de
qualidade, a manutenibilidade. A divisão da O uso de abreviaturas na declaração de
aplicação em componentes e dos variáveis dificulta a compreensibilidade de
componentes em classes tornou cada programas fonte (LAITINEN et al, 1997).
unidade de código bem menor do que em
uma abordagem monolítica, de modo que o 8 MÉTRICAS DE MANUTENIBILIDADE
esforço para modificar o código foi pequeno
e o potencial de inclusão de erros nessa Para controlar a manutenibilidade de um
modificação foi reduzido. software, deve-se saber como medi-la.
Para isso existem as métricas, que auxiliam
b) Tecnologia na verificação do software produzido. As
métricas que aferem a manutenibilidade
Uma das preocupações que o gerente verificam a complexidade do software
deve ter é a de verificar se a tecnologia que (BANDI et Al, 2003).
vai empregar na implementação do
software permite um bom grau de 9 MÉTRICAS DE MANUTENIBILIDADE
manutenibilidade, pois a fácil proliferação A NÍVEL DE CÓDIGO
de programas pode se tornar mais tarde,
um pesadelo de manutenção. Existem muitas métricas de
manutenibilidade a nível de código. A
A hipótese de que softwares que dificuldade não reside em se encontrá-las,
utilizam tecnologias orientadas a objetos mas sim em selecionar as mais adequadas
possuam alta manutenibilidade foi objeto a determinado projeto. As métricas podem
de estudo por Sallye M. Henry e Mathew ser utilizadas isoladamente ou fazer parte
Humphey (HENRY, HUMPHREY, 1990). O de métricas híbridas.
software produzido com linguagem
orientada a objetos necessita menos
modificações no código fonte, em locais
específicos. Em grandes sistemas, que são
manutenidos por longo tempo, o impacto

Revista Digital Online – www.revdigonline.com Vol 2 – Janeiro/2004

12
 10 MÉTRICAS DE a) Complexidade Ciclomática
COMPLEXIDADE DE HALSTED
Desenvolvida por McCabe para indicar
Halsted (HALSTEAD, 1977) a testabilidade e manutenibilidade de
desenvolveu métricas de complexidade que software, medindo o número de caminhos
ainda hoje são utilizadas para se derivar a linearmente independentes do programa
manutenibilidade de software. (ou método). Para determinar os caminhos,
representa-se o método como um grafo
As métricas de Halsted são baseadas fortemente conectado com uma única
em quatro números escalares derivados entrada e uma única saída. Os nodos são
diretamente de um programa fonte(SEI, blocos seqüenciais de código, e as arestas
2003): são decisões que causam uma ramificação.
A complexidade é dada por:
n1=número de operadores distintos
n2=número de operandos distintos CC = E –N+2
N1=número total de operadores
N2=número total de operandos Onde E = número de arestas e N =
número de nodos
A partir destes números, cinco métricas
são derivadas, como consta da tabela1. b) Fluxo de Informação

Tabela 1 – Métricas de Halsted Definido por Sallie Henry e Denis Kafura

Métrica Símbolo Fórmula (HENRY et al., 1981), o valor da métrica é
Tamanho do N N=N1+N2 dado pelo quadrado da multiplicação do
Programa fan-in de um módulo pelo seu fan-out.
Vocabulário n n=n1+n2
do Programa Cc = (fan-in * fan-out)2
Volume V V=N*(LOG2 n)
Dificuldade D D=(n1/2)* Fan-in é a quantidade de fluxos de
(N2/n2) informações que entram no programa; fan-
Esforço E E=D * V out é a quantidade de fluxos que saem do
programa. No cálculo também devem ser
11 MÉTRICAS DE MANUTENIBILIDADE consideradas as variáveis globais utilizadas
A NÍVEL DE DESIGN e modificadas pelo programa ou método.

As métricas de código ignoram as 12 MÉTRICAS HÍBRIDAS

interdependências entre módulos,
assumindo que cada componente é uma O Softwate Engineering Institute (SEI,
entidade separada. As métricas de design 2003) adotou uma técnica específica:o
de arquitetura tentam quantificar o nível de Maintainability Index (MI), que foi
interação entre módulos, partindo do desenvolvido por Paul Oman (OMAN,
pressuposto que as interdependências HAGEMEISTER, 1994). Artigo de Don
contribuem para a complexidade geral do Coleman (COLEMAN et Al, 1995), cita e
software (HENRY, SELIG, 1990). explica a como os elementos do MI foram
calibrados, validando a sua utilização para
H. Dieter Rombach, faz uma distinção a indústria de software.
entre design da arquitetura, que é de alto
nível, e design algorítmico, de baixo nível. Neste índice, a manutenibilidade é
O design da arquitetura impacta mais na calculada utilizando uma combinação de
manutenibilidade do que design do métricas. O MI de um conjunto de
algoritmo (ROMBACH, 1990, p. 22), e sua programas é dado pelo seguinte polinômio:
experiência demonstra que não vale a pena
MI=171 - 5.2 * ln(mediaV) - 0.23 * mediaV(g')
medir o código: maior ganho é obtido ao - 16.2 * ln (mediaLDC) + 50 * sen (sqrt(2.4 * perCM))
investir na arquitetura, e o fator mais
importante é a experiência e conhecimento Onde:
do designer. mediaV = Média do Volume de
Halstead por módulo
As métricas de complexidade a nível de mediaV(g') = Média estendida da
design que afetam a manutenibilidade mais complexidade ciclomática por
citadas na literatura são: módulo

Revista Digital Online – www.revdigonline.com Vol 2 – Janeiro/2004

13
 mediaLDC = Média de linhas de Os objetivos de qualidade são atingidos
código (LDC) por módulo atuando-se nos processos e nas métricas.
perCM = Média percentual de Somente o uso das métricas não garante o
linhas de comentários por módulo aumento da manutenibilidade, pois deve
(opcional) ser definido quando serão utilizadas, quem
fará a avaliação, quais serão as medidas
A manutenibilidade é diretamente corretivas, quais serão os índices
proporcional ao MI, ou seja, quanto maior o aceitáveis ou não.
índice, mais manutenível é o programa. Um
índice de 6, por exemplo, é de manutenção 14 CONCLUSÃO
quase impossível. Já um índice de 70 é
muito bom. A manuteniblidade de um software é
desejável que pode ser verificada.
13 PRÁTICAS DE MANUTENIBILIDADE
Como os processos de desenvolvimento
Thomas Pigoski nos dá uma pista sobre atuais não estimulam a preocupação com a
como produzir sistemas manuteníveis: manutenibilidade, e devem ser
pensar em manutenção já no levantamento aperfeiçoados para melhorar a qualidade
de requisitos (PIGOSKI, 1996, p.46). O dos produtos obtidos.
mesmo autor explica que os processos de
desenvolvimento e manutenção devem As práticas de manutenibilidade podem
evoluir e se integrar de alguma forma, ser inseridas na especificação de um
sugerindo algumas práticas que levam à processo de desenvolvimento, e a
manutenibilidade: qualidade do produto pode ser aferida
através das métricas apresentadas.
• Revisões de averiguação;
• Caminhamentos estruturados; Futuros trabalhos podem investigar o
• Uso de design orientado a objetos; aumento da manuteniblidade obtido com a
• Assegurar que cada linha de adaptação de um processo de
código tenha no máximo uma desenvolvimento de software.
declaração;
• Assegurar que comentários tenham 15 REFERÊNCIAS BIBLIOGRÁFICAS
informação útil;
• Assegurar que programação BANDI, Rajendra K, VAISHNAV, Vijay K,
“esotérica” seja evitada; TURK, Daniel E. Predicting Maintenance
• Empregar convenções de Perfformance Using Object Oriented
programação; Design Complexity Metrics. IEEE, 2003.
• Usar definições de dados comuns;
COLEMAN, Don, ASH, Dan. Using Metrics
• Estabelecer padrões para
to Evaluate Software System
desenvolvimento de procedimentos
Maintainability. IEEE, 1994.
e documentos do sistema;
• Registrar o processo de COLEMAN, Don, LOWTHER, Bruce,
desenvolvimento explicando a OMAN, Paul. The application of Software
filosofia de desenvolvimento e o Maintainability Models in Industrial Software
processo decisório; Systems. J. Systems Software, 1995; 29:3-
• Estimular a simplicidade; 16;
• Estudar possíveis mudanças
futuras e aperfeiçoamentos; GLASS, Robert L. Editor’s Corner – Which
• Medir a complexidade dos do You Think? Modern Methods Will Lead
componentes do sistema; to Less Maintenance, or More?. J. Systems
• Registrar os pontos fracos do Software. 1993; 23:209-210.
sistema e pontos problemáticos;
• Estabelecer critérios de aceitação HENRY, Sallie, SELIG, Calvin. Predicting
para avaliar a qualidade do Source-Code Complexity at Design Stage.
software, com particular atenção na IEEE, 1990.
qualidade da manutenibilidade;
• Previsão de falhas. HENRY, Sallie M, HUMPHEY, Matthew. A
controlled Experiment to Evaluate
Maintainability of Object-Oriented Software.

Revista Digital Online – www.revdigonline.com Vol 2 – Janeiro/2004

14
IEEE, 1990.
CHIDAMBER, Shyam R., KEMERER, Chris
LAND, Rikard. Software Deterioration And F. A metrics Suite for Object Oriented
Maintainability – A Model Proposal. Design. MIT Sloam School of Management,
Mälardalen University. 2003. 1993.

LI, Wei, HENRY, Sallie. Maintenance DEKLAVA, S. M. The Influence of the

Metrics for the Object Oriented Paradigm. Information System Development Approach
IEEE, 1993. on Maintenance. MIS, 1992.

MARTINS, Vidal, VOLPI, Lisiane M. FENTON, Norman, KRAUSE, Paul, NEIL,

Influência da Arquitetura na Qualidade do Martin. Software Measurement: Uncertainty
Software. Bate Byte, 2002. and Causal Modelling. 2001.

PALM, D. Jeffrey, ANDERSON, Keneth M., HALSTEAD, Maurice H. Elements of

LIEBERHERR, Karl M. Investigating the Software Science, Operating and
Relationshio Between VioLations of the Programming Systems Series. Vol. 7.
Law of Demeter and Software Elsevier, 1977.
Maintaninability.
HARRISON, R., COUNSELL, S., NITHI, R.
PIGOSKI, Thomas M. Pratical Software Experimental assessment of the effect of
Maintenance : Best Practices for Managing inheritance on the maintainability of object-
Your Software Investment. Wiley Computer oriented systems. J. Systems and Software,
Publishing, 1996. 2000.

DUNKE, Reiner R., FOLTIN, Erik. Metrics- HENRY, Sallie, KAFURA, Denis. Software
based Evaluation of Object-Oriented Structure Metrics Based on Information
Software Developmente Metrics. University Flow. IEE Transactions on Software
of Magdeburg, 1996. Engineering. 1981.

ROCHA, Ana R. C, MALDONADO, José SAKKINEN, M. Comments on “the Law of

Carlos, WEBER, Kival Chaves. Qualidade Demeter” and C++. ACM SIGPLAN
de Software – Teoria e Prática. Prentice Notices, New York, v.23, n.12, p.38-44,
Hall, 2001. Dec. 1988.

ROMBACH, H. Dieter. Design ZHUO, Fang, LOWTER, Bruce, OMAN,

Measurement: Some Lessons Learned. Paul, HAGEMEISTER, Jack. Constructing
IEEE, 1990. and Testing Software Maintainability
Assessment Models. IEEE, 1993.
SEI Software Technology Review,
Maintainability Index Technique for 16 BIOGRAFIA
Measuring Program Maintainability,
http://www.sei.cmu.edu/str/descriptions/mit Valério Brusamolin,
mpm.html, acessado em 10/11/2003. especialista em
Desenvolvimento de
STAVRINOUDIS, Dimitris, XENOS, Sistemas, é professor
Michalis, CHRISTODOULAKIS, Dimitris. do Instituto Científico de
Relation Between Software Metrics and Ensino Superior e
Maintainability. 1999. Pesquisa, nas
disciplinas de Análise
BRIAND, Lionel C., BUNSE, Christian, Orientada a Objetos e
DALY, John. A Controlled Experiment for Programação Orientada
Evaluating Quality Guidelines on the a Objetos.
Maintainability of Object-Oriented Designs.
IEEE, 2001.

Revista Digital Online – www.revdigonline.com Vol 2 – Janeiro/2004

15