Engenharia de Software

Manuteno de Software:
problemas tpicos e diretrizes

para uma disciplina especfica
Mateus Maida Paduelli
Manuteno de Software:
problemas tpicos e diretrizes
para uma disciplina especfica
Mateus Maida Paduelli
Orientadora: Profa. Dra. Rosely Sanches
Dissertao apresentada ao Instituto de Cincias

Matemticas e de Computao - ICMC-USP, como
parte dos requisitos necessrios para obteno do ttulo
de Mestre em Cincias de Computao e Matemtica
Computacional.
VERSO REVISADA APS A DEFESA

Data da Defesa:
Visto do Orientador:
USP So Carlos
Junho/2007
21/05/2007
Dedico este trabalho:

A meus pais, Srgio e Diva, pelo
carinho e exemplo de vida,
honestidade e perseverana.
vi
vii
AGRADECIMENTOS
A Deus, em primeiro lugar, pela sade, inteligncia e por ter me colocado ao lado das
pessoas certas para ajudarem-me neste trabalho.
Aos meus pais, Srgio e Diva, exemplos de persistncia, trabalho e honestidade, por
todo o carinho e ateno que sempre me dedicaram. Eles representam o foco de minha
inspirao conduzindo-me por todas as conquistas e realizaes. Aos meus irmos,
verdadeiros amigos, por todo o apoio nos momentos em que necessitei. Aos meus avs e avs
pelo exemplo de vida e perseverana.
A Rosely Sanches, professora, orientadora e acima de tudo amiga pela confiana
depositada em mim e por fazer-me acreditar em minha capacidade. Tambm pelas suas
assistncias, orientaes e contribuies durante todas as atividades desta pesquisa.
E a todos que, de alguma forma, contriburam para essa minha vitria.
Muito Obrigado!
viii
ix
No sei como o mundo me v; mas eu me sinto como um garoto brincando na praia,

contente em achar aqui e ali uma pedrinha mais lisa ou uma concha mais bonita,
tendo sempre diante de mim, ainda por descobrir, o grande oceano da verdade.
Isaac Newton (1642-1727)
xi
RESUMO
PADUELLI, M. M. Manuteno de Software: problemas tpicos e diretrizes para uma

disciplina especfica. 2007. 144 p. Dissertao (Mestrado) Instituto de Cincias
Matemticas e de Computao, Universidade de So Paulo, So Carlos, SP, 2007.
O volume crescente de software em funcionamento em todo tipo de organizao vem
despertando ateno para uma fase do ciclo de vida de software, at ento considerada sempre
de maneira secundria, a manuteno de software. O fato de geralmente no ser vivel
substituir os produtos de software de uma organizao por outros baseados em tecnologias
mais recentes, torna a manuteno daqueles sistemas legados um desafio adicional para a
busca de tcnicas e mtodos para a manuteno de software. Os problemas oriundos dessa
atividade precisam ser melhor compreendidos, e justamente na definio e estudo dessas
dificuldades que este trabalho se dedica. O confronto da teoria de engenharia de software com
observaes prticas conduz para a melhor definio de quais so os problemas tpicos de
manuteno de software e do que se dispe para abord-los. Finalmente, com base no
entendimento formado sobre os problemas, neste trabalho so apresentadas diretrizes para
guiar a elaborao de uma disciplina especfica de manuteno de software para cursos de
graduao na rea de computao.
Palavras-chave: Manuteno de Software, Problemas de Manuteno de Software, Ensino de
Manuteno de Software.
xii
xiii
ABSTRACT
PADUELLI, M. M. Software Maintenance: typical problems and guidelines for a specific

discipline. 2007. 144 p. Dissertao (Mestrado) Instituto de Cincias Matemticas e de
Computao, Universidade de So Paulo, So Carlos, SP, 2007.
The increasing volume of software being used in all types of organizations has been calling
attention for a phase of the software life cycle, until now considered in a secondary way, the
software maintenance. Since it is generally not possible to replace all software products used
in an organization by others based on more recent technologies, the maintenance of those
legacy systems becomes one more challenge for the search of techniques and methods to
handle the software maintenance efficiently. The problems arising from this activity need to
be better understood, and it is precisely on the definition and study of these difficulties that
this work is devoted. The confrontation between the theory of software engineering and
practice observations drives to the definition of typical problems of software maintenance and
what exists to solve them. Besides, based on the understanding about these problems, this
work also presents guidelines to drive the elaboration of a specific discipline of software
maintenance for undergraduate courses in computing area.
Keywords: Software Maintenance, Software Maintenance Problems, Software Maintenance
Teaching.
xiv
xv
SUMRIO
.
1. INTRODUO ................................................................................................................................. 21
1.1 CONTEXTO E MOTIVAO .............................................................................................................. 21
1.2 OBJETIVOS ................................................................................................................................... 23
1.3 ORGANIZAO DO TRABALHO ........................................................................................................ 25
2. MANUTENO DE SOFTWARE .................................................................................................... 27
2.1 CONSIDERAES INICIAIS.............................................................................................................. 27
2.2 ATIVIDADE DE MANUTENO DE SOFTWARE ................................................................................... 27
2.2.1 Definies ........................................................................................................................... 28
2.2.2 Evoluo de Software......................................................................................................... 30
2.2.3 Natureza e Caractersticas ................................................................................................. 33
2.2.4 Tipos de Manuteno ......................................................................................................... 34
2.2.5 Custos e Desafios............................................................................................................... 36
2.3 NORMA ISO/IEC 12207................................................................................................................ 37
2.4 SISTEMAS LEGADOS ..................................................................................................................... 41
2.4.1 Conceitos ............................................................................................................................ 42
2.4.2 Problemtica dos Sistemas Legados ................................................................................. 42
2.5 GERENCIAMENTO DE MANUTENO DE SOFTWARE ........................................................................ 44
2.6 HISTRICO DOS PROBLEMAS DE MANUTENO DE SOFTWARE ....................................................... 48
2.7 CONSIDERAES FINAIS ............................................................................................................... 52
3. ESTUDO DE CASO ......................................................................................................................... 53
3.2 DESCRIO DA ORGANIZAO ...................................................................................................... 53
3.3 DINMICA DE MANUTENO .......................................................................................................... 54
3.3.1 Registro de Manutenes................................................................................................... 54
3.3.2 Controle de Verses ........................................................................................................... 56
3.4 METODOLOGIA .............................................................................................................................. 58
3.4.1 Parte A Base de Dados ................................................................................................... 59
3.4.2 Parte B Questionrio e Entrevista ................................................................................... 59
3.5 ANLISE DOS DADOS COLETADOS ................................................................................................. 59
3.5.1 Estatsticas sobre a Base de Dados................................................................................... 60
3.5.2 Ambiente e Equipe de Manuteno ................................................................................... 63
3.6 PROBLEMAS IDENTIFICADOS .......................................................................................................... 64
3.7 CONCLUSES PARCIAIS ................................................................................................................ 64
4. PROBLEMAS DE MANUTENO DE SOFTWARE ...................................................................... 67
4.2 PROBLEMAS DO PASSADO VERSUS PROBLEMAS ATUAIS ................................................................. 67
4.3 PROBLEMAS DE MANUTENO PUBLICADOS .................................................................................. 68
4.4 RELACIONAMENTO ENTRE OS PROBLEMAS DE MANUTENO E OS GRUPOS DE PROCESSOS DA NORMA
ISO/IEC 12207 .................................................................................................................................. 70
xvi
4.5 CONSIDERAES FINAIS ............................................................................................................... 73
5. ALTERNATIVAS DE REDUO DOS PROBLEMAS DE MANUTENO DE SOFTWARE ...... 75
5.2 EXTENSO DO ESTUDO DE CASO ................................................................................................... 76
5.2.1 Metodologia ........................................................................................................................ 76
5.2.2 Solues Identificadas........................................................................................................ 76
5.2.3 Consideraes Gerais ........................................................................................................ 79
5.3 SOLUES COM BASE NA NORMA ISO/IEC 12207 ......................................................................... 80
5.3.1 Grupo de Processos de Engenharia .................................................................................. 83
5.3.2 Grupo de Processos de Operao ..................................................................................... 88
5.3.3 Grupo de Processos de Gerncia ...................................................................................... 89
5.3.4 Grupo de Processos de Recursos e Infra-estrutura........................................................... 97
5.3.5 Grupo de Processos de Gerncia de Configurao......................................................... 102
5.4 PROPOSTAS NA LITERATURA ....................................................................................................... 107
5.5 CONSIDERAES FINAIS ............................................................................................................. 108
6. CARACTERSTICAS DO ENSINO DE MANUTENO DE SOFTWARE ................................... 109
6.1
6.2
6.3
6.4
6.5
6.6
CONSIDERAES INICIAIS............................................................................................................ 109

PANORAMA DO ENSINO DE ENGENHARIA DE SOFTWARE ............................................................... 109
QUESTES SOBRE O ENSINO DE MANUTENO DE SOFTWARE ..................................................... 111
PADRES DE CURRCULO PARA CURSOS DE COMPUTAO .......................................................... 112
EXPERINCIAS COM O ENSINO DE MANUTENO DE SOFTWARE ................................................... 116
CONSIDERAES FINAIS ............................................................................................................. 118
7. PERSPECTIVAS PARA UMA DISCIPLINA DE MANUTENO DE SOFTWARE ..................... 119

7.1 CONSIDERAES INICIAIS............................................................................................................ 119
7.2 VISO PEDAGGICA .................................................................................................................... 120
7.3 PROCEDIMENTOS PARA DISCIPLINA DE MANUTENO DE SOFTWARE ............................................ 122
7.3.1 Modelo Geral .................................................................................................................... 122
7.3.2 Estruturao de Mdulos.................................................................................................. 123
7.3.3 Mdulo A Conceitos....................................................................................................... 124
7.3.4 Mdulo B Ambiente de Manuteno ............................................................................. 125
7.3.5 Mdulo C Manutenibilidade Durante o Desenvolvimento ............................................. 128
7.3.6 Mdulo D Manuteno no Produto Final de Software................................................... 131
7.3.7 Resumo da Estrutura........................................................................................................ 135
7.4 CONSIDERAES FINAIS ............................................................................................................. 137
8. CONCLUSO ................................................................................................................................ 139
8.1 CONSIDERAES GERAIS............................................................................................................ 139
8.2 CONTRIBUIES ......................................................................................................................... 140
8.3 TRABALHOS FUTUROS................................................................................................................. 140
REFERNCIAS BIBLIOGRFICAS .................................................................................................. 143
APNDICE A ..................................................................................................................................... 147
APNDICE B ..................................................................................................................................... 151
xvii
LISTA DE FIGURAS
.
FIGURA 1.1: MODELO GERAL DO DESENVOLVIMENTO DESTE TRABALHO..................................................... 23
FIGURA 2.1: FLUXO ENVOLVIDO NA MANUTENO DE SOFTWARE (ADAPTAO POLO ET AL. 1999)............. 29
FIGURA 2.2: CURVA DE ESFORO PARA MANUTENO DE SOFTWARE (ADAPTAO DE BHATT
ET AL. 2004) 33
FIGURA 2.3: CICLO DE VIDA DE MANUTENO DE SOFTWARE (ADAPTAO DE KUNG & HSU, 1998) ............ 34
FIGURA 2.4: ESTRUTURAO DA NORMA ISO/IEC 12207 ........................................................................ 38
FIGURA 2.5: PROCESSOS DO CICLO DE VIDA DA NORMA ISO/IEC 12207................................................... 38
FIGURA 2.6: ATIVIDADES DO PROCESSO DE MANUTENO DE SOFTWARE E SISTEMA (ISO/IEC 12207) ...... 40
FIGURA 2.7: ESTRUTURA DA ABORDAGEM CONSERTO RPIDO .................................................................. 46
FIGURA 2.8: ESTRUTURA DA ABORDAGEM MELHORIA INTERATIVA .............................................................. 46
FIGURA 2.9: ESTRUTURA DA ABORDAGEM REUSO TOTAL .......................................................................... 46
FIGURA 2.10: RELAO DE CAUSA ENTRE OS FATORES ENVOLVIDOS NA MANUTENO DE SOFTWARE .......... 51
FIGURA 3.1: ETAPAS ENVOLVIDAS NA SOLICITAO DE MANUTENES ...................................................... 55
FIGURA 3.2: PADRO DE NUMERAO DE VERSES ................................................................................. 57
FIGURA 3.3: LINHA DO TEMPO PARA DISPONIBILIZAO DE VERSES ......................................................... 58
FIGURA 3.4: TOTAL MENSAL DE SOLICITAES DE MANUTENO .............................................................. 60
FIGURA 3.5: DIAS NECESSRIOS PARA A CONCLUSO DE MANUTENES .................................................. 61
FIGURA 3.6: DISTRIBUIO DE PRIORIDADES DAS MANUTENES ............................................................. 61
FIGURA 3.7: DISTRIBUIO DOS PROBLEMAS ENTRE OS TIPOS DE MANUTENO ........................................ 62
FIGURA 3.8: TEMPO CONSUMIDO EM DESENVOLVIMENTO VERSUS EM MANUTENO .................................. 62
FIGURA 4.1: DISTRIBUIO DOS PROBLEMAS NOS GRUPOS DE PROCESSOS ............................................... 72
FIGURA 7.1: ESTRUTURA HIERRQUICA ADOTADA PARA OS ASSUNTOS DA DISCIPLINA .............................. 122
FIGURA 7.2: VISO GERAL DA ESTRUTURA DE MDULOS E TPICOS ........................................................ 136
xviii
xix
LISTA DE QUADROS
.
QUADRO 2.1: DEFINIES IEEE PARA AS CATEGORIAS DE MANUTENO DE SOFTWARE ........................... 35
QUADRO 2.2: VERIFICAO DO CONHECIMENTO SOBRE CADA ITEM RESPONDIDO....................................... 50
QUADRO 3.1: SITUAES POSSVEIS PARA OS CHAMADOS DE MANUTENO ............................................. 55
QUADRO 3.2: CARACTERSTICAS DE MANUTENO CONSIDERADAS E SEUS OBJETIVOS .............................. 59
QUADRO 3.3: PROBLEMAS DE MANUTENO DE SOFTWARE LISTA PARCIAL............................................. 64
QUADRO 4.1: COMPARAO ENTRE PROBLEMAS DE MANUTENO DE SOFTWARE ..................................... 68
QUADRO 4.2: PROBLEMAS DE MANUTENO DE SOFTWARE LISTA GERAL ............................................... 69
QUADRO 4.3: GRUPOS DE PROCESSOS NO OBSERVADOS E AS RESPECTIVAS CONSEQNCIAS ................ 71
QUADRO 5.1: PROCESSOS DA NORMA ISO/IEC 12207 E PROBLEMAS DE MANUTENO DE SOFTWARE ...... 80
QUADRO 5.2: ENGENHARIA: PROCESSO DE ELICITAO DE REQUISITOS ................................................... 83
QUADRO 5.3: ENGENHARIA: PROCESSO DE ANLISE DE REQUISITOS DE SOFTWARE ................................. 84
QUADRO 5.4: ENGENHARIA: PROCESSO DE TESTE DE SOFTWARE ............................................................ 86
QUADRO 5.5: ENGENHARIA: PROCESSO DE MANUTENO DE SOFTWARE E SISTEMA ................................ 87
QUADRO 5.6: OPERAO: PROCESSO DE SUPORTE AO CLIENTE .............................................................. 88
QUADRO 5.7: GERNCIA: PROCESSO DE ALINHAMENTO ORGANIZACIONAL ................................................ 89
QUADRO 5.8: GERNCIA: PROCESSO DE GERNCIA ORGANIZACIONAL ...................................................... 91
QUADRO 5.9: GERNCIA: PROCESSO DE GERNCIA DE PROJETO ............................................................. 92
QUADRO 5.10: GERNCIA: PROCESSO DE GERNCIA DE QUALIDADE .......................................................... 94
QUADRO 5.11: GERNCIA: PROCESSO DE GERNCIA DE RISCOS ............................................................... 95
QUADRO 5.12: RECURSOS E INFRA-ESTRUTURA: PROCESSO DE GERNCIA DE RECURSOS HUMANOS ......... 97
QUADRO 5.13: RECURSOS E INFRA-ESTRUTURA: PROCESSO DE TREINAMENTO .......................................... 99
QUADRO 5.14: RECURSOS E INFRA-ESTRUTURA: PROCESSO DE GERENCIAMENTO DO CONHECIMENTO ..... 100
QUADRO 5.15: RECURSOS E INFRA-ESTRUTURA: PROCESSO DE INFRA-ESTRUTURA .................................. 101
QUADRO 5.16: GERNCIA DE CONFIGURAO: PROCESSO DE DOCUMENTAO ....................................... 102
QUADRO 5.17: GERNCIA DE CONFIGURAO: PROCESSO DE GERNCIA DE CONFIGURAO ................... 104
QUADRO 5.18: GERNCIA DE CONFIGURAO: PROCESSO DE GERNCIA DE SOLICITAES DE MUDANA 105
QUADRO 6.1: CURSOS DE COMPUTAO E DISCIPLINAS DE ACORDO COM A SBC .................................... 114
QUADRO 6.2: NFASES SUGERIDAS PARA A DISCIPLINA DE MANUTENO DE SOFTWARE .......................... 116
QUADRO 7.1: MDULOS PARA UMA DISCIPLINA DE MANUTENO DE SOFTWARE ...................................... 123
xx
QUADRO 7.2: TPICOS DO MDULO A CONCEITOS ............................................................................. 124
QUADRO 7.3: TPICOS DO MDULO B AMBIENTE DE MANUTENO .................................................... 126
QUADRO 7.4: TPICOS DO MDULO C MANUTENIBILIDADE DURANTE O DESENVOLVIMENTO ................. 129
QUADRO 7.5: TPICOS DO MDULO D MANUTENO NO PRODUTO FINAL DE SOFTWARE .................... 131
CAPTULO
1
Introduo
.
1.1 Contexto e Motivao
O termo engenharia de software foi criado em uma conferncia no final da dcada de 60
(Naur & Randell, 1968), sediada em Garmisch, Alemanha, que envolveu usurios, fabricantes
e pesquisadores, interessados em tratar dos constantes problemas no desenvolvimento de
software.
Os problemas enfatizados na poca abrangiam atrasos na entrega, oramentos irreais,
falta de resposta correta aos anseios dos usurios e dificuldades diversas para criar, usar,
manter e melhorar software. Desde aqueles primeiros momentos, a engenharia de software
iniciou seu desenvolvimento, passando a criar e aperfeioar continuamente mtodos,
procedimentos e ferramentas para tornar a atividade de desenvolver e manter software uma
tarefa que pudesse ser medida, controlada e avaliada. De uma forma simples, pode-se dizer
que ao longo das ltimas dcadas houve um amadurecimento do conceito de software e de
suas caractersticas e processos atrelados.
Todo esse desenvolvimento culmina na atualidade com o aumento da ateno
destinada atividade de manuteno de software. Essa importncia decorre, em parte, da
crescente quantidade de software em funcionamento nas organizaes ao redor de todo globo,
que por representarem investimentos significativos, precisam continuar em funcionamento
atravs dos anos, e no serem substitudos, momento no qual surge a necessidade de
Captulo 1 Introduo
22
manuteno de software. Essa necessidade traz consigo problemas originados de diversas

fontes, como a prpria administrao da organizao, o perfil dos clientes ou as deficientes
tcnicas utilizadas na construo do software original.
Considerando-se toda a importncia prtica da atividade de manuteno de software,
esperado que as boas universidades preparem seus alunos para oferecerem mecanismos
acadmicos apoiados na prtica, que facilitem a minimizao dos efeitos negativos que a falta
de controle e entendimento da atividade de manuteno pode trazer para os negcios.
Esse entendimento evidenciado pelo fato de que a demanda por profissionais
capazes de tratar eficientemente problemas oriundos da manuteno de software possui
crescimento visvel, uma vez que a cada ano mais softwares so conduzidos ao perfil de
recursos indispensveis e construdos com tcnicas no mais recomendveis.
Considerando que a engenharia de software um campo de estudo em evoluo e
adaptao contnua, uma vez que seu objeto de trabalho (software) apresenta caractersticas
dinmicas, de se esperar que a forma de replicar todo o conhecimento acumulado tambm
passe por atualizaes e adaptaes. Esse ajuste natural visa formar novos pesquisadores ou
preparar futuros profissionais, para atuarem de forma mais produtiva e eficiente nas
organizaes que utilizem software como atividade meio ou atividade fim.
Partindo desse pressuposto, este trabalho contribui tanto no aspecto de entender
melhor as dificuldades de uma das mais importantes atividades dentro do ciclo de vida de
software, a atividade de manuteno de software, como tambm oferece diretrizes para o
ensino acadmico dessa atividade. O enfoque em ensino justifica-se pela carncia ainda
existente na obteno de informaes que estabeleam uma base slida para que as
universidades possam propor uma forma no puramente acadmica de ensinar manuteno de
software, mas sim uma maneira que oferea tambm aos alunos uma viso mais ampla e clara
de todos os fatores envolvidos nessa tarefa. Essa viso dever estar ligada realidade das
organizaes e aos seus problemas dirios quando precisam manter software dentro de
inmeras limitaes, como tempo, recursos e falta de treinamento. Essas consideraes vo ao
encontro da influncia internacional da Association for Computing Machinery (ACM), que de
acordo com o que ser exposto no captulo de Caractersticas do Ensino de Manuteno de
Software, j considera uma disciplina especfica de manuteno de software nos seus
currculos de referncia para cursos de computao.
Existem iniciativas em algumas universidades brasileiras no sentido de estabelecer
uma disciplina especfica para manuteno de software em cursos de graduao na rea de
computao. Essa postura mostra a conscientizao crescente sobre a importncia de ensinar
Captulo 1 Introduo
23
manuteno de software ainda no meio acadmico, antes que os alunos se tornem

profissionais.
No entanto, ainda no existe um consenso sobre o contedo que essa disciplina deve
abordar. Alguns relatos descrevem os resultados com a implantao experimental de
disciplinas de manuteno de software em cursos de graduao, e alguns at de psgraduao, sendo que em todos os casos o contedo ministrado baseado em experincias
pessoais dos professores. A falta de dados que apresentem nmeros atualizados sobre os
problemas mais comuns um dos motivos dessa incerteza sobre o contedo a ser abordado.
Partindo-se dessas consideraes, fica mais claro entender a necessidade de pesquisar
e relacionar mais informaes sobre a atividade de manuteno dentro de organizaes, de
maneira a evidenciar quais so as principais dificuldades dessa atividade, para que possam
ento ser estabelecidos programas de ensino sustentados tambm pela prtica e no apenas
fechados dentro da realidade do meio acadmico. Entender quais so os problemas um passo
muito importante para que seja possvel estudar as formas de abordagem possveis para tais
problemas, ou para evitar que eles surjam, organizando por fim um contedo a ser ensinado
que esteja adequado realidade organizacional.
1.2 Objetivos
Os objetivos desta pesquisa, bem como os passos realizados para alcan-los, podem ser
visualizados de uma maneira global pelo esquema mostrado na figura 1.1.
FIGURA 1.1: MODELO GERAL DO DESENVOLVIMENTO DESTE TRABALHO
Captulo 1 Introduo
24
Em um primeiro momento, por meio de um estudo de caso em uma organizao do

setor de software, foram levantados totais a respeito de pedidos de manuteno sobre
diferentes caractersticas (data, tipo de manuteno, complexidade etc.), bem como sobre a
maneira como a organizao aborda a sua atividade de manuteno (fluxo de informaes,
sistemtica de atualizaes etc.), sendo possvel inferir sobre os principais problemas afetos
abordagem que a organizao utiliza para a atividade.
Conforme sugere a figura anterior, ao resultado das informaes obtidas pelos pedidos
de manuteno so somados os itens referidos em artigos relacionados a problemas
manuteno de software, para finalmente estabelecer uma relao dos problemas tpicos de
manuteno.
No passo seguinte, aps a elaborao da relao de problemas, so consideradas, por
um lado, as solues eficientes adotadas pela organizao estudada para resolver ou reduzir
os seus problemas de manuteno, sendo as caractersticas de manuteno a forma
encontrada para oferecer respostas aos seus problemas. Por outro lado, so verificados artigos
com solues eficientes apontadas para problemas correlatos, finalmente considerando o que a
teoria de engenharia de software disponibiliza em termos de recursos para investir contra os
problemas de manuteno. Aqui, a abordagem da engenharia de software foi fortemente
baseada na norma ISO/IEC 122071, conforme ser apresentado nos captulos seguintes. Essa
fuso de informaes, conforme mostram as setas na figura anterior, produz uma relao de
alternativas para a reduo dos problemas de manuteno de software.
Finalmente, sabendo-se quais so os problemas, e o que pode ser feito para auxiliar
seu controle ou preveno, so propostas diretrizes para o ensino de manuteno de software.
Essas diretrizes levam a uma proposta de assuntos considerados essenciais a uma disciplina de
manuteno de software, no sendo, no entanto, uma especificao final de ementa.
Essa maneira de propor os temas essenciais a uma disciplina, por meio da verificao
dos problemas prticos existentes, est de acordo com a idia de proposta pedaggica
orientada a problemas, conforme ser discutido no item 7.2.
Pode-se resumir o propsito deste trabalho como uma contribuio ao estudo de
problemas de manuteno de software e tambm sistematizao do ensino de manuteno
de software, por meio de um levantamento de dados reais e seu relacionamento com boas
prticas em engenharia de software, de forma a estabelecer uma base no qual o contedo da
disciplina possa se apoiar.
International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC).
Captulo 1 Introduo
25
1.3 Organizao do Trabalho

Esta dissertao est dividida em oito captulos. No presente captulo foi apresentado o
contexto em que se insere o trabalho, as motivaes para o seu desenvolvimento e os seus
objetivos. No captulo 2 apresentada a reviso bibliogrfica relativa manuteno de
software, expondo os conceitos importantes que sero utilizados ao longo do texto. No
captulo 3 descrito o estudo de caso realizado, incluindo a metodologia empregada, o
levantamento de dados e os resultados obtidos.
No captulo 4 feita uma comparao entre os problemas de manuteno de software
do passado com os atualmente verificados no estudo de caso, alm do estabelecimento de um
rol de problemas tpicos de manuteno. Esse rol retomado no captulo 5, que apresenta
alternativas para a reduo dos problemas, com base na extenso do estudo de caso, na norma
ISO/IEC 12207 e na literatura.
Nos captulos seguintes so tratados assuntos referentes ao ensino de manuteno de
software. No captulo 6 feita uma reviso bibliogrfica das caractersticas pertinentes a esse
ensino, com a exposio de padres de currculos para cursos de computao e resultados com
disciplinas de manuteno de software experimentais.
No captulo 7 apresentada a proposta de assuntos que se mostraram essenciais a uma
futura ementa de disciplina de manuteno de software, expondo a fundamentao de cada
assunto, bem como a proposta de estruturao.
Finalmente, no captulo 8, as concluses gerais deste trabalho so apresentadas,
incluindo suas contribuies e idias para trabalhos futuros.
Captulo 1 Introduo
26
CAPTULO
2
Manuteno de Software
.
2.1 Consideraes Iniciais
O desenvolvimento de qualquer software, exceto programas muito simples, uma tarefa
bastante complexa. Esse fato se tornou evidente com a crise de software, o que originou o
conceito de engenharia de software como uma abordagem sistemtica, disciplinada e
quantificvel para o desenvolvimento, manuteno e descarte de software.
A engenharia de software surgiu inicialmente mais como uma promessa do que uma
realidade. De fato, muitos dos problemas ligados ao desenvolvimento e manuteno de
software continuam sem soluo, apesar de muitos conceitos terem evoludo.
Entender o que significa manuteno de software, e principalmente a abrangncia do
significado do termo, constitui passo fundamental para o estudo e aprofundamento de
solues para os problemas atrelados a essa tarefa.
Faz-se importante destacar nesse ponto que o autor deste trabalho vem trabalhando
diretamente com manuteno de software no meio organizacional h alguns anos, desde o
momento em que concluiu seu curso de graduao na rea de computao. Esta experincia
acaba por influenciar a percepo dos fatores mais importantes envolvidos na prtica com a
manuteno de software, contribuindo para a concretizao deste trabalho.
2.2 Atividade de Manuteno de Software

Este tpico tem por objetivo destacar as caractersticas, tipos e desafios para a manuteno de
Captulo 2 Manuteno de Software
28
software. Trata-se de um tpico importante para esclarecer alguns pontos pertinentes ao

assunto que sero considerados ao longo deste trabalho.
2.2.1 Definies
A atividade de manuteno de software caracterizada pela modificao de um produto de
software j entregue ao cliente, para a correo de eventuais erros, melhora em seu
desempenho, ou qualquer outro atributo, ou ainda para adaptao desse produto a um
ambiente modificado (IEEE, 1998).
Embora a definio trate genericamente qualquer produto de software, existem
diferenas entre a manuteno de softwares com propsitos distintos. Essa distino
explicada por Pfleeger (2001), que estabelece trs categorias de sistemas.
Uma primeira classificao2 representa aqueles softwares construdos com base em
uma especificao rgida e bem definida, cujos resultados esperados so bem conhecidos. Por
exemplo, um software construdo para realizar operaes com matrizes (adio, multiplicao
e inverso). Nesse tipo de software, uma vez que tenha sido construdo considerando a correta
implementao do mtodo, dificilmente haver a necessidade de manutenes.
J em uma segunda classificao3, so agrupados os softwares que constituem
implementaes de solues aproximadas para problemas do mundo real, uma vez que
solues completas somente so conseguidas na teoria nesses casos. Como exemplo, pode-se
citar um jogo de xadrez. Embora suas regras sejam bem definidas, no possvel construir um
software que calcule a cada passo todos os possveis movimentos de peas do tabuleiro, de
forma a determinar o melhor movimento. Isso porque o nmero de movimentos possveis
muito grande para ser calculado em um intervalo de tempo relativamente curto. A tcnica
utilizada para desenvolver esse tipo de soluo baseia-se em descrever o problema de forma
abstrata e ento definir os requisitos de software a partir dessa abstrao.
Percebe-se que esse tipo de sistema j abre espao para diferentes interpretaes por
parte do desenvolvedor, o que tende a produzir software com maior necessidade de
manuteno do que quando comparado aos da classificao anterior. Por considerar uma
abstrao para especificao de requisitos, a necessidade de mudana pode aparecer caso a
abstrao mude, na medida em que um maior entendimento do problema seja alcanado.
Finalmente, uma terceira e ltima classe de softwares4 considera mudanas no
ambiente onde o software vai ser utilizado, caracterstica no existente nas duas classificaes
anteriores.
2
S-systems, na nomenclatura adotada pelo autor.

P-systems, idem.
4
E-systems, idem.
3
29
Um software integrante da terceira classificao corresponde quele criado com base

em um modelo dos processos abstratos envolvidos no sistema, e precisar mudar sempre que
ocorrer mudanas nesses modelos, sendo, portanto, parte do ambiente que ele modela. Um
exemplo desse tipo de software seria aquele que apresenta informaes da economia de um
pas. medida que a economia passa a ser mais bem compreendida, o modelo muda e com
ele a abstrao do problema, causando uma necessidade inevitvel de manuteno no
software. Esse tipo de software, comumente encontrado no dia-a-dia das organizaes, tem
interesse particular neste trabalho.
Alm de considerar tipos diferentes de software, o processo de manuteno no
corresponde a uma atividade isolada. Durante a sua execuo, diferentes partes precisam
interagir de forma que os objetivos da manuteno sejam entendidos e os resultados esperados
alcanados. Essas partes so apresentadas em Polo et al. (1999), que as define como:
Organizao Cliente: essa organizao corresponde ao adquirente do software,

conforme definido pela norma ISO/IEC 12207. Isso significa a organizao que possui
o software e requisita o servio de manuteno.
Mantenedor: trata-se da organizao que oferece o servio de manuteno.
Usurio: representa a organizao ou pessoa que utiliza o software em questo,

valendo-se de suas funcionalidades para automatizar e facilitar tarefas.
Ainda segundo esse autor, existe um relacionamento entre essas partes e a constituio
de um fluxo para os pedidos de manuteno, conforme esquematizado na figura 2.1.
FIGURA 2.1: FLUXO ENVOLVIDO NA MANUTENO DE SOFTWARE (ADAPTAO POLO ET AL. 1999)
A organizao solicitante deve possuir algum responsvel pela solicitao de

manuteno, que ser encarregado de verificar os requisitos e informar o mantenedor. Esse
30
responsvel dever considerar os erros e dificuldades apontadas pelo help-desk, que

corresponde ao departamento diretamente encarregado do dilogo com os usurios.
Do lado do mantenedor, a organizao que presta o servio deve possuir algum
responsvel por avaliar as requisies, julgando-as apropriadas ou no para os objetivos do
software e da organizao solicitante. Uma vez que os pedidos de manuteno so aceitos,
deve existir algum responsvel por estabelecer um cronograma de entrega, que dever
considerar as prioridades e interesses de ambas as partes. Esse cronograma dever ser seguido
pela equipe de manuteno, que compreende o pessoal envolvido diretamente em atender s
solicitaes.
Finalmente, o papel do usurio consiste em utilizar o software reportando problemas
para o help-desk, que por sua vez informar o responsvel pelas solicitaes de manuteno,
fechando o ciclo.
Uma observao faz-se necessria com relao ao termo falha e defeito de software.
Conforme explica Pressman (2005), a IEEE5 define para o contexto de hardware a explicao
de que um defeito constitui uma anomalia do produto. J uma falha pode significar um
defeito em um dispositivo ou componente, ou uma definio incorreta de passo, processo ou
de dados em um programa de computador.
No contexto de manuteno de software, os termos falha e defeito so sinnimos, e
ambos se referem a algum problema de qualidade, identificado aps o software ter sido
entregue ao usurio.
2.2.2 Evoluo de Software

As mudanas que ocorrero em um software para deix-lo mais completo, livre de erros, ou
adaptado ao seu ambiente, podem ser definidas como atividades de evoluo de software,
conforme explica Sommerville (2003).
A deciso de investir na evoluo de um software, ou abandon-lo para iniciar um
projeto novo, construdo com base nos requisitos atuais, no uma tarefa trivial (Pfleeger,
2001). Essa deciso deve considerar fatores como o custo envolvido, a confiabilidade do
software aps a manuteno, a capacidade que possuir de se adaptar a mudanas futuras, seu
desempenho, limitaes de suas atuais funes, e ainda as opes existentes no mercado que
atendam o mesmo problema de maneira mais completa, rpida e barata.
Se o software atual funciona adequadamente, supe-se que a organizao que o utiliza
ter uma preferncia em aplicar a ele apenas os ajustes necessrios em funo de mudanas
nos negcios ou outras necessidades de adaptaes, do que substitu-lo por completo.
5
Institute of Electrical and Electronics Engineers.
31
Abandonar sistemas existentes para iniciar projetos a partir do zero representa uma perda
considervel (Silva & Santander, 2004).
Visando entender melhor as caractersticas de evoluo de software, Lehman (1996),
publicou suas oito leis da evoluo de software6. De acordo com esse trabalho, seriam oito
as principais caractersticas que regem o envelhecimento de um software, e foram
determinadas aps mais de vinte anos de estudos e observaes. Inicialmente foram definidas
apenas trs leis (Lehman, 1974), que passaram a ser cinco (Lehman, 1980), alcanando seis
leis (Lehman, 1991). Finalmente, aps estudos mais longos com processos de software, as
atuais oito leis foram publicadas. Essas leis consideram no apenas o software em si, mas as
caractersticas da organizao que o desenvolve e mantm.
A primeira lei, caracterizada pela evoluo contnua, explica que um software
desenvolvido para tratar um problema do mundo real, precisa ser constantemente adaptado,
pois caso contrrio, ele se tornar progressivamente menos satisfatrio. Essa lei baseia-se na
experincia, sendo que a evoluo somente pode acontecer por meio de um processo de
manuteno controlado e dirigido.
Na segunda lei, o autor explica que existe um aumento progressivo de complexidade
do software medida que este se desenvolve, o que pode ocasionar uma desestruturao
crescente. Esse problema ser inevitvel, a menos que algum trabalho seja feito para reduzilo, e ocasionado por alteraes efetuadas em cima de outras alteraes, na medida em que o
software adaptado ao seu ambiente.
A terceira lei prega uma auto-regulao do processo de evoluo do software. Isso
significa que a organizao responsvel pelo desenvolvimento desse software estabelecer
normas e verificaes capazes de assegurar o entendimento das dificuldades e prover
respostas que sero utilizadas para o crescimento e estabilizao tanto do processo, como do
produto de software. O gerenciamento de retornos positivos e negativos dos pontos de
controle um exemplo de mecanismos de estabilizao. Existem vrios outros, e juntos eles
estabelecem uma dinmica disciplinada cujos parmetros so, pelo menos em parte,
normalmente distribudos.
A quarta lei trata da conservao da estabilidade organizacional, no sentido de que ao
longo de todo ciclo de vida do software, a forma como a organizao ir trabalh-lo sempre
produzir resultados constantes. A lei sugere que mudanas de pessoal e recursos tm pouco
efeito sobre a evoluo do sistema.
Na quinta lei, apresentada a caracterstica de conservao de familiaridade, o que
significa dizer que o conhecimento dos objetivos da organizao ao lanar uma nova
6
Do ingls, laws of software evolution.
32
atualizao do software, conhecido entre os membros da equipe que trabalha com esse
software. Quanto mais mudanas forem necessrias ao software, maior ser a dificuldade de
manter toda a equipe ciente dos objetivos organizacionais. A taxa, qualidade de progresso e
outros parmetros so influenciados, at mesmo limitados, pela taxa de aquisio da
informao necessria pelos participantes coletivamente e individualmente.
A sexta lei consagra a caracterstica do contnuo crescimento do software, decorrente
de novas funcionalidades, a fim de manter a satisfao do cliente. Essas mudanas podem ser
correes de erros, adies de novas funcionalidades ou melhorias em funes pr-existentes.
A maioria certamente no foi planejada pela equipe de desenvolvimento na poca da primeira
verso, ou foram causadas devido a alguma mudana no domnio operacional em que o
software est inserido. Essas mudanas no planejadas inicialmente geram a necessidade de
mdulos extras para o software, causando assim um inevitvel aumento do contedo
funcional.
Na stima lei, apresentada a caracterstica de qualidade decrescente do software,
medida que evolui. Isso ocorre uma vez que o software est inserido em um ambiente
imprevisvel, no qual existem possibilidades ilimitadas que entraro em contraste com as
caractersticas de evoluo do software, limitadas pelo nmero de recursos e tempo
disponvel, expondo a suscetibilidade do software a eventos externos. Ainda que esse
software funcionar satisfatoriamente por muitos anos, isto no ser um indicativo de que
continuar funcionando a contento nos anos vindouros. Essa caracterstica somente poder ser
evitada com um esforo para deteco e correo contnuas.
Finalmente, na oitava lei, publicada somente na dcada de 1990, o autor apresenta a
caracterstica de sistema de retorno, o que significa que o sistema de evoluo de um software
ser constantemente realimentado pelo retorno de seus usurios. A vida de um software um
ciclo bem estabelecido de retornos positivos e negativos dos usurios entre cada verso do
software. Em longo prazo, a taxa de crescimento do sistema ser estabelecida pela quantidade
de retornos negativos e positivos, e controlado por fatores como quantidade de recursos
(verba), nmero de usurios solicitando novas funcionalidades ou reportando algum erro,
interesses administrativos e tempo entre uma verso e outra.
De uma maneira geral, as leis de Lehman abordam caractersticas aplicveis a grandes
corporaes, que desenvolvem softwares complexos e com longo ciclo de vida. No ficam
claras quais as dificuldades para a manuteno de software. O que se tem um panorama
geral da evoluo de software, apresentando em diversas leis a necessidade de interveno no
software para que problemas sejam evitados, mas nada diz a respeito das dificuldades que
emergem dessa interveno.
33
2.2.3 Natureza e Caractersticas

Atividades de manuteno de software so caracterizadas por intervenes no produto de
software de forma a evitar sua deteriorao. Um software no se desgasta como peas de um
equipamento, mas se deteriora no sentido de os objetivos de suas funcionalidades cada vez
menos se adequarem ao ambiente externo.
Do ponto de vista de desenvolvimento, Pfleeger (2001) explica que o foco das
atenes est em produzir cdigo que atenda aos requisitos e funcione corretamente. Isso
inclui dizer que a cada estgio do desenvolvimento, haver uma referncia contnua a
componentes produzidos em estgios anteriores. O desenvolvimento levar a uma integrao
dos componentes desenvolvidos, passando por etapas de reviso e testes para certificao de
sua corretude, adequao aos requisitos a ao projeto. Resumindo, o desenvolvimento ter foco
em considerar estgios anteriores do processo de maneira controlada.
A manuteno de software, por sua vez, incluir no apenas considerar resultados de
etapas anteriores, mas atividades do presente de forma a conseguir compreender o nvel de
satisfao dos usurios em relao ao software. Uma caracterstica importante tambm
considerar o futuro durante a manuteno, buscando antever necessidades de mudanas nos
negcios, o que causaria mudanas nesse software.
Outra caracterstica fundamental est relacionada imprevisibilidade da manuteno
de software. Esse fato est relacionado influncia que o software sofre de fatores externos,
naturalmente imprevisveis (Bhatt et al., 2004).
Na figura 2.2 mostrada a curva de esforo despendido com a atividade de
manuteno de software, destacando os picos de esforo ocasionados por fatores externos.
FIGURA 2.2: CURVA DE ESFORO PARA MANUTENO DE SOFTWARE (ADAPTAO DE BHATT
ET AL. 2004)
Pela figura percebe-se que o software sensvel ao contexto no qual est inserido,
estando sujeito a mudanas na medida em que seu ambiente muda, causando a necessidade de
considerar e tentar prever esses fenmenos, tanto durante o desenvolvimento como durante a
manuteno.
34
Um modelo de ciclo de vida de manuteno de software proposto por Kung e Hsu

(1998), no qual se destacam quatro fases de vida para uma aplicao de software: (i)
introduo; (ii) crescimento (iii) maturidade; (iv) declnio. Para cada fase, os autores indicam
qual o tipo de tarefa que ser mais incidente, conforme mostrado na figura 2.3.
FIGURA 2.3: CICLO DE VIDA DE MANUTENO DE SOFTWARE (ADAPTAO DE KUNG & HSU, 1998)
Quanto tempo o software vai levar para entrar na fase de declnio uma previso
quase impossvel, visto que, uma vez na fase de maturidade, o software adquiriu certa
estabilidade na organizao, possivelmente j se enquadrando na classificao de sistema
legado. Nesse sentido, a fase de declnio corresponderia quela na qual uma deciso a respeito
de manter ou substituir o software deve ser tomada, conforme exposto com mais detalhes no
tpico 2.4, relacionado a sistemas legados.
2.2.4 Tipos de Manuteno

As aes ligadas atividade de manuteno de software foram classificadas de acordo com
sua natureza em trs categorias (Lientz & Swanson, 1980): corretivas, adaptativas e
perfectivas.
Manutenes do tipo corretivas visam corrigir defeitos de funcionalidade, o que inclui

acertos emergenciais de programa. Pfleeger (2001) expe um exemplo desse tipo de
manuteno, que consiste em um usurio apresentando um problema de impresso em
um relatrio. O nmero de linhas impresso por folha muito grande, o que causa
sobreposio de informaes. O problema foi identificado como uma falha no driver
da impressora, provocando a necessidade de se alterar o menu do relatrio para aceitar
um parmetro adicional que determina o nmero mximo de linhas impressas por
folha.
35
Manutenes do tipo adaptativas referem-se a adequar o software ao seu ambiente

externo. O exemplo apontado por Pfleeger (2001) ilustra bem essa categoria. Suponha
um gerenciador de banco de dados, que faz parte um sistema maior de hardware e
software. Em uma atualizao do gerenciador, os programadores perceberam que as j
existentes rotinas de acesso a disco precisavam agora de mais um parmetro adicional.
Essa manuteno corresponde a uma manuteno adaptativa, uma vez que teve por
finalidade adequao do software ao seu ambiente e no a correo de um defeito.
Manutenes do tipo perfectivas tm por objetivo acrescentar novos recursos de

funcionalidade ao software, normalmente em razo de solicitaes dos usurios.
Significam ainda re-projetar partes de um software, de forma a tornar mais simples a
compreenso e utilizao do mesmo. Como exemplo, pode-se citar o pedido do
usurio por um novo relatrio com informaes que at ento no podiam ser obtidas
do banco de dados.
A unio das categorias adaptativa e perfectiva sugerida por Pigoski (1996), que
prope uni-las em uma nica denominada aprimoramentos7. Essa classificao estaria de

acordo com organizaes que geralmente utilizam o termo manuteno para se referir
execuo de pequenas mudanas no software, enquanto o termo desenvolvimento usado
para os demais tipos de modificaes.
Uma quarta categoria de manuteno apresentada por alguns autores, como
Pressman (2005). Essa categoria se refere a manutenes do tipo preventivas que buscam
identificar previamente possveis fontes de problemas no software e corrigi-las
antecipadamente.
A IEEE (1998) modifica a definio apresentada inicialmente por Lientz e Swanson
(1980), definindo uma categoria a mais chamada emergencial. Essa categoria caracterizada
pela execuo de uma manuteno corretiva no planejada, com o intuito de manter o
software operacional. Tal classificao insere a idia de manuteno planejada e noplanejada, bem como manuteno reativa e pr-ativa, como ilustrado no quadro 2.1.
QUADRO 2.1: DEFINIES IEEE PARA AS CATEGORIAS DE MANUTENO DE SOFTWARE
Do ingls, enhancements.
Planejada
No-Planejada
Reativa
Corretiva
Adaptativa
Emergencial
Pr-ativa
Perfectiva
36
Para efeito de estudo, neste trabalho ser considerada a classificao de tipos de

manuteno definida por Pressman (2005): corretivas, adaptativas, perfectivas e preventivas.
Dentro dessa classificao adotada, um estudo com empresas de software (Souza et
al., 2004), constatou que entre as organizaes pesquisadas, as manutenes do tipo corretivas
prevaleceram com 50% dos resultados, seguido pelas perfectivas (30%) e adaptativas (20%).
Na pesquisa de Souza no foi identificada nenhuma organizao realizando manuteno do
tipo preventiva.
Essa ausncia de manuteno preventiva tambm pode ser verificada no estudo de
caso que ser apresentado no captulo 3.
2.2.5 Custos e Desafios

A manuteno de software uma operao importante pois consome a maior parte dos custos
envolvidos no ciclo de vida de um software (SWEBOK, 2004), e a falta de habilidade em
mudar um software rapidamente, e de maneira confivel, pode causar a perda de
oportunidades de negcio (Bennett & Rajlich, 2000).
Embora no exista um consenso sobre o valor exato do custo atrelado atividade de
manuteno, as pesquisas na rea apontam, na totalidade dos casos, sempre mais de 50% dos
investimentos realizados no software. De fato, para Bhatt et al. (2004), esse percentual
corresponde a algo entre 67% a 75% do investimento total, enquanto para Polo et al. (1999)
corresponde a um valor entre 67% e 90%. Ainda de acordo com esse ltimo autor, a razo do
custo elevado deve-se, em parte, prpria natureza da atividade de manuteno, caracterizada
principalmente pela imprevisibilidade. Alm dos altos custos financeiros, essa tambm a
atividade que exige maior esforo dentre as atividades de engenharia de software, conforme
apontado por Sneed (2003). Pressman (2005) ainda completa que o grande esforo necessrio
na manuteno se justifica pela abrangncia do significado desse termo no contexto de
software.
A importncia financeira atrelada manuteno de software ainda agravada quando
se leva em considerao o risco para as oportunidades de negcio, que podem ser causadas
pela falta de gerenciamento e compreenso total da dinmica da atividade. De acordo com a
pesquisa realizada por Dart et al. (2001), esse gerenciamento deve considerar trs fatores: (i)
ferramentas, (ii) pessoas, (iii) processos, revelando-se, pois, uma atividade gerencial
complexa.
Se por um lado a atividade de manuteno dispendiosa, por outro ela um desafio
para as organizaes que precisam consider-la em seu dia-a-dia. No de se esperar que uma
empresa de grande porte troque todos seus sistemas somente pelo fato de que a tecnologia
37
neles empregada est ultrapassada. Esses sistemas representam ativos importantes da

organizao e ela estar disposta a investir de maneira a manter seus valores (Sommerville,
2003).
Prever quando uma manuteno precisar ser conduzida uma tarefa geralmente
muito difcil de ser realizada. Essa dificuldade de previso, e tambm controle sobre a
manuteno, explicada pelo fato de muitas vezes ficar a cargo de empresas terceirizadas a
manuteno, revelando-se um problema j que normalmente essas organizaes no possuem
nenhum contato com o projeto inicial do software (Bhatt et al., 2004). Ainda segundo esse
autor, o aumento na complexidade dos softwares produzidos (tanto em termos de
funcionalidades, como de tcnicas) torna a previso de esforos de manuteno muito vaga.
Essa dificuldade em estimar esforos torna-se mais evidente quando se trata de sistemas
legados, que sero discutidos com maiores detalhes no tpico 2.4.
2.3 Norma ISO/IEC 12207

Em 1987 a ISO e a IEC estabeleceram um Comit Tcnico Conjunto JTC (Joint Technical
Committee) sobre tecnologia da informao, com o objetivo de efetuar a normatizao no
campo de sistemas de tecnologia da informao (incluindo microprocessadores) e
equipamentos (Singh, 1996).
Dentre os objetivos do comit estava o estabelecimento de um padro para processos
de ciclo de vida de software, que culminou com a norma ISO/IEC 12207, que teve incio em
1989. Esta norma deveria ser estabelecida como um framework adaptvel, que pudesse ser
usado para auxiliar na gerncia e na construo do software.
Assim, a ISO/IEC 12207 foi publicada em 1 de agosto de 1995, todavia est em
constante evoluo, como pode ser comprovado pelas duas emendas que j recebeu
(amendment 1, publicada em 2002, e a amendment 2, publicada em 2004).
Essa norma prov um conjunto de processos de engenharia de software que uma
organizao deve utilizar para adquirir, fornecer, desenvolver ou manter software, ou seja, ela
documenta os processos do ciclo de vida de software em um modelo de referncia de
processos. Sua organizao se d de acordo com o exposto na figura 2.4.
38
FIGURA 2.4: ESTRUTURAO DA NORMA ISO/IEC 12207
Ao todo so trs categorias, totalizando dez grupos de processos com 47 processos no

geral. Na figura 2.5, extrada da norma ISO/IEC 15504, mostrada a organizao da norma.
Processos Fundamentais
Processos Organizacionais
Grupo de Processos de Aquisio

Preparao da Aquisio
Seleo do Fornecedor
Acordo Contratual
Monitoramento do Fornecedor
Aceitao pelo Cliente
Grupo de Processos de Gerncia

Alinhamento Organizacional
Gerncia Organizacional
Gerncia de Projeto
Gerncia de Qualidade
Gerncia de Riscos
Medio
Grupo de Processos de Fornecimento

Proposta do Fornecedor
Liberao de Produto
Apoio para Aceitao de Produto
Grupo de Processos de Melhoria de

Processo
Estabelecimento de Processo
Avaliao de Processo
Melhoria de Processo
Grupo de Processos de Engenharia

Elicitao de Requisitos
Anlise de Requisitos de Sistema
Projeto de Arquitetura de Sistema
Anlise de Requisitos de Software
Projeto de Software
Construo de Software
Integrao de Software
Teste de Software
Teste de Sistema
Instalao de Software
Manuteno de Software e Sistema
Grupo de Processos de Recursos e Infraestrutura

Gerncia de Recursos Humanos
Treinamento
Gerncia de Conhecimento
Infra-estrutura
Grupo de Processos de Reuso

Gerncia de Ativos
Gerncia de Programa de Reuso
Engenharia de Domnio
Grupo de Processos de Operao

Operao
Suporte ao Cliente
Processos de Apoio
Grupo de Processos de Gerncia de
Configurao
Documentao
Gerncia de Configurao
Gerncia de Resoluo de Problemas
Gerncia de Solicitaes de Mudana
Grupo de Processos de Garantia de

Qualidade
Garantia de Qualidade
Verificao
Validao
Reviso Conjunta
Auditoria
Avaliao de Produto
FIGURA 2.5: PROCESSOS DO CICLO DE VIDA DA NORMA ISO/IEC 12207
39
Para um melhor entendimento, relevante descrever, ainda que em linhas gerais em

um primeiro momento, quais os propsitos de cada um dos grupos de processos da norma. No
captulo 5 esses processos so retomados com o intuito de se estabelecer quais deles
implicariam diretamente na reduo de problemas de manuteno de software.
A Categoria de Processos Fundamentais
Grupo de Processos de Aquisio: inclui processos a serem seguidos pelo cliente com
a finalidade de aquisio de um produto ou servio.
Grupo de Processos de Fornecimento: inclui processos a serem observados pelo
fornecedor, com a finalidade de oferecimento de um produto ou servio.
Grupo de Processos de Engenharia: inclui processos para elicitao e gerenciamento
dos requisitos do cliente, bem como especificao, implementao e/ou manuteno do
produto de software, considerando ainda sua relao com o sistema maior do qual fizer parte.
Grupo de Processos de Operao: inclui processos com a finalidade de oferecer
suporte transio do produto para o ambiente do cliente, provendo ainda a correta operao
e uso desse produto ou servio.
B Categoria de Processos Organizacionais
Grupo de Processos de Gerncia: inclui processos que englobam prticas que devem
ser observadas por todos aqueles que gerenciam qualquer tipo de projeto ou processo
relacionado ao ciclo de vida de software.
Grupo de Processos de Melhoria de Processo: inclui processos destinados definio,
criao e melhoria de processos realizados na organizao.
Grupo de Processos de Recursos e Infra-estrutura: inclui processos com a finalidade
de prover recursos humanos e infra-estrutura adequada para todos os processos da
organizao.
Grupo de Processos de Reuso: inclui processos com a finalidade de sistematicamente
explorar oportunidades de reuso dentro da organizao.
C Categoria de Processos de Apoio
Grupo de Processos de Gerncia de Configurao: inclui processos com a finalidade
de controle e manuteno da integridade do produto desenvolvido pelos processos de
engenharia.
40
Grupo de Processos de Garantia de Qualidade: inclui processos com o intuito de

prover garantias de que os produtos de trabalho e processos estejam de acordo com as
condies predefinidas e o planejado.
A manuteno de software aparece na norma como um dos processos dentro da
categoria de processos fundamentais. Na figura 2.6 apresentado quais so as atividades
pertencentes a esse processo.
FIGURA 2.6: ATIVIDADES DO PROCESSO DE MANUTENO DE SOFTWARE E SISTEMA (ISO/IEC 12207)
Implantao do processo: essa atividade inclui tarefas para o desenvolvimento de

planos e procedimentos para manuteno de software, criando procedimentos para
receber, gravar e monitorar pedidos de manuteno, e estabelecer uma interface
organizacional com o processo de gerenciamento de configurao. A implementao
do processo deve comear cedo no ciclo de vida do software, conforme refora
Pigoski (1996) ao dizer que os planos de manuteno devem ser preparados em
paralelo com os planos de desenvolvimento. Essa atividade inclui definir o escopo de
manuteno e a identificao e anlise de alternativas, bem como organizar e contratar
a equipe de manuteno, relacionando recursos e responsabilidades.
Anlise do problema e da modificao: em um primeiro momento, essa atividade tem

por objetivo analisar a requisio de manuteno para classific-la, podendo ento
determinar o escopo em termos de tamanho, custos e tempo necessrio, destacando
ainda sua prioridade. As demais tarefas dessa atividade focam o desenvolvimento e a
documentao de alternativas para mudana de implementao e aprovao das
opes adotadas.
Implantao da modificao: essa atividade engloba a identificao dos itens que

precisam ser modificados e os processos de desenvolvimento que precisaro ser
41
implementados. Outros requisitos da modificao incluem teste e validao de que as

modificaes esto corretamente implementadas e que os itens no modificados no
foram afetados.
Reviso / aceitao da modificao: as tarefas dessa atividade so dedicadas

confirmao da integridade do software modificado e concluso dos negcios com o
cliente, quando este concorda e aprova satisfatoriamente a concluso da requisio de
manuteno. Muitos processos de apoio podem ser utilizados aqui, incluindo a
garantia da qualidade de processo, o processo de verificao, o processo de validao
e o processo de reviso conjunta.
Migrao: corresponde atividade que ocorrer quando o software for transferido de

um ambiente de operao para outro. Ser preciso o desenvolvimento de planos de
migrao e os usurios precisaro estar cientes dos requisitos, dos motivos do antigo
ambiente no ser mais suportado e terem disposio uma descrio do novo
ambiente e sua data de disponibilidade. Outras tarefas dessa atividade concentram-se
em operaes paralelas do novo e antigo ambiente, incluindo a reviso de psoperao para certificar-se do impacto da mudana de ambiente.
Descontinuao do software: essa atividade consiste em descontinuar o software por

meio da formalizao, junto ao cliente, de um plano de descontinuao.
Um ltimo comentrio referente norma refere-se ao fato de que ela no representa
um modelo fixo ao qual uma organizao que a adote se submete. Ao contrrio disso, ela
funciona como uma estrutura de apoio, devendo a organizao que a adotar proceder com
adaptaes nas recomendaes para a sua realidade.
2.4 Sistemas Legados

Um sistema legado normalmente representa um dos bens com maior valor econmico de uma
organizao (Visaggio, 2001).
Essa a idia central que envolve as decises em torno de um software nessas
condies, gerando muitas variveis a considerar, entre elas: (i) arriscado substituir um
software que esteja estvel; (ii) os usurios j esto acostumados com a forma de trabalhar
com o software e uma mudana normalmente no seria bem vinda; (iii) a mudana vai exigir
gastos com treinamento de todos os envolvidos com o uso desse software; (iv) a compra ou
construo de um novo software pode extrapolar previses de custos e prazos; (v) o novo
software pode possuir menos funcionalidades, dificultando tarefas dos usurios etc.
42
Se por um lado o software no pode ficar como est, j que ou possui erros, ou no
est mais atendendo s novas necessidades de negcios, por outro, substitu-lo pode trazer
problemas ainda maiores.
Neste tpico sero consideradas as caractersticas desses softwares e algumas das
solues, e paliativos, j propostos, uma vez que se relacionam diretamente com a atividade
de manuteno de software.
2.4.1 Conceitos
Um software desenvolvido no passado e ainda um utilizao em uma determinada
organizao constitui um sistema legado.
Em funo da dependncia cada vez maior em relao a sistemas de software, as
organizaes em geral, especialmente as de grande porte, investiram muito dinheiro no
desenvolvimento de softwares para atender s suas necessidades operacionais e de gerncia.
Considerando que a evoluo da tecnologia, tanto de hardware como de software, foi muito
rpida nos ltimos anos, provocando o abandono de linguagens de programao mais antigas
e a adoo de novas metodologias de desenvolvimento de software, fortemente esperado
que aqueles softwares, frutos de grandes investimentos das organizaes, tenham sido
construdos com alguma tecnologia ou mtodo que hoje obsoleto. Esses softwares,
chamados de sistemas legados, constituem mais um desafio para a engenharia de software,
especialmente para a atividade de manuteno de software, uma vez que dificilmente sero
abandonados de imediato, justamente por causa do investimento que representam.
A vida til de um software muito variada. Alguns softwares de grande porte podem
continuar em uso durante mais de dez anos, e em alguns casos organizaes podem ainda
contar com software desenvolvido h mais de vinte anos (Sommerville, 2003). Uma tentativa
de quantificar a quantidade de software legado existente foi feita em 1990, e ainda naquela
data, estimou-se que haveria no mundo cerca de 120 bilhes de linhas de cdigo pertencentes
a esse tipo de software (Ulrich, 1990).
2.4.2 Problemtica dos Sistemas Legados

Vrias abordagens foram propostas para gerenciar software legado. Solues tpicas so
(Bennett et al., 1999): (i) descartar o software e substitu-lo totalmente (muito invivel na
grande maioria dos casos, por restries financeiras e tcnicas); (ii) tornar o software parte
integrante de um novo software de maiores propores; (iii) adiar a manuteno por mais
algum tempo (nem sempre isso possvel), e finalmente, (iv) modificar o software para
aumentar sua vida til.
43
Quando a deciso de modificar o software tomada, inicia-se um processo de

entender esse software, bem como suas estruturas, uma vez que dificilmente o projeto inicial
estar disponvel, e se estiver, seguramente estar desatualizado.
As razes para explicar a dificuldade de manuteno em sistemas legados apresentada
por Sommerville (2003) esto descritas a seguir:
Diferentes partes do software foram desenvolvidas por equipes diferentes, o que

implica em uma no uniformidade no estilo de programao ao longo dele todo;
Partes do software, ou ele todo, podem ter sido desenvolvidas com o uso de alguma
linguagem de programao obsoleta. Isso torna difcil encontrar profissionais com
conhecimento e experincia na linguagem, o que pode forar a terceirizao da
manuteno (normalmente a um custo elevado);
A documentao existente normalmente inadequada e desatualizada. Em muitos

casos, a nica documentao existente o prprio cdigo-fonte. Em outras situaes
mais graves, nem mesmo o cdigo-fonte est disponvel, somente a verso executvel
existe;
Provavelmente os muitos anos de manutenes alteraram a estrutura do software,

tornando-o progressivamente mais difcil de compreender. Novos programas podem
ter sido adicionados e sua interface de comunicao com outras partes construda de
maneira ad-hoc;
O software pode ter sido otimizado para reduzir a ocupao de espao ou melhorar sua
velocidade de execuo. Isso pode causar problemas de compreenso para
profissionais que aprenderam somente as tcnicas modernas de engenharia de
software, no tendo tido contato com os truques usados no passado;
Os dados processados pelo software podem estar armazenados em arquivos separados,

com estruturas distintas e incompatveis. Podem ainda existir duplicaes de dados,
erros e dados incompletos.
Vale aqui uma observao curiosa, referente ao crescimento do nmero de
profissionais da rea de software interessados em aprender linguagens e tcnicas de

programao antigas, justamente para trabalharem no aparente promissor campo da migrao
de sistemas legados. Organizaes de porte mdio e grande tm se dedicado preparao de
equipes para conduzir longos e complexos processos de migrao de grandes sistemas
legados, notadamente aqueles construdos com a linguagem de programao COBOL. Esse
provavelmente o fato que tem feito com que os livros de linguagens antigas estejam voltando
44
a circular, principalmente na indstria, entre profissionais da rea.
2.5 Gerenciamento de Manuteno de Software

Com o aumento da necessidade de manuteno de software, principalmente de softwares mal
desenvolvidos, as organizaes tm buscado maneiras de lidar com o problema, j que no
possvel trocar o software por um modelo mais novo, como seria comum pensar em face de
um equipamento com defeitos ou com funcionalidades limitadas.
Essa busca por alternativas viveis economicamente e eficazes tecnicamente, acabam
por produzir diferentes abordagens de resposta necessidade de manuteno, respostas essas
que no so sempre corretas e de aplicabilidade universal.
Est a cargo dos tomadores de deciso em relao a software decidir o que fazer e
como proceder necessidade de manuteno de software, o que envolver sempre questes
financeiras e a credibilidade da organizao frente a seus clientes.
De Lucia et al. (2004) organizaram em quatro grupos as questes importantes a
considerar por esses tomadores de deciso:
Programadores: envolve as questes ligadas equipe de engenheiros de software.

Aqui esto includos assuntos importantes como a atitude dos profissionais diante de
tarefas de manuteno e no de desenvolvimento, ressaltando a necessidade de avaliar
questes no apenas tcnicas, mas tambm de compreenso dos negcios do cliente.
Nesse grupo esto includas ainda eventuais alegaes de falta de glamour da
atividade
de
manuteno,
inclusive
questes
como
impossibilidade
de
desenvolvimento de carreira em manuteno de software, o que acaba por gerar

grande rotatividade. Deve-se ainda considerar a habilidade que a equipe de
engenheiros de software possui com a atividade de manuteno, avaliando-se a curva
de aprendizado para a atividade.
Atitude Gerencial: observa-se que a prpria postura gerencial a principal responsvel

por ditar os rumos e o sucesso ou fracasso do ambiente de manuteno. Esse grupo
envolve as questes relacionadas ao estudo de programas de manuteno, que
normalmente so escassas, e seu relacionamento com fatores como tempo e dinheiro.
justamente esse tipo de estudo que permite o sucesso em tomadas de deciso
relacionadas a software. Um fator apontando nesse grupo refere-se atitude gerencial
de atribuir o desenvolvimento de projetos importantes a programadores como uma
forma de presente-los por bom desempenho profissional. Essa atitude agravada
ainda mais quando acompanhada de falta de treinamento e oportunidade para
equipes de manuteno.
45
Cdigo-Fonte: definir critrios de qualidade para o cdigo-fonte outro grupo que

envolve questes pertinentes. Arquitetura pobre de software e de estruturas de
programa, documentao irregular, falta de padres e guidelines para atividades de
manuteno, incluindo ainda ausncia de estudos de impactos de mudanas em outros
trechos e mdulos do software, representam consideraes importantes a fazer.
Usurios: os usurios devem ter participao ao longo de toda atividade de

manuteno, para evitar que problemas de manutenibilidade no software possam gerar
falta de credibilidade no trabalho do programador. Questes envolvendo confirmao
e validao do usurio a respeito do software enquanto em processo de manuteno
devem ser consideradas, para evitar erros de interpretao e de especificaes.
fundamental reportar aos usurios os erros e dvidas de interpretao.
Em razo dos muitos critrios a considerar, as decises gerenciais podem ora fluir por
um caminho, ora por outro, sendo importante o acompanhamento do resultado das decises
tomadas, efetuando ajustes o tempo todo, medida que falhas forem diagnosticadas.
Ao tomador de deciso em organizaes de software, fundamental o conhecimento
claro tanto dos objetivos de sua organizao, como das caractersticas e dificuldades da
atividade de manuteno de software, para ento somente ser capaz de conduzir
adequadamente sua equipe.
Dentro desse contexto, Basili (1990) props trs paradigmas diferentes para tratar a
manuteno de software: (i) Conserto Rpido8; (ii) Melhoria Interativa9; (iii) Reuso Total10.
A idia de conserto rpido compreende aplicar primeiramente as mudanas
necessrias no cdigo-fonte do software e ento depois atualizar a documentao, nessa
ordem. Essa abordagem corresponde normalmente preferida pelo mantenedor, justificando a
deciso pela urgncia da manuteno (Visaggio, 2001). A deciso de alterar a documentao
aps a manuteno, no entanto, no comumente uma boa prtica, pois pressionado pelo
tempo, o mantenedor executa mal, ou no executa, essa tarefa, dificultando cada vez mais
manutenes posteriores. Na figura 2.7 mostrado um paralelo entre o software atual e o
derivado da manuteno, notando-se, que o ponto de partida o cdigo-fonte do software
antes da manuteno.
Quick Fix, nas palavras do autor.

Iterative Enhancement, idem.
10
Full Reuse, idem.
9
46
FIGURA 2.7: ESTRUTURA DA ABORDAGEM CONSERTO RPIDO
A proposta de melhoria interativa, por sua vez, prope inicialmente adequar e atualizar
a documentao de alto nvel que ser afetada, para ento propagar as mudanas at o nvel de
cdigo-fonte. Na figura 2.8 representada essa idia.
FIGURA 2.8: ESTRUTURA DA ABORDAGEM MELHORIA INTERATIVA
Finalmente, a ltima proposta, reuso total, consiste em construir um novo software,

utilizando componentes do software antigo e outros disponveis em um repositrio. Na figura
2.9 essa idia mostrada.
FIGURA 2.9: ESTRUTURA DA ABORDAGEM REUSO TOTAL
Essa ltima proposta no freqentemente usada no ambiente industrial, e uma das

razes seria a deficincia ainda existente na tecnologia para gerenciar o repositrio e o reuso
de componentes de software.
A comparao entre os dois paradigmas mais comuns, o conserto rpido e a melhoria
interativa, foi feito por Visaggio (2001) e o resultado apontou que a primeira abordagem
47
apenas mais indicada do que a segunda, quando o impacto da modificao envolver poucos
componentes, o que pode ser reforado pelo menor tempo empregado para tornar a
manuteno operacional. Porm, e principalmente, para alteraes maiores, o emprego da
melhoria contnua a melhor indicao, pois permite antever defeitos e conseqentemente
reduzir re-trabalhos, contribuindo para a garantia de qualidade global do software. Esse
ltimo mtodo funciona ainda como uma maneira automtica de continuamente revisar a
consistncia do software.
Nesse ponto, o autor deste trabalho tem a acrescentar que verificou, por sua
experincia na prtica em algumas organizaes, o emprego do mtodo de corrigir o problema
diretamente no cdigo-fonte, exceo feita em algumas situaes mais complexas que
envolvem pequenas reunies entre os profissionais responsveis pela manuteno, produzindo
em algumas delas um roteiro escrito de passos ou de fatores a observar para a manuteno. No
entanto, na maior parte dos casos, esses registros no eram utilizados para a atualizao da
documentao de software existente. O procedimento mais adotado o de revisar e completar
a documentao de tempos em tempos, com base em vises gerais do software. justo
destacar, no entanto, que algumas organizaes decidem por desenvolver internamente seu
prprio sistema de controle de manutenes, no qual se registra requisies formais de
manuteno, podendo ser mais ou menos completo dependendo da organizao, contendo
descrio da soluo, tempo despendido, estrutura do software entre outros. Essa postura, no
entanto, normalmente adotada por organizaes de mdio e grande porte. Existem trabalhos
dedicados a sistematizar e melhorar a construo desse tipo de ferramenta, como por exemplo,
o trabalho de Koskinen et al. (2004), que prope uma ferramenta baseada em hipertexto para
auxiliar a recuperao de diversas informaes sobre um software que sofrer manuteno.
Outro desafio gerencial notvel em manuteno de software relaciona-se
necessidade de estimar esforo para atividade, conforme explica De Lucia et al. (2004). Com
uma maneira eficaz de estimar o esforo, fica mais fcil aos tomadores de deciso argumentar
sobre as melhores opes para a organizao, contribuindo para a deciso de terceirizar ou
no a atividade. Esse auxlio na tomada de deciso envolve consideraes como:
Reavaliar a eficincia de processos de manuteno;
Tratar a manuteno ou reengenharia;
Fundamentar as decises tomadas;
Planejar o oramento de equipe e avaliar a rotatividade.

Definir quem far a manuteno um ponto que pode levar ao fracasso ou ao sucesso
dos esforos em manter um software em funcionamento e adequado s necessidades.
48
Portanto, decidir entre manter uma equipe interna de manuteno ou submeter o software
manuteno por outra organizao exige estudo cuidadoso, e isso se justifica pela simples
lembrana de que a organizao pode ter dependncia enorme em relao a esse software,
necessitando de seu correto e adequado funcionamento o tempo todo.
Aplicar manuteno de software as tcnicas, ferramentas, modelos de processos,
etc., prprios do desenvolvimento de software no constitui uma deciso correta, pois
manuteno e desenvolvimento apresentam caractersticas distintas, como afirma Polo et al.
(2003).
Algumas razes que justificam essas caractersticas distintas so apresentadas pelo
mesmo autor:
O esforo despendido em tarefas de desenvolvimento e manuteno no igual,

constituindo uma prtica comum nas organizaes concentrar a maior parte do esforo
humano disponvel em codificao e tarefas de teste durante o desenvolvimento.
Outro fator de diferena est ligado ao fato de que a manuteno tem mais
similaridade com um servio do que com desenvolvimento, o que acaba implicando na
necessidade de no aplicar as mesmas estratgias de desenvolvimento em manuteno.
Essa ltima razo pode ainda ser apontada como fator que justifica o aumento no
nmero de organizaes que oferecem servios de manuteno de software, e esse aumento

estaria ainda ligado alta demanda j existente.
De fato, a prestao de servios de manuteno de software, mais do que uma situao
nova, na verdade, trata-se de um setor j competitivo, como afirma Bhatt et al. (2006). O
autor explica que nos primeiros momentos o que se viu foram clientes contratando
organizaes de software e pagando com base no nmero de engenheiros de software
envolvidos nas atividades de manuteno. Atualmente, observa uma mudana nesse cenrio,
com os clientes contratando as organizaes por um preo fixo, estipulado por um perodo
determinado e com base em estimativas a respeito da atividade de manuteno que ser
necessria.
2.6 Histrico dos Problemas de Manuteno de Software

Edward Yourdon (Yourdon, 1992), considerado um dos nomes mais importantes da anlise
estruturada clssica, estimou, ainda no incio dos anos 1990, que a manuteno de software
viria a ser um dos problemas relevantes no futuro. Essa previso foi feita com base em
constataes da poca, como a poltica de entregar em tempo ao usurio um sistema que
funcionasse, no se preocupando com questes de manutenibilidade. Mais do que isso,
49
Yourdon afirmou que a postura da alta direo das organizaes que dependiam de software
seria a de atacar o problema apenas quando ele emergisse de fato.
Antes, porm, do que afirmou Yourdon, ainda na dcada de 1980, estudos referentes a
problemas com manuteno de software j ocorriam, e um pioneiro e relevante trabalho foi
realizado por Lientz e Swanson (1980), publicado na forma de um livro. Esse trabalho
descreve os resultados obtidos com estudos no intuito de averiguar a forma como as
organizaes tratavam a questo de manuteno de software na poca.
A pesquisa contou com duas fases. Na primeira, realizada com 69 organizaes, foram
levantadas as caractersticas da atividade de manuteno de software por elas realizada. Essa
fase inicial obteve as seguintes concluses:
A manuteno de software existente consome uma mdia de 48% das horas anuais do
pessoal de sistemas e programao;
Aproximadamente 60% dos esforos de manuteno so dedicados a manutenes do

tipo perfectivas. Dentre esse percentual, dois teros se referem a esforos de melhoria
de software;
Problemas de natureza gerencial em manuteno foram vistos como mais importantes

do que aqueles de natureza tcnica.
Com base nessas verificaes, uma segunda fase foi conduzida na pesquisa, nesse caso
envolvendo 487 organizaes, o que abrangia instituies governamentais, bancos,

transportes, minerao, educao e indstrias de manufatura em geral, localizadas nos Estados
Unidos e Canad. O intuito dessa segunda fase foi o de validar os resultados obtidos na
primeira, buscando uma compreenso mais profunda e abrangente.
Para se obter esses resultados, os autores buscaram saber das organizaes as
caractersticas dos esforos de manuteno empregados em sistemas considerados de grande
importncia, que constituam resultados de investimentos significativos.
A coleta de dados se deu por meio de questionrios enviados para 2000 profissionais
que ocupavam cargos de diretoria, gerncia ou superviso de departamentos de
processamento de dados. Os questionrios foram cuidadosamente elaborados, e enviados por
meio de cartas s pessoas, contendo j um envelope selado para resposta. Cada questionrio
consistia de dezenove pginas, com perguntas que envolviam totais, porcentagens e respostas
sim ou no para diversas caractersticas da organizao e da manuteno por ela praticada.
Uma caracterstica importante do questionrio foi considerar a confiabilidade das
informaes fornecidas, reconhecendo tambm que nem sempre era fcil ao profissional
entrevistado obter os dados para responder algumas questes. Para isso, aps cada questo,
50
era fornecido um quadro (quadro 2.2), que visava avaliar o conhecimento que o entrevistado
tinha a respeito do que acabava de responder.
QUADRO 2.2: VERIFICAO DO CONHECIMENTO SOBRE CADA ITEM RESPONDIDO
Marque a sentena apropriada
A resposta anterior :
a. Razoavelmente precisa, baseada em dados confiveis.
b. Uma estimativa grosseira, baseado em dados mnimos.
c. Uma suposio, sem base em dados.
Do total de questionrios enviados, somente 487 respostas foram obtidas, o que

representou uma taxa de resposta menor que 25%.
Nessa segunda fase, os principais resultados obtidos esto resumidos a seguir:
Mais de um tero dos sistemas descritos tinham sua manuteno realizada por apenas
uma pessoa;
A maioria dos profissionais alocados para manuteno tinha outras tarefas ao mesmo
tempo;
Do total de manutenes, cerca de 20% representavam manutenes corretivas, 25%

manutenes adaptativas e mais de 50% manutenes perfectivas (isso est de acordo
com aos resultados obtidos na primeira fase da pesquisa);
Quanto mais velho era o sistema, maior era o esforo que deveria ser empregado em
sua manuteno, e mais sujeita a organizao estava em perder o conhecimento em
torno desse sistema, devido rotatividade dos profissionais.
Finalmente, os autores chegaram aos principais problemas de manuteno enfrentados
pelas organizaes na poca:

(i)
Baixa qualidade da documentao dos sistemas;
(ii) Necessidade constante dos usurios por melhorias e novas funcionalidades;

(iii) Falta de uma equipe de manuteno;
(iv) Falta de comprometimentos com cronogramas;
(v) Treinamento inadequado do pessoal de manuteno;
(vi) Rotatividade dos profissionais.
Conforme explicam os autores, desses seis problemas, trs esto relacionados com os
usurios do software, dois esto relacionados a restries gerenciais e um trata de problema
com documentao, representando uma questo de natureza mais tcnica.
No geral, foi verificada uma predominncia de problemas no-tcnicos sobre
problemas tcnicos, o que refora a necessidade de uma maior ateno a questes gerenciais
51
em manuteno de software.
Em 1986, outro estudo (Chapin, 1986), envolveu 250 gerentes de manuteno de
software e buscou saber quais eram os principais problemas de manuteno nas equipes por
eles lideradas. Dos resultados obtidos, foi estabelecida uma classificao em oito categorias.
Entre os problemas apontados, a grande maioria referia-se a caractersticas do prprio
software, como documentao insuficiente e cdigo excessivamente complexo ou mal
estruturado.
Em outra pesquisa (Dekleva, 1990), realizada pelo Software Maintenance Association
(SMA), o intuito foi a obteno de respostas para a seguinte pergunta: Quais os trs
principais problemas de manuteno de software no seu departamento de sistemas de
informao?, sendo que os resultados permitiram apontar questes ligadas principalmente a
dificuldades de gerenciamento, caractersticas de desenvolvimento de software, administrao
de equipes e mudanas no ambiente externo ao software.
Em 1992, valendo-se de uma tcnica de pesquisa iterativa denominada delphi, que
leva a um consenso entre os entrevistados, Dekleva (1992), obteve uma lista de problemas de
manuteno muito parecida com os apresentados por Lientz e Swanson, incluindo apenas o
problema da dificuldade da organizao em medir o desempenho de sua equipe de
manuteno. Novamente, foi constatado que problemas de ordem gerencial so absolutamente
dominantes no contexto de problemas de manuteno de software. Na figura 2.10, extrada do
trabalho de Dekleva (1992), mostrada a relao de causa identificada entre os fatores
envolvidos na atividade de manuteno. As ms caractersticas ou mal gerenciamento de um
fator, prejudicam o fator correlacionado.
FIGURA 2.10: RELAO DE CAUSA ENTRE OS FATORES ENVOLVIDOS NA MANUTENO DE SOFTWARE
Existem ainda outros trabalhos com resultados semelhantes, como o de Dart et al.
(2001), conduzido pelo Software Engineering Institute (SEI) junto a uma agncia do governo
dos Estados Unidos. Uma caracterstica interessante apontada nesse estudo refere-se
52
alegao dos profissionais encarregados de tarefas de manuteno de que acabam no tendo

contato com ferramentas que representariam o estado-da-arte da tecnologia. Outro fator
apontado refere-se ao fato de que as lies adquiridas com a experincia de manuteno em
um determinado software no estavam sendo disseminadas para as outras equipes dentro da
mesma organizao.
2.7 Consideraes Finais

A grande maioria dos estudos existentes na rea de manuteno de software utiliza a
metodologia de pesquisar-e-transferir, no sentido de pesquisa fechada dentro do meio
acadmico, enquanto existe uma necessidade de utilizar a abordagem indstria-comolaboratrio, uma vez que nas indstrias que a atividade de manuteno existe como
atividade real e intensa no dia-a-dia, de acordo com a viso de Niessink (1999).
Nesse sentido, a manuteno de software deve ser considerada, assim como a
engenharia de software, com base em seu ambiente de aplicao, e essa abordagem representa
a melhor fonte de evidncias para sustentar e guiar as pesquisas de melhoria e sistematizao
da atividade.
CAPTULO
3
Estudo de Caso
.
Um estudo de caso foi conduzido com o objetivo de verificar os problemas de manuteno de
software existentes em uma organizao empenhada no desenvolvimento de software
comercial. Essa organizao mantm uma base de dados contendo registros histricos de
manutenes efetuadas sobre um sistema de informao por ela desenvolvido e mantido. O
resultado deste estudo de caso foi publicado em um artigo (Paduelli & Sanches, 2006),
apresentado no III Workshop de Manuteno de Software Moderna (WMSWM06), evento
paralelo ao V Simpsio Brasileiro de Qualidade de Software. As subsees a seguir so
baseadas no artigo.
3.2 Descrio da Organizao

Criada em 1993, portanto com mais de 14 anos de existncia, a organizao estudada
corresponde a uma software-house, que desenvolve e mantm alguns softwares voltados
rea mdica e de sade. composta por uma unidade na cidade de So Carlos - SP,
responsvel pelo desenvolvimento e manuteno, e outra unidade na cidade de So Paulo,
dedicada venda e consultoria.
O software estudado corresponde a um sistema de porte mdio voltado odontologia,
mais precisamente ao gerenciamento de operadoras odontolgicas, sendo, no entanto, um
produto com caractersticas tpicas grande maioria dos softwares que se sujeitam a gerenciar
Captulo 3 Estudo de Caso
54
algum ramo de atividade comercial. So exemplos de recursos oferecidos pelo software:

cadastro de clientes, cadastro de fornecedores, emisso de boletos bancrios, controle
financeiro, relatrios analticos complexos, controle de estoques, suporte a multiusurio,
controle de permisso de acesso a diferentes mdulos, controle de fluxo de caixa, emisso de
faturas, emisso de relatrios especficos para prestao de contas a rgos de fiscalizao do
governo, integrao com sistemas web etc.
Relativamente ao nmero de clientes, no momento da pesquisa, existiam 41 clientes
(operadoras de odontologia), envolvendo desde organizaes de pequeno porte, com at 5.000
associados cada, utilizando o software em cerca de 5 computadores, at empresas maiores,
com mais de 50 mquinas em rede, utilizando o software de maneira simultnea e contando
com at 150.000 associados. Normalmente essas empresas de maior porte so estruturadas por
departamentos, e cada departamento utiliza um mdulo especfico do software.
3.3 Dinmica de Manuteno

Neste tpico so abordadas as caractersticas da maneira de trabalhar da organizao, expondo
como registra, altera e entrega as suas manutenes.
Uma observao inicial se faz necessria, e se refere possvel confuso entre o que
seria uma tarefa de desenvolvimento e o que seria uma atividade de manuteno, no contexto
do software estudado. De uma forma objetiva, o software aqui referido encontra-se
desenvolvido, uma vez que est em uso por muitos clientes, ou seja, um produto de software
j entregue ao cliente, conforme dita a definio da IEEE apontada no item 2.2.1. Partindo-se
desse pressuposto, qualquer solicitao, seja por parte de clientes, seja por observao de
algum profissional que atue sobre o software, ser classificada como uma manuteno, ainda
que exija criar um mdulo novo ou refazer um j existente. Tais atividades se encaixam
perfeitamente na classificao de tipos de manuteno apresentadas no item 2.2.4.
3.3.1 Registro de Manutenes

Os registros de manutenes so inseridos na base de dados de trs formas distintas: (i) pelo
prprio cliente, atravs do sistema de help-desk disponvel no site da organizao; (ii) pelos
consultores da empresa, aps visita ao cliente e levantamento de necessidades de manuteno;
(iii) pelos prprios programadores, que podem identificar necessidades de manuteno
medida que evoluem o software. Uma interface especfica baseada na web foi criada para a
insero desses registros na base.
Cada registro contm diversas informaes, como por exemplo, qual o cliente que
solicita, grau de prioridade, quem realizar a manuteno, tempo gasto previsto para a
55
atividade, tipo de manuteno, status da implementao, datas de insero do chamado e data

prevista para entrega, observaes, descrio da soluo adotada, entre outras.
Aps o registro de um chamado, sua execuo depender da anlise de viabilidade,
efetuada pelo responsvel pelo produto. O procedimento adotado est resumido na figura 3.1.
FIGURA 3.1: ETAPAS ENVOLVIDAS NA SOLICITAO DE MANUTENES
Eventualmente, solicitaes de manuteno so consideradas inviveis, sendo

canceladas pelo responsvel por essa avaliao. Uma vez cancelada, esse fato informado ao
respectivo cliente, podendo ser revisada a necessidade para que uma proposta de manuteno
mais adequada seja registrada.
Uma caracterstica do sistema de controle de chamados a interao que oferece entre
mantenedor/cliente. Essa interao ocorre da seguinte maneira: quando o cliente registra
alguma necessidade de manuteno, automaticamente a equipe de suporte e o analista
responsvel pelos cronogramas e testes, recebem um e-mail informando que uma nova
solicitao foi feita. Diversos status so atribudos a uma solicitao, e a cada troca de status,
o cliente pode receber um e-mail informando o andamento de sua solicitao. No quadro 3.1
esto representados os status possveis para as solicitaes, e em quais mudanas o cliente
recebe um e-mail de notificao.
QUADRO 3.1: SITUAES POSSVEIS PARA OS CHAMADOS DE MANUTENO
Status do chamado
Pendente
Em execuo
Cancelado
Em testes
Em homologao
Concludo
Cliente recebe e-mail

Sim
Sim
Sim
No
Sim
Sim
56
Na situao em testes, o cliente no recebe notificao, pois esse status utilizado

para controle interno. Uma solicitao em testes significa que est com a alterao no
cdigo-fonte efetuada e disponvel para o analista responsvel realizar os testes preliminares a
fim de produzir a verso de homologao, que ento disponibilizada ao cliente. Somente
quando a solicitao tiver sido testada e a verso de homologao estiver concluda e
fornecida ao cliente, o analista responsvel ir alterar o status para em homologao,
permitindo ento o envio da notificao ao cliente. A situao concludo ocorre quando a
verso de homologao finalmente for instalada no ambiente de produo do cliente.
Para o status de cancelado, o cliente informado apenas que sua solicitao foi
negada, e que para maiores esclarecimentos ele deve entrar em contato com a equipe de
suporte.
Por fim, destaca-se que o cliente pode, a qualquer momento, conferir os status de seus
chamados, consultando sua rea privativa no site da organizao, que oferece acesso ao helpdesk tanto para incluso de novos chamados, como para acompanhamento por meio dos
diferentes status.
3.3.2 Controle de Verses

Os clientes tm sua disposio uma rea privativa no site da organizao, atravs do qual
podem realizar o download de verses atualizadas do software, medida que so
disponibilizadas.
Essa disponibilizao de verses ocorre mensalmente, podendo incluir rotinas de
manuteno no banco de dados, quando necessrias, alm dos componentes de software
alterados. As atualizaes de banco de dados so efetuadas automaticamente no momento em
que o cliente abre o software pela primeira vez, aps a atualizao. Uma caracterstica
relevante a de que o software sempre ser o mesmo independente do cliente, ou seja, no
existem verses distintas para clientes diferentes, todos utilizam uma verso nica que pode
ser configurada de acordo com necessidades especficas de cada cliente (mdulo de opes de
sistema do software).
Aps a disponibilizao de uma nova verso, o sistema de controle de chamados
consultado e as manutenes de software pendentes so consideradas, e ento definidas quais
entraro na verso do ms seguinte. Essas manutenes so encaminhadas para os
programadores (que consultam no sistema de chamados suas atividades pendentes), devendo
seguir as datas programadas para entrega do mdulo/arquivo alterado. As datas de entrega no
so para o usurio final, mas sim para o analista responsvel, que ir test-las, e ento
disponibilizar uma verso de homologao do software. Essa verso fornecida a um grupo
57
de clientes com os quais foi estabelecido um acordo para realizao desses testes. Isso ocorre
na ltima semana do ms que antecede aquele de disponibilizao da nova verso.
A idia de disponibilizar verses intermedirias a um ou mais clientes para testes reais
em ambiente parte do de produo, corresponde a uma das tcnicas de teste apresentadas
por Pressman (2005), intitulada teste beta. Segundo o autor, esse o tipo de teste conduzido
nas instalaes do prprio cliente, sem acompanhamento do desenvolvedor, estando o cliente
responsvel por registrar problemas e inform-los em intervalos regulares.
Evidentemente entre a data de estabelecimento de cronograma para os chamados
pendentes e a data de liberao da nova verso, surgem normalmente chamados novos e
urgentes, que no podem esperar at prxima verso. No geral, procura-se evitar essa
situao, mas quando ocorrem, verses intermedirias modificadas a partir da ltima verso
oficial, somente com a alterao urgente ora solicitada, so disponibilizadas e apenas para o
cliente que precisou da manuteno urgente.
Um padro para nomenclatura das verses foi adotado, buscando atrelar a verso ao
seu ms de lanamento, bem como informar o nmero da reviso atual da verso (caso a
verso oficial tenha necessitado de alguma alterao emergencial). Na figura 3.2 ilustrado
um exemplo do padro de numerao adotado.
Build_070401_00
A B C
A Dois dgitos indicando o ano

B Dois dgitos indicando o ms
C Dois dgitos indicando o dia
D Dois dgitos indicando nmero da reviso
FIGURA 3.2: PADRO DE NUMERAO DE VERSES
Os dois ltimos dgitos so incrementados em uma unidade, medida que a verso for
passando por manutenes emergenciais (aquelas que no podem ser acumuladas para a
verso do ms seguinte). No exemplo da figura, a verso em questo a oficial (reviso 00),
do ms de abril de 2007.
A verso de homologao, uma vez testada pelo perodo de uma semana nos clientes
selecionados, e com eventuais problemas detectados e corrigidos, oficialmente convertida
em uma verso final (oficial), e disponibilizada no site para todos os clientes, na primeira
semana do ms seguinte ao de testes. Na figura 3.3 a seguir ilustrado esse processo.
58
FIGURA 3.3: LINHA DO TEMPO PARA DISPONIBILIZAO DE VERSES
Durante a fase de manuteno no cdigo-fonte, utilizado um software de controle de

verso (Microsoft Source Safe), que trabalha da seguinte forma: cada desenvolvedor que for
alterar algum arquivo (que faz parte do projeto do software) realiza uma operao de checkout11 desse arquivo do repositrio (o qual armazena o projeto todo), ficando nesse momento
responsvel pelo arquivo, impedindo que qualquer outra pessoa possa realizar check-out do
mesmo arquivo. Diz-se que o arquivo fica travado para o programador x. Somente quando a
manuteno for concluda, o arquivo submetido a um check-in12, voltando para o repositrio
e ficando livre para uso por outro programador.
medida que alteraes vo sendo entregues e disponibilizadas no repositrio, o
analista responsvel, realiza o check-out dos arquivos alterados e procede com testes
preliminares. Uma vez que a data de liberao da nova verso para homologao se aproxima,
esse analista realiza um check-out completo de todo o projeto do software, e realiza testes
gerais, a fim de compor a verso de homologao para envio aos clientes pr-estabelecidos.
Durante
homologao,
eventualmente
esses
clientes
so
acompanhados
pessoalmente por algum consultor, ou remotamente via apoio por telefone, e-mail, VNC
(software que permite conexo ao desktop remoto do cliente), entre outros.
Na medida em que problemas so verificados, se forem erros nas manutenes
realizadas para a verso que ser disponibilizada, esses erros so imediatamente corrigidos e a
verso de homologao atualizada. Se forem problemas novos (novas necessidades de
alteraes ainda no previstas), eles so registrados e ento programados para
disponibilizao em verses posteriores do software.
3.4 Metodologia
A metodologia de pesquisa buscou, por um lado, estudar a base de dados na qual esto os
registros de manuteno, e, por outro lado, entrevistar os profissionais responsveis pela
11
12
Ao de obter uma cpia do arquivo na mquina local (estando o repositrio em um servidor).

Ao inversa ao check-out. Devolver o arquivo alterado ao repositrio, atualizando-o.
59
tarefa de manuteno. A forma como cada etapa foi conduzida est descrita a seguir.
3.4.1 Parte A Base de Dados

Na primeira etapa, o foco dos esforos centrou-se em extrair da base de dados totais a respeito
de diferentes caractersticas das manutenes efetuadas no software. Esses totais foram
obtidos por meio de consultas SQL base, sendo que as totalizaes buscadas esto resumidas
no quadro 3.2.
QUADRO 3.2: CARACTERSTICAS DE MANUTENO CONSIDERADAS E SEUS OBJETIVOS
Valor
Objetivo
Distribuio de solicitaes mensalmente
Verificar algum padro na distribuio
Tempo em dias para entrega de solicitaes
Verificar o tempo de resposta ao cliente
Totais de solicitaes por grupo de prioridade
Verificar a expectativa do usurio
Totais por tipo de manuteno (vide item 2.2.4)
Verificar distribuio entre os tipos
Tempo de desenvolvimento e manuteno
Verificar esforo necessrio em cada fase
Finalmente, os nmeros obtidos foram utilizados para construo de grficos,

mostrados no tpico 3.5.
3.4.2 Parte B Questionrio e Entrevista

A segunda etapa do levantamento de dados foi realizada com o auxlio de questionrio e
entrevistas.
O questionrio elaborado (apndice A) visou obter dos profissionais envolvidos com
manuteno de software caractersticas de seu trabalho dirio, coletando uma gama de
informaes para anlise posterior junto com os dados da Parte A.
Aps a elaborao do questionrio foram realizadas entrevistas individuais com essas
pessoas, procurando-se registrar todo comentrio e informao relevante para o propsito da
entrevista.
Detalhes da estratgia e da confeco do questionrio podem ser vistas no apndice A.
3.5 Anlise dos Dados Coletados

Este tpico apresenta os resultados das duas formas utilizadas para obteno de dados: a
pesquisa na base de dados e as entrevistas. A base de dados, no momento da pesquisa, contava
com mais de 3700 solicitaes de manuteno, e as entrevistas foram realizadas com 8
pessoas ligadas diretamente manuteno do software. Os subitens a seguir pormenorizam
esses resultados.
60
3.5.1 Estatsticas sobre a Base de Dados

Partindo dos totais obtidos com a base de dados, algumas figuras puderam ser construdas.
Inicialmente, na figura 3.4, apresentado o nmero de solicitaes registradas
mensalmente desde a implantao do sistema de registro de manutenes, em abril de 2004,
at a data de realizao deste trabalho.
FIGURA 3.4: TOTAL MENSAL DE SOLICITAES DE MANUTENO
Nota-se que no existe uma constncia no nmero de manutenes por ms, o que
sugere uma imprevisibilidade nas necessidades de manuteno por parte dos clientes. Em
abril de 2005 foi registrado o maior nmero de chamados de manuteno (355). Os dados
representam uma mdia de 163,45 solicitaes de manuteno por ms (desvio padro de
83,7). Constatou-se ainda que a mdia de solicitaes diria de 8,59 novas requisies. Uma
possvel razo para a existncia de pocas com maior incidncia de pedidos de manuteno
seria o fato de o nmero de solicitaes entregues naquele ms ter sido maior, o que
normalmente acarretaria mais falhas colaterais, ou seja, aquelas que acabam incidindo em
outros mdulos do software, apesar dos testes e da homologao em clientes.
Os registros de solicitaes de manuteno incluem desde operaes simples, que
resultam em poucos dias para a implementao, at solicitaes mais complexas, que podem
levar semanas, e at meses, para serem concludas. Solicitaes desse porte normalmente
exigem que o projeto de um ou mais mdulos seja reestruturado, o que justifica o tempo gasto
para entrega ao cliente.
A distribuio, em termos de dias gastos para a implementao de manutenes,
mostrada na figura 3.5.
61
FIGURA 3.5: DIAS NECESSRIOS PARA A CONCLUSO DE MANUTENES
Um estudo do grfico revela que as manutenes de menor grau de complexidade

ocupam a maior parte do tempo dos mantenedores. No entanto, existem manutenes com
complexidade suficiente para exigir mais de dois meses de trabalho.
Observou-se que a grande quantidade de manutenes de menor complexidade acaba
por interferir no tempo de entrega das manutenes mais complexas, gerando atrasos. Isso
ocorre em funo da grande expectativa do cliente no sentido de obter respostas rpidas, o que
fora os mantenedores a liberar primeiro as manutenes mais simples. Na figura 3.6
mostrado qual o grau de prioridade indicado pelo cliente ao fazer as suas solicitaes de
manuteno.
FIGURA 3.6: DISTRIBUIO DE PRIORIDADES DAS MANUTENES
Nota-se que o cliente busca respostas rpidas, considerando com prioridade elevada a
maior parte dos chamados de manuteno efetuados.
Do ponto de vista dos quatro tipos de manuteno software (adaptativa, perfectiva,
corretiva e preventiva), realizou-se a quantificao das manutenes efetuadas dentro desses
tipos. Para esse levantamento, foi considerada a classificao das manutenes informada em
cada registro feito na base de dados. O resultado obtido apresentado na figura 3.7.
62
FIGURA 3.7: DISTRIBUIO DOS PROBLEMAS ENTRE OS TIPOS DE MANUTENO
Os valores apresentados apontam que o maior esforo da organizao est em atender

requisies de novas funcionalidades, mostrando enfoque em manuteno perfectiva. Uma
constatao preocupante foi a de que no existe uma ateno em avaliar e prevenir problemas
futuros no software (0% em manuteno preventiva), o que poderia ser feito por um processo
de reengenharia. Fica evidente que o enfoque est em manter o software em funcionamento,
adequando-o na medida em que as necessidades surgem, ou seja, seria uma postura de
aguardar acontecer e no de buscar prevenir.
esperado, pela literatura, que o tempo empenhado em tarefas de manuteno exceda
o tempo de desenvolvimento, e esse fato buscou ser comprovado pela comparao entre
tempo gasto com o desenvolvimento da primeira verso entregue ao cliente e o tempo gasto
com a manuteno at ento. Para isso, elegeram-se trs mdulos representativos do software
analisado (aqui referenciados por mdulo 1, mdulo 2 e mdulo 3), com o intuito de
contabilizar o tempo gasto em desenvolvimento e o gasto em manuteno. O tempo de
desenvolvimento inclui tempo gasto em projeto, codificao e testes.
Esse resultado apresentado na figura 3.8, que considera os registros de manuteno
efetuados at o momento de realizao deste trabalho.
FIGURA 3.8: TEMPO CONSUMIDO EM DESENVOLVIMENTO VERSUS EM MANUTENO
63
De acordo com o mostrado na figura, percebe-se que a organizao consumiu, nos trs
exemplos, mais de 60% do esforo empregado em atividades de manuteno, e esse
percentual tende a subir com o passar do tempo.
3.5.2 Ambiente e Equipe de Manuteno

Durante a entrevista com os responsveis pelas manutenes, constatou-se que no existe um
procedimento padro a ser seguido para a execuo das manutenes. O que existe uma
preocupao em agendar datas de entrega para as solicitaes cujos clientes responsveis
insistem em respostas mais rpidas, o que freqentemente acaba inviabilizando a metodologia
de disponibilizao de atualizaes descrita anteriormente. Casos de manutenes de
urgncia, quando ocorrem, so priorizados em detrimento das demais.
Observou-se tambm que o cdigo-fonte modificado no documentado de maneira
adequada, sendo muitas vezes atribudas somente pequenas notas, ou o nmero do chamado
que resultou na modificao de um trecho de cdigo. Esse nmero de chamado est
relacionado com o registro de necessidade de manuteno efetuado pelo cliente, podendo um
futuro mantenedor consultar do que se tratou a manuteno, buscando pelo nmero do
chamado informado no cdigo-fonte no sistema de registro de manutenes.
Os profissionais encarregados de tarefas de manuteno relataram ainda que nem
sempre o cliente compreende totalmente o que est solicitando, muitas vezes gerando
discusses entre empresa/cliente, o que est relacionado com os problemas de comunicao
entre usurio e desenvolvedor. Muitas vezes o cliente acredita que uma determinada
manuteno ser suficiente para adequar o software sua nova necessidade de negcio,
quando na verdade no suficiente. Essa dificuldade de compreenso do software pelo
prprio cliente acaba por gerar situaes de desgaste na relao entre empresa-cliente.
Prazo de entrega sempre um problema quando no existe um processo para conduzir
a manuteno. Esse foi outro fato verificado, uma vez que nem sempre a manuteno, com
data agendada e informada ao cliente, pode ser entregue no prazo combinado, geralmente em
funo de re-trabalho em manutenes j realizadas, ou mudanas de prioridades de entrega.
Em parte esse atraso decorre do fato de o mantenedor ser tambm a pessoa que
desenvolve, de forma que a tarefa de desenvolvimento precisa mesclar-se com a de
manuteno, contribuindo para a diminuio do desempenho do mantenedor. Isso se agrava
quando testes em uma nova funcionalidade esto sendo feitos em paralelo a alguma correo
solicitada pelo cliente.
Outro ponto importante refere-se ao baixo interesse dos profissionais envolvidos em
tarefas de manuteno, fato que pode ser comprovado pelo interesse desses profissionais em
64
deixar a atividade de manuteno para dedicar-se ao desenvolvimento. Esse interesse foi

manifestado por todos os profissionais de manuteno entrevistados.
A poltica de testes utilizada, embora prevista como uma alternativa pela literatura,
nesse caso especfico no vinha apresentando os resultados esperados. Nem sempre o cliente
tinha tempo e boa vontade para avaliar uma verso de testes em ambiente separado daquele de
produo, culminando com problemas nas manutenes efetuadas surgindo quando a verso
oficial j estava no site e em uso pela maior parte dos clientes em seus ambientes de
produo.
3.6 Problemas Identificados

Aps obter e analisar os dados, foi possvel montar o quadro 3.3, que envolve os principais
problemas de manuteno identificados na organizao.
QUADRO 3.3: PROBLEMAS DE MANUTENO DE SOFTWARE LISTA PARCIAL
Ausncia de um processo de manuteno de software
Problemas Gerenciais
Grande expectativa dos usurios

Elevada rotatividade de membros e funes dentro da equipe
Sobrecarga de tarefas
Estimativa de prazo no condizente com a complexidade do software
Baixa motivao entre profissionais de manuteno
Ausncia de manuteno preventiva
Falhas de comunicao com o usurio
Atrasos na entrega
Problemas
Tcnicos
Registro inexistente ou superficial de manutenes anteriores

Ausncia de um ambiente computacional especfico para manuteno
Validao insuficiente de manutenes efetuadas
Documentao insuficiente ou superficial
Falta de compreenso do software e suas estruturas
Os problemas, como pode ser visto no quadro, foram classificados de acordo com sua
natureza em problemas gerenciais e tcnicos. No item a seguir so tecidas consideraes
gerais sobre o resultado obtido.
3.7 Concluses Parciais

A classificao dos problemas de manuteno identificados na organizao quanto a sua
natureza, permite observar que aqueles ligados a questes gerenciais esto mais presentes do
65
que os de carter mais tcnico. De fato, constatou-se que conciliar dificuldades tcnicas de
manuteno com os anseios dos usurios no uma tarefa simples, e infelizmente no vem
obtendo o sucesso desejado.
A ausncia de um processo de manuteno de software formal, como dita normas de
engenharia de software, no seria de todo condenvel se o processo interno criado pela
prpria organizao funcionasse de maneira satisfatria. O que se observou foi que a presso
gerada pelos clientes muitas vezes prejudica o cumprimento correto da seqncia de passos
estipulada pela prpria organizao para tratar a manuteno de software.
Por fim, a inexistncia de manuteno preventiva um fato que precisa ser analisado
em conjunto com os objetivos de negcio da organizao e com seus projetos em relao
vida til do software que mantm.
66
CAPTULO
4
Problemas de Manuteno de Software
.
Este captulo apresenta uma comparao entre os problemas de manuteno de software
atuais, identificados pelo estudo de caso, e aqueles registrados no passado, buscando inferir
algum padro de evoluo nos mesmos. Alm disso, estabelece um rol de problemas de
manuteno de software, publicados por diferentes autores, na forma de uma lista de
dificuldades inerentes atividade de manuteno, para fins de anlise nos prximos captulos.
Procurou-se estabelecer uma denominao direta e simples para os problemas, facilitando a
leitura, o entendimento e posteriores referncias.
4.2 Problemas do Passado versus Problemas Atuais

Os problemas identificados no estudo de caso permitem o surgimento da seguinte questo: Os
problemas de manuteno de software de hoje guardam relao com aqueles verificados no
passado? A resposta a essa questo fornecer indcios da maneira como a mudana da
tecnologia pode estar ou no influenciando tanto o agravamento como o surgimento de
problemas.
Partindo desse princpio, constatou-se que existe um alinhamento mais ou menos
regular entre os problemas do passado com os atuais, o que permitiu a construo do quadro
4.1, no qual mostrado esse fato por meio de um paralelo entre os problemas apontados no
Captulo 4 Problemas de Manuteno de Software
68
tpico 2.6, obtidos por Lientz e Swanson (1980), e os identificados no estudo de caso. O
quadro associa os problemas relacionando-os de acordo com a sua natureza.
QUADRO 4.1: COMPARAO ENTRE PROBLEMAS DE MANUTENO DE SOFTWARE
Problemas apontados por
Lientz e Swanson (1980)
Problemas atuais
Baixa qualidade da
documentao dos sistemas
- Registro inexistente ou superficial de manutenes

anteriores;
- Documentao insuficiente ou superficial.
Necessidade constante dos

usurios por melhorias e novas
funcionalidades
- Grande expectativa dos usurios;

- Falhas de comunicao com o usurio.
Falta de uma equipe de

manuteno
Falta de comprometimentos
com cronogramas
Treinamento inadequado do
pessoal de manuteno
Rotatividade dos profissionais
- Ausncia de um processo de manuteno de software;

- Sobrecarga de tarefas;
- Ausncia de manuteno preventiva;
- Ausncia de um ambiente computacional especfico para
manuteno.
- Estimativa de prazo no condizente com a complexidade do
software;
- Atrasos na entrega.
- Baixa motivao entre profissionais de manuteno;
- Validao insuficiente de manutenes efetuadas;
- Falta de compreenso do software e suas estruturas.
- Elevada rotatividade de membros e funes dentro da
equipe.
Embora no se estabelea uma equivalncia exata, esse quadro mostra uma

semelhana muito grande entre a natureza dos problemas obtidos em cada levantamento. Esse
fato favorvel aos objetivos deste trabalho, pois mostra que existe uma relativa estabilidade
entre os problemas.
Essa constatao permite que uma sistematizao do estudo possa ser estabelecida. Se
os problemas atuais fossem muito diferentes dos verificados no passado, ento seria difcil
decidir sobre quais deles buscar tcnicas e procedimentos para a reduo dos esforos
empregados, porm esse fato no se verificou. Isso permite concluir que possvel estabelecer
estudos e respostas sobre problemas de manuteno de software que no se tornaro
totalmente obsoletos quando uma nova tecnologia surgir.
4.3 Problemas de Manuteno Publicados

A relao de problemas de manuteno de software identificada pode ser visualizada no
quadro 4.2, construdo de forma a mostrar os problemas e suas respectivas fontes. Em virtude
da lista relativamente extensa, optou-se por dividi-la em categorias para promover melhor
organizao e facilidade de leitura. A numerao seqencial atribuda a cada problema tem o
intuito nico de facilitar as referncias posteriores, no guardando qualquer outro significado.
Faz-se necessrio dizer que a separao dos problemas a seguir no rigorosamente exata,
uma vez que muitos deles poderiam ser classificados em mais de uma categoria.
69
QUADRO 4.2: PROBLEMAS DE MANUTENO DE SOFTWARE LISTA GERAL

Fatores de Gerncia
Problema
01. Falta de comprometimento com cronogramas
02. Treinamento inadequado da equipe de manuteno
Referncias
Lientz e Swanson (1980);
Estudo de Caso
Dekleva (1992); Dart et al.
(2001); Estudo de Caso
03. Ausncia de um profissional responsvel exclusivamente ao

Dart et al. (2001)
controle de configurao de software
04. Viso organizacional diferenciada para a equipe de
Dart et al. (2001)
desenvolvimento e para a equipe de manuteno
05. Dificuldades de comunicao entre a equipe de manuteno
Dart et al. (2001)
e a prpria organizao
06. Software desenvolvido visto pela gerncia como no
Dart et al. (2001)
construdo para a manuteno
07. Mantenedores desconhecem planos da organizao com
Dart et al. (2001)
relao equipe de manuteno
08. Contratao de temporrios para auxlio na manuteno
Dart et al. (2001)
leva ao menor controle sobre a atividade
09. Experincias com manutenes anteriores no so
Dart et al. (2001); Estudo de
disseminadas dentro da prpria organizao e entre novos
Caso
membros da equipe
10. Dificuldade na medio do desempenho da equipe de
Dekleva (1992)
manuteno
11. Ausncia de adoo de padres, metodologias e Dekleva (1992); Estudo de
procedimentos de manuteno
Caso
12. Falta de suporte da gerncia
Dekleva (1992)
13. Sobrecarga de tarefas
Estudo de Caso
14. Ausncia de manuteno preventiva
Estudo de Caso
15. Estimativa de prazo no condizente com a complexidade do

software
Estudo de Caso
Fatores de Infra-estrutura
Problema
16. Necessidade de suporte automatizado gerncia de
configurao de software
17. Ferramentas para manuteno precisam ser diferentes
daquelas de desenvolvimento
18. Falta de recursos tecnolgicos adequados
19. Estagnao tecnolgica no ambiente de trabalho
Referncias
Dart et al. (2001)
Dart et al. (2001)
Dart et al. (2001); Estudo de
Caso
Dart et al. (2001)
Fatores humanos equipe

Problema
Referncias
20. Falta de uma equipe de manuteno
Lientz e Swanson (1980)
21. Elevada rotatividade dos profissionais

Dekleva (1992); Estudo de
Caso
70
22. Mantenedores lamentam por no possurem contato com

estado-da-arte da tecnologia
23. Preferncia dos profissionais por trabalhos de
desenvolvimento
24. Manuteno de software vista como uma tarefa no
prestigiosa
25. Falhas de comunicao com o usurio
Dart et al. (2001)

Dart et al. (2001)
Estudo de Caso
26. Mtodos inadequados de testes

27. Documentao insuficiente ou superficial (software alterado)
Dekleva (1992); Estudo de

Caso
Dekleva (1992) ; Dart et al.
Fatores humanos cliente

Problema
Referncias
28. Necessidade constante dos usurios por melhorias e novas

funcionalidades
29. Falta de compreenso dos usurios a respeito de suas reais
necessidades de software

Estudo de Caso
30. Mudanas freqentes de prioridades (clientes)
Estudo de Caso
Dekleva (1992)
Fatores de software
Problema
Referncias
31. Baixa qualidade da documentao dos sistemas (software

original)
32. M qualidade do cdigo-fonte original
33. Necessidades de integrao com softwares incompatveis
34. Plataformas heterogneas
ferramentas adequadas
dificultam
definio

(2001)
Dart et al. (2001)
de
Dart et al. (2001)
A relao anterior, embora seguramente no exaustiva, apresenta de forma geral os

principais problemas que recaem sobre a atividade de manuteno de software. Outros
problemas que eventualmente existam e no foram citados, so demasiados especficos de
certo domnio, ou fortemente relacionados a algum dos problemas j citados. Dessa forma,
acredita-se que a listagem anterior seja representativa das dificuldades mais importantes em
manuteno de software, no se prendendo a nenhum domnio especfico de software.
4.4 Relacionamento entre os Problemas de Manuteno e os

Grupos de Processos da Norma ISO/IEC 12207
Conforme j apresentado neste trabalho, a norma ISO/IEC 12207 representa um padro
internacionalmente adotado que engloba processos para o ciclo de vida de software. Neste
tpico, a norma utilizada para criar uma relao de causa e conseqncia com os problemas
de manuteno de software apresentados no rol anterior.
71
Essa relao se estabelece da seguinte maneira: a norma apresenta grupos de processos

(que por sua vez englobam diversos outros processos), que visam atingir alguma fase do ciclo
de vida de software, guiando-o com as melhores prticas. Assim, a no verificao de um
grupo de processos, acarretar problemas para a respectiva fase (e conseqncias para as
futuras).
Dessa maneira, foi possvel a construo do quadro 4.3, no qual so relacionados os
grupos de processos da norma, com os problemas de manuteno, procurando estabelecer
uma relao de causa (a no verificao do respectivo grupo) e conseqncia (problema
derivado). Para essa distribuio, verificaram-se, para cada grupo, seus processos e as
determinaes de suas respectivas tarefas. O no atendimento a uma das tarefas do processo,
automaticamente relaciona o problema ao processo, e em um nvel mais alto, ao grupo ao qual
esse processo pertence.
QUADRO 4.3: GRUPOS DE PROCESSOS NO OBSERVADOS E AS RESPECTIVAS CONSEQNCIAS
Problemas
Categoria Processos Fundamentais
(11), (26), (29), (33), (34)
(25)
Categoria Processos Organizacionais

(01), (04), (05), (06), (07), (08), (12), (13),

(14), (15), (20), (21), (24), (30), (31), (32)
Grupo de Processos de Melhoria de Processo

Grupo de Processos de Recursos e Infraestrutura
(02), (09), (10), (17), (18), (19), (22), (23)

Categoria Processos de Apoio
Configurao
(03), (16), (27), (28)
Grupo de Processos de Garantia de Qualidade
A distribuio grfica das informaes anteriores est representada na figura 4.1.
18
16
14
12
10
8
6
4
2
0
72
47,1%
23,5%
14,7%
11,8%
G
er
n
ci
a
ad
e
lid
Q
ua
ur
a
o
de
tia
de
In
f
e
0%
on
f ig
Re
u
so
0%
o
ra
-e
st
ru
tu
ra
Pr
oc
es
s
ci
a
Re
cu
rs
os
el
h
or
ia
de
G
er
n
o
O
pe
ra
ar
ia
ge
nh
En
en
to
rn
ec
im
0%
G
ar
an
2,9%
0%
Fo
Aq
ui
si
0%
FIGURA 4.1: DISTRIBUIO DOS PROBLEMAS NOS GRUPOS DE PROCESSOS
Percebe-se, pela figura anterior, que existe uma grande concentrao de problemas
relacionados principalmente com fatores de ordem gerencial, ligados interao com pessoas
e processos, respondendo por 47,1% dos problemas.
Dentre os dez grupos de processos, cinco ficaram sem nenhum problema relacionado.
Os grupos de aquisio e de fornecimento apresentam uma razo clara: esto relacionados
criao de um produto de software novo, portanto fortemente ligadas ao desenvolvimento, o
que no foi considerado. O grupo de melhoria de processo pode ser visto sob duas
perspectivas, que consideram a existncia ou no de processos implantados na organizao.
Na primeira das vises, assumindo que a organizao possua processos implantados, os
problemas de manuteno poderiam ser associados a falhas nesses processos, alegando-se que
seriam essas falhas as responsveis diretamente pela maioria dos problemas de manuteno.
Isso, no entanto, no corresponde realidade, j que normalmente os processos no existem
nas organizaes.
Em outra viso do grupo de melhoria de processo, agora considerando que a
organizao no possua processos implantados, seria inadequado valer-se desse fato para se
associar a esse grupo praticamente todos os problemas de manuteno, sob a alegao de que
existem como resultado da ausncia de processos adequados para tratar a manuteno de
software. A inadequao desse posicionamento se justifica pelo fato de que possvel
estabelecer uma melhor relao dos problemas com outros processos da norma, muitas vezes
de forma direta, valendo-se para isso das tarefas estipuladas para cada processo. O no
73
cumprimento de uma tarefa especfica, automaticamente relaciona o processo correspondente

com algum dos problemas j apresentados. Assim, pode-se concluir que a norma capaz de
fornecer indcios de quais processos especficos inexistem ou so falhos para a ocorrncia de
cada problema, permitindo ento distribu-los de forma mais precisa e no associ-los todos
ao grupo de melhoria de processo sob a alegao genrica de sua ausncia na organizao.
O prximo grupo a considerar o de reuso, que tambm parece ter uma razo clara
para ter permanecido sem problemas associados. No simples tratar o reuso de artefatos de
software nem mesmo durante o desenvolvimento. O que dizer ento da atividade de
manuteno, normalmente com necessidades imprevisveis e muitas vezes inditas para o
contexto do software. Dificilmente ser possvel valer-se de solues prontas, o que torna o
grupo de processos de reuso com pouca ou nenhuma importncia para a reduo de problemas
de manuteno de software.
Finalmente, o grupo de processos de garantia de qualidade tambm no teve
problemas relacionados em razo de existirem outros processos da norma com tarefas
especficas no atendidas que melhor se encaixam como fonte do problema. Por exemplo,
considere o processo de garantia de qualidade (os processos do grupo so: garantia de
qualidade, verificao, validao, reviso conjunta, auditoria e avaliao de produto). O
objetivo principal desse processo prover garantias de que os produtos de trabalho e
processos obedeam aos planos predefinidos para o software. Note, no entanto, que os
problemas de manuteno de software normalmente so frutos da ausncia de planejamento
ou do planejamento falho da manuteno, sendo que o correto planejamento e execuo so
tarefas reservadas a outro processo (processo de Manuteno de Software e Sistema). Assim,
a existncia de processos com tarefas mais especficas acabou por evitar que problemas de
manuteno fossem relacionados a processos do grupo de garantia de qualidade. No entanto,
fcil perceber que a palavra qualidade extremamente conhecida em diversos contextos,
mesmo aqueles no relacionados a software, chegando a ser quase intuitivo pensar que algo
feito com qualidade resultar em menos problemas ou maior satisfao do usurio. Esse
raciocnio leva concluso de que, embora sem problemas associados diretamente, os
processos do grupo de garantia de qualidade devem ser observados como recurso de apoio
execuo com qualidade das tarefas de manuteno como um todo.

Embora tenha se produzido neste captulo uma relao de problemas com base em
apontamentos feitos por outros autores, e tambm pelo estudo de caso realizado, entende-se
que no se trata de uma relao fixa e exaustiva. Em diferentes abordagens futuras, nomes
74
diferentes podem ser utilizados para se referirem s mesmas dificuldades. razovel pensar
ainda que novos problemas surjam, constituindo novas categorias de problemas, distintas das
aqui definidas.
Esse fato, porm, no invalida ou torna de todo desatualizado o que foi exposto, j que
a literatura, e tambm o estudo de caso apresentado, apontam uma relativa estabilidade entre
os problemas mais relevantes ao longo do tempo.
admissvel, tambm, que o surgimento de novas tcnicas de programao, novas
tecnologias e metodologias, influenciem a forma como as organizaes trabalham, e nesse
caso poderiam reduzir os problemas aqui apresentados.
Outra observao necessria se faz com relao aos problemas e os tamanhos de
software sobre os quais incidem. O que ocorre, de fato, que os problemas apresentados
incidem de maneira geral sobre qualquer tamanho de software, variando apenas a nfase que o
problema representa para cada tamanho de software.
Por fim, a relao estabelecida entre os problemas e os grupos da norma, permite uma
viso inicial das caractersticas do processo de ciclo de vida de software que devem ser
tomadas com maior ateno para o contexto de minimizao de problemas de manuteno de
software. No captulo seguinte, esse relacionamento retomado e considerado com maiores
detalhes.
CAPTULO
5
Alternativas de Reduo dos Problemas
de Manuteno de Software
.
As alternativas de respostas para os problemas de manuteno de software apresentadas neste
captulo esto embasadas em trs fontes distintas: na norma ISO/IEC 12207, nas solues
encontradas na organizao analisada no estudo de caso, e nas propostas de outros autores que
se dedicaram ao assunto.
Acredita-se que a norma seja um excelente veculo para conduzir uma organizao de
software pelas melhores prticas, j que seu contedo resultado de um esforo
fundamentado no que poderia se chamar estado-da-arte da engenharia de software. Outra
considerao importante diz respeito maneira como a norma se apresenta. Ela no um
modelo fechado que diz como fazer e manter software da melhor forma, mas sim, mostra o
que deve ser considerado para que isso seja alcanado. Dessa forma, a norma funciona como
um guia para ser seguido por organizaes interessadas em tratar sistematicamente seu
processo de software.
O estudo de caso apresentado anteriormente estendido neste captulo, expondo agora
prticas adotadas pela organizao que trouxeram resultados satisfatrios para a preveno ou
conteno de problemas de manuteno de software em seu ambiente de trabalho.
Finalmente, os mesmos autores que identificaram problemas de manuteno de
software em seus trabalhos tambm contribuem para fornecer propostas de reduo desses
problemas.
Captulo 5 Alternativas de Reduo dos Problemas de Manuteno de Software
76
5.2 Extenso do Estudo de Caso

Neste tpico apresentada a extenso do estudo de caso mostrado no captulo 3.
Essa extenso foi possvel graas constatao de que a organizao estava em busca
freqente por melhorias em seu ambiente de trabalho, e em sua capacidade de resposta
satisfatria aos clientes, que vinham crescendo em nmero, sem, no entanto, valer-se da
adoo de um processo extenso e sistemtico como o sugerido pela norma ISO/IEC 12207.
O objetivo foi verificar quais mudanas a organizao vinha adotando no seu dia-a-dia
que estivessem contribuindo positivamente para a diminuio de seus problemas de
manuteno de software, ou ainda, o que os profissionais empenhados nessa atividade
achavam que deveria ser feito para que essa reduo ocorresse.
5.2.1 Metodologia
A metodologia aplicada na extenso do estudo de caso tambm foi baseada em questionrios
e entrevistas (apndice A).
O intuito principal desses questionrios foi o de servirem para a abertura de uma
discusso na qual exemplos de solues eficientes fossem citados pelos entrevistados. Como
o objetivo era que a organizao mostrasse quais atitudes vinha adotando para tratar de
maneira satisfatria sua atividade de manuteno, no havia como estipular questes prvias,
por isso o questionrio reduzido funcionou somente como recurso para incio de entrevista.
De fato, as solues citadas, bem como observaes e todas as informaes relevantes para o
contexto da entrevista, foram registradas pelo entrevistador em documento a parte e
posteriormente compiladas.
5.2.2 Solues Identificadas

Os resultados obtidos foram organizados e utilizados para elaborar os itens a seguir, que
apresentam solues apontadas pelos entrevistados como favorveis para a atividade de
manuteno de software, contribuindo para reduzir um ou mais dos problemas conhecidos.
Melhoria em treinamento: uma prtica relevante adotada pela organizao diz respeito
a treinamento. A soluo considerada foi a de verificar entre os profissionais
interessados, quais eram as ferramentas de software que gostariam de um
aprofundamento em conhecimentos, por meio de certificaes. A partir desse
levantamento, a organizao se comprometeu em comprar os livros necessrios
preparao para alguns exames de certificao oficial. Como exemplo, tem-se uma das
modalidades de certificao de DBA SQL Server da Microsoft. O gerenciador de
banco de dados SQL Server corresponde ao utilizado pela organizao, e sua
77
configurao correta, seja em termos de desempenho ou de funcionalidades, de

fundamental importncia. Assim, a organizao comprou os livros necessrios
preparao, e que normalmente tm um custo relativamente alto, se comprometendo
ainda a reembolsar o valor pago para realizao do exame, caso o profissional fosse
aprovado. No momento das entrevistas, algumas pessoas j haviam conseguido
aprovao no mdulo inicial da certificao. Esse conhecimento adicional em banco
de dados de relevncia para manuteno, j que o software da empresa tem muitas
partes implementadas na forma de stored procedures, e muitas das manutenes so
efetuadas nesses componentes.
Gerenciamento do conhecimento: ligado diretamente ao problema da rotatividade

elevada, a organizao vinha se empenhando em sistematizar os problemas de
manuteno, principalmente os problemas de atendimento ao cliente via suporte e
help-desk, montando uma base de conhecimentos onde fosse possvel consultar as
solues possveis para um problema freqente. Para isso, uma ferramenta web de
colaborao on-line foi instituda, e nela registrado, na forma de perguntas e respostas,
as maneiras de abordar inmeros problemas. A atitude gerencial inicial para a
composio das primeiras questes dessa base foi a obteno, junto equipe de
suporte, de uma lista de problemas mais comuns. O passo seguinte foi reunir
consultores da empresa que trabalham na cidade de So Paulo, para em reunies
conjuntas entre equipe de suporte e consultores, elaborar as primeiras respostas lista
de problemas de suporte. Tais questes foram posteriormente inseridas na ferramenta
web, de forma que qualquer pessoa dentro da organizao pudesse ter acesso e editar
seu contedo, como forma de complementao.
Melhoria na documentao oferecida ao cliente: da mesma forma que foi criado um

repositrio de problemas e solues para a prpria organizao, tambm se criou algo
semelhante em relao aos clientes. Com o uso da mesma ferramenta web, uma
interface de consulta foi disponibilizada aos clientes, permitindo a obteno de
respostas a problemas comuns que o suporte vinha reiteradas vezes atendendo, com
uma linguagem padronizada e uniforme. Questes de carter tcnico, que envolvesse
informaes de cdigo-fonte ou configurao de banco de dados, no ficavam
disponveis aos clientes (essa classificao de o que o cliente podia consultar e o que
no podia, era feita principalmente pela equipe de suporte, mas de uma forma geral
todos podiam interferir).
78
Padronizao no fluxo de informaes: buscando corrigir problemas de comunicao

com os usurios, muitas vezes por motivos de o usurio informar partes de seu
problema para pessoas diferentes do suporte, o que tornava a compreenso do todo
dificultada e muitas vezes gerava insatisfao desse cliente, foi uniformizada a
maneira como esse tipo de informao fluiria na organizao. O fluxo estabelecido foi
o seguinte: todo problema de software deveria ser primeiramente cadastrado no
sistema de help-desk, para ento algum contato via telefone ou e-mail poder ser
estabelecido. O sistema de help-desk possua recurso de interao entre usurio e
suporte, registrando-se ali (e no por e-mail, como antes) todas as interaes e detalhes
do problema em questo. Com isso evitou-se a perda de informaes passadas pelo
cliente, o que impactava na manuteno, pois chamados de alterao eram
estabelecidos sem o devido detalhamento, o que causava m especificao de
requisitos de alterao, gerando conflitos do prprio suporte com a equipe de
manuteno.
Melhoria em cronogramas: um dos grandes problemas em manuteno a questo de

prazos e o cumprimento de cronogramas estabelecidos junto aos clientes. A
organizao, visando minimizar esse tipo de problema, adotou a postura de assumir de
fato o cronograma junto ao cliente, garantindo isso da seguinte forma: aps serem
agendadas as datas de entrega de manutenes, cada profissional responsvel pela
implementao deveria informar, diariamente, ao coordenador o andamento de suas
atividades. Ao menor sinal de contratempos que fossem levar a um no-cumprimento
da data de entrega estipulada, o coordenador indicava algum ou ele prprio assumia a
responsabilidade de auxiliar na manuteno para que o prazo fosse cumprido. Essa
postura forou a contratao de novos programadores.
Diviso de tarefas: o sistema de registro de chamados de manutenes passou a

abrigar mais um campo de informao: o nvel de complexidade da manuteno,
estipulado pelo coordenador. Isso permitiu um melhor controle do problema da
sobrecarga de tarefas, o que seguramente foi auxiliado pela contratao de novos
programadores.
Melhoria em testes: essa foi uma das mudanas significativas para a reduo do
nmero de problemas de software que acabavam no ambiente de produo dos
clientes. A medida adotada foi a de insistir no uso de teste beta (testes pelo cliente, em
seu ambiente), porm a maneira de negociao foi alterada. A organizao se
comprometeu a preparar todo ambiente paralelo ao de produo, necessrio para
79
efetuar os testes, sempre que uma verso de testes fosse disponibilizada, ficando a
cargo do cliente apenas proceder com os testes, sem necessidade de qualquer
configurao de software. O cliente deveria oferecer apenas os recursos de hardware
(computador, espao em disco rgido para replicao do banco de dados de produo
etc.). Alm disso, a liberao da verso inicial de testes passou a ocorrer somente aps
revises mais rgidas realizadas internamente na organizao por uma pessoa dedicada
exclusivamente a essa tarefa.
Por fim, verificou-se que a questo da documentao interna das manutenes era uma
das preocupaes da organizao, porm ainda sem soluo satisfatria implementada,
portanto no citada aqui.
Embora no se tenha adotado um processo de manuteno complexo e rgido, a lista
de modificaes internas citada contribuiu para a diminuio daqueles problemas mais
simples e que causavam grande impacto negativo junto aos clientes.
No entanto, uma nova dificuldade parece ter surgido, e tambm j estava sendo
combatido pela gerncia atravs de maiores exigncias, que era justamente o fato de os
procedimentos novos adotados nem sempre estarem sendo seguidos, como por exemplo, a
necessidade de sempre registrar na base de conhecimento as solues adotadas para
problemas que ainda no constavam dessa base.
5.2.3 Consideraes Gerais

As solues encontradas pela organizao pesquisada no representam o resultado do
emprego de alguma norma ou processo bem definido, como dito anteriormente.
Foi justamente esse fato que permitiu utilizar essas solues como alternativas para
abordar os problemas de manuteno de software. Isso porque importante que seja mostrado
tanto o aspecto rigorosamente formal proposto pela norma ISO/IEC 12207, como tambm
alternativas de solues. valioso destacar que alternativas como as aqui apresentadas podem
at mesmo serem mais viveis do que a adoo da prpria norma, dependendo do porte da
organizao e de sua estruturao.
O fundamental que as organizaes de software se empenhem em compreender as
caractersticas e dificuldades de si prprias, buscando continuamente por falhas e possveis
formas de trat-las, o que muitas vezes pode ocorrer pela simples mudana de atitudes e
controle mais rgido de tarefas. O uso de ferramentas de software tambm um ponto
importante, e nesse exemplo houve o uso de ferramentas para auxlio no tratamento de
informaes.
80
5.3 Solues com base na Norma ISO/IEC 12207

O relacionamento entre os problemas de manuteno de software mostrado no captulo
anterior pode ser estendido para especificar tambm a qual processo do grupo o problema de
manuteno de software se relaciona (lembre-se que essa relao devida ao no
cumprimento de tarefas do processo correspondente).
Para criar esse relacionamento, o quadro 5.1 foi construdo. Nele so apresentados
todos os grupos e processos da norma, mostrando em quais desses processos os problemas de
manuteno de software se encaixam, de forma individual.
QUADRO 5.1: PROCESSOS DA NORMA ISO/IEC 12207 E PROBLEMAS DE MANUTENO DE SOFTWARE
Problema
Categoria Processos Fundamentais
Preparao da Aquisio
Seleo do Fornecedor
Acordo Contratual
Monitoramento do Fornecedor
Aceitao pelo Cliente
Proposta do Fornecedor
Liberao de Produto
Apoio para Aceitao de Produto
Elicitao de Requisitos
29. Falta de compreenso dos usurios a respeito de

suas reais necessidades de software
Anlise de Requisitos de Sistema

Projeto de Arquitetura de Sistema
Anlise de Requisitos de Software
33. Necessidades de integrao com softwares

incompatveis
34. Plataformas heterogneas dificultam a definio
de ferramentas adequadas
Projeto de Software
Construo de Software
Integrao de Software
Teste de Software
Integrao de Sistema
Teste de Sistema
Instalao de Software
26. Mtodos inadequados de testes

Manuteno de Software e Sistema
11. Ausncia de adoo de padres, metodologias e

procedimentos de manuteno

Operao
Suporte ao Cliente
25. Falhas de comunicao com o usurio
Categoria Processos Organizacionais

Alinhamento Organizacional
Gerncia Organizacional
Gerncia de Projeto
07. Mantenedores desconhecem planos da

organizao com relao equipe de manuteno
04. Viso organizacional diferenciada para a equipe
de desenvolvimento e para a equipe de manuteno
05. Dificuldades de comunicao entre a equipe de
manuteno e a prpria organizao
20. Falta de uma equipe de manuteno
24. Manuteno de software vista como uma tarefa
no prestigiosa
01. Falta de comprometimento com cronogramas
06. Software desenvolvido visto pela gerncia
como no construdo para a manuteno
08. Contratao de temporrios para auxlio na
manuteno leva ao menor controle sobre a
atividade
12. Falta de suporte da gerncia
13. Sobrecarga de tarefas
15. Estimativa de prazo no condizente com a
complexidade do software
Gerncia de Qualidade
14. Ausncia de manuteno preventiva
Gerncia de Riscos
21. Elevada rotatividade dos profissionais

30. Mudanas freqentes de prioridades (clientes)
31. Baixa qualidade da documentao dos sistemas
(software original)
32. M qualidade do cdigo-fonte original
Medio
Grupo de Processos de Melhoria de
Processo
Estabelecimento de Processo
Avaliao de Processo
Melhoria de Processo
Grupo de Processos de Recursos e
Infra-estrutura
Gerncia de Recursos Humanos
Treinamento
Gerncia de Conhecimento
10. Dificuldade na medio do desempenho da

equipe de manuteno
23. Preferncia dos profissionais por trabalhos de
desenvolvimento
02. Treinamento inadequado da equipe de
manuteno
22. Mantenedores lamentam por no possurem
contato com estado-da-arte da tecnologia
09. Experincias com manutenes anteriores no
so disseminadas dentro da prpria organizao e
entre novos membros da equipe
81
Infra-estrutura
13
82
17. Ferramentas para manuteno precisam ser

diferentes daquelas de desenvolvimento
18. Falta de recursos tecnolgicos adequados
19. Estagnao tecnolgica no ambiente de trabalho

Gerncia de Ativos
Gerncia de Programa de Reuso
Engenharia de Domnio
Categoria Processos de Apoio
Configurao
Documentao
27. Documentao insuficiente ou superficial

(software alterado)
03. Ausncia de um profissional responsvel
exclusivamente ao controle de configurao de
software
16. Necessidade de suporte automatizado gerncia
de configurao de software
Gerncia de Resoluo de Problemas

Gerncia de Solicitaes de Mudana
28. Necessidade constante dos

melhorias e novas funcionalidades
usurios
por
Grupo de Processos de Garantia de

Qualidade
Garantia de Qualidade
Verificao
Validao
Reviso Conjunta
Auditoria
Avaliao de Produto
Percebe-se que no so todos os processos da norma que quando no observados

contribuem para os problemas de manuteno de software. Porm, aqueles que esto
diretamente ligados ao surgimento dos problemas, precisam de um entendimento mais
detalhado, explorando-se tambm as tarefas previstas para cada um.
No tpico seguinte, cada processo que apresentou associao com problemas de
manuteno descrito em um quadro, que apresenta os resultados esperados de uma
implementao com sucesso do processo e suas respectivas tarefas, de acordo com o que
expe a norma. As tarefas podem ser consideradas como as solues possveis para os
problemas atrelados a cada processo. Imediatamente aps cada quadro, so tecidas
observaes ou comentrios a respeito do processo no contexto de manuteno de software.
13
De acordo com a norma, infra-estrutura pode incluir hardware, software, mtodos, ferramentas, tcnicas,
padres e outras facilidades para desenvolvimento, operao e manuteno.
83
5.3.1 Grupo de Processos de Engenharia

Um total de 14,7% dos problemas de manuteno de software foi classificado em processos
pertencentes ao grupo de processos de engenharia.
No quadro 5.2 apresentado o primeiro processo considerado desse grupo, o processo
de elicitao de requisitos.
QUADRO 5.2: ENGENHARIA: PROCESSO DE ELICITAO DE REQUISITOS
Processo: Elicitao de Requisitos
Objetivos: Reunio, processamento e monitoramento da evoluo das necessidades do cliente
e de seus requisitos atravs da vida do produto e/ou servio.
Resultados esperados de uma implementao com sucesso:
(i)
Contnua comunicao com o cliente;
(ii)
Ajuste dos requisitos definidos com o cliente;
(iii)
Estabelecimento de um mecanismo para avaliar e recepcionar mudanas de

requisitos do cliente, resultado de mudanas de necessidades do mesmo;
(iv)
Elaborao de um mecanismo para continuamente monitorar as necessidades do

cliente;
(v)
Criao de um meio que permita ao cliente consultar o status de suas requisies;
(vi)
Gerenciamento de melhorias derivadas de troca de tecnologias ou mudanas de

necessidades do cliente.
Tarefas necessrias
Obteno dos requisitos do cliente: consiste em obter e definir quais so os requisitos do cliente,
por meio de solicitaes diretas e pela especificao de entradas para o seu sistema. Isso pode
ser obtido por reviso dos propsitos de negcio do cliente, verificao do ambiente operacional
e de hardware e ainda outros documentos.
Entendimento das expectativas do cliente: tem por objetivo assegurar que tanto fornecedor
quanto o cliente entenderam cada requisito da mesma maneira. Revises com os clientes para
um entendimento melhor das suas necessidades e expectativas devem ser conduzidas.
Concordncia com os requisitos: busca obter formalmente junto ao cliente e seus interessados a
concordncia total com relao aos requisitos estipulados.
Estabelecimento final dos requisitos: essa tarefa produz um documento formal considerado o
estabelecimento final dos requisitos para uso na fase de projeto e para confronto com futuras
mudanas de necessidades do cliente.
Gerenciamento de mudanas de requisitos do cliente: consiste em gerenciar todas as mudanas
do cliente em relao ao documento original de requisitos, garantindo que melhorias resultantes
de mudana de tecnologias ou de necessidades do cliente possam ser identificadas e aquelas
que sejam afetadas por mudanas possam ser analisadas em relao a impacto e riscos,
permitindo a tomada de aes.
Estabelecimento de mecanismo de comunicao com cliente: consiste em prover meios para
que o cliente possa ser alertado do status e disposio das suas mudanas de requisitos.
84
Comentrio sobre o processo:

A clara definio e entendimento comum dos requisitos uma das caractersticas mais
relevantes para manuteno de software, porm, as sugestes da norma podem ser demasiadas
formais para a grande massa de pequenas manutenes normalmente existentes. Exigir que o
cliente documentasse todos os pedidos da maneira como a norma expe pode no ser
adequado para a grande maioria dos pequenos ajustes, o que poderia levar a um
descontentamento do cliente, o qual consideraria a organizao que contratou extremamente
burocrtica.
A soluo mais evidente, a exemplo do que fazem muitas organizaes, o uso de
sistemas on-line de help-desk, reservando apenas s manutenes mais complexas um
procedimento formal de documento de requisitos.
Por meio de um help-desk, possvel documentar tanto as solicitaes do cliente,
como as interaes da equipe de suporte/manuteno, atendendo tambm ao requisito da
norma de criao de um mecanismo para consulta ao status da uma determinada solicitao
pelo cliente. Essa uma forma de evitar outro problema importante que surge com a obteno
dos requisitos: a perda de informaes. Se os requisitos forem passados via telefone, e-mail,
fax, etc., a experincia mostra que a perda dessas informaes comum e leva a um
descontentamento geral, com conseqente perda de credibilidade da organizao frente ao
cliente.
Na seqncia, o prximo processo a ser considerado o de anlise de requisitos de

software. No quadro 5.3 exposto esse processo.
QUADRO 5.3: ENGENHARIA: PROCESSO DE ANLISE DE REQUISITOS DE SOFTWARE
Processo: Anlise de Requisitos de Software
Objetivos: Estabelecimento dos requisitos de elementos de software para o sistema.
(i)
Definio dos requisitos necessrios aos elementos de software do sistema, bem

como suas interfaces;
(ii)
Requisitos de software so analisados quanto corretude e testabilidade;
(iii)
O impacto dos requisitos de software no ambiente operacional compreendido;
(iv)
Consistncia e rastreabilidade so estabelecidas entre os requisitos de software e

os requisitos de sistema;
(v)
Definio da priorizao de implementao para os requisitos de software;

(vi)
Aprovao e atualizao dos requisitos de software sempre que necessrio;
(vii)
Avaliao das mudanas de requisitos de software com relao a custos,
85
cronograma e impacto tcnico;

(viii)
Composio final dos requisitos de software e comunicao a todas as partes

afetadas.
Tarefas necessrias
Especificao de requisitos de software: definir, analisar e priorizar requisitos de software

operacionais e no-operacionais do sistema, registrando no documento de requisitos de
software.
Determinao do impacto no ambiente operacional: determinar as interfaces entre os requisitos
de software e outros elementos do ambiente operacional e o impacto que esses requisitos tero.
Desenvolvimento de um critrio de teste de software: usar os requisitos de software para definir
critrios de aceitao para os testes do produto de software, que devem mostrar conformidade
com esses requisitos de software.
Garantia de consistncia: garantir a consistncia entre a anlise dos requisitos de sistema e a
anlise dos requisitos de software. Essa consistncia deve ser mantida por meio do
estabelecimento e manuteno da rastreabilidade entre os requisitos de sistema e os requisitos
de software.
Avaliar e atualizar os requisitos de software: avaliar os requisitos junto ao cliente, aprovando as
mudanas e atualizando os requisitos de especificao de software.
Comunicar os requisitos de software: estabelecer mecanismos de comunicao para
disseminao dos requisitos de software, atualizando os mesmos para todas as partes que
forem precisar.

No contexto de manuteno de software, os requisitos so freqentemente de incluso
de novas funcionalidades ou de adaptaes nas j existentes. Assim, supondo que o atual
software esteja com relativa estabilidade, modificaes precisam ser cuidadosamente
consideradas, j que no verdade que uma alterao no software sempre garantir que ele
estar melhor adequado realidade da organizao. Problemas como efeito cascata de
alteraes, que geram problemas em outros mdulos do sistema, precisam ser considerados. A
anlise de requisitos em muitas situaes pode encontrar outros meios de atender
necessidade do cliente sem exigir mudana no software (o software normalmente tem
recursos que so desconhecidos ao cliente). Nesse ponto necessrio um servio de suporte
eficiente da organizao que desenvolve e mantm o produto, para que possam ser percebidas
as situaes nas quais recursos pouco conhecidos do software podem ser utilizados, evitandose assim manutenes desnecessrias.
O prximo processo considerado o de teste de software, conforme mostrado no

quadro 5.4.
86
QUADRO 5.4: ENGENHARIA: PROCESSO DE TESTE DE SOFTWARE

Processo: Teste de Software
Objetivos: Confirmao de que o produto de software integrado est de acordo com os
requisitos previamente definidos.
(i)
Critrio de integrao de software definido para demonstrar a conformidade com

os requisitos de software;
(ii)
O software integrado verificado usando-se o critrio criado;
(iii)
Os resultados dos testes so registrados;
(iv)
Uma estratgia de regresso definida para ser usada para re-testar o software
quando uma alterao em seus itens for realizada.
Tarefas necessrias
Desenvolvimento de testes para o produto de software integrado: descrever os testes a serem

efetuados no produto de software integrado, indicando os requisitos sendo checados, entrada de
dados e critrio de verificao. O conjunto de testes deve mostrar conformidade com os
requisitos de software.
Teste do produto de software integrado: teste do produto de software utilizando-se o critrio
estabelecido, registrando os resultados. Atualizao da documentao quando necessrio.
Teste de regresso do produto de software integrado: desenvolver uma estratgia de testes de
regresso para re-testar o software integrado. Se mudanas forem feitas nos itens de software,
proceder com os testes de regresso conforme critrio estabelecido.

Testes de manutenes efetuadas, principalmente em sistemas legados (normalmente
softwares de grande porte e com estrutura e documentao comprometidas), representam uma
dificuldade grande para a disponibilizao de um produto estvel. Esse fato torna o
planejamento de testes fundamental para evitar que ocorram muitas idas e voltas do software
ao ambiente de produo do cliente, em razo de erros.
Quando a manuteno ocorre em um software que ainda no constitui um sistema
legado, como aqueles em pleno processo de crescimento e agregao de novas
funcionalidades, a importncia dos testes acentuada principalmente no quesito de
integrao. Testar um pequeno mdulo, ou uma pequena funcionalidade alterada, pode ser
simples e realizado pelo prprio programador, porm no momento da integrao que o
efeito cascata de uma alterao com problemas pode gerar situaes futuras indesejadas.
Garantir que o produto de software integrado funcione por completo o mnimo esperado
pelos clientes. Se a organizao falha continuamente nesse ponto, a desconfiana do cliente
no software logo verificada.
87
Finalmente, o ltimo processo considerado no grupo de processos de engenharia o

de manuteno de software e sistema. No quadro 5.5 esse processo descrito.
QUADRO 5.5: ENGENHARIA: PROCESSO DE MANUTENO DE SOFTWARE E SISTEMA
Processo: Manuteno de Software e Sistema
Objetivos: Modificao de um sistema/produto de software aps entrega ao cliente, para corrigir
falhas, melhorar o desempenho ou outros atributos, ou ainda adapt-lo para um ambiente
modificado.
(i)
Uma estratgia de manuteno desenvolvida para gerenciar modificaes,

migraes e retirada de produtos de acordo com a estratgia adotada;
(ii)
Identificao do impacto das mudanas no sistema/software existente para a

organizao, operaes ou interfaces;
(iii)
Documentao de sistema/software afetada atualizada conforme necessrio;
(iv)
Produtos modificados so desenvolvidos com testes associados que demonstram

que outros requisitos no esto comprometidos;
(v)
Produtos atualizados so migrados para o ambiente do cliente;
(vi)
Via requisio, produtos so retirados de uso de uma maneira controlada que

minimize os distrbios para o cliente;
(vii)
O sistema/software modificado comunicado a todas as partes afetadas.

Tarefas necessrias
Desenvolvimento de uma estratgia de manuteno: desenvolver a estratgia para manuteno,

migrao e retirada de produtos de maneira consistente com os requisitos de manuteno,
comunicando a estratgia e possveis polticas de garantias.
Anlise de problemas do usurio e mudanas: analisar os problemas do usurio, suas
requisies e mudanas necessrias, avaliando o impacto de diferentes opes para modificar o
sistema ou software existente, interfaces e requisitos. Documentar a opo escolhida.
Implementar e testar modificaes: determinar quais produtos precisam ser mudados.
Implementar, testar e documentar as modificaes selecionadas, demonstrando que o sistema e
requisitos de software, bem como a integridade, no sero comprometidos com a alterao.
Atualizar o sistema do cliente: migrar o sistema e software atualizados para o ambiente do
cliente. Prover conforme apropriado: notificao dos planos de migrao e atividades, operao
paralela do antigo e do novo sistema e necessidades de treinamento. Proceder com uma
atividade de ps-operao para revisar e assegurar o impacto da modificao.
Retirada do produto de software: seguindo aprovao, retirar o sistema obsoleto do ambiente do
usurio, provendo conforme apropriado: notificao dos planos de retirada e atividades,
operao paralela com a troca de sistemas, converso de dados para o sistema novo,
arquivamento do sistema e dados, treinamento de usurios e suporte.
Comunicar modificaes: estabelecer mecanismos de comunicao para prover a disseminao
das modificaes de sistema/software a todas as partes afetadas.
88

A previso, pela norma, de um processo especfico para manuteno de software, vem
diretamente ao encontro dos propsitos deste trabalho. Uma poltica de manuteno focada no
entendimento da dinmica da atividade significa economia de tempo e reduo de custos.
As tarefas da norma buscam conscientizar a organizao de que a manuteno no
pode ser uma tarefa subsidiria dentro da empresa, sendo acionada ocasionalmente quando
necessria, sem um planejamento e acompanhamento maior. A razo disso a sua
caracterstica de atividade inevitvel. praticamente impossvel imaginar um software que
funcionar em uma empresa dinmica sem necessidade de modificaes e de incluso de
novas funcionalidades.
Uma observao importante sobre esse processo refere-se novamente necessidade de
avaliar a real necessidade do cliente, mantendo para isso um meio eficiente de comunicao e
um conhecimento sobre o negcio dele (ainda que pontual).
5.3.2 Grupo de Processos de Operao

Um total de 2,9% dos problemas de manuteno de software foi classificado em processos
pertencentes ao grupo de processos de operao, sendo somente um processo desse grupo
referenciado. O processo referenciado foi o de suporte ao cliente, conforme apresentado no
quadro 5.6.
QUADRO 5.6: OPERAO: PROCESSO DE SUPORTE AO CLIENTE
Processo: Suporte ao Cliente
Objetivos: Estabelecimento e manuteno de um aceitvel nvel de servios atravs de
assistncia e consultoria ao cliente para dar apoio ao uso efetivo do produto.
(i)
Identificao e monitorao dos servios necessrios para o suporte ao cliente;
(ii)
Avaliao da satisfao do cliente tanto com relao ao suporte oferecido como com
relao ao produto;
(iii)
Suporte operacional oferecido atravs do tratamento das questes do cliente,

incluindo suas novas requisies;
(iv)
As necessidades de suporte do cliente so conhecidas por meio do oferecimento de

servios apropriados.
Tarefas necessrias
Estabelecer suporte do produto: estabelecer um servio por meio do qual o cliente possa
apresentar problemas e questes encontradas no uso do produto e receber ajuda para
solucion-los.
89
Prover treinamento dos usurios: oferecer treinamento e documentao ao usurio, de forma

que o produto possa ser eficientemente utilizado.
Monitorar o desempenho: monitorar o desempenho operacional do produto, de forma a estar
ciente dos problemas que podem impactar no nvel de servio.
Determinar o nvel se satisfao do cliente: determinar o nvel de satisfao do cliente com os
produtos e servios oferecidos.
Comparar a satisfao do cliente: comparar e monitorar o nvel obtido de satisfao do cliente
com as indstrias do setor e, quando possvel, com os concorrentes diretos.

Prover suporte efetivo ao produto de software tornou-se um fator bsico de
competitividade. Diante dessa realidade, e considerando que muitos dos problemas com
operao de software esto relacionados ao desconhecimento do usurio em relao maneira
correta de utilizar o software, planejar e administrar a forma como o servio ser oferecido
representa caracterstica bsica de uma organizao que comercializa e mantm produto de
software.
No contexto de manuteno de software, o papel do suporte ao produto tem grande
importncia no sentido de evitar necessidades de mudanas. Pessoal de suporte bem treinado
pode ser extremamente til para oferecer alternativas ao usurio, evitando manutenes
freqentemente desnecessrias.
5.3.3 Grupo de Processos de Gerncia

Um total de 47,1% dos problemas de manuteno de software foi relacionado aos processos
do grupo de gerncia. Esse foi o grupo que mais apresentou problemas associados, e isso vem
ao encontro dos resultados encontrados no estudo de caso apresentado, que aproxima os
problemas de questes mais de ordem gerencial do que de ordem tcnica.
O primeiro processo desse grupo o de alinhamento organizacional, conforme
descrito no quadro 5.7.
QUADRO 5.7: GERNCIA: PROCESSO DE ALINHAMENTO ORGANIZACIONAL
Processo: Alinhamento Organizacional
Objetivos: Capacitao dos processos de software necessrios organizao para prover
produtos de software e servios, de forma que fiquem consistentes com seus objetivos de
negcios.
(i)
Definio dos objetivos de negcios da organizao;

(ii)
90
Definio de seu framework de processos, que inclui uma srie de processos de

software necessrios para alcanar os objetivos de negcios da organizao;
(iii)
Elaborao de uma estratgia para definio, implementao e melhoria de

processos;
(iv)
A misso da organizao, seus valores principais, vises e objetivos so

apresentados a todos os funcionrios;
(v)
Comum viso da organizao pelos seus funcionrios, compartilhando o

entendimento dos objetivos de negcios para que possam realizar suas funes
eficientemente;
(vi)
Cada indivduo na organizao deve entender seu papel para alcanar os objetivos
de negcios e avaliar se est apto a cumprir esse papel.
Tarefas necessrias
Desenvolver uma viso estratgica: desenvolver uma viso estratgica para a organizao, que
seja capaz de identificar os objetivos de negcios e sua relao com funes de engenharia de
software e de sistemas.
Definir o framework de processos: identificar os processos que precisam ser executados para
que seja possvel alcanar os objetivos de negcios.
Prover comprometimento gerencial: prover suporte gerencial para a aplicao e melhoria
estratgica de processos.
Comunicar a viso e objetivos: explicar a viso e objetivos estratgicos da organizao para
todos os indivduos que trabalhem para ela, utilizando mecanismos adequados de comunicao
e gerenciamento.
Garantir o compartilhamento de uma viso comum: garantir que cada indivduo da organizao
compreenda a viso comum e se comprometa a cumprir sua funo individual com eficincia.
Permitir participao ativa: permitir que cada indivduo contribua para se alcanar os objetivos
de negcios e apresentar iniciativas de melhoria de processos.

A postura gerencial, como em todos os demais processos envolvidos no ciclo de vida
de software, tem papel fundamental na atividade de manuteno. Um nico funcionrio de
desenvolvimento preocupado em produzir software com alta manutenibilidade dificilmente
conseguir apoio dos demais programadores e analistas, sem o devido suporte gerencial.
Desenvolver software com alta manutenibilidade algo de natureza estratgica e, portanto,
deve partir da conscincia dos altos administradores, como uma postura global da
organizao.
Para complementar o papel da gerncia no contexto de manuteno de software, as
decises afetas ao planejamento e aos objetivos de longo prazo sobre o software no devem
ser mantidas de forma fechada entre os membros da cpula da organizao, mas, pelo
contrrio, devem ser compartilhadas com as suas equipes, deixando claro ao
desenvolvedor/mantenedor a sua importncia e contribuio para o propsito maior do
91
software em que trabalha. Viso diferenciada para equipes de desenvolvimento e de

manuteno o principal ponto a se evitar.
O prximo processo do grupo de gerncia o de gerncia organizacional, apresentado

no quadro 5.8.
QUADRO 5.8: GERNCIA: PROCESSO DE GERNCIA ORGANIZACIONAL
Processo: Gerncia Organizacional
Objetivos: Estabelecimento e controle de prticas de gerenciamento de software durante a
execuo dos processos necessrios ao provimento de produtos/servios de software.
(i)
Investimento em infra-estrutura de gerenciamento adequada;
(ii)
Identificao das melhores prticas para apoiar a implementao do gerenciamento

efetivo da organizao e de seus projetos;
(iii)
Constituio de uma base para avaliao da conquista ou no dos objetivos de

negcios da organizao.
Tarefas necessrias
Identificar a estrutura de gerenciamento: identificar a infra-estrutura de gerenciamento

apropriada para a execuo de prticas de gerenciamento de software que forem consistentes
com os objetivos de negcios da organizao.
Investir em infra-estrutura de gerenciamento de software: investir na infra-estrutura apropriada
de gerenciamento de software, segundo o escopo amplo da organizao.
Identificar as prticas de gerenciamento de software: identificar efetivas prticas de
gerenciamento de software para apoiar a organizao e a implementao de software.
Avaliar a efetividade: avaliar a efetividade das prticas de gerenciamento de software
implementadas para alcanar os objetivos de negcios da organizao.
Prover suporte para a adoo das melhores prticas: utilizar abordagens de incentivo e infraestrutura de gerenciamento de software para apoiar a implementao de prticas de
gerenciamento, registrando-se as melhores para disseminao na organizao, como parte de
seus bens.

Citar a adoo de prticas modernas de gerncia organizacional, bem como o uso de
ferramentas e meios de monitorao do desempenho global tanto das pessoas como dos
demais recursos de infra-estrutura, parece ser desnecessrio, uma vez que isso j a realidade
de organizaes competitivas. Porm, no desnecessrio afirmar que mesmo em um
ambiente controlado e adaptado, problemas surgem, e no contexto de manuteno de software
92
eles podem representar um entrave para a efetivao de outros processos, como o alinhamento
organizacional citado no processo anterior.
Os problemas de manuteno de software relacionados com o processo de gerncia
organizacional so totalmente de natureza humana e relacionados com a tradicional postura de
valorizao, muitas vezes absoluta, do desenvolvimento frente a manuteno de software.
Todavia, no seria justo acusar a organizao que adota tal postura como incapaz de visualizar
e entender de maneira ampla seu negcio de software. Essa postura clssica, e resultante da
prpria histria de evoluo da engenharia de software, vem agora gradativamente sendo
alterada, sendo que a velocidade dessa alterao depende muito de uma anlise cuidadosa dos
objetivos de mdio e longo prazo de cada organizao.
Na seqncia, o prximo processo relevante dentro do grupo de gerncia o de

gerncia de projeto, conforme mostrado no quadro 5.9.
QUADRO 5.9: GERNCIA: PROCESSO DE GERNCIA DE PROJETO
Processo: Gerncia de Projeto
Objetivos: Identificao, estabelecimento, coordenao e monitorao de atividades, tarefas e
recursos necessrios a um projeto para produzir um produto ou servio no contexto de requisitos
e limitaes.
(i)
Definio do escopo de trabalho para o projeto;
(ii)
Verificao das possibilidades de execuo do projeto com os recursos disponveis

e limitaes impostas;
(iii)
Estimativa das tarefas e dimensionamento dos recursos necessrios;
(iv)
Identificao e monitoramento de interfaces necessrias entre elementos do projeto

e entre outros projetos e unidades organizacionais;
(v)
Desenvolvimento e implementao de planos para a execuo do projeto;
(vi)
Monitorao do progresso do projeto e elaborao de relatrios;
(vii)
Tomada de aes de correo de desvios quando objetivos no forem alcanados.

Tarefas necessrias
Definio do escopo do trabalho: definir o trabalho necessrio ao cumprimento do projeto.

Definio do ciclo de vida do projeto: definir o ciclo de vida e estratgia de desenvolvimento para
o projeto, que deve ser apropriado ao seu contexto, escopo e complexidade.
Avaliao da possibilidade de execuo do projeto: avaliar as possibilidades de se alcanar os
objetivos do projeto, diante dos recursos e limitaes existentes.
Determinar e manter estimativas para os atributos do projeto: definir e manter conjuntos de
atributos validados por etapas de projeto (atributos podem incluir: negcios e objetivos de
93
qualidade do projeto, estimativas de tamanho e complexidade, esforo necessrio e oramento).

Definio de tarefas e atividades do projeto: identificar atividades e tarefas de projeto de acordo
com o ciclo de vida, definindo ainda as dependncias entre elas.
Definio de necessidades de experincia, conhecimento e habilidades: identificar a experincia
e habilidades necessrias ao projeto, e aplic-las para selecionar indivduos e equipes.
Definio de cronograma: alocar recursos para as atividades e determinar a seqncia e
cronograma de execuo das atividades ligadas ao projeto.
Identificar e monitorar as interfaces de projeto: identificar e concordar com interfaces do projeto
com outros projetos ou com outras partes afetadas, monitorando os compromissos acordados.
Alocar responsabilidades: identificar as contribuies especficas de cada indivduo e de cada
grupo necessrias ao projeto, alocando suas responsabilidades especficas, e garantindo que os
comprometimentos foram entendidos e aceitos por todos.
Estabelecer o plano de projeto: definir e manter um plano mestre de projeto, bem como outros
planos relevantes, para cobrir o escopo e objetivos do projeto, seus recursos, infra-estrutura,
interfaces e mecanismos de comunicao necessrios.
Implementar o plano de projeto: implementar as atividades planejadas para o projeto,
registrando o status do progresso e reportando-o s partes afetadas.
Monitorar os atributos do projeto: monitorar o escopo do projeto, seu oramento, custos,
recursos e outros atributos necessrios, documentando desvios significativos que possam
ocorrer.
Revisar o progresso do projeto: relatar regularmente e revisar o status do projeto e seu
desempenho frente ao plano de projeto.
Agir para corrigir desvios: tomar aes quando os objetivos de projeto no forem alcanados,
para corrigir desvios com relao ao planejamento, prevenindo a recorrncia de problemas j
identificados.

Esse foi o processo com maior quantidade de problemas de manuteno de software
associados, apesar de ser um tema tradicional em administrao. Aparentemente, os
problemas resultantes de uma gerncia falha de projetos so bem conhecidos em todos os
contextos, no sendo exclusivos de manuteno de software. Como exemplos tm-se a falta
de comprometimento com cronogramas, falta de suporte da gerncia, sobrecarga de tarefas e
estimativa de prazos no condizentes com a complexidade do trabalho. Isso mostra que apesar
da teoria estar evoluda, preciso um controle muito prximo no dia-a-dia para se evitarem
tais problemas comuns.
No contexto de manuteno de software, no entanto, alguns outros problemas se
sobressaem e esto intimamente ligados ao trabalho com software. Entre eles est a conhecida
idia falsa de que contratar novos integrantes para uma equipe que trabalha com
desenvolvimento ou manuteno de software trar mais agilidade ao processo. Isso pode ser
verificado no problema da contratao de temporrios que leva diminuio do controle
94
sobre a atividade de manuteno. Esse problema se une ao do software no ser visto pela
gerncia como um produto que precisa, ainda durante o desenvolvimento, ter a manuteno
trabalhada. A unio desses dois problemas revela um outro: a falta de conhecimento sobre o
processo de software como um todo. E aqui vale uma observao prtica importante: no se
podem atribuir a gerentes de projetos que no so de software, tarefas de gerncia de projetos
de software, sem assegurar que estes conheam as peculiaridades inerentes ao trabalho com
software e seu ciclo de vida.
O processo seguinte, gerncia de qualidade, apresentado no quadro 5.10.

QUADRO 5.10: GERNCIA: PROCESSO DE GERNCIA DE QUALIDADE
Processo: Gerncia de Qualidade
Objetivos: Alcanar a satisfao do cliente, por meio da monitorao da qualidade dos produtos
ou servios, a nvel organizacional e de projeto, para assegurar que esto de acordo com os
requisitos.
(i)
Estabelecimento dos objetivos de qualidade com base nos requisitos explcitos e

implcitos do cliente;
(ii)
Definio de uma estratgia completa de desenvolvimento para alcanar os

objetivos definidos;
(iii)
Implantao de um sistema de gerenciamento de qualidade;
(iv)
Execuo de atividades de controle e garantia de qualidade, avaliando-se seu

desempenho;
(v)
Monitorao do desempenho com relao aos objetivos de qualidade;
(vi)
Tomada de providncias quando objetivos de qualidade no forem alcanados.

Tarefas necessrias
Estabelecer objetivos de qualidade: estabelecer objetivos de qualidade para o produto e

processo, preferencialmente de forma quantitativa, baseando-se nos requisitos de qualidade do
cliente, e considerando-se tambm aqueles implcitos relevantes ao ambiente desse cliente.
Definir estratgia global: definir uma estratgia global, incluindo os recursos e responsabilidades,
bem como os objetivos a serem alcanados e a contnua melhoria da qualidade.
Definir critrios de qualidade: definir padres, referncias e mtricas que iro assegurar e
verificar o alcance dos objetivos de qualidade, bem como definir o critrio de aceitao que ir
ajudar a decidir quando objetivos de qualidade foram ou no alcanados.
Estabelecer um sistema de gerenciamento de qualidade: estabelecer e manter um sistema de
gerenciamento de qualidade para planejar, implementar, monitorar e controlar aes preventivas
e corretivas.
Avaliar o cumprimento de objetivos de qualidade: revisar regularmente o atendimento de
objetivos, no nvel mais alto de gerenciamento, usando os critrios definidos.
95
Tomar aes corretivas ou preventivas: tomar aes corretivas e preventivas, em nvel de

organizao e projeto, quando os objetivos de qualidade no forem alcanados.
Coletar resultados: coletar o retorno do cliente, do projeto, dos processos e das pessoas, para
verificar a contnua melhora da qualidade tanto na organizao como no projeto.

De uma maneira geral, quase todos os problemas de manuteno de software
poderiam ser reduzidos ou evitados com o controle da qualidade. Especificamente na
classificao adotada, o problema da ausncia de manuteno preventiva se relacionou com a
gerncia da qualidade, pelo fato da norma prever para esse processo a tomada de aes
corretivas e preventivas, que vem ao encontro da idia de buscar antever problemas em um
produto de software, procedendo-se com sua correo ou ajuste.
fato conhecido que na prtica muitas vezes a garantia da qualidade prejudicada por
questes como tempo curto e restries financeiras. No entanto, isso mais uma questo
cultural do que de limitao real. Por exemplo, se existe limitao financeira para o projeto,
razovel pensar que se deva produzir exatamente o que o cliente deseja (idia de verificao)
e de forma correta (conceito de validao), evitando problemas futuros com correes e
modificaes perfeitamente evitveis.
Dentro de manuteno de software, a garantia da qualidade deve estar enquadrada
como objetivo estratgico da organizao e disseminada da gerncia para os funcionrios de
nvel operacional. a postura gerencial e a conscincia de equipe que leva a produo de
trabalhos com qualidade. Parece razovel pensar que se o foco for a qualidade da manuteno,
problemas como a ausncia de adoo de padres ou treinamento inadequado da equipe de
manuteno poderiam deixar de figurar na lista de problemas de manuteno de software.
Por fim, o ltimo processo considerado no grupo de gerncia o de gerncia de

riscos, conforme mostrado no quadro 5.11.
QUADRO 5.11: GERNCIA: PROCESSO DE GERNCIA DE RISCOS
Processo: Gerncia de Riscos
Objetivos: Identificao, anlise, tratamento e monitorao de riscos de projeto continuamente.
(i)
Determinao do escopo do gerenciamento de riscos;
(ii)
Definio e implementao da apropriada estratgia de gerenciamento de riscos;
(iii)
Identificao dos riscos conforme se desenvolvem ao longo da conduo do projeto;

(iv)
96
Determinao dos recursos de tratamento dos riscos com base na anlise e

priorizao dos mesmos;
(v)
Implementao do correto tratamento para evitar o impacto do risco, baseando-se

na prioridade e probabilidade de sua ocorrncia.
Tarefas necessrias
Estabelecer o escopo do gerenciamento de riscos: determinar o escopo do gerenciamento de

riscos a ser implementado, observando-se as polticas de gerenciamento de riscos da
organizao.
Definir as estratgias de gerenciamento de riscos: definio das apropriadas estratgias,
anlises, tratamentos e monitoramento de riscos, sempre em relao organizao e ao
projeto.
Identificar os riscos: identificar os riscos do projeto, inicialmente com relao estratgia de
projeto, e posteriormente, com os que surgirem durante a conduo do projeto.
Analisar os riscos: analisar os riscos para determinar prioridades e quais recursos de
monitoramento aplicar.
Definir e executar aes de tratamento de riscos: para cada risco ou conjunto de riscos
semelhantes, definir e executar aes apropriadas para reduzi-los a um nvel aceitvel.
Monitorar os riscos: monitorar o estado corrente de cada risco e assegurar a efetividade das
aes de tratamento.
Tomar aes corretivas: tomar aes corretivas apropriadas para reduzir ou evitar o impacto de
cada risco, quando verificado que o tratamento de risco no est atingindo o progresso previsto.

fato conhecido que riscos so circunstncias inerentes a qualquer projeto. A
diferena entre um desastre ou a definio de uma alternativa quando um risco ocorre est no
planejamento e nas formas controle que se estabeleceu sobre a possibilidade dos mesmos
ocorrerem.
Dada a caracterstica de ser normalmente impossvel prever se um risco ocorrer e
quando ocorrer, somente resta valer-se da verificao de dados histricos, ou mesmo do uso
de heursticas, para determinar quais os riscos potenciais conhecidos e ento estabelecer
formas de reao a eles caso ocorram.
Dentro do contexto de manuteno de software, foi possvel listar pelo menos quatro
riscos muito comuns, perante os quais possvel adotar medidas de conteno. Percebe-se que
o problema da elevada rotatividade dos profissionais ligados manuteno pode ser reduzido
com programas de motivao e de justo trato de recursos humanos. J o problema das
mudanas freqentes de prioridades por parte dos clientes pode ser combatido com a
definio e execuo de aes de tratamento de riscos, conforme sugere uma das tarefas da
norma.
97
Por fim, os ltimos dois riscos que se transformam em problemas de manuteno de

software so ligados a questes tcnicas, como a m qualidade do cdigo-fonte original e a
baixa qualidade da documentao. A exemplo dos demais riscos, o estudo prvio de como
reagir a eles a nica preparao com a qual a organizao pode contar, sendo que nesses
dois ltimos casos, uma possvel preparao seria o acordo antecipado com o cliente sobre a
possibilidade de se rever os prazos estabelecidos.
5.3.4 Grupo de Processos de Recursos e Infra-estrutura

Um total de 23,5% dos problemas de manuteno de software foi relacionado a problemas
com a ausncia de observncia dos processos desse grupo, colocando-o em uma posio
bastante relevante para o contexto de problemas de manuteno de software.
O primeiro processo que mereceu destaque nesse grupo foi o de gerncia de recursos
humanos, conforme mostrado no quadro 5.12.
QUADRO 5.12: RECURSOS E INFRA-ESTRUTURA: PROCESSO DE GERNCIA DE RECURSOS HUMANOS
Grupo de Processos de Recursos e Infra-estrutura
Processo: Gerncia de Recursos Humanos
Objetivos: Prover organizao, e aos seus projetos, os indivduos que possuam habilidades e
conhecimentos para cumprir eficientemente seus papis, trabalhando em grupos coesivos.
(i)
Identificao e contratao dos indivduos com as habilidades e competncias

requeridas;
(ii)
Suporte efetiva interao entre indivduos e grupos;
(iii)
Fora de trabalho capaz de utilizar suas habilidades para compartilhar informaes

e coordenar suas atividades eficientemente;
(iv)
Definio de critrios objetivos para monitorar o desempenho de cada grupo e

indivduo, para o provimento de retorno e melhoria de desempenho.
Tarefas necessrias
Identificar as habilidades e competncias necessrias: identificar e avaliar habilidades e

competncias necessrias para atingir os objetivos da organizao.
Determinar o critrio de avaliao: definir critrio objetivo que possa ser usado para avaliar
candidatos e assegurar desempenho da equipe.
Recrutar pessoal qualificado: estabelecer um programa sistemtico para recrutamento de
pessoal qualificado que se encaixe nas necessidades da organizao.
Desenvolver habilidades e competncias: definir e prover oportunidades de desenvolvimento de
habilidades e competncias.
Definir a organizao de equipes de projeto: definir a estrutura e regras de operao sobre as
quais as equipes trabalharo.
98
Motivar equipes de projeto: motivar equipes para a execuo de seus trabalhos, assegurando
que todos tm: (i) entendimento do seu trabalho, (ii) uma viso de comum interesse, (iii)
mecanismos apropriados de comunicao e trabalho, (iv) suporte da gerncia no que o indivduo
estiver executando.
Manter interaes entre equipes de projeto: obter e manter um acordo no gerenciamento de
interaes entre equipes.
Avaliar desempenho: avaliar o desempenho de pessoal, tanto individualmente como por
equipes, no que se refere s suas contribuies aos objetivos da organizao como um todo.
Assegurar que os fatos levantados sero discutidos com o pessoal.
Prover retorno sobre o desempenho: prover retorno s pessoas, referente aos resultados de
avaliaes efetuadas.
Manter registros de pessoal: manter registros adequados de pessoal, incluindo no apenas
detalhes pessoais, mas tambm informaes a respeito de habilidades, treinamentos
completados e avaliaes de desempenho.

Os problemas de manuteno relacionados a esse processo podem ser vistos como um
reflexo da postura clssica das organizaes: a ateno voltada quase exclusivamente para o
desenvolvimento de software.
Uma caracterstica importante da postura organizacional que se relaciona tanto com
esse processo, como com o de treinamento, conforme apresentado no prximo quadro,
refere-se estratgia de manter os profissionais mais experientes, e com maior conhecimento
sobre o software, em tarefas de desenvolvimento, reservando aos novatos as tarefas de
manuteno. Essa postura evidencia o desprestgio da tarefa de manuteno pela gerncia o
que justifica diretamente um dos problemas associados a esse processo, o problema da
preferncia dos profissionais por trabalhos de desenvolvimento. Percebe-se aqui, novamente,
um problema cultural funcionando como fonte para problemas de manuteno.
Nesse sentido, a gerncia de recursos humanos deve ser considerada no contexto de
manuteno de software, e no de forma genrica, isso devido s caractersticas diferenciadas
que essa atividade apresenta em face de outros tipos de projetos no de software. Um dos
pontos a considerar com cuidado o de avaliar a possibilidade de maiores benefcios em se
colocar profissionais mais experientes em tarefas de manuteno e no novatos recm
contratados.
O prximo processo a ser estudado refere-se ao processo de treinamento, conforme

mostrado no quadro 5.13.
99
QUADRO 5.13: RECURSOS E INFRA-ESTRUTURA: PROCESSO DE TREINAMENTO

Processo: Treinamento
Objetivos: Prover a organizao, e seus projetos, de indivduos que possuam as habilidades e
conhecimentos necessrios execuo de seus papis eficientemente.
(i)
Treinamentos so desenvolvidos ou adquiridos para atender s necessidades de

treinamento tanto da organizao como de projeto;
(ii)
Treinamentos so conduzidos para assegurar que todos os indivduos possuam as

habilidades necessrias para executar suas tarefas, usando mecanismos como
estratgias de treinamento e materiais.
Tarefas necessrias
Desenvolver a estratgia para treinamento: desenvolver a estratgia de treinamento, incluindo

como as necessidades de treinamento sero identificadas, como os treinamentos necessrios
sero desenvolvidos ou adquiridos, e como os treinamentos sero realizados.
Identificar necessidades de treinamento: identificar e avaliar habilidades e competncias para
prover e melhor-las atravs de treinamentos.
Desenvolver ou adquirir treinamentos: desenvolver ou adquirir treinamentos que representem
necessidades comuns de treinamento.
Preparar para a execuo do treinamento: identificar e preparar a execuo das sesses de
treinamento, incluindo disponibilidade de materiais e de pessoal a ser treinado.
Treinar o pessoal: treinar o pessoal para possurem conhecimento e habilidades necessrias
execuo de seus papis.
Manter registros de treinamentos: manter adequado registro de treinamentos completados.
Avaliar efetividade do treinamento: identificar e avaliar o valor adicionado oferecido por cada
sesso de treinamento, incluindo a avaliao do material de treinamento utilizado.

Os problemas de manuteno associados a esse processo so o treinamento
inadequado da equipe de manuteno e o fato de os mantenedores lamentarem por no
possurem contato com o estado-da-arte da tecnologia. Percebe-se aqui que a valorizao da
atividade de manuteno poderia diminuir ambos os problemas: por um lado entendendo-se o
papel importante da manuteno de software, o problema da falta ou inadequao do
treinamento seria atacado diretamente, com o surgimento de programas de treinamento
especficos e focados nas peculiaridades da atividade. Por outro lado, a questo do no
contato com o estado-da-arte tambm seria reduzido.
O problema do no contato com o estado-da-arte algo relativo. Hoje um mantenedor
afirma isso, por exemplo, porque no est em contato com a linguagem de programao da
100
moda ou a ltima metodologia para desenvolvimento gil. Tal fato se deve valorizao do
desenvolvimento. Porm, se a manuteno passar a ser outro ponto forte de ateno, a pessoa
encarregada de tarefas de manuteno ter a possibilidade de estar em contato com tcnicas e
ferramentas que so estado-da-arte, mas da manuteno. Por exemplo, tm-se as tcnicas
modernas de decompilao, as ferramentas de recuperao de documentao etc. Dessa forma
o no contato com o estado-da-arte representa uma alegao referente aos artefatos utilizados
em desenvolvimento, uma vez que infelizmente ainda so pouco conhecidos aqueles possveis
de serem utilizados em manuteno.
O prximo processo considerado no grupo de recursos e infra-estrutura o de

gerenciamento do conhecimento, conforme mostrado no quadro 5.14.
QUADRO 5.14: RECURSOS E INFRA-ESTRUTURA: PROCESSO DE GERENCIAMENTO DO CONHECIMENTO
Processo: Gerenciamento do Conhecimento
Objetivos: Garantia de que o conhecimento individual, informaes e habilidades sejam
coletados, compartilhados, reusados e melhorados atravs da organizao.
(i)
Infra-estrutura estabelecida e mantida para o compartilhamento de informao

atravs da organizao;
(ii)
Conhecimento disponibilizado e compartilhado atravs da organizao;
(iii)
A organizao selecionar a apropriada estratgia de gerenciamento do

conhecimento.
Tarefas necessrias
Estabelecer um sistema de gerenciamento do conhecimento: estabelecer e manter uma infraestrutura de gerenciamento do conhecimento, bem como mecanismos para suportar as
atividades de identificar, classificar, exportar e usar o conhecimento.
Criar uma rede de contribuidores de conhecimento: estabelecer uma rede de especialistas
provendo sua natural interao.
Desenvolver uma estratgia de gerenciamento do conhecimento: definir uma estratgia
apropriada de gerenciamento do conhecimento baseada em necessidades organizacionais,
individuais, de domnio e de projetos.
Capturar o conhecimento: identificar e registrar cada item de conhecimento de acordo com a
classificao estabelecida e critrio de disseminao.
Disseminar a propriedade do conhecimento: compartilhar o conhecimento com especialistas,
usurios e projetistas.
Melhorar o conhecimento disponvel: validar e enriquecer o conhecimento armazenado,
assegurando sua adequao aos valores da organizao.
101

Manuteno de software uma tarefa imprevisvel. Isso resulta no fato de que nem
sempre possvel aplicar a ela tcnicas pr-moldadas tpicas de processos de
desenvolvimento. Nesse sentido, cada manuteno pode se tornar uma fonte de novos
conhecimentos e novas descobertas heursticas.
justamente esse conhecimento derivado de manutenes passadas que deve ser
preservado e, principalmente, disseminado entre pessoas e equipes diferentes. Essa ao pode
gerar economia de tempo e de recursos, acelerando a liberao das alteraes para o cliente.
Infelizmente, notou-se que um dos problemas de manuteno apontados refere-se justamente
perda ou no disseminao de conhecimentos adquiridos com os demais membros
interessados da organizao. Isso pode ser evitado com a construo de sistemas internos
paralelos de apoio, dedicados a armazenar e disponibilizar esse tipo de informao.
Por fim, o ltimo processo desse grupo que recebe destaque o processo de infraestrutura, mostrado no quadro 5.15.
QUADRO 5.15: RECURSOS E INFRA-ESTRUTURA: PROCESSO DE INFRA-ESTRUTURA
Processo: Infra-estrutura
Objetivos: Manter a infra-estrutura confivel e estvel, uma vez que necessria para o apoio
do desempenho de qualquer outro processo.
(i)
Definio dos requisitos de infra-estrutura necessrios;
(ii)
Identificao e especificao dos elementos de infra-estrutura;
(iii)
Aquisio dos elementos de intra-estrutura;
(iv)
Implementao dos elementos de infra-estrutura.

Tarefas necessrias
Identificar o escopo do processo de infra-estrutura: identificar os procedimentos, padres,

ferramentas e tcnicas que o processo de infra-estrutura deve apoiar.
Definir os requisitos do processo de infra-estrutura: definir os requisitos de infra-estrutura para
apoiar o desempenho dos processos relacionados. Pode incluir: (i) segurana, (ii) facilidades de
acesso remoto, (iii) backup e recuperao de dados, (iv) requisitos de manuteno, etc.
Adquirir e prover processo de infra-estrutura: adquirir e prover um processo de infra-estrutura,
que satisfaa aos requisitos.
Estabelecer o processo de infra-estrutura: reunir e integrar os elementos do processo de infraestrutura, provendo um ambiente efetivo que apie a implementao dos processos da
organizao.
102
Prover apoio para o processo de infra-estrutura: prover suporte para aqueles que utilizam o
processo de infra-estrutura.
Manter o processo de infra-estrutura: realizar manuteno no processo de infra-estrutura com o
propsito de corrigir defeitos e melhorar o desempenho.

O processo de infra-estrutura no contexto de conteno e preveno de problemas de
manuteno de software se destaca no sentido de fornecer ferramentas e ambiente
diferenciado para manuteno.
Normalmente, o que ocorre nas empresas a unio, em um mesmo ambiente
computacional, de ferramentas e atividades de desenvolvimento e manuteno, o que causa
freqentemente problemas com sobreposio de arquivos, perda de modificaes e
propagao de falhas. A soluo para esses problemas no se resume em adotar um software
de controle de verso. A soluo precisa incluir uma separao entre desenvolvimento e
manuteno e principalmente processos para se conduzir ambas as atividades.
conhecida a relativa dificuldade de se unir um projeto modificado com o projeto
paralelo em desenvolvimento. Isso porque no mesmo instante em que um software esteja
sendo modificado em um determinado ponto, ele pode estar em desenvolvimento por outra
equipe, agregando-se funcionalidades novas, no necessariamente solicitadas pelos clientes,
mas como forma de sofisticao e complementao do software original. Nesse momento
surge a dificuldade de unir eventualmente mesmos arquivos modificados em locais diferentes.
Situaes como essas devem ser analisadas e amparadas por ferramentas atravs de um
processo de infra-estrutura.
5.3.5 Grupo de Processos de Gerncia de Configurao

Um total de 11,8% dos problemas de manuteno de software foi relacionado m
implementao de processos do grupo de processos de gerncia de configurao. So trs os
processos desse grupo que merecem destaque nesse contexto.
O primeiro processo, documentao, apresentado no quadro 5.16.
QUADRO 5.16: GERNCIA DE CONFIGURAO: PROCESSO DE DOCUMENTAO
Grupo de Processos de Gerncia de Configurao
Processo: Documentao
Objetivos: Desenvolvimento e manuteno do registro de informaes produzidas por um
processo.

(i)
103
Desenvolvimento da estratgia para identificao da documentao que ser

produzida durante o ciclo de vida de um produto ou servio;
(ii)
Identificao dos padres a serem aplicados para o desenvolvimento da

documentao;
(iii)
Identificao da documentao a ser produzida pelo processo ou projeto;
(iv)
O contedo e propsito de toda documentao especificado, revisado e aprovado;
(v)
Documentao desenvolvida de acordo com os padres definidos;
(vi)
Documentao mantida de acordo com os critrios definidos.

Tarefas necessrias
Desenvolver a estratgia de gerenciamento da documentao: determinar a estratgia de

gerenciamento da documentao, que deve indicar o que deve ser documentado a cada estgio
do ciclo de vida do produto/servio.
Estabelecer padres para documentos: estabelecer padres para desenvolver, modificar e
manter documentos.
Especificar requisitos de documentos: especificar os requisitos para os documentos, como ttulo,
data, identificao, verso, autores, revisores, propsito, lista de distribuio etc.
Identificar os documentos a serem produzidos: para qualquer ciclo de vida, identificar os
documentos a serem produzidos.
Desenvolver os documentos: desenvolver os documentos requeridos ao ponto corrente do
processo, de acordo com os padres e poltica estabelecidos.
Checar os documentos: revisar os documentos antes da distribuio e autoriz-los antes de
cada distribuio/atualizao.
Distribuir os documentos: distribuir os documentos de acordo com as formas de distribuio
determinadas, confirmando o recebimento quando necessrio.
Manter os documentos: manter os documentos atualizados de acordo com a estratgia de
documentao empregada.

A documentao de software uma das tarefas mais trabalhosas em manuteno de
software. Isso porque cada manuteno individual deve ser documentada, e o projeto do
software como um todo atualizado. O desenvolvimento de documentos padronizados e
processos formais de atualizao de documentao podem no ser viveis para manutenes
corriqueiras e de pequeno porte. Enfrentar um processo burocrtico a cada pequena
manuteno acaba desestimulando a execuo dessa atividade e conseqentemente levando
progressiva desatualizao da documentao do projeto.
Cada organizao deve avaliar o produto de software que desenvolve do ponto de vista
da documentao, estabelecendo-se uma maneira prtica de manter essa documentao
atualizada. O interessante facilitar no caso de pequenas manutenes, reservando somente s
104
de grande porte processos mais formais de construo e atualizao de documentos.

Novamente o uso de sistemas internos de apoio uma alternativa favorvel.
O prximo processo a receber ateno nesse grupo o de gerncia de configurao,

conforme mostrado no quadro 5.17.
QUADRO 5.17: GERNCIA DE CONFIGURAO: PROCESSO DE GERNCIA DE CONFIGURAO
Processo: Gerncia de Configurao
Objetivos: Estabelecimento e manuteno da integridade dos itens de um processo (como
exemplo, um mdulo do produto de software em desenvolvimento), tornando-os disponveis s
partes interessadas.
(i)
Desenvolvimento de uma estratgia de gerenciamento de configurao;
(ii)
Itens/produtos gerados por um processo ou projeto so identificados, definidos e

confirmados;
(iii)
Modificaes e atualizaes nos itens/produtos so controladas;
(iv)
Modificaes e atualizaes so disponibilizadas a todas as partes afetadas;
(v)
O status e modificaes dos itens/produtos so registrados e reportados;
(vi)
A completude e consistncia dos itens/produtos so asseguradas;
(vii)
O armazenamento, manipulao e entrega dos itens/produtos controlado.

Tarefas necessrias
Desenvolver a estratgia de gerenciamento de configurao: determinar a estratgia de

gerenciamento de configurao, incluindo as atividades e cronograma.
Identificar os itens de configurao: identificar os itens de configurao que precisam ser
individualmente armazenados, testados, revisados, usados, alterados, entregues e mantidos.
Estabelecer a estrutura e hierarquia de arquivo e diretrios: prover meios eficientes de acesso e
armazenamento de entidades necessrias.
Estabelecer baselines: estabelecer as baselines internas e de entrega, que devem armazenar
todos os itens configurados necessrios ao estgio respectivo do projeto (obs.: uma baseline
representa um pacote de itens validados e considerados de acordo com os propsitos do
projeto).
Manter a descrio dos itens de configurao: manter uma descrio atualizada de cada item de
configurao.
Controlar modificaes e atualizaes: estabelecer um mecanismo para registrar e atualizar os
itens.
Manter histrico de item de configurao: manter um histrico de cada item de configurao em
detalhamento suficiente para permitir recuperar toda verso anterior, quando necessrio.
Relatar status da configurao: relatar o status de cada item de configurao e seu
relacionamento com a atual integrao do sistema.
105
Verificar informaes sobre os itens configurados: verificar se a informao sobre os itens

configurados e suas estruturas, fornecidos pelo relatrio de status, est completa e assegurar
ainda a consistncia desses itens.
Gerenciar o backup, armazenamento, manipulao e entrega de itens de configurao:
assegurar a integridade dos itens configurados, bem como dos recursos de backup e
armazenamento. Controlar tambm a manipulao e entrega dos itens configurados.

A quantidade de arquivos modificados em uma manuteno, ainda que de pequeno
porte, pode ser grande. A esse fato inclui-se o problema de os mesmos arquivos poderem estar
sofrendo outras modificaes por parte da equipe de desenvolvimento. Esse apenas um dos
problemas que precisam ser tratados nesse processo, e est relacionado com a questo de
conciliar manuteno com desenvolvimento.
Outro fato ligado ao processo de gerncia de configurao o estabelecimento de
componentes e verses baselined. Se o produto de software est, de um lado, em evoluo
pela equipe de desenvolvimento e, por outro lado, em fase de adaptao e modificao por
equipe de manuteno, torna-se difcil e necessrio garantir uma forma de estabelecer e
armazenar verses testadas e confiveis do software como um todo. A ausncia de um
processo adequado pode levar a perda de cdigo e alteraes, bem como a entrega de verses
do software com novos problemas para o cliente.
Finalmente, o ltimo processo a ser destacado o de gerncia de solicitaes de

mudana. Esse processo mostrado no quadro 5.18.
QUADRO 5.18: GERNCIA DE CONFIGURAO: PROCESSO DE GERNCIA DE SOLICITAES DE MUDANA
Processo: Gerncia de Solicitaes de Mudana
Objetivos: Assegurar que as solicitaes de mudana sejam gerenciadas, monitoradas e
controladas.
(i)
Desenvolvimento de uma estratgia de gerenciamento;
(ii)
Requisies de mudana so identificadas e registradas;
(iii)
Dependncias e relaes com outros pedidos de mudana so identificadas;
(iv)
Definio de critrios para confirmao da implementao de mudanas;
(v)
Priorizao de requisies de mudana e estimativas de recursos necessrios;
(vi)
Aprovao de mudanas com base na prioridade e disponibilidade de recursos;
(vii)
Mudanas aprovadas so implementadas;
(viii)
Possibilidade de conhecimento do status de todos os pedidos de mudana.
106
Tarefas necessrias
Desenvolver uma estratgia de gerenciamento de mudanas: estabelecimento de uma
estratgia de gerenciamento de mudanas para assegurar que as mudanas possam ser
descritas, registradas, analisadas e implementadas.
Registrar os pedidos de mudanas: cada requisio de mudana deve ser unicamente
identificada e registrada.
Registrar o status dos pedidos de mudana: requisies de mudana devem possuir um status
associado para permitir facilidade no monitoramento.
Estabelecer as dependncias e relaes com outros pedidos: identificar o relacionamento do
pedido de mudana com outros pedidos para estabelecer suas dependncias (por exemplo,
mudanas no mesmo componente de software ou mudanas requisitadas para uma futura
verso j planejada do software).
Avaliar o impacto da mudana: avaliar o impacto da mudana, os recursos e os potenciais
benefcios resultantes.
Identificar as atividades de verificao e validao necessrias: antes de implementar a
mudana, o escopo das atividades de verificao e validao correspondentes deve ser
identificado.
Aprovar as mudanas antes de implementao: todas as mudanas devem ser aprovadas antes
da implementao.
Incluir mudana em cronograma: as mudanas aprovadas devem ser agendadas para
implementao.
Revisar a mudana implementada: todas as mudanas devem ser revisadas aps
implementao e antes de serem concludas, de modo a garantir que tiveram os efeitos
desejados e atingiram os objetivos.

Mudanas talvez seja a palavra mais presente no contexto de manuteno de software
e mudanas podem surgir em um volume muito grande, o que depender do estgio de
evoluo do software e do domnio ao qual atende. A prtica mostra que quando o volume de
solicitaes de mudana grande, inmeros outros problemas surgem derivados desse fato.
Um processo adequado de gerncia de solicitaes de mudana deve ser capaz de
filtrar o que de fato resultar em uma alterao no produto de software e o que pode ser
resolvido por outros meios ou valendo-se de recursos j existentes e pouco conhecidos do
software. Alm de saber separar o que mesmo necessrio do que mero preciosismo do
usurio, esse processo deve atentar-se especialmente para a questo da priorizao dos
chamados. Isso porque o usurio normalmente ir solicitar alteraes em cima de alteraes e
a probabilidade de se perder o controle do que est sendo feito alta. Uma dica aqui
estabelecer um mecanismo de comunicao eficiente com o usurio, preferencialmente
atravs de um sistema paralelo ao qual o usurio possa consultar e que possa tambm ser
usado pela organizao para expor dificuldades e possveis sobreposies de chamados
107
considerados urgentes, deixando claro ao cliente os fatos que justificam a negao ou

adiamento de uma determinada manuteno.
5.4 Propostas na Literatura

Alguns autores que se dedicaram a pesquisar problemas de manuteno de software tambm
mostraram propostas de solues ou de reduo desses problemas.
As solues apresentadas so semelhantes e pode-se dizer que esto muito bem
resumidas e apresentadas em Dart et al. (2001), que organizou suas propostas de interveno
nos problemas de manuteno em trs grandes grupos: recomendaes quanto a processos,
quanto a pessoas e quanto a ferramentas.
Propostas quanto aos processos:
Reexaminar polticas corporativas luz de ferramentas CASE;
Enfatizar a importncia de garantir que todo cdigo esteja completamente e

cuidadosamente documentado;
Discernir as diferenas de necessidades entre projetos de manuteno e projetos de

novos softwares;
Implantar filosofia de projeto-para-manuteno;
Planejar apropriadamente o tempo em cronogramas que incluam documentao e

testes;
Promover os sucessos anteriores com relatrios de lies aprendidas;
Instituir e reforar prticas de garantia de qualidade;
Investigar porque a comunicao interna na organizao ocasionalmente torna-se

ineficiente;
Melhorar as interaes dos clientes com os desenvolvedores e mantenedores;
Melhorar a seleo de fornecedores e monitorar processos, planos de estratgia e

tomadas de decises.
Propostas quanto s pessoas:
Disseminar
conhecimento
relativo
ao
estado-da-arte
de
ferramentas
conhecimentos;
Associar pessoas a papis particulares (exemplo: testes) para projetos e oferecer

suporte corporativo a esses papis;
108
Encorajar as pessoas mais experientes para se tornarem mantenedores;
Melhorar o prestgio das tarefas de manuteno;
Melhorar a comunicao entre grupos por meio de recursos diversos (quadros,

ferramentas eletrnicas etc.), registrando-se a experincia individual e inter-projetos,
elegendo-se algum para organizar e promover essa comunicao;
Tornar mais efetivo o treinamento, especialmente com relao ao uso de ferramentas,

padres e documentao;
Estabelecer um recurso de consulta a informaes tcnicas para suporte da gerncia.
Propostas quanto s ferramentas:
Investir em ferramentas mais efetivas, principalmente aquelas que suportarem

engenharia reversa, reengenharia, testes, gerncia de configurao e documentao;
Encorajar fornecedores a construrem ou adaptarem suas ferramentas, especialmente

para suportarem as necessidades da organizao;
Melhorar a qualidade das ferramentas desenvolvidas internamente;
Avaliar novas ferramentas e determinar a sua aplicabilidade em projetos especficos;
Melhorar as atividades e uso de ferramentas que centralizem comunicao entre

projetos;
Encontrar solues de ferramentas que suportem plataformas heterogneas da

organizao (quando houver);
Encorajar o pessoal tcnico para freqentemente comunicarem suas necessidades de

ferramentas gerncia superior.

Os exemplos de solues possveis para os problemas de manuteno de software
apresentados neste captulo, principalmente os derivados da interpretao das recomendaes
da norma, mostram como pode ser extenso e detalhadamente tratado o assunto.
Nesse sentido, este captulo representa um documento de que existem maneiras de se
tratar os problemas de manuteno de software, residindo na cultura organizacional o
principal entrave para se atacar de forma ampla as dificuldades. Certamente a formao
acadmica de seus funcionrios, voltada para a conscientizao da importncia da
manuteno de software e das alternativas de resposta aos seus problemas, levaria a uma
predisposio maior para a mudana organizacional.
CAPTULO
6
Caractersticas do Ensino
.
Dentre as atividades previstas no ciclo de vida de software, a manuteno a que possui a
menor ateno e conseqente incipincia em seu ensino (Dias, 2004), apesar de no ser uma
atividade nova, j que o seu surgimento est relacionado ao surgimento dos primeiros
softwares (Zvegintzov & Parikh, 2005).
Para ensinar manuteno de software, alm de conhecer profundamente essa atividade
fundamental saber o que vem sendo feito pela comunidade cientfica no intuito de transmitir
o conhecimento a respeito. Essa compreenso pode ser til para a extrao de recomendaes
do que deve ser aperfeioado e tambm de erros que j foram identificados, de forma a poder
propor solues no absolutamente novas, mas baseadas em correes de erros e melhoria dos
acertos de experincias anteriores.
6.2 Panorama do Ensino de Engenharia de Software

Contando com mais de trinta anos de existncia, a engenharia de software ainda uma rea de
estudo recente, tendo alguns de seus tpicos sem consenso entre a comunidade de
pesquisadores, no possuindo um corpo de conhecimento estabilizado (Castro et al., 2000).
Ensinar engenharia de software vem sendo um desafio atravs dos anos e dados
mostram que ainda existe uma grande carncia de qualidade na forma como os softwares so
desenvolvidos. Isso pode ser comprovado por uma estatstica relativamente recente que indica
Captulo 6 Caractersticas do Ensino de Manuteno de Software
110
que 40 a 50% dos softwares de usurio apresentam defeitos no-triviais (Boehm & Basili,
2001).
Um dos problemas de ensinar engenharia de software est ligado vasta quantidade de
termos e conceitos, o que pode resumir uma disciplina de engenharia de software em uma
disciplina de termos e conceitos de engenharia de software (Stiller & LeBlanc, 2002). Ainda
segundo a viso desse autor, necessrio que exista um projeto prtico para prover um
contexto para os termos e conceitos, pois caso contrrio os alunos no retero o contedo de
maneira apropriada.
De acordo com Soares (2005), fatores relacionados com a questo tcnica
(metodologias, linguagens etc.) em engenharia de software esto mais amadurecidos do que
aqueles ligados a caractersticas sociais (como trabalho em equipe), sendo necessria a unio
desses fatores para um ensino adequado da disciplina.
Diversas so as propostas para ensino de engenharia de software, algumas
preocupadas essencialmente com a forma de ensinar, enquanto outras com o contedo a
ensinar, como exemplificado a seguir:
Em Tomayko (1987), distinguem-se quatro modos em que esta disciplina pode ser
ministrada: aulas expositivas; aulas expositivas e seminrios; aulas expositivas e
estudos de casos com pequenas equipes; aulas expositivas e estudos de casos com
grandes equipes, de quinze a trinta alunos, sendo o professor o gerente da equipe.
Em Silva et al. (2003), professores apresentam uma experincia de ensino da

disciplina usando a metodologia gil XP (Beck, 1999) e buscando enfocar a
implementao baseada em web, com ferramentas como PHP, HTML e XML.
Em Hazzan e Dubinsky (2003), demonstra-se a preocupao em se tratar as questes

humanas do desenvolvimento de software.
A questo de ensino de engenharia de software como disciplina no isolada exposta
por Ghezzi e Mandrioli (2005) ao dizer que a engenharia de software precisa ser ensinada de
forma atrelada ao seu contexto. Isso significa que o engenheiro de software deve no apenas
conhecer tcnicas de engenharia de software, mas tambm linguagens de programao,
algoritmos e estrutura de dados, banco de dados, sistemas operacionais, etc., que estaro ainda
ligados ao ambiente para o qual o software for ser desenvolvido (organizao comercial,
indstria, sistema de misso crtica etc.). Em suma, o ensino de engenharia de software deve
abordar, na medida do possvel, assuntos muito diversos.
Os conhecimentos necessrios a um engenheiro de software, de acordo com Ghezzi e
Mandrioli (2005), esto relacionados ao domnio amplo de:
Fundamentos tericos da disciplina;
Mtodos de projeto;
Tecnologia e ferramentas.
111
Alm disso, o profissional precisa ter habilidades para:
Manter seu conhecimento a respeito de novas abordagens e tecnologias;
Interagir com outras pessoas (freqentemente de culturas diferentes);
Entender, modelar, formalizar e analisar um novo problema;
Reconhecer problemas recorrentes e reusar ou adaptar solues conhecidas;
Gerenciar processos e coordenar o trabalho de pessoas diferentes.

Uma observao importante se refere ao fato de que algumas dessas habilidades
somente podem ser totalmente entendidas fora do ambiente acadmico, ou seja, com a prtica
no mundo real. Aqui possvel um paralelo com o ensino de manuteno de software, que
guarda tambm essa caracterstica de total aprendizado somente com a prtica, o que vem a
reforar os objetivos deste trabalho, quando tenta aproximar problemas da prtica com a
teoria acadmica.
6.3 Questes sobre o Ensino de Manuteno de Software

O ensino de manuteno de software na indstria e dentro do meio acadmico, por meio de
disciplina especfica, est recebendo ateno crescente. No geral, na quase totalidade dos
casos, o enfoque das universidades est em ensinar desenvolvimento de software, incluindo a
manuteno como um item dentro do desenvolvimento, muitas vezes recebendo pouca nfase.
Dias (2004) explica que o enfoque em desenvolvimento dentro do meio acadmico
uma postura tendenciosa, e que considera a manuteno como parte do processo de
desenvolvimento, ou em outros casos quando o processo de desenvolvimento proposto
iterativo, a cada iterao a atividade de manuteno aparece.
Criar uma forma explcita de abordar a manuteno de software dentro de
universidades uma deciso que vem sendo tratada com cautela. Cardow (1992) j havia
apresentado trs razes pelas quais se justificava o adiamento do ensino de manuteno: (i)
essa rea um subconjunto de um grande corpo de conhecimento, que adequadamente cobre
o tpico; (ii) no h interesse suficiente para se preocupar com o estudo desse curso; (iii) no
existe uma quantidade suficiente de material para apresentar. Ele complementa que a viso at
ento era de que a manuteno representava uma continuao do processo de
112
desenvolvimento de software e que no necessitaria de uma ateno maior.

No entanto, nesse mesmo trabalho, Cardow mostra que essa viso errnea, j que o
desenvolvimento sempre produz software com necessidade de manuteno, em funo de
mudanas de requisitos, escolhas erradas de projeto ou m interpretao do mesmo e ainda
por ser a atividade de testes muitas vezes reduzida por limitaes de tempo e custos.
O interesse didtico com manuteno de software, por sua vez, tambm existe, como
Cardow explica por estudos realizados naquela poca junto ao exrcito americano e na
indstria em geral, bem como atualmente pela existncia de congressos destinados
exclusivamente a tratar essa questo.
Por fim, a afirmao de que a quantidade de material existente no suficiente para
elaborar um curso tambm no deve ser considerada vlida, pois existe uma quantidade
crescente de bons artigos apresentados em congressos e eventos especficos de manuteno de
software ou no, ao redor do mundo, bem como diversas pesquisas.
A dificuldade, portanto, est centrada no contedo a ser ensinado. Esse contedo deve
ser suficientemente fundamentado em resultados de situaes reais e no puramente
acadmicas. Assim, alm dos conceitos tericos bsicos, o ensino deve acatar dificuldades
persistentes verificadas na indstria.
6.4 Padres de Currculo para Cursos de Computao

No Brasil, a Sociedade Brasileira de Computao14 (SBC), uma organizao que fomenta e
desenvolve pesquisa cientfica na rea da computao. Ela estabelece alguns planos
pedaggicos recomendados para cursos de graduao na rea de computao. Mais
especificamente, so propostos planos de ensino para os cursos de Licenciatura em
Computao, Bacharelado em Engenharia de Computao, Bacharelado em Sistemas de
Informao e Bacharelado em Cincia da Computao, que so os nomes padronizados pela
instituio para os cursos de graduao na rea pelo pas.
Para o curso de Licenciatura em Computao, Dahmer et al. (2002) explica que o
objetivo formar professores, especialistas da rea de computao, capazes de tratar os
contedos da cincia da computao, nos anos finais do ensino fundamental (5 a 8 sries) e
mdio, podendo abordar esses contedos de forma integrada ou no a outras disciplinas, ou
tratados como projetos, temas transversais ou atividades colaborativas.
O plano da disciplina organizado por matrias que possuem disciplinas que cobrem
total ou parcialmente uma matria.
14
http://www.sbc.org.br
113
Analisando a grade curricular proposta para esse curso, verifica-se que o total de horas
previsto para a matria engenharia de software de 210 horas, sendo representado por apenas
uma disciplina. O termo manuteno de software no aparece, de forma que se algo nesse
sentido ensinado, isso dever ser feito dentro da nica disciplina oferecida, e ser muito
ligado viso do professor que ministrar essa disciplina, de forma que o enfoque em
manuteno poder ser variado, ou at no existir.
Para o curso de Bacharelado em Engenharia de Computao, Teixeira et al. (2002)
explica que o objetivo formar recursos humanos para o desenvolvimento e aplicao de
tecnologias da computao no controle de processos e automao industrial. O currculo
proposto para esse curso reserva um total de 680 horas para a matria de engenharia de
software, distribudas por oito disciplinas. Fica claro um enfoque bem maior em engenharia
de software quando comparado com o curso de licenciatura. O plano de engenharia de
computao considera que o egresso poder exercer atividades de manuteno de software e
dentro da disciplina Mtodos e Ferramentas de Engenharia de Software apresenta, como um
dos objetivos, capacitar o aluno no uso de mtodos e ferramentas para manuteno de
software.
No curso de Bacharelado em Sistemas de Informao, Costa et al. (2000) explica que
o objetivo do curso a formao de profissionais para atuao em planejamento, anlise,
utilizao e avaliao de modernas tecnologias de informao aplicadas s reas
administrativas e industriais, em organizaes pblicas e privadas.
Por se tratar de um curso que oferece uma viso de administrao de empresas e
sistemas de informao, esperava-se que esse pudesse ser o curso mais propenso em ensinar
manuteno de software por meio de uma disciplina especfica, isso porque o egresso poder
deparar-se com situaes onde precisar decidir sobre o futuro de sistemas legados, por
exemplo, determinando sua descontinuidade ou manuteno. Porm, esse fato no se
verificou. O curso reserva um total de 432 horas para a matria engenharia de software,
distribudas em quatro disciplinas. Em nenhuma delas est previsto explicitamente o ensino
de manuteno de software. A disciplina de Engenharia de Software Aplicada prev exercitar
com o aluno o ciclo de vida de software, subentendendo-se que a atividade de manuteno
possa ser mesclada nessa disciplina, novamente estando dependente do perfil do professor que
a ministrar.
Finalmente, no curso de Bacharelado em Cincia da Computao, fechando os quatro
cursos de computao definidos pela SBC, Ferreira et al. (2001) explica que o objetivo
formar recursos humanos para o desenvolvimento tecnolgico da computao. Nesse curso,
144 horas so reservadas para a matria engenharia de software, distribudas em duas
114
disciplinas. Apesar de o curso prever a capacitao do egresso para resolver problemas de

manuteno de software, em nenhuma das disciplinas o ensino explicitamente previsto.
Novamente, vale o que foi dito para os cursos anteriores, o ensino de manuteno de software
poder ser mesclado nas disciplinas previstas para engenharia de software, mas isso
depender do perfil do professor que ministrar as aulas, o que certamente implicar em
abordagens diferentes cada vez que as disciplinas forem ensinadas por professores com vises
diferentes.
No quadro 6.1 resumido o plano pedaggico para os quatro cursos descritos. So
relacionados os nomes dos cursos, as disciplinas para o tema engenharia de software e o total
de horas previsto para cada disciplina.
QUADRO 6.1: CURSOS DE COMPUTAO E DISCIPLINAS DE ACORDO COM A SBC
Curso
Disciplinas de
Engenharia de Software
Total de
Horas
Total
Geral
Licenciatura em Computao
210
210 h
Engenharia de Computao
Engenharia de Software I
Engenharia de Software II
Engenharia de Software III
Processo de Engenharia de Software
Mtodos e Ferramentas para Eng. de Soft.
Qualidade de Engenharia de Software
Tpicos Especiais em Eng. de Software
120
80
80
80
80
80
80
80
680 h
Sistemas de Informao
Engenharia de Software A
Engenharia de Software B
Engenharia de Software Aplicada
Tpicos Especiais em Eng. de Software
72
72
72
72
288 h
Cincia da Computao
Laboratrio de Engenharia de Software
72
72
144 h
Uma outra organizao, de importncia internacional, que tambm deve ser

considerada do ponto de vista de recomendaes curriculares, a Association for Computing
Machinery15 (ACM).
A ACM corresponde a uma organizao educacional e cientfica, dedicada ao avano
das artes, cincias e aplicaes de tecnologia de informao (Blasi, 1999).
Um dos objetivos da organizao desenvolver recomendaes curriculares, que pela
relevncia das publicaes acabam por influenciar o ensino acadmico na rea de computao
em muitas instituies ao redor do mundo (Rodriguez, 2004).
Em uma publicao (Shackelford et al., 2004) so discutidas as caractersticas de
planos de cursos de computao nos Estados Unidos, explicando o foco desses cursos antes
15
http://www.acm.org
115
de 1990 e aps essa data, na qual significativos avanos proporcionaram uma adaptao dos
currculos para os cursos de Engenharia de Computao, Cincia da Computao e Sistemas
de Informao. Tais avanos incluem a importncia atribuda ao tema de engenharia de
software dentro do contexto de cincia da computao.
A importncia que o tema engenharia de software assumiu a partir de 1990 nos
Estados Unidos est atrelada ao fato de que quanto mais a computao usada para abordar
quantidades crescentes de problemas complexos, criar software de confiana se torna mais
difcil. Na medida em que os problemas se tornam cada vez mais complexos, no possvel
que apenas uma pessoa entenda o software por completo, considerando ainda que diferentes
mdulos de um software possam precisar interagir de forma imprevisvel. O uso da
computao para tarefas crticas, que envolvam segurana de pessoas, tambm pode ser
considerado um dos fatores que influenciaram o desenvolvimento da engenharia de software.
De uma forma geral, o que foi possvel compreender era que produzir software
consistia em uma tarefa difcil, muito cara e muito necessria.
Segundo ainda o mesmo autor, a percepo de todos esses fatos fez com que a
engenharia de software se tornasse uma disciplina fundamental em cursos de computao,
sendo aplicada inicialmente em cursos de computao na Inglaterra e Austrlia durante a
dcada de 1980 e adotada mais tarde, durante a dcada de 1990, nos Estados Unidos.
Percebe-se que essa evoluo da engenharia de software contnua, e os currculos
propostos pela ACM j consideram a atividade de manuteno de software como uma
disciplina especfica.
A importncia da disciplina difere de acordo com o curso de computao em questo.
Para mostrar essa importncia relativa, Shackelford prope em seu trabalho uma escala de 0 a
5, que representa um ndice de nfase atribuda disciplina. O valor 5 (cinco) representaria a
mxima nfase possvel, enquanto 0 (zero) indicaria nenhuma relevncia dentro do curso
considerado. Para cada disciplina dentro de um curso, a escala diria qual a mnima e qual a
mxima nfase que a disciplina pode ter dentro do currculo do curso. Essa estipulao de
mximo e mnimo visa oferecer flexibilidade para a grade curricular como um todo, que
poderia variar as horas-aula dentro da faixa de mxima e mnima nfase de cada disciplina.
As nfases propostas para a disciplina de manuteno de software foram consideradas
para elaborar o quadro 6.2, no qual mostrada a distribuio dessas nfases para cada um dos
trs cursos de computao em questo.
116
QUADRO 6.2: NFASES SUGERIDAS PARA A DISCIPLINA DE MANUTENO DE SOFTWARE

Disciplina
Evoluo e Manuteno de Software
EC*
CC**
SI***
mn.
mx.
mn.
mx.
mn.
mx.
* EC = Engenharia de Computao, ** CC = Cincia da Computao, *** SI = Sistemas de Informao
Percebe-se pelos nmeros uma importncia maior dada ao tema no curso de

Engenharia de Computao (prev nfase de at 4 pontos).
Embora esses nmeros ainda possam representar um enfoque baixo, a proposta da
ACM j considera a manuteno de software como uma disciplina em cursos de graduao
em computao, e esperado que no Brasil tambm surjam recomendaes nesse sentido,
considerando a representatividade e influncia internacional da ACM.
6.5 Experincias com o Ensino de Manuteno de Software

As tentativas de ensinar manuteno de software no meio acadmico tm aumentado e alguns
exemplos so discutidos nesta seo.
Em seu trabalho, Andrews (Andrews & Lutfiyya, 2000) apresenta a descrio e os
resultados obtidos com a criao de um curso de manuteno de software de duas horas
semanais (com uma durao total de 26 semanas), em uma universidade canadense16 para
alunos de graduao.
Para esse curso, a metodologia escolhida consistia em trabalhar teoria e prtica com os
alunos, por meio de projetos prticos desenvolvidos durante a disciplina. Essa abordagem
envolvia dividir os alunos em grupos e cada grupo conduziria um projeto, que era motivado
pelos diferentes tipos de tarefas em manuteno de software.
Andrews explica que dentre os tipos de manuteno de software, o tipo manuteno
corretiva no era abordado pela disciplina, uma vez que os alunos j haviam tratado de
correes de erros em software em disciplinas anteriores. O foco estava em projetos que
priorizassem manutenes adaptativas e perfectivas (nota-se que manuteno do tipo
preventiva no era considerada).
Em um primeiro momento, os alunos organizaram-se em grupos de no mximo seis
alunos e a cada grupo foi atribudo um projeto. Tais projetos objetivavam, por exemplo,
adaptar software para uso em diferentes mquinas, escrever novos mdulos de modo que
esses mdulos fizessem comunicao com sistemas legados e ainda alguns projetos
envolviam entender e efetuar manutenes diversas em software-livres. No geral as atividades
16
University of Western Ontario (UWO).
117
de cada grupo consistiam em entender o cdigo-fonte, realizar instalao, implementar

pequenas caractersticas novas e a produo de relatrios para apresentao em sala de aula.
O autor descreve os problemas iniciais dessa abordagem, que envolveu o
cancelamento dos projetos de alguns grupos e a atribuio de novos. O cancelamento ocorreu
em funo dos softwares proprietrios em uso no poderem ser submetidos a algumas
atividades previstas na disciplina, como instalao. Outros problemas como m organizao
das equipes e falta de tempo para execuo completa dos projetos foram citados.
Finalmente, como resultados finais da experincia, os professores puderam constatar
que existia uma tendncia nos resultados apresentados no sentido de trabalhar atividade de
desenvolvimento e no de manuteno. Observaram que os temas de arquitetura de software e
padres de projeto deveriam ter sido apresentados aos alunos antes de iniciarem os projetos, j
que foi uma deficincia identificada nos trabalhos entregues.
O relato anterior foi publicado no ano 2000, o que mostra que a preocupao em
ensinar manuteno de software no absolutamente recente.
Em outro trabalho, dessa vez no Brasil, descrito a experincia obtida com a
implantao de uma disciplina de manuteno de software em um curso de ps-graduao lato
sensu17 (Dias, 2004).
Nesse curso, a disciplina de manuteno descrita com o objetivo de formar
profissionais para (i) exercer a gesto das manutenes de software, compreendendo e
avaliando as possibilidades de uso de tecnologias de ltima gerao no ambiente das
organizaes; (ii) realizar pesquisas tecnolgicas, na rea da gesto de manutenes de
software; e (iii) projetar, desenvolver e implantar projetos (diretamente relacionados com
manuteno de software), buscando neles seu estado da arte para propiciar incremento no
desempenho profissional em organizaes pblicas e privadas.
O escopo definido para a disciplina bem amplo e o autor descreve brevemente a
ementa estabelecida para buscar os objetivos propostos. Percebe-se que os assuntos da ementa
foram definidos com base nas experincias dos professores, em observaes gerais do
ambiente organizacional e na teoria clssica de engenharia de software.
A disciplina proposta tem durao de 20 horas, distribudas em quatro aulas
expositivas. Nesse perodo apresentado, por exemplo, a classificao dos tipos de
manuteno de software (corretiva, adaptativa, perfectiva, preventiva), e a cada aula, os
alunos recebem um artigo em cima do qual devem preparar um relatrio para a aula seguinte,
destacando: resumo da essncia do artigo, principais problemas apontados pelo autor,
principais solues consideradas e quais os questionamentos mais relevantes que surgem da
17
Gesto de Tecnologias da Informao.
118
discusso do tema. A disciplina introduziu ainda o uso de uma lista de discusso via internet,
para discusses de assuntos relevantes ao tema.
Entre os resultados, obtidos por meio de uma pesquisa com os egressos da disciplina,
verificou-se que 50% dos alunos no tinham conhecimento da importncia do tema, 100%
disseram que passaram a se interessar pelo tema, 62,5% iniciaram a definio de um processo
de manuteno em seu ambiente de trabalho; ocorreu um acrscimo de 18,18% no uso de
ferramentas CASE para apoiar essa atividade; houve um crescimento de 14,29% em termos
de controle gerencial dessa atividade; 33,33% dos alunos presenciaram a criao de um setor
ou grupo especfico para administrar as manutenes em suas empresas; 100% concordaram
com a relevncia do tema; e 100% julgaram a disciplina realmente necessria para o curso.
Um resultado interessante do relato anterior a constatao da relevncia que os
egressos deram ao tema e as iniciativas de aplicao de conceitos tericos de manuteno de
software na prtica.

Definir o contedo a ser abordado em uma disciplina de engenharia de software ainda no
um consenso entre os professores. Por ser um tema extremamente extenso, surgem focos ora
em um ponto, ora em outro. No entanto, de uma forma geral, sabe-se ensinar engenharia de
software nas universidades, em funo tambm da prpria experincia e cultura que j se
adquiriu em torno do tema.
De maneira semelhante, o ensino de manuteno de software corresponde a outro
ponto de divergncias em relao ao ensino, que diferentemente da engenharia de software
como um todo, ainda no possui um histrico de experincias que sustentem uma ou outra
forma de ensinar.
Tendncias internacionais apontam que o ensino de manuteno de software de forma
especfica, por meio de uma disciplina, no deve tardar a fazer parte de currculos de cursos
de computao. Nesse sentido, buscar o melhor contedo a ensinar um desafio ao qual este
trabalho se prope a ajudar, em uma tentativa de evitar que um contedo adequado demore a
surgir dentro do meio acadmico. O objetivo trazer idias que facilitem a formao
adequada de profissionais aptos a lidar com manuteno de software mais facilmente.
CAPTULO
7
Perspectivas para uma Disciplina
.
Neste captulo so resumidas as propostas de resposta aos problemas de manuteno de
software em diretrizes para a elaborao de uma disciplina especfica sobre o assunto no meio
acadmico. O objetivo apresentar caminhos que orientem quais pontos devem ser
considerados com cuidado em uma futura implementao prtica da disciplina.
A experincia do autor com manuteno de software representa uma caracterstica
favorvel no momento de tecer indicaes do contedo a ser abordado pela disciplina, pois
permite confrontar o aprendizado que adquiriu nessa rea durante seu curso de graduao com
a experincia prtica desde ento obtida com manuteno de software.
Relativamente ao aprendizado durante a graduao, notvel a viso limitada que foi
formada, pois apenas em alguns momentos dentro de disciplinas de desenvolvimento de
software esse contedo foi abordado. De fato, ao experimentar os problemas reais no dia-a-dia
de organizaes que produzem e mantm produtos de software em constante evoluo, foi
sensvel a deficincia em entender alguns pontos. Primeiramente, existiu a deficincia em
perceber a importncia que a manuteno de software pode representar para a organizao,
obrigando-a a tratar o assunto de maneira independente e sistmica. Em segundo lugar, no
foi imediata a percepo do perigo de se criar uma falta de credibilidade da organizao frente
aos seus clientes, uma vez que reiteradamente problemas relacionados a alteraes de
software no fossem resolvidos ou fossem de maneira insatisfatria.
Captulo 7 Perspectivas para uma Disciplina de Manuteno de Software
120
J durante seu programa de ps-graduao, o autor teve contato mais aprofundado

com o tema de manuteno de software, quando cursou disciplinas que focaram qualidade de
software e processo de software, incluindo de maneira mais pausada e detalhada, a dinmica e
problemtica da atividade, principalmente podendo confrontar a estrutura de normas e
processos para desenvolvimento com aquelas para manuteno.
A unio de todos esses fatores com a compreenso dos problemas exposta at aqui
possibilitou a elaborao deste captulo.
7.2 Viso Pedaggica

As idias que envolvem as diretrizes para o ensino de manuteno de software esto cunhadas
em um conceito pedaggico apresentado por Nunes (2005), focado na resoluo de
problemas. Essa abordagem pode ser utilizada para a elaborao de planos pedaggicos e
fundamenta-se na verificao de quais problemas os egressos de um determinado curso se
deparam quando ingressam no mercado de trabalho.
As formas tradicionais utilizadas para o projeto de planos pedaggicos so chamadas
de abordagem orientada a competncias e habilidades e abordagem orientada a contedos.
Zarifian (2001) explica que na abordagem orientada a competncias e habilidades, o
projetista do plano pedaggico procura visualizar as funes que o egresso precisar exercer,
preocupando-se, portanto, com o desenvolvimento das habilidades que sero necessrias para
isso. Essas funes podem ser tanto aquelas tradicionais, como outras criadas mais
recentemente, em decorrncia de progresso tecnolgico. Nunes revela que muitas das funes
tradicionais esto apresentadas na Classificao Brasileira de Ocupaes (CBO)18, como por
exemplo: (i) administrao de redes de computadores; (ii) administrao de bases de dados;
(iii) anlise de sistemas etc. Cada uma dessas funes engloba capacidades que os egressos
devem possuir, como o conhecimento de certas ferramentas, devendo o plano pedaggico
oferecer o conhecimento necessrio. Ainda segundo esse autor, trata-se de uma abordagem
focada no mercado de trabalho, estando detalhada no texto de Zarifian e sugerida no Conselho
Nacional de Educao (CNE)19.
Especificamente sobre manuteno de software, existe uma breve referncia nas
descries da CBO referente s atividades do analista de sistemas, porm na estrutura
chamada de tabela de atividades (nome dado pela CBO), nada aparece. A tabela de atividades
da profisso de analista de sistemas e afins pode ser visualizada no apndice B.
18
19
http://www.mtecbo.gov.br.
Parecer n.: CNE/CES 583/2001 - www.mec.gov.br.
121
Os cursos no Brasil que seguem a abordagem de orientao a competncias e

habilidades so aqueles chamados de profissionalizantes, independentemente da modalidade:
bacharelado, seqenciais de formao especfica, tecnolgico e tcnico (Nunes, 2005).
De outro lado, a abordagem orientada a contedos ignora o mercado de trabalho,
centrando a formao dos alunos nas disciplinas bsicas de computao, principalmente
matemtica, computabilidade e algoritmos. Segundo essa viso, os egressos assim preparados
estaro aptos a atuar com criatividade, resolvendo qualquer problema de computao no
mercado de trabalho, sendo capazes ainda de produzir novas tecnologias. A idia que,
produzindo novas tecnologias (ferramentas), esses egressos vo demandar outros com
formao orientada por competncias e habilidades, formando um ciclo.
Existem defensores das duas abordagens, sendo essa ltima adotada pela ACM e
aplicada em seus computing curricula, orientao curricular para cursos de computao,
editados anualmente. No Brasil, o Ministrio da Educao e Cultura (MEC) tambm
recomenda em suas Diretrizes Curriculares da rea de Computao a mesma abordagem.
Finalmente, os currculos de referncia para cursos de computao da SBC, citados no
captulo anterior (item 6.4) tambm so construdos de acordo com a idia de orientao a
contedos.
Os cursos de computao que adotam a orientao a contedos no Brasil so
categorizados como acadmicos e normalmente so da modalidade bacharelado (Nunes,
2005).
Por fim, a terceira abordagem para planos pedaggicos vem diretamente ao encontro
das idias deste trabalho: abordagem orientada a problemas, ou seja, so os problemas
prticos que serviro de indicadores para a elaborao de um plano pedaggico.
A idia nessa abordagem especificar uma classe de problemas encontrada por
egressos, e a partir dela fixar os conhecimentos necessrios para o entendimento dos
problemas e conseqente resoluo dos mesmos. Conforme explica Nunes, a soluo dos
problemas pode ser complementada pela construo de ferramentas (de propsito geral ou
especfico, dependendo da classe de problemas).
No caso deste trabalho, a mesma idia utilizada, ou seja, a verificao de quais so
os problemas de manuteno de software que incidem no trabalho de profissionais dedicados
a essa tarefa, produzindo ento a classe de problemas sugerida pela metodologia. Tendo-se a
classe, o passo seguinte a fixao dos conhecimentos necessrios e a construo de
ferramentas. Neste trabalho, a fixao de conhecimentos e a construo de ferramentas se
fundiram na busca de solues e propostas para resoluo dos problemas de manuteno,
culminando com diretrizes para a elaborao de uma disciplina de manuteno de software.
122
Na abordagem de orientao a problemas, Nunes alerta que a idia pode apresentar

distores caso os problemas sejam muito especficos de certo domnio, o que fatalmente
levaria a solues aplicveis em um nico contexto.
Comparando-se novamente com o propsito deste trabalho, o alerta do autor parece
no ser preocupante, uma vez que os problemas de manuteno de software so normalmente
os mesmos para diferentes pocas e domnios, abrangendo, portanto, dificuldades comuns e
no especficas de uma aplicao.
7.3 Procedimentos para Disciplina de Manuteno de Software

Neste tpico apresentada a estrutura utilizada para expor os assuntos que se mostraram
indispensveis a uma disciplina de manuteno de software focada na resposta a problemas de
manuteno. Os subitens a seguir detalham essa estrutura.
7.3.1 Modelo Geral

Em sua ltima edio (maro de 2006), o computing curricula apresenta um corpo de
conhecimento em torno de currculos de cursos de computao, e o organiza hierarquicamente
em disciplinas, mdulos (essenciais e optativos) e tpicos.
De maneira semelhante, a proposta de contedo para uma disciplina de manuteno de
software obedece a uma hierarquia de mdulos e tpicos, como a sugerida pela ACM para
engenharia de software. Na figura 7.1 ilustrada essa hierarquizao.
FIGURA 7.1: ESTRUTURA HIERRQUICA ADOTADA PARA OS ASSUNTOS DA DISCIPLINA
Em um nvel inicial, tem-se a disciplina como um todo. No nvel imediatamente

seguinte surgem quatro mdulos considerados essenciais, e para cada mdulo existem
conceitos a serem tratados, apresentados na forma de tpicos que se baseiam em: a) nas
determinaes da norma ISO/IEC 12207 (levando-se em considerao o exposto no captulo
5), b) nos resultados do estudo de caso e c) nas recomendaes apresentadas no item 5.4. Os
tpicos representam os assuntos que so de fato o contedo que ser tratado junto aos alunos.
Os tpicos de cada mdulo se baseiam na abordagem pedaggica de orientao a
problemas, apresentado no item 7.2 deste captulo. Acredita-se que em razo da grande
123
importncia prtica da atividade, essa seja a abordagem mais correta, por basear-se no estudo
e entendimento dos problemas reais.
7.3.2 Estruturao de Mdulos

A especificao dos assuntos comea com a definio dos mdulos. Para isso, optou-se pela
definio de quatro grandes mdulos: Conceitos, Ambiente de Manuteno, Manutenibilidade
Durante o Desenvolvimento e Manuteno no Produto Final de Software. Cada um desses
mdulos descrito no quadro 7.1, expondo-se o nome de cada mdulo e seus objetivos gerais.
QUADRO 7.1: MDULOS PARA UMA DISCIPLINA DE MANUTENO DE SOFTWARE
M d u lo A : Conceitos
Objetivos
No mdulo inicial, conceitos, ocorre a aproximao inicial do aluno com o contedo que ser
abordado. Os tpicos desse mdulo visam oferecer uma viso geral e abrangente da
importncia e significado da matria. Isso inclui posicionar a manuteno de software dentro do
ciclo de vida de software, apresentar suas caractersticas, importncia prtica e principalmente
expor os problemas de manuteno. importante que desde o incio o aluno tenha contato com
a natureza de tais problemas, caracterizada pela incidncia maior de fatores de ordem gerencial
do que de ordem tcnica.
M d u lo B : Amb i en te d e Manu ten o
Objetivos
No mdulo relacionado ao ambiente de manuteno so apresentados os recursos necessrios
ao cumprimento com sucesso da atividade de manuteno, tanto no que se refere aos fatores
de infra-estrutura (ferramentas, recursos computacionais etc.), como aos fatores de ordem
gerencial, por exemplo, processos e administrao de pessoas. Um dos grandes focos o de
expor maneiras de tornar eficiente a comunicao, tanto interna como em relao aos clientes.
Aliado a isso, esse mdulo preocupa-se em mostrar que o registro e compartilhamento de
experincias de manutenes passadas com novos membros de equipe, ou mesmo com outras
equipes, indispensvel.
M d u lo C : M an u ten ib il i dad e D ur a n te o D es e nvo lv i me nto
Objetivos
No mdulo destinado manutenibilidade durante o desenvolvimento, o intuito maior o de
apresentar quais caractersticas precisam ser consideradas durante o desenvolvimento de
software, para que se produzam facilidades posteriores durante atividades de manuteno. Aqui
o apoio gerencial fundamental, sendo necessrio que a alta administrao da organizao
possua um entendimento abrangente das caractersticas do ciclo de vida de um software.
Termos chaves nesse mdulo so: documentao, verificao e validao e qualidade de
software.
M d u lo D : Man u ten o no Pro duto Fina l d e So ftwa re
Objetivos
No ltimo mdulo, focado na manuteno no produto final de software, algumas questes
fundamentais que apareceram no mdulo anterior so retomadas. Documentao, verificao e
validao e qualidade de software voltam em pauta, agora com uma viso diferente, focada na
alterao de um produto de software j pronto. So includas aqui novas questes gerenciais e
de equipe, como o problema da delegao de tarefas, administrao de riscos, controle de
mudanas, manuteno preventiva e principalmente anlise e estudos sobre a viabilidade das
mudanas e o impacto delas no sistema como um todo.
124
Uma vez que os mdulos e seus principais objetivos foram determinados, os tpicos
que cada um dever conter podem ser estabelecidos.
A especificao dos tpicos para cada mdulo feita de forma a apresentar o tpico e
a respectiva constatao que justificou sua existncia. Essa constatao est baseada nas
seguintes fontes:
Teoria fundamental e conceituao bsica necessria a qualquer disciplina;
Resultados do estudo de caso apresentado no captulo 3;
Resultados do estudo da relao de problemas de manuteno de software com as

recomendaes dos processos da norma ISO/IEC 12207, apresentado no captulo 5
(especificamente com base nas determinaes das tarefas de cada processo);
Sugestes de soluo de outros autores, conforme apresentado tambm no captulo 5;
Experincia pessoal do autor na rea de manuteno de software.

Os quatro itens a seguir detalham a estrutura de tpicos prevista para cada mdulo,
sendo que nas consideraes finais deste captulo feita uma anlise crtica da estrutura
apresentada.
7.3.3 Mdulo A Conceitos

O mdulo de conceitos, diferentemente dos demais, possui a maioria de seus tpicos
fortemente ligados apenas teoria fundamental e a conceituao bsica, em razo da
caracterstica que possui de introduo ao tema.
No quadro 7.2 so apresentados os tpicos e suas respectivas fundamentaes.
QUADRO 7.2: TPICOS DO MDULO A CONCEITOS
Tpico
Fundamentao
Ciclo de vida de software
(TF)
Os diferentes significados de manuteno de software
(TF)
Tipos de manuteno de software
(TF)
Importncia prtica sistemas legados
(TF)
Causas da evoluo do software
(TF)
Apresentao e caracterizao dos problemas
(TF), (EC), (OA)
Natureza dos problemas
(TF), (EC)
Legenda:
TF = Teoria Fundamental, EC = Estudo de Caso, OA = Outros Autores (vide item 5.4).
125
Cada tpico descrito, em termos de contedo a abordar, nos itens a seguir.
Ciclo de vida de software: os objetivos neste tpico incluem a apresentao do ciclo

de vida de software e de suas caractersticas gerais, destacando a fase de manuteno e
descontinuao de software. O intuito maior que o aluno perceba em que ponto se
encaixa o assunto que ser estudado.
Os diferentes significados de manuteno de software: o intuito principal neste tpico

diferenciar o significado do termo manuteno dentro do contexto de software e fora
dele, expondo as peculiaridades e abrangncia do termo quando aplicado a software.
Tipos de manuteno de software: neste tpico o objetivo mostrar as tradicionais

classificaes de manutenes (corretivas, adaptativas, perfectivas e preventivas), bem
como os conceitos de manuteno reativa e pr-ativa.
Importncia prtica sistemas legados: os objetivos neste tpico englobam a

apresentao do conceito de sistemas legados e das razes de sua manuteno e
necessidade de continuidade de operao, apresentando-se caractersticas desses
sistemas que dificultam a atividade de manuteno de software.
Causas da evoluo do software: exposio de conceitos de evoluo de software. Por

que o software evolui e quais as razes que obrigam a constante adaptao dos
mesmos. Exemplificao de softwares que no precisam de manuteno (como
aqueles que codificam alguma regra matemtica imutvel), e caracterizao de
softwares comerciais.
Apresentao e caracterizao dos problemas: apresentao dos problemas de

manuteno de software descritos neste trabalho. A apresentao dos problemas deve
incluir uma explicao sobre o significado de cada um e tambm a caracterstica de
relativa estabilidade dos tipos de problemas atravs dos anos.
Natureza dos problemas: finalmente, aps a exposio dos problemas de manuteno,

neste ltimo tpico so apresentadas as caractersticas desses problemas, expondo o
fato de serem predominantemente de origem gerencial e no tcnica, como pode
indicar a intuio.
7.3.4 Mdulo B Ambiente de Manuteno

O mdulo destinado ao ambiente de manuteno visa apresentar os recursos necessrios para
a execuo com sucesso da atividade de manuteno. Esses recursos no se restringem a
126
ferramentas e mquinas, mas esto ligados principalmente ao apoio gerencial e definio de

processos adequados a diferentes etapas da manuteno.
No quadro 7.3 so mostrados os tpicos considerados para esse mdulo.
QUADRO 7.3: TPICOS DO MDULO B AMBIENTE DE MANUTENO
Tpico
Fundamentao
Gesto para manuteno
(TF), (OA), (6)
Equipe de manuteno
(TF), (EC), (OA), (11)
Gerenciamento de comunicao e do fluxo de conhecimento
(TF), (EC), (OA), (1), (2), (4),

(6), (7), (9), (11), (13), (15),
(16)
Definio, avaliao e provimento do ambiente de manuteno
(TF), (OA), (7), (11), (14)
Organizao, treinamento e avaliao de equipes
(TF), (EC), (OA), (9), (11),

(12)
Controle e gerncia de configurao de software
(TF), (16)
Processos e padres para manuteno
(TF), (4), (6), (7), (9)
Definio de recursos de suporte ao produto de software
(TF), (EC), (OA), (5)
Legenda (comum aos mdulos B, C e D):

TF = Teoria Fundamental
EC = Estudo de Caso
OA = Outros Autores (vide item 5.4)
(1) = Processo de Elicitao de Requisitos (grupo de Engenharia)
(2) = Processo de Anlise de Requisitos de Software (grupo de Engenharia)
(3) = Processo de Teste de Software (grupo de Engenharia)
(4) = Processo de Manuteno de Software e Sistema (grupo de Engenharia)
(5) = Processo de Suporte ao Cliente (grupo de Operao)
(6) = Processo de Alinhamento Organizacional (grupo de Gerncia)
(7) = Processo de Gerncia Organizacional (grupo de Gerncia)
(8) = Processo de Gerncia de Projeto (grupo de Gerncia)
(9) = Processo de Gerncia de Qualidade (grupo de Gerncia)
(10) = Processo de Gerncia de Riscos (grupo de Gerncia)
(11) = Processo de Gerncia de Recursos Humanos (grupo de Recursos e Infra-estrutura)
(12) = Processo de Treinamento (grupo de Recursos e Infra-estrutura)
(13) = Processo de Gerncia do Conhecimento (grupo de Recursos e Infra-estrutura)
(14) = Processo de Infra-estrutura (grupo de Recursos e Infra-estrutura)
(15) = Processo de Documentao (grupo de Gerncia de Configurao)
(16) = Processo de Gerncia de Configurao (grupo de Gerncia de Configurao)
(17) = Processo de Gerncia de Solicitaes de Mudana (grupo de Gerncia de
Configurao)
De maneira semelhante ao mdulo anterior, a seguir descrito o contedo geral que

cada tpico deve abordar.
Gesto para manuteno: neste tpico deve ser apresentado o problema existente em
aplicar critrios de gesto no adequados ao contexto de software. importante
destacar que alm de ser necessria uma gerncia capaz de compreender as
127
peculiaridades do ciclo de vida de software, tambm preciso considerar a

manuteno de software desde as primeiras etapas do desenvolvimento. Essa postura
visa contribuir tanto para a existncia de um ambiente prprio para a manuteno,
como tambm para o surgimento de uma conscincia comum a respeito das
dificuldades que podero advir da necessidade de manter o software em
funcionamento atravs dos anos.
Equipe de manuteno: os objetivos neste tpico incluem apresentar a necessidade de

existncia de uma equipe especfica para manuteno de software dentro da
organizao, bem como as caractersticas que essa equipe deve possuir. Entre essas
caractersticas esto, por exemplo, qual o papel de cada membro e a necessidade de
adoo de ferramentas destinadas a tratar questes especficas de manuteno de
software.
Gerenciamento de comunicao e do fluxo de conhecimento: apresentao da

importncia da comunicao eficiente entre membros de uma mesma equipe e entre
equipes diferentes, principalmente no que se refere troca de experincias e ao uso de
solues eficientes adotadas em situaes passadas. Explorar os problemas das falhas
de comunicao pode ser uma maneira eficaz de ensinar a importncia da
comunicao eficiente. A proposta de ferramentas para auxlio dessa necessidade
tambm deve ser considerada.
Definio, avaliao e provimento do ambiente de manuteno: o assunto neste

tpico est ligado ao da gesto para manuteno e acaba sendo uma conseqncia do
implemento daquele. Inclui o delineamento e monitorado do ambiente de manuteno,
o que envolve verificar a necessidade de ferramentas, pessoal e ainda o desempenho
dos mesmos do ponto de vista geral, como necessidades comuns do ambiente e no
necessidades de treinamento de um nico indivduo. O ambiente de manuteno como
um todo deve ser considerado.
Organizao, treinamento e avaliao de equipes: neste tpico, diferentemente do

anterior, deve ser tratada a necessidade de avaliao individual e a proposio de
programas de treinamento focado em pequenos grupos. O papel individual de cada
indivduo dentro da equipe deve ser considerado, e deve ser mostrada a necessidade de
entender as habilidades individuais, para que se possa atrelar a cada um o papel que
melhor se adeque s suas habilidades pessoais.
Controle e gerncia de configurao de software: expor conceitos bsicos de

configurao de software e como esses conceitos se aplicam a manuteno de
128
software. A idia principal mostrar as conseqncias de falhas na gerncia de

configurao e seu impacto no produto de software alterado.
Processos e padres para manuteno: o objetivo neste tpico esclarecer, em um

primeiro momento, a idia de processo, apresentando, na medida do possvel,
conceitos e normas para esse fim. Em um passo seguinte, devem ser expostas
alternativas menos rgidas e formais, mas tambm eficazes, para diminuir os
problemas de manuteno de software, bem como para permitir maior controle sobre a
atividade como um todo.
Definio de recursos de suporte ao produto de software: neste tpico, o aluno deve

ser conscientizado de que manter um software uma tarefa muito rdua e
freqentemente responsvel por grande desgaste na relao empresa-cliente. To
importante quando desenvolver o software para o cliente acompanhar o uso do
mesmo e suas necessidades de ajustes. Do ponto de vista prtico, a questo do suporte
parece ser um dos pontos menos conhecidos por recm-formados. Muitos acreditam
que possvel o uso de tcnicas mirabolantes de desenvolvimento para produzir um
software que nunca precisar de manuteno. A percepo da total impossibilidade
disso muitas vezes s conseguida com a prtica, sendo de grande valor tentar
antecipar esse fato aos alunos.
7.3.5 Mdulo C Manutenibilidade Durante o Desenvolvimento

No mdulo de manutenibilidade durante o desenvolvimento, o foco est na idia do
desenvolvimento para manuteno. Isso significa que a preocupao agora deve ser diferente
daquela do passado, ligada normalmente apenas a fatores prprios do desenvolvimento.
Caractersticas que tornem o software mais fcil de ser modificado e ampliado, provavelmente
em um futuro prximo entrega ao cliente, devem ser consideradas e aplicadas ao software
ainda em fase de desenvolvimento. Os requisitos do cliente devero ser interpretados j com a
abordagem de que em breve mudanas precisaro ser feitas.
Alguns tpicos so apresentados na forma de parte 1 e parte 2. Essa diviso foi
adotada por julgarem-se necessrias vises diferenciadas para um mesmo assunto em fases
distintas do ciclo de vida de software.
Note-se, no entanto, que os tpicos apresentados a seguir so apenas aqueles que se
mostraram importantes do ponto de vista de preveno de problemas de manuteno de
software, j que essa atividade somente aparecer de fato quando o produto final for entregue.
Fica claro que para uma ementa final de disciplina, outros assuntos devem ser abordados, e
129
que aqui no apareceram por no terem se revelado importantes para o contexto considerado.
No quadro 7.4 esto listados esses tpicos.
QUADRO 7.4: TPICOS DO MDULO C MANUTENIBILIDADE DURANTE O DESENVOLVIMENTO
Tpico
Fundamentao
Documentao (parte 1)
(TF), (OA), (15)
Aquisio e anlise de requisitos
(TF), (1), (2), (8)
Definio e aplicao de critrios de testes (parte 1)
(TF), (EC), (2), (3), (4), (9),

(17)
Definio e monitoramento de requisitos de qualidade (parte 1)
(TF), (OA), (9)
Verificao e validao de software (parte 1)
(TF), (1), (2), (3), (4), (5),

(16), (17)

EC = Estudo de Caso
Configurao)
A seguir, so descritos os objetivos gerais de cada tpico.
Documentao (parte 1): a primeira viso da documentao deve contemplar a

necessidade de se construir um projeto bem elaborado do software, incluindo detalhar
adequadamente pontos que so de natureza mais crtica ou de difcil compreenso da
lgica empregada. Essa postura na confeco da documentao visa especialmente
facilitar a manuteno do software, principalmente se essa tarefa for ser realizada por
pessoas que no tiveram contato com o projeto inicial. Em suma, preciso deixar
claro que a documentao durante o desenvolvimento deve ser feita sempre se
pensando nas pessoas que a utilizaro, por exemplo, dois anos mais tarde.
130
Aquisio e anlise de requisitos: neste tpico devero ser apresentados os critrios

formais necessrios aquisio e mudana de requisitos, bem como sua anlise do
ponto de vista de viabilidade de desenvolvimento. Isso significa mostrar maneiras de
formalizar requisitos e de como valid-los junto ao cliente. O importante passar aos
alunos que antes do desenvolvimento a aquisio e anlise de requisitos deve sempre
seguir um processo formal que facilitar a percepo de necessidades futuras do
cliente. Essa percepo importante para que se possam prever no projeto do software
mudanas evidentes ou potenciais nos requisitos, possibilitando que ainda durante o
desenvolvimento sejam embutidas facilidades de manuteno no projeto.
Definio e aplicao de critrios de testes (parte 1): a idia central neste tpico a
de mostrar que um produto de software entregue com erros acarretar a antecipao de
necessidades de manuteno. Note que corrigir erros em um software j entregue
constitui atividade de manuteno, segundo a definio da IEEE, ainda que o software
tenha acabado de ser entregue. Por conseqncia, os alunos devem valer-se do
conhecimento de engenharia de software para utilizarem tcnicas de definio e
aplicao de testes eficientemente.
Definio e monitoramento de requisitos de qualidade (parte 1): visando garantir a

qualidade global do produto que ser entregue, o aluno precisar tomar conhecimento,
neste tpico, da existncia de processos de qualidade e padres para desenvolvimento.
Novamente, garantir um produto com qualidade durante o desenvolvimento evitar
que muitas manutenes sejam necessrias posteriormente.
Verificao e validao de software (parte 1): as principais fontes de necessidades de

manuteno, nos primeiros momentos aps a entrega do software, so deficincias na
interpretao do que o cliente desejava e erros de codificao. Essa a motivao
principal para expor procedimentos de verificao (fazer o que de fato o cliente quer) e
validao (fazer de maneira correta), no momento do desenvolvimento. fcil
perceber que com a verificao e validao realizada de maneira adequada, menos
problemas surgiro no produto de software final. importante destacar, no entanto,
que ainda que fosse possvel realizar essas tarefas de forma perfeita, isso no anularia
as futuras necessidades de manuteno, j que essa tambm uma necessidade que
surge com a modificao do ambiente no qual o software trabalha.
131
7.3.6 Mdulo D Manuteno no Produto Final de Software

Finalmente, o mdulo de manuteno no produto final de software deve considerar as
respostas possveis para a grande maioria dos problemas de manuteno de software
conhecidos, j que nesse momento que a maior parte desses problemas surge.
No quadro 7.5 esto apresentados os tpicos considerados necessrios para esse
mdulo com suas respectivas fundamentaes.
QUADRO 7.5: TPICOS DO MDULO D MANUTENO NO PRODUTO FINAL DE SOFTWARE
Tpico
Fundamentao
Documentao (parte 2)
(TF), (OA), (15)
Definio e aplicao de critrios de testes (parte 2)
(TF), (EC), (2), (3), (4), (9),

(17)
Definio e monitoramento de requisitos de qualidade (parte 2)
(TF), (OA), (9)
Verificao e validao de software (parte 2)
(TF), (1), (2), (3), (4), (5),

(16), (17)
Delegao e administrao de tarefas
(TF), (EC), (OA), (8)
Acompanhamento das manutenes
(TF), (8), (9)
Obteno e anlise de solicitaes de mudana
(TF), (1), (2), (4), (5), (8),

(17)
Planejamento de administrao de riscos
(TF), (10)
Manuteno preventiva
(TF), (9)
Planejamento de manuteno
(TF), (EC), (OA), (4), (8),

(17)
Definio de poltica de troca de verses
(TF), (4)
Medio de nvel de satisfao do cliente
(TF), (5), (9)

EC = Estudo de Caso
132

Configurao)
Da mesma forma que nos mdulos anteriores, a seguir apresenta-se a descrio geral
do contedo de cada tpico.
Documentao (parte 2): na segunda viso sobre a documentao, algumas

consideraes diferentes devem ser apresentadas com relao maneira como ela
abordada durante o desenvolvimento. Durante a manuteno, preciso considerar
alternativas de documentao para alteraes pontuais simples, facilitando essa tarefa,
j que esse tipo de manuteno normalmente o mais freqente. Para alteraes
maiores, processos formais precisam ser considerados como no desenvolvimento.
Outro ponto fundamental decidir por qual processo a documentao geral do projeto
ser atualizada, e quem sero os responsveis por essa tarefa. importante destacar
que a desatualizao da documentao causar dificuldades progressivas para a
manuteno.
Definio e aplicao de critrios de testes (parte 2): o objetivo neste tpico

apresentar a necessidade de se estabelecer critrios bem definidos para testes em
manutenes efetuadas. Os testes pontuais na alterao apenas uma das obrigaes.
Essa condio se justifica pelo fato de que manutenes freqentemente produzem
efeitos colaterais em outras partes do software, e os alunos precisam estar cientes disso
para estabelecerem tanto testes pontuais, como de integrao no produto alterado.
interessante esclarecer que o efeito cascata de alteraes um dos principais motivos
de gerao de desconfiana do cliente em relao ao software.
Definio e monitoramento de requisitos de qualidade (parte 2): neste tpico deve ser
tratada a exposio de quais so os requisitos desejveis de qualidade nas
manutenes e como acompanhar seu efetivo cumprimento, propondo-se correes
conforme necessrias. Novamente, importante que o aluno esteja ciente que
manutenes mal validadas geraro novas necessidades de manuteno, assim como
desconfiana do cliente.
Verificao e validao de software (parte 2): neste tpico a verificao e validao

de software retomada, agora sob a perspectiva de um produto final de software em
manuteno. O principal intuito mostrar que o entendimento incompleto ou errneo
da necessidade de manuteno do cliente pode ocasionar esbanjamento de tempo e
133
recursos. Aqui a verificao e validao assume um papel ainda mais relevante do que
durante o desenvolvimento, isso porque o impacto negativo de alteraes fora de
conformidade com o que o cliente precisa pode produzir efeitos negativos muito
grandes, uma vez que o cliente provavelmente j apresenta dependncia em relao s
funcionalidades do software. Essa viso de dependncia em relao ao produto de
software estvel e correto deve ser trabalhada junto aos alunos.
Delegao e administrao de tarefas: neste tpico o intuito expor as conseqncias

negativas da sobrecarga de tarefas, principalmente quando tarefas de desenvolvimento
e de manuteno so atribudas s mesmas pessoas. O aluno deve aprender que a
manuteno precisa ter equipe e ambiente computacional separado do de
desenvolvimento. O uso de ferramentas para auxiliar a classificao da complexidade
das alteraes uma alternativa vivel para melhorar a distribuio de tarefas.
Acompanhamento das manutenes: a inteno do acompanhamento de manutenes

est centrada no estabelecimento de mecanismos de controle das alteraes em
andamento, principalmente do ponto de vista de cumprimento de cronogramas. O
acompanhamento deve propor medidas de correo ou alternativas quando uma
manuteno se mostrar invivel em meio codificao ou os prazos forem
comprometidos por atividades paralelas ou complexidade superior estimada. O
controle deve considerar o tempo necessrio tambm para a realizao de testes, j que
as manutenes no podero ser entregues sem os testes adequados.
Obteno e anlise de solicitaes de mudana: neste tpico deve ser abordada, em

um primeiro momento, a discusso de alternativas para a obteno dos requisitos de
mudanas do cliente. Devem ser citados os problemas de se utilizar e-mail, telefone,
fax etc. Documentos padronizados pode ser uma alternativa, porm necessria a
avaliao de como ser a troca desses documentos com o cliente (envio por e-mail
seguido de preenchimento e retorno via fax no uma boa opo - isso justamente
uma das fontes de problemas, pois muito fcil a perda dessas informaes). O ideal
o uso de ferramentas com registro em bases de dados, principalmente fornecendo uma
forma de o cliente acompanhar o status de seus pedidos (normalmente com o uso de
sistemas baseados na web). Em um segundo momento devem ser apresentados
critrios de como analisar a viabilidade dos pedidos do cliente. Os alunos devem
entender que a possibilidade de se perder a estabilidade do produto de software alta
quando manutenes mal validadas so efetuadas, portanto uma boa poltica a de
sempre considerar alternativas antes de proceder-se com as modificaes no cdigo-
134
fonte. claro que isso nem sempre ser possvel e os casos que de fato exigirem
manutenes precisam ser bem entendidos e analisados do ponto de vista de efeitos
colaterais em outros mdulos do software.
Planejamento de administrao de riscos: neste tpico busca-se mostrar que, assim

como no desenvolvimento, na atividade de manuteno riscos tambm existem e o
planejamento de resposta aos mais conhecidos representa uma garantia de maior
estabilidade para a organizao. Dificuldades inesperadas de manuteno, atrasos,
mudanas de prioridades, manutenes urgentes no previstas e rotatividade so
exemplos de riscos potenciais para a manuteno de software que devem ser
considerados em um planejamento por parte da gerncia.
Manuteno preventiva: neste tpico deve ser apresentado aos alunos o conceito de
manuteno preventiva e a exposio de suas principais tcnicas. Alm disso, os
objetivos desse tpico incluem criar uma viso crtica do aluno sobre o tema. Isso
significa explicar a necessidade de recursos humanos extras e a complexidade para
trabalhar a manuteno preventiva, tornando necessrio sempre avaliar os objetivos
estratgicos da organizao em relao ao seu produto de software, para a partir desse
entendimento decidir sobre preocupar-se ou no com manuteno preventiva.
Planejamento de manuteno: neste tpico os conceitos de planejamento de

manuteno devem ser apresentados. Tais conceitos incluem considerar a atualizao
da documentao, a delegao de tarefas, o controle da atividade e a realizao de
testes. Alm do planejamento tcnico, necessrio tambm o planejamento da
comunicao com o cliente, da definio de cronograma e de possveis verses de
teste. Todos os conceitos e caractersticas relevantes a esses pontos devem ser
trabalhados com os alunos.
Definio de poltica de troca de verses: neste tpico deve ser exposta a necessidade
de previamente se estabelecer qual processo ser utilizado para a disponibilizao e
troca de verses, informando o cliente o que ficar a seu cargo e o que ser
responsabilidade da organizao. Vrias formas de tratar essa disponibilizao podem
ser aplicadas, sendo as mais comuns a disponibilizao de download via internet ou o
uso de CD-ROM. Dependendo da infra-estrutura do cliente, a opo por download
pode no ser vivel, devendo ser consideradas outras alternativas. O aluno precisa
tomar conhecimento dos inmeros problemas que podem surgir com a troca de
verses, como por exemplo, o cliente no saber como proceder e a organizao no
possuir algum para apoi-lo nessa tarefa. Problemas como esse podem dar a
135
impresso ao cliente de que a sua solicitao de manuteno que no est sendo

disponibilizada, quando na verdade se trata de uma dificuldade com a atualizao de
seu software.
Medio de nvel de satisfao do cliente: neste tpico o aluno deve perceber que a
manuteno de software pode ser considerada tambm como um fator de
competitividade. A esperada satisfao do cliente com a entrega do produto final aps
desenvolvimento seguindo padres e processos bem definidos, somente poder ser
conservada com o suporte, e conseqentes manutenes necessrias. Estabelecer
formas de medir o nvel de satisfao do cliente aps meses, ou anos, da entrega do
software favorecer a adoo de medidas, principalmente relacionadas com
manuteno e suporte, para manter uma relao positiva da organizao com o cliente.
Uma forma de medir essa satisfao pode ser com um sistema baseado em web que
permita ao cliente marcar, para cada pedido de manuteno efetuado, a sua impresso
com relao soluo oferecida. Por exemplo, para cada manuteno registrada e
concluda, o cliente poderia ter a sua disposio a possibilidade de selecionar entre
algumas opes de resposta, a que melhor refletisse seu sentimento com relao ao
atendimento oferecido para a manuteno.
7.3.7 Resumo da Estrutura

A estruturao dos assuntos e tpicos considerados relevantes para uma disciplina de
manuteno de software, em face da metodologia de resposta aos problemas prticos de
manuteno, est resumida na figura 7.2.
FIGURA 7.2: VISO GERAL DA ESTRUTURA DE MDULOS E TPICOS
136
137

Uma das caractersticas fundamentais da estrutura de mdulos e tpicos apresentada refere-se
ao fato de que ela expe aqueles assuntos que foram considerados essenciais a uma futura
disciplina de manuteno de software baseada na resposta a problemas. A estrutura no
corresponde, portanto, a uma ementa definitiva, sendo to somente um guia de quais assuntos
devem constar em uma ementa final para essa disciplina.
A opo por dividir alguns tpicos em parte1 e parte2 resultou da observao de que
em diferentes etapas do ciclo de vida de software, diferentes abordagens devem ser atribudas
a um mesmo assunto, mostrando-se necessrio discutir com os alunos esse fato. Por exemplo,
apresentar conceitos de documentao de maneira geral parece ser menos eficiente do que
apresentar abordagens diferenciadas levando-se em conta o fato de o software ainda estar em
desenvolvimento ou j ter sido entregue ao usurio final.
Um ponto no considerado foi o da adoo de projetos prticos para a fixao e
treinamento dos conceitos expostos durante a disciplina. Seguramente o uso de projetos
prticos recomendvel e j se mostrou adequado em muitos momentos para o ensino de
engenharia de software. No entanto, a estipulao de quais trabalhos desenvolver e como
organizar equipes de alunos para esse propsito foge do escopo deste trabalho, que se
fundamenta principalmente no diagnstico dos assuntos necessrios para o contexto de
disciplina centrada na resposta a problemas de manuteno.
138
CAPTULO
8
Concluso
.
8.1 Consideraes Gerais
O crescimento do nmero de sistemas legados e a dificuldade para mant-los adequados s
necessidades das organizaes foram a principal observao que guiou a elaborao deste
trabalho.
Percebe-se mais do que nunca como o mundo dos softwares dinmico e as
abordagens modificam-se atravs dos tempos. Partindo de uma euforia inicial por
desenvolvimento e formas de melhorar esse desenvolvimento, atinge-se agora um estgio a
mais, um crescente equilbrio com outra atividade do ciclo de vida de software: a manuteno.
Isso no significa que o desenvolvimento esteja com sua importncia sendo reduzida.
Pelo contrrio, no param de surgir novas idias, ferramentas e metodologias, algumas vezes
com propostas inovadoras, para facilitar o desenvolvimento e a prpria evoluo de software.
A idia de valer-se de componentes de software reutilizveis em diferentes projetos um
exemplo da tentativa da comunidade de pesquisadores de favorecer ainda mais o
desenvolvimento de software.
O fato que se percebe agora o surgimento de trabalhos e pesquisas voltadas
exclusivamente para manuteno de software, o que inclui o surgimento de eventos (como
congressos) especficos para esse fim. E isso com certeza fruto da verificao de que j se
conta com um volume grande de software em pleno funcionamento pelo mundo e que
precisar continuar em funcionamento por tempo indeterminado. Como prover vitalidade a
Captulo 8 Concluso
140
esse legado que a evoluo da computao produziu, e que hoje so tratados como bens das
organizaes, representa o foco de muitas pesquisas recentes.
8.2 Contribuies
As contribuies deste trabalho incluem a apresentao e estudo de fatos relacionados
atividade de manuteno de software, principalmente dos problemas ligados a essa atividade,
fornecendo parmetros inicias para guiar a confeco de uma disciplina de manuteno de
software em graduaes na rea de computao.
A apresentao dos problemas tpicos de manuteno de software e seu confronto com
a norma ISO/IEC 12207 um dos pontos fortes deste trabalho, pois se a norma considerada
um excelente guia para a prtica controlada e ajustvel do processo de desenvolvimento de
software, defront-la com os problemas de manuteno uma forma de identificar o que vem
sendo feito errado nas organizaes.
A esse entendimento das causas dos problemas de manuteno une-se a proposta dos
assuntos que devem ser tratados em uma futura disciplina de manuteno de software. Esses
assuntos so reflexos imediatos das constataes das razes principais dos problemas de
manuteno apresentados, e acredita-se que devam ser o ponto de partida para testes com uma
disciplina de manuteno de software.
Mais do que a disciplina em si, o propsito maior deste trabalho consiste em motivar e
conscientizar seus futuros leitores para a importncia da manuteno de software, que
ironicamente ainda colocada de lado em muitas organizaes, apesar de elas mesmas
sofrerem com a falta de controle sobre essa atividade.
8.3 Trabalhos Futuros

O trabalho futuro mais evidente o de implementar na prtica uma disciplina de manuteno
de software que use como parmetros as indicaes e observaes apresentadas. Uma anlise
posterior, tanto da receptividade dos alunos, como dos resultados finais, inicialmente com
uma pesquisa entre os egressos, produziria uma nova fonte para anlise, possibilitando um
caminho para o estabelecimento em definitivo de uma ementa adequada para a disciplina.
Outra possibilidade seria reproduzir os passos do atual trabalho, mas focando-se em
alguma caracterstica do processo de desenvolvimento de software ou de seu ciclo de vida.
Um exemplo seria reproduzir este trabalho aplicando-o qualidade de software.
Primeiramente, seriam elencados os critrios de qualidade de software desejveis, e isso pode
incluir tanto critrios funcionais como no funcionais, como por exemplo, a usabilidade,
manutenibilidade, portabilidade, etc. A partir dos requisitos desejveis, o passo seguinte seria
Captulo 8 Concluso
141
investigar quais deles so comumente no atendidos, ou atendidos de maneira insuficiente,

nos softwares criados para um determinado domnio. De forma semelhante a este trabalho,
essa investigao tambm traria indcios de como tratar o ensino, dessa vez de qualidade de
software, que seria considerado de maneira focada nos problemas de qualidade verificados na
indstria, e no apenas baseado em teoria e conceitos acadmicos.
Captulo 8 Concluso
142
REFERNCIAS BIBLIOGRFICAS
.
ANDREWS, J. H.; LUTFIYYA, H. L. (2000) Experiences with a software maintenance project
course, IEEE Transactions on Software Engineering (TSE), v. 43, n. 4, p. 383-388.
BASILI, V. (1990) Viewing Maintenance as Reuse-Oriented Software Development, IEEE
Software, v. 7, n. 1, p. 19-25.
BECK, K. (1999) Extreme Programming Explained, First Edition. Addison-Wesley.
BENNETT, K. H.; RAJLICH, V. T. (2000) Software maintenance and evolution: a roadmap, In:
Conference on The Future of Software Engineering, Limerick, Ireland, June.
BENNETT, K. H.; RAMAGE, M.; MUNRO, M. (1999) Decision Model for Legacy Systems,
IEEE Proceedings on Software (TSE), v.146, n. 3, p. 153-159.
BHATT, P.; SHROFF, G.; MISRA, A. K. (2004) Dynamics of software maintenance, ACM
SIGSOFT Software Engineering Notes, v. 29, n. 5, p. 1-5.
BHATT, P.; WILLIAMS, K.; SHROFF, G.; MISRA, A. K. (2006) Influencing Factors in
Outsourced Software Maintenance, ACM SIGSOFT Software Engineering Notes, v. 31,
n. 3, p. 1-6.
BLASI,
P.
J.
(1999)
Overview
of
ACM.
Disponvel
<http://www.acm.org/about_acm/ov.html>. Acesso em: 09 mai. 2006.
em:
BOEHM, B.; BASILI, V. (2001) Software Defect Reduction Top 10 List, Computer, v. 34, n.
1.
CARDOW, J.E. (1992) Can software maintenance be taught?, In: Conference on Software
Maintenance, Orlando, FL, USA, November.
CASTRO, J. F. B.; GIMENES, I. M. S.; MALDONADO, J. C. (2000) Uma proposta de Plano
Pedaggico para a matria Engenharia de Software, In: II Curso de Qualidade de Cursos
de Graduao da rea de Computao e Informtica, Curitiba, PR, Brasil, Julho.
CHAPIN, N. (1986) Software maintenance: A different view, In: Conference on Software
Maintenance, Orlando, FL, USA, November.
COSTA, C. M.; AUDY, J. L. N.; MAZZUCCO, J.; FURTADO, J. V. (2000) Plano Pedaggico para
cursos de Bacharelado em Sistemas de Informao, Sociedade Brasileira de Computao
(SBC). Disponvel em <http://www.sbc.org.br/index.php?subject=39>. Acesso em: 09 mai.
2006.
Referncias Bibliogrficas
144
DAHMER, A.; SANTOS, B. S. DOS; OGIBA, S.; KIST, T. (2002) Uma Proposta de Plano
Pedaggico para o Curso de Licenciatura em Computao, Sociedade Brasileira de
Computao (SBC). Disponvel em: <http://www.sbc.org.br/index.php?subject=39>.
Acesso em: 14 mai. 2006.
DART, S.; CHRISTIE, A. M.; BROWN, A. W. (2001) A Case Study in Software Maintenance,
Technical Report, Carnegie Mellon University.
DEKLEVA, S. M. (1990) Annual Software Maintenance Survey: Survey Results, Software
Maintenance Association, Vallejo, California, USA.
________. (1992) Delphi study of software maintenance problems, In: Conference on
Software Maintenance, Orlando, FL, USA, November.
DE LUCIA, A., POMPELLA, E., STEFANUCCI, S. (2004) Effort estimation for corrective software
maintenance. In: 14th International Conference on Software Engineering and Knowledge
Engineering, Ischia, Italy, July.
DIAS, M. G. B. (2004) Uma experincia no ensino de manuteno de software, In:
Workshop de Manuteno de Software Moderna (WMSWM04), Braslia, DF, Brasil,
Outubro.
FERREIRA, A. P. L.; BATTAIOLA, A. L.; SOUZA, F. F.; TORI, R. (2001) Proposta de Plano
Pedaggico: Bacharelado em Cincia da Computao, Sociedade Brasileira de
Computao (SBC). Disponvel em: <http://www.sbc.org.br/index.php?subject=39>.
Acesso em: 09 mai. 2006.
GHEZZI, C.; MANDRIOLI, D. (2005) The Challenges of Software Engineering Education, In:
27th International Conference on Software Engineering, Saint-Louis, Missouri, USA,
May.
HAZZAN, O.; DUBINSKY, Y. (2003) Teaching a Software Development Methodology: The
case of Extreme Programming, In: 16th Conference on Software Engineering Education
and Training (CSEE&T 2003), Madrid, Spain, March.
IEEE (1998) Std 1219 IEEE Standard for Software Maintenance, Institute of Electrical
and Eletronic Engineers, New York, NY, USA.
ISO/IEC 12207 (1998) Standard for Information Technology - Software Lifecycle
Processes, International Standard Organization, New York, NY, USA.
Processes/Amd.1, International Standard Organization, New York, NY, USA.
Processes/Amd.2, International Standard Organization, New York, NY, USA.
ISO/IEC 15504 (2003) Software Process Assessment, International Standard Organization,
New York, NY, USA.
KOSKINEN, J.; SALMINEN, A.; PAAKKI, J. (2004) Hypertext support for the information needs
of software maintainers, Journal of Software Maintenance and Evolution: Research and
Practice, v. 16, n. 3 , p. 187-215.
KUNG, H.; HSU, C. (1998) Software Maintenance Life Cycle Model, In: International
Conference on Software Maintenance, Bethesda, Maryland, USA.
LEHMAN, M. M. (1974) Programs, Cities, Students, Limits to Growth?, In: Imperial College
of Science Technology, London, England, May.
________. (1980) On Understanding Laws, Evolution and Conservation in the Large
Program Life Cycle, Journal of Systems and Software (JSS), v. 1, n. 3, p. 213-221.
145
________. (1991) Software Engineering, the Software Process and their Support, IEEE
Software Engineering Journal: Special Issues on Software Environments and Factories, v.
1, n. 3, p. 213-221.
________. (1996) Laws of Software Evolution Revisited. In: 5th European Workshop on
Software Process Technology, Nancy, France, October.
LIENTZ, B. P.; SWANSON, E. B. (1980) Software Maintenance Management, Reading, MA,
Addison-Wesley.
NAUR, P.; RANDELL, B. (1968) Software Engineering: Report, In: Conference of NATO
Science Committee, Garmisch, Germany, October.
NIESSINK, F. (1999) Software Maintenance Research in the Mire?, In: Annual Workshop on
Empirical Studies of Software Maintenance (WESS99), Oxford, United Kingdom,
September.
NUNES, J. D. (2005) Projetos de Planos Pedaggicos Orientados a Problemas, Biblioteca
Digital
da
SBC.
Disponvel
em
<<
http://www.sbc.org.br/bibliotecadigital/download.php?paper=218>>. Acesso em: 20 jan.
2007.
PADUELLI, M.; SANCHES, R. (2006) Problemas em manuteno de software: caracterizao e
evoluo, In: III Workshop de Manuteno de Software Moderna, Vila Velha, ES, Brasil,
Maio.
PFLEEGER, S. L. (2001) Software Engineering: theory and practice. Second Edition, New
Jersey, Prentice Hall.
PIGOSKI, T. M. (1996) Practical Software Maintenance: Best Practices for Managing Your
Software Investment, Willey Computer Publishing.
POLO, M.; PIATTINI, M.; RUIZ, F.; CALERO, C. (1999) Roles in the maintenance process,
ACM SIGSOFT Software Engineering Notes, v. 24, n. 4, p. 84-86.
POLO, M.; PIATTINI, M.; RUIZ, F. (2003) Using a qualitative research method for building a
software maintenance methodology, Software Practice and Experience, v.32, n. 13, p.
12391260.
PRESSMAN, R. S. (2005) Software Engineering: a practitioners approach, 6.ed.,
McGrawHill Higher Education.
RODRIGUEZ, E. (2004). Overview of ACM / Education. Disponvel
<http://www.acm.org/about_acm/ov_edu.html>. Acesso em: 09 mai. 2006.
em:
SHACKELFORD, R.; CROSS, J. H.; DAVIES, G.; IMPAGLIAZZO, J.; KAMALI, R.; LEBLANC, R.;
LUNT, B.; MCGETTRICK, A.; SLOAN, R.; TOPI, H. (2004) Computing Curricula 2004: A
Guide to Undergraduate Degree Programs in Computing, Joint Task Force for Computing
Curricula 2004, The Association for Computing (ACM), November.
SILVA, L.; SAYO, M.; LEITE, J. C. S. P.; BREITMAN, K. (2003) Enriquecendo o cdigo com
cenrios, In: Simpsio Brasileiro de Engenharia de Software (SBES), Manaus, AM,
Brasil, Outubro.
SILVA, L. DE P.; SANTANDER, V. F. A. (2004) Uma Anlise Crtica dos Desafios para
Engenharia de Requisitos em Manuteno de Software, In: Workshop em Engenharia de
Requisitos, Tandil, Argentina, Dezembro.
SINGH, R. (1996). International Standard ISO/IEC 12207 Software Life Cycle Processes,
Software Process Improvement and Practice, vol. 2, p. 3550.
146
SNEED, H. M. (2003) Critical Success Factors in Software Maintenance, In: International

Conference on Software Maintenance, Amsterdam, The Netherlands, September.
SOARES, M. DOS S. (2005) Uma experincia no ensino de Engenharia de Software orientada a
trabalhos prticos, In: Workshop de Educao em Informtica (WEI2005), Rio de Janeiro,
RJ, Brasil, Novembro.
SOMMERVILLE, I. (2003) Engenharia de Software, 6.ed., So Paulo, Addison Wesley.
SOUZA, S. C. B. DE; NEVES, W. C. G. DAS; ANQUETIL, N.; OLIVEIRA, K. M. DE. (2004)
Documentao Essencial para Manuteno de Software II, In: I Workshop de
Manuteno de Software Moderna, Braslia, DF, Brasil, Outubro.
STILLER, E.; LEBLANC, C. (2002) Effective Software Engineering Pedagogy, Journal of
Computing Sciences in Colleges, v. 17, n. 6, p. 124-134.
SWEBOK (2004) The Institute of Electrical and Electronics Engineers, Inc IEEE, Guide
to the Software Engineering Body of Knowledge, Version 2004.
TEIXEIRA, C. A. C.; MARTINS, J. S. B.; PRADO, A. F.; JNIOR, O. M.; GEYER, C. F. R.;
AZEREDO, P. A. (2002) Um Plano Pedaggico de Referncia para Cursos de Engenharia
de Computao, Sociedade Brasileira de Computao (SBC). Disponvel em
<http://www.sbc.org.br/index.php?subject=39>. Acesso em: 09 mai. 2006.
TOMAYKO, J. E. (1987) Teaching a Project-Intensive Introduction to Software Engineering,
Technical Report, Carnegie Mellon Institute.
ULRICH, W. M. (1990) The evolutionary growth of software reengineering and the decade
ahead. American Programmer, v. 3, n. 10, p. 14-20.
VISAGGIO, G. (2001) Assessing the Maintenance Process Through Replicated, Controlled
Experiment. Journal of Systems and Software, v. 44, n. 3, p. 187-197.
________. (2001) Ageing of a data-intensive legacy system: symptoms and remedies.
Journal of Software Maintenance and Evolution: Research and Practice, v. 13, n. 5, p.
281-308.
ZARIFIAN, P. (2001) Objetivo competncia: por uma nova lgica. Traduo Maria Helena C.
V. Trylinski, So Paulo, Atlas.
ZVEGINTZOV, N.; PARIKH, G. (2005) 60 years of Software Maintenance: Lessons Learned,
In: 21st IEEE International Conference on Software Maintenance (ICSM 2005), Budapest,
Hungary, September.
YOURDON, E. (1992) Anlise Estruturada Moderna, traduo da terceira edio, Rio de
Janeiro, Campus.
APNDICE A
.
Questionrios utilizados no estudo de caso
A seguir so apresentados os questionrios utilizados para obter parte dos dados analisados no
estudo de caso do captulo 3.
Por no se conhecer previamente o tamanho das respostas, e visando evitar que a
estrutura do questionrio pudesse limit-las, as questes foram listadas em uma pgina e as
respostas eram dadas em pginas seguintes.
Para a confeco dos questionrios, os seguintes pontos foram considerados:
Apresentao dos objetivos de cada um;
Perguntas diretas, evitando-se textos longos;
Questionrios com nmero reduzido de questes.

No quadro A.1 apresentado o questionrio utilizado para a coleta de dados da
primeira etapa do estudo de caso (caractersticas da atividade de manuteno de software na

organizao e principais problemas envolvidos).
QUADRO A.1: QUESTIONRIO DA PRIMEIRA ETAPA DO ESTUDO DE CASO
QUESTIONRIO
OBJETIVOS: Coletar dados referentes maneira como a equipe de manuteno de
software trabalha, obtendo respostas que influenciaro diretamente a elaborao de uma
relao de problemas caractersticos da atividade de manuteno de software na
organizao.
PARTE 1: Caractersticas do gerenciamento da atividade de manuteno.
1. Como um cliente se manifesta para apresentar uma necessidade de manuteno de
software? (e-mail, telefone, algum sistema especfico de help-desk etc.)
2. Uma vez que uma alterao de software foi requisitada pelo cliente, qual o processo
usado para avaliar tal solicitao? (todo pedido do cliente atendido?)
Apndice A
3. Para as solicitaes de manuteno, como tratado o acordo de datas de entrega com o

cliente? (existe algum tipo de programao diferenciado por nvel de urgncia da solicitao ou por importncia
do cliente?)
4. Considerando que nem sempre clara a comunicao entre o responsvel por obter os
requisitos de software e o cliente, como so tratados os problemas de m especificao de
manutenes? (exemplo, quando o profissional que for tratar a manuteno no entender o que deve ser
feito de fato)
5. comum que prazos acordados com o cliente no sejam cumpridos? Caso positivo, a
que se devem, principalmente, os atrasos?
6. Supondo que j exista um cronograma de manutenes a entregar, como so distribudas
internamente as tarefas? (ou seja, existe algum critrio para determinar qual profissional atender qual
solicitao?)
7. Considerando agora que a manuteno do cdigo-fonte j foi efetuada, quais os critrios
para testes antes de fornecer a verso modificada ao cliente?
8. Estando a modificao implementada e testada, como ela fornecida ao cliente? (por meio
de download em site, CD de atualizao etc.)
PARTE 2: Caractersticas tcnicas da abordagem das manutenes.
9. De maneira simples, como tratada a documentao das manutenes? (considere
questes como reviso geral da documentao de projeto).
10. Considerando a grande quantidade de arquivos associados a um projeto de software,
como tratado o controle de verso desses arquivos, quando manutenes simultneas
precisam ser feitas em arquivos comuns? (alguma ferramenta de controle de verso usada?
comum terem problemas com a ferramenta?)
11. De maneira geral, os profissionais empenhados na tarefa de manuteno possuem um

conhecimento suficiente da tecnologia utilizada? (linguagens, banco de dados etc.) Existe algum
programa de reciclagem desses profissionais?
Consideraes Finais
12. Caso voc seja responsvel por decises na rea de manuteno de software, poderia
descrever, livremente, quais as principais dificuldades que sente para garantir uma
manuteno eficiente e a satisfao do cliente?
A seguir mostrado o questionrio utilizado na segunda parte do estudo de caso, agora

focado na obteno de solues adotadas pela organizao para tratar seus problemas de
manuteno de software. Vale lembrar que esse questionrio possui poucas questes
justamente porque se esperava que os entrevistados espontaneamente citassem as solues
durante a entrevista, as quais seriam registradas pelo entrevistador em material a parte. Nessa
segunda parte do estudo de caso no seria possvel estipular um conjunto prvio de questes,
porque somente a organizao seria capaz de listar suas solues eficientes adotadas.
Apndice A
QUADRO A.2: QUESTIONRIO DA SEGUNDA ETAPA: QUESTES GERAIS PARA DISCUSSO
QUESTIONRIO
OBJETIVOS: Identificar solues eficientes adotadas pela organizao para tratar seus
problemas de manuteno de software.
1. Os problemas com a atividade de manuteno de software so geralmente muitos.
Partindo desse fato, como sua empresa vem tratando a questo: (assinale apenas uma
alternativa):
Normalmente apenas resolvemos os problemas medida que surgem.
Buscamos, alm de resolver os problemas medida que surgem, adotar medidas para
preveni-los.
2. Alguma ferramenta utilizada para mapear ou registrar solues normalmente muito

parecidas para problemas que ocorrem com freqncia? (considere problemas comuns de helpdesk e suporte ao cliente)
3. Do seu ponto de vista, os problemas de manuteno de software vm diminuindo na

organizao? (deixe em branco caso no saiba avaliar)
4. Descreva, livremente, atitudes gerenciais, hbitos ou outros fatores que do seu ponto de
vista j contriburam para melhorar a abordagem dos problemas de manuteno, citando
outras mudanas que acredita poderem auxiliar nesse sentido.
Apndice A
APNDICE B
.
Tabela de Atividades (CBO)
A Classificao Brasileira de Ocupaes (CBO) corresponde ao documento que reconhece,
nomeia e codifica os ttulos bem como descreve as caractersticas das ocupaes do mercado
de trabalho brasileiro1.
No quadro B.1 esto listadas as denominaes principais e os respectivos sinnimos
das ocupaes ligadas anlise de sistemas (o quadro exclui funes de tcnicos e auxiliares
normalmente sem exigncia de curso superior).
QUADRO B.1: DENOMINAES PRINCIPAIS E RESPECTIVOS SINNIMOS DAS OCUPAES (CBO)
Denominao principal
Sinnimos
- Analista de comrcio eletrnico (e-commerce)
- Analista de sistemas de informtica administrativa
Analista de desenvolvimento de
sistemas
- Analista de sistemas web (webmaster)

- Analista de tecnologia de informao
- Consultor de tecnologia da informao
- Analista de comunicao (tele-processamento)
Analista de redes e de comunicao de

dados
- Analista de rede
- Analista de telecomunicao
Analista de sistemas de automao

- Analista de suporte de banco de dados
Analista de suporte computacional
- Analista de suporte de sistema

- Analista de suporte tcnico
Administrador de banco de dados
http://www.mtecbo.gov.br
- Administrador de banco de dados e de sistemas

computacionais
Apndice B
- Administrador de rede e de sistemas computacionais
Administrador de redes
- Administrador de sistema operacional de rede

- Analista de suporte de rede
Administrador de sistemas
operacionais
- Administrador de sistemas computacionais
Engenheiro de aplicativos em
computao
- Engenheiro de sistemas computacionais aplicativos
Engenheiro de equipamentos em
computao
Engenheiros de sistemas operacionais

em computao
- Analista de aplicativo bsico (software)
- Engenheiro de softwares computacionais

- Engenheiro de hardware computacional
- Engenheiro de sistemas computacionais
equipamentos
- Engenheiro de software computacional bsico
- Engenheiro de suporte de sistemas operacionais em
computao
Programador de internet
- Programador de computador
- Programador de processamento de dados
Programador de sistemas de
informao
- Programador de sistemas de computador

- Tcnico de aplicao (computao)
- Tcnico em programao de computador
Para os profissionais enquadrados dentro dessas denominaes, a CBO informa que

so atribuies gerais tpicas deles as mostradas a seguir. Percebe-se que em momento algum
existe uma referncia especfica para manuteno (de software).
Apndice B
Apndice B
Apndice B

Engenharia de Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Engenharia de Software

Uploaded by

Copyright:

Available Formats

Manuteno de Software:

problemas tpicos e diretrizes

Mateus Maida Paduelli

Orientadora: Profa. Dra. Rosely Sanches

Dissertao apresentada ao Instituto de Cincias

VERSO REVISADA APS A DEFESA

Dedico este trabalho:

No sei como o mundo me v; mas eu me sinto como um garoto brincando na praia,

PADUELLI, M. M. Manuteno de Software: problemas tpicos e diretrizes para uma

PADUELLI, M. M. Software Maintenance: typical problems and guidelines for a specific

CONSIDERAES INICIAIS............................................................................................................ 109

7. PERSPECTIVAS PARA UMA DISCIPLINA DE MANUTENO DE SOFTWARE ..................... 119

manuteno de software. Essa necessidade traz consigo problemas originados de diversas

manuteno de software ainda no meio acadmico, antes que os alunos se tornem

FIGURA 1.1: MODELO GERAL DO DESENVOLVIMENTO DESTE TRABALHO

Em um primeiro momento, por meio de um estudo de caso em uma organizao do

International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC).

1.3 Organizao do Trabalho

2.2 Atividade de Manuteno de Software

Captulo 2 Manuteno de Software

software. Trata-se de um tpico importante para esclarecer alguns pontos pertinentes ao

S-systems, na nomenclatura adotada pelo autor.

Captulo 2 Manuteno de Software

Um software integrante da terceira classificao corresponde quele criado com base

Organizao Cliente: essa organizao corresponde ao adquirente do software,

Mantenedor: trata-se da organizao que oferece o servio de manuteno.

Usurio: representa a organizao ou pessoa que utiliza o software em questo,

de um fluxo para os pedidos de manuteno, conforme esquematizado na figura 2.1.

A organizao solicitante deve possuir algum responsvel pela solicitao de

Captulo 2 Manuteno de Software

responsvel dever considerar os erros e dificuldades apontadas pelo help-desk, que

2.2.2 Evoluo de Software

Institute of Electrical and Electronics Engineers.

Captulo 2 Manuteno de Software

Do ingls, laws of software evolution.

Captulo 2 Manuteno de Software

Captulo 2 Manuteno de Software

2.2.3 Natureza e Caractersticas

FIGURA 2.2: CURVA DE ESFORO PARA MANUTENO DE SOFTWARE (ADAPTAO DE BHATT

Captulo 2 Manuteno de Software

Um modelo de ciclo de vida de manuteno de software proposto por Kung e Hsu

2.2.4 Tipos de Manuteno

Manutenes do tipo corretivas visam corrigir defeitos de funcionalidade, o que inclui

Captulo 2 Manuteno de Software

Manutenes do tipo adaptativas referem-se a adequar o software ao seu ambiente

Manutenes do tipo perfectivas tm por objetivo acrescentar novos recursos de

prope uni-las em uma nica denominada aprimoramentos7. Essa classificao estaria de

Captulo 2 Manuteno de Software

Para efeito de estudo, neste trabalho ser considerada a classificao de tipos de

2.2.5 Custos e Desafios

Captulo 2 Manuteno de Software

neles empregada est ultrapassada. Esses sistemas representam ativos importantes da

2.3 Norma ISO/IEC 12207

Captulo 2 Manuteno de Software

FIGURA 2.4: ESTRUTURAO DA NORMA ISO/IEC 12207

Ao todo so trs categorias, totalizando dez grupos de processos com 47 processos no

Grupo de Processos de Aquisio

Grupo de Processos de Gerncia

Grupo de Processos de Fornecimento

Grupo de Processos de Melhoria de

Grupo de Processos de Engenharia

Grupo de Processos de Recursos e Infraestrutura

Grupo de Processos de Reuso

Grupo de Processos de Operao