Implementando um Processo de Manutenção de

Software para Organizações Tradicionais

Lucas Itamar da Costa

Stellio Matos Mineiro

RESUMO
 Em avanço constante, a Engenharia de Software vem tentando atingir
níveis mais altos de qualidade definindo modelos para melhoria dos processos
de desenvolvimento, buscando softwares que atendem totalmente os requisitos
do usuário final, com o menor número de falhas e com menor custo possível.
Mas a qualidade dos produtos de software não pode estar somente vinculada
aos processos de construção e aos produtos produzidos por esses processos,
pois não há garantia que esta qualidade se propague por toda vida útil deste
software. Existe uma real necessidade de modelos de qualidade para a fase de
manutenção de software visando processos que garantam a qualidade durante
esta fase, amenizando a deterioração da qualidade a partir do momento que o
software for implantado e começar a sofrer manutenções. Esses modelos de
qualidade já podem ser evidenciados em alguns padrões e normas de
qualidade nacionais e internacionais. Visando atender esta necessidade, este
trabalho apresenta uma proposta de processo de manutenção de software para
possibilitar a continuidade da qualidade dos serviços e produtos de software
após a sua entrega ao usuário final, apoiado por uma ferramenta automatizada
de gerenciamento de worflows, e tendo como base uma organização tradicional
que desenvolve e mantém software.

ÍNDICE

1. INTRODUÇÃO ..................................................................... 02

2. QUALIDADE DE SOFTWARE ............................................ 03

3. MANUTENÇÃO DE SOFTWARE ........................................ 05

4. CONTEXTUALIZAÇÃO ....................................................... 06

5. PROPOSTA DE PROCESSO DE MANUTENÇÃO ............ 07

5.1 Processos chaves ocorridos durante a manutenção .............. 07
5.2 Documentação de apoio aos processos ................................... 09
5.3 Utilização do software como ferramenta automatizada ........... 09
5.4 Sugestão de mudanças na cultura da empresa ....................... 09

6. CONCLUSÃO ...................................................................... 10

7. REFERÊNCIAS BIBLIOGRÁFICAS ................................... 11

8. ANEXOS ............................................................................. 12

2
 INTRODUÇÃO
Existe, atualmente, uma grande atenção voltada para melhoria da
qualidade dos produtos de software. Muitas organizações buscam e utilizam,
de forma constante, modelos e padrões para alcançar níveis mais altos de
qualidade dos seus produtos[1]. A maioria destes modelos confere a qualidade
do software ao processo de construção e aos seus resultados. Porém, essa
qualidade alcançada no final do processo de desenvolvimento do software não
tem garantia da sua própria extensão durante toda a vida útil deste software.
Dessa forma, a utilização de um modelo de qualidade para o processo de
desenvolvimento de projetos de software não assegura um processo de
manutenção com qualidade, havendo necessidade de modelos próprios para
essa fase do ciclo de vida do software.
É interessante é que a fase do ciclo de vida do software que, na maioria
dos casos, consome mais recursos, humanos e financeiros, das organizações
que produzem softwares, é a que menos atenção recebe no planejamento do
desenvolvimento do software. Essa desatenção gera muitas dificuldades para a
realização das futuras manutenções. A falta de documentação mínima, um
controle de alterações e configurações deficiente, a descriminação das equipes
de manutenção são algumas dessas dificuldades que acarretam em um grande
obstáculo para dar continuidade na qualidade das atividades e produtos
gerados pela fase de manutenção. Além disso, a falta de um modelo próprio,
de treinamentos específicos ou de ferramentas adequadas influencia
negativamente nos processos de manutenção. Dessa forma, as manutenções
no software, após sua entrega, deverão ser realizadas utilizando-se algum
modelo de qualidade para evitar que a qualidade adquirida no processo de
desenvolvimento se adultere. É importante entender que empregar o mesmo
modelo de qualidade do desenvolvimento pode tornar o processo de
manutenção inviável por custar mais e ser mais demorado que a própria
manutenção, na maioria dos casos. Buscando garantir um melhor e maior
controle dos serviços e produtos envolvidos na fase de manutenção, esse
trabalho foca a definição de um processo de manutenção de software como
solução, total ou parcial, das dificuldades existentes.
Através deste papel, nós apresentamos uma proposta de um processo
de manutenção software, para atividades de manutenção tanto corretivas,
adaptativas e perfectivas. Essa proposta apresentada compreende também na
demonstração de uma ferramenta automatizada que dará suporte para as
atividades de manutenção durante o processo e relata a necessidade da
mudança da cultura das organizações que desenvolvem e mantém softwares, a
partir do relato breve da atual situação de uma organização tradicional.
Este trabalho se divide em 6 seções. Após esta introdução, relatamos
sobre qualidade de software e apresentamos alguns modelos, destacando os
padrões para processo de manutenção. Na terceira seção justificamos a
necessidade de um processo de manutenção bem definido para controle e
organização das atividades e documentos envolvidos. A contextualização de
uma organização, que servirá de exemplo para nossa proposta, é apresentada
na seção 4. Na quinta seção apresentamos a proposta do processo de
manutenção, com a definição das atividades principais, os documentos
necessários e envolvidos e a utilização de um software como ferramenta
automatizada para controlar as atividades. A necessidade da mudança na
cultura interna da organização também é relatada nesta seção. Finalmente, a
seção 6 apresenta as conclusões do trabalho.

3
 QUALIDADE DE SOFTWARE
Primeiramente, o que é qualidade?
Existem muitas definições, mas segunda a norma brasileira sobre o
assunto (NBR ISO 8402), qualidade é a totalidade das características de um
produto (bem ou serviço) que lhe confere a capacidade de atender às suas
próprias condições e objetivos propostos e de satisfazer às necessidades
diferenciadas de seus usuários, evolução de tempo, questões de segurança,
etc.
A qualidade não é importante apenas por ser um diferencial dentro do
mercado para que a empresa possa vender e lucrar mais, mas também por se
tornar um pré-requisito que qualquer organização deve atender e conquistar
para conseguir colocar seu produto no mercado global.
Na área de software, há uma maior preocupação sobre qualidade, visto
que a evolução desta área se deu de uma forma muito rápida, que hoje o
produto gerado por ela assumiu um papel muito importante na sociedade e que
qualidade é o sucesso para o negócio, como em qualquer outro.
Essa preocupação com a qualidade de software é essencial já que
qualidade é[2]:
a) Competitividade: a melhor forma de diferenciar seus produtos dos
produzidos pelos seus concorrentes;
b) Sobrevivência: clientes querem qualidade. Sem esse fator sua
organização perder mercado.
c) Custo/Benefício: a melhor forma de aumentar produtividade e
aumentar a qualidade do software, reduzindo os custos.

Devido a alta complexidade da estrutura de um software, era muito difícil

definir um modelo, um padrão ou forma de controlar a sua qualidade. Muitas
pessoas acham que criar programas é uma arte e não pode seguir regras,
normas ou padrões, já que não tem produção em série, não se desgasta com o
tempo e nem se modifica com o uso. Isso gerou um desacordo entre os
profissionais da área.
Apesar disso tudo, deve-se entender que o problema não é o produto
software em si, mas a maneira como os produtores têm desenvolvido o mesmo
até agora. Hoje em dia, muitos esforços estão sendo gastos para definir uma
base para poder qualificar corretamente um software.
Essa base, ou sistema de qualidade de software, para ser eficiente, deve
utilizar boas práticas baseadas nos seguintes princípios[2]:
• Princípio de qualidade
- Prevenir defeitos ao invés de consertá-los;
- Garantir rapidez na correção de defeitos que foram encontrados;
- Determinar e eliminar as causas e os sintomas dos defeitos;
- Auditar as atividades de acordo com padrões e procedimentos
previamente estabelecidos;
• Princípios de Gerência
- Estabelecer regras e responsabilidades;
- Planejar o trabalho;
- Trilhar o progresso através de planos e corrigir quando
necessário;
- Refinar o plano sempre e progressivamente;

4
 • Princípios de engenharia
- Analisar o problema antes de desenvolver a solução;
- Quebrar problemas complexos em problemas menores;
- Garantir que subproblemas unam-se pelo controle de seus
relacionamentos

Outra preposição importante é a abrangência do sistema de qualidade

dentro do processo de software.
A qualidade deve acompanhar todas as fases do ciclo de vida do
software, como a definição de requisitos, criação e gestão de documentos,
desenvolvimento e serviço de suporte ao usuário, por exemplo, garantindo que
cada uma seja realizada da melhor forma possível. E para isso o sistema de
qualidade deve seguir uma padronização, regras e normas.
Existem várias padronizações determinadas e normalizadas por
organismos próprios, reconhecidos internacionalmente como:
• ISO – International Organization for Standardization
• IEEE – Instituto de Engenharia Elétrica e Eletrônica
• ABNT – Associação Brasileira de Normas Técnicas

Essas instituições criaram normas e padrões para permitir a correta

avaliação de qualidade tanto de produtos de software quanto de processos de
desenvolvimento de software. Através desta avaliação, elas emitem o
certificado de qualidade indicando que uma organização possui conformidade
com uma norma ou padrão determinado.
Dentre as principais normas nacionais e internacionais para processo de
software, destacam-se:
- ISO 9126: Qualidade de Produtos de Software;
- NBR 13596: Versão Brasileira da ISO 9126;
- ISO 12119: Qualidade de Pacotes de Software (Software de
prateleira);
- ISO 12207: Qualidade do Ciclo de Vida de Processo de Software;
- NBR ISO 9001: Sistema de Qualidade – Processos;
- NBR ISO 9000-3: Gestão de Qualidade – Aplicação da ISO 9000
para Processo de Desenvolvimento de Software;
- CMM: Capability Maturity Model – Qualidade do Processo de
Desenvolvimento de Software;

A ISO/IEC 9126 foca a qualidade dos produtos de software. Essa norma

foi publicada em 1991 e possui sua tradução para o Brasil, publicada em
agosto de 1996, como NBR 13596.
Ela determina um conjunto e características e subcaracterísticas que
devem ser verificadas em um software para que o mesmo seja considerado um
“software de qualidade”. São seis grandes grupos de características, cada um
dividido em algumas subcaracterísticas, conforme tabela I (em anexo).
A norma internacional ISO/IEC 12207 foi publicada internacionalmente
em 1995 e no Brasil, a NBR ISO/IEC 12207, em 1998. O seu principal objetivo
é determinar uma estrutura comum de processos de software, bem como
descrever as melhores práticas de engenharia e gerenciamento de software.

5
 Nessa norma, os processos do ciclo de vida do software são agrupados
em 3 classes que são definidas por um conjunto de processos de acordo com a
estrutura da tabela II (em anexo).
Como destacamos, tanto a ISO 9126 como a ISO 12207 definem, dentro
das suas estruturas, seções para o processo de manutenção de software,
propondo padrões e modelos para aumentar a qualidade das atividades e dos
produtos gerados durante a fase de manutenção, garantindo a qualidade final
do software também após sua implantação, e durante o seu ciclo de vida.

1. MANUTENÇÃO DE SOFTWARE
A manutenção de software não pode ser vista apenas como uma fase
dentro do processo de desenvolvimento de software e sim como uma nova
iteração dentro do ciclo de vida do software.
O processo de manutenção de software é um conjunto de atividades de
adaptação, melhoramento, evolução, adequação ou correção do software, e
dos artefatos envolvidos, perante o mundo real a os requisitos reais do seu
usuário final, que envolve todas as fases do processo de desenvolvimento
como análise, projeto, implementação, teste, documentação, integração, etc.
Atualmente percebeu-se a necessidade de uma maior atenção para
esse tema, visto que a manutenção é uma fase inevitável e a mais longa do
ciclo de vida de um software e por gerar um grande custo a qualquer
organização que mantém softwares chegando a consumir até 65% do custo
total de um produto[4]. Dessa forma as normas internacionais de qualidade já
destacam padrões e modelos que definem e classificam a manutenibilidade de
um software, que é o atributo que caracteriza a facilidade de modificação e
adaptação do mesmo, e as atividades que definem o processo de manutenção.
Existem muitos problemas que podem dificultar a atividade de
manutenção, especialmente para os softwares mais antigos, como:
• A falta de documentação ou documentação incompleta ou defasada;
• Falta de disponibilidade dos desenvolvedores para esclarecimentos
sobre o software;
• Módulos fortemente integrados;
• Códigos fontes complexos;
• Falta de controle de configuração do software;
• Etc.

Na maioria das organizações, que produzem e mantém softwares, essas

dificuldades não determinam a desativação de sistemas e, por esta razão,
devem ter uma preocupação maior no desenvolvimento e tentar alcançar os
seguintes objetivos[4]:
• Entendimento da importância da manutenção e a determinação de
requisitos de manutenibilidade pelos usuários e desenvolvedores;
• Elaboração de documentação mínima exigida para auxiliar o
processo de manutenção;
• Manter disponível todas as informações sobre o software para todas
as pessoas envolvidas;
• Elaborar um processo de manutenção, se possível, suportado por
ferramenta automatizada;

6
 Sobre esta última meta, processo de manutenção visa facilitar a
adequação das alterações em itens de software, minimizando os esforços da
fase de manutenção e permitindo, de forma ampla, suportar manutenções
corretivas, adaptativas ou perfectivas. Esse processo deve garantir[5]:
- A documentação de todos os pedidos de manutenção;
- Realização/Execução dos pedidos de manutenção
através de atividades sequenciais bem definidas;
- Controle e organização de versões e variantes de cada
artefato identificado;
- Registro de todas as alterações aplicadas para gerar
históricos;
Como a origem dos pedidos de manutenção pode ser as mais variadas
possíveis, desde uma necessidade real do usuário a alterações legais, é
importante que haja um processo formal, controlado e documentando, para que
as alterações sejam efetivadas ou ignoradas, registrando-se as informações
independentes da aceitação dos pedidos.
Com o objetivo de atender a necessidade de um melhor controle e uma
melhor organização das atividades e dos documentos envolvidos na fase de
manutenção de software, elaboramos um modelo de processo de manutenção
software para uma organização de software descrita a seguir.

2. CONTEXTUALIZAÇÃO
A empresa em questão tem como principal atividade o desenvolvimento
de um sistema único de atendimento a clientes, telemarketing, controle de
tarefas internas e CRM. Como filosofia adotada, a empresa não vende um
produto pronto mas uma ferramenta que se adeqüe à necessidade de cada
cliente. Sendo assim, apesar de ser comercializado apenas um produto de
software, este è adequado às necessidades individuais de cada organização
que o adquire.
Após a implantação do software, é oferecido um contrato de
manutenção sem restrições. Isto é, o valor mensal pago permite que o cliente
solicite qualquer tipo de alteração, seja no aplicativo em si ou nos relatórios
emitidos, desde que estas mudanças não alterem a finalidade principal do
software.
Quanto à equipe envolvida no processo, esta se resume a apenas duas
pessoas. Uma delas tem como função a análise das alterações solicitadas e
sua implementação. A outra é responsável pela implantação do sistema,
treinamento dos usuários e levantamento dos novos requisitos.
Devido à pequena equipe, existência de quatro contratos de
manutenção e à ausência de qualquer processo definido de implementação e
manutenção, a empresa tem enfrentado alguns problemas de insatisfação dos
usuários e estouro de cronogramas. Isto também tem feito com que a pessoa
responsável pelo levantamento de requisitos tão tenha executado esta função.
Sendo assim, toda solicitação é feita através de e-mail, sendo enviada
diretamente do cliente ao analista, e este fica responsável pela verificação da
solicitação, sua implementação e testes.
Além dos quatro contratos existentes, a empresa também dá
manutenção em sistemas de clientes que não pagam mensalmente, sendo
estes cobrados por hora.

7
 De fato, a falta de processos definidos de manutenção, além de
prejudicar a empresa frente aos seus clientes atuais, também tem impedido
que novos projetos sejam iniciados.
À partir do contexto apresentando, o esquema abaixo descrito tem como
finalidade propor um modelo de processo de manutenção que padronize a
solicitação das alterações, sua implementação e testes, buscando aumentar a
satisfação dos clientes e melhorar a qualidade do software produzido.

Proposta de processo de manutenção

O modelo de manutenção proposto implica no levantamento dos
processos chave executados durante a manutenção e sua padronização,
usando como ferramenta de apoio um software de workflow, desenvolvido pela
própria empresa. Porém, apesar deste modelo tentar solucionar ou pelo
menos, à princípio, amenizar os problemas enfrentados pela empresa de
desenvolvimento, para que ele seja eficaz, também é necessário que haja uma
mudança de cultura na organização. À partir deste pressuposto, esta proposta
se divide em quatro partes:
• Elaboração dos processos chave ocorridos durante a manutenção
• Definição da documentação de apoio ao processo
• Utilização do software como ferramenta de automatização dos processos
• Sugestão de mudanças na cultura da empresa

2.1 Processos chaves ocorridos durante a manutenção

Os processos podem ser divididos de acordo com as seguintes fases

ou situações:
a) Recebimento da solicitação de manutenção
b) Análise introdutória da solicitação de manutenção por um
analista
c) Atendimento da solicitação de manutenção pertinente
d) Análise conclusiva da solicitação de manutenção
e) Conclusão da solicitação de manutenção
E cada situação pode possuir algumas atividades conforme diagrama
apresentado na Figura 1 (em anexo).

a) Recebimento da solicitação de manutenção

Nesta fase a solicitação de manutenção é enviada pelo

cliente e é recebida pela organização. O cadastro da solicitação
no sistema poderá ser realizado diretamente pelo cliente, através
de um formulário via WEB, ou por contato ao centro de
atendimento ao cliente, disponibilizado pela organização, que
cadastrará as informações da solicitação.

b) Análise introdutória da solicitação de manutenção por um

analista

Nesta fase a solicitação é analisada por um analista que

determina se a mesma é pertinente ou não. Se pertinente, o

8
 analista identifica os artefatos envolvidos e a solicitação é
encaminhada para um desenvolvedor para que seja atendida. Se
não for pertinente, a solicitação é concluída e o analista envia
uma resposta para o cliente.
Atividades:

Avaliação da solicitação pelo analista: Neste processo o analista verifica se

alteração é pertinente ou não. Verifica se o que foi solicitado realmente requer
uma alteração verificando:
- Existência de erros do sistema;
- Falta dos recursos solicitados;
- Ou se a solicitação não foge do objetivo do contrato de manutenção.

Analista responde ao cliente: Este processo ocorre quando a alteração não é

pertinente. O analista deve responder ao cliente informando o que deve ser
feito para que sua necessidade seja atendida ou sobre a inviabilidade da
implementação.

Registro da solicitação não atendida: Neste processo registra-se a

solicitação não atendida no histórico do cliente. Serão registrados os dados da
solicitação e as causas e motivos que impossibilitaram seu atendimento.

Levantamento dos artefatos: Nesta fase verificam-se quais documentos,

classes, módulos, formulários e demais artefatos que deverão ser alterados
para atender à solicitação do cliente. Uma lista dos artefatos a serem
manipulados é preparada.

Seleção do responsável: Nesta fase o analista seleciona o programador ou

equipe de programadores que melhor se enquadra no perfil requisitado pela
manutenção. É necessário que o analista tenha um bom conhecimento de sua
equipe e do problema em questão.

Criação da tarefa: Esta fase dá início aos processos internos de

desenvolvimento dentro da empresa. Considerando o uso de uma ferramenta
de workflow, esta fase considera a criação de uma pendência na lista de
tarefas do responsável pela implementação.

c) Atendimento da solicitação de manutenção pertinente

A solicitação de manutenção pertinente e a lista de

artefatos envolvidos são recebidas por um desenvolvedor que
deverá fazer as alterações necessárias possíveis para atender a
solicitação do cliente.
Atividades:

Implementação das alterações: Nesta fase, o programador responsável faz

as devidas alterações no código. Além disso, deve ser criado um “checklist”
com os itens alterados e o que eventualmente possa ser testado. Este
“checklist” será usado pela equipe de testes, para que esta possa validar o que
foi feito.

Teste dos itens alterados e implementados: Consiste na validação do

“checklist” criado pelo programador e também no teste de outras possíveis
situações não previstas no “checklist”. Caso haja qualquer falha na
implementação, esta deve ser relatada ao desenvolvedor para que seja feita a
correção. Esta fase pode entrar num ciclo com o processo de implementação,
até que os testes validem todos dos itens alterados.

9
 d) Análise conclusiva da solicitação de manutenção

Após a resolução da solicitação de manutenção pelo

desenvolvedor, a mesma deverá ser analisada novamente pelo
analista que deverá atualizar os documentos envolvidos no
processo e deverá apresentar uma nova análise concluindo se a
solicitação foi atendida completamente, parcialmente ou não foi
atendida, realizando testes. No caso de solicitação parcialmente
atendida ou não atendida as causas deverão ser apresentadas.
Atividades:

Atualização da documentação: Este processo também utiliza o “checklist” do

desenvolvimento para fazer as alterações definitivas na documentação do
sistema, de forma que esta esteja sempre atualizada. As versões antigas
também devem ser armazenadas, para que seja criado um histórico dos
documentos.

Controle de configuração: Consiste na atualização das versões do software.

Caso sejam usados novos componentes ou funções estas devem ser
incorporadas à versão mais atual do software. Além disso, se houver a inclusão
de alguma biblioteca que não exista no cliente, deve-se criar um novo pacote
de instalação para que seja enviado junto com o novo executável.

e) Conclusão da solicitação de manutenção

Nesta fase os artefatos envolvidos são verificados e

validados. Resultados da solicitação são apresentados e a
solução é implantada/integrada ao sistema do cliente.
Treinamentos podem ser necessários nesta fase.
Atividades:

Envio da nova versão ao cliente: Nesta fase, o novo executável e, caso

exista, o novo pacote de instalação são enviados ao cliente. Caso seja
necessário treinamento para utilização do novo recurso, deve-se disponibilizar
uma pessoa para execução desta tarefa.

Finalização da tarefa: Após concluído o processo, finaliza-se as tarefas

armazenadas no sistema de workflow. A partir desta finalização pode-se extrair
informações sobre o tempo gasto em cada uma das fazes, possibilitando a
criação de estatísticas para manutenções futuras.

Avaliação pós entrega junto ao cliente: Após a implantação da nova versão,

pode-se fazer um questionário de avaliação junto ao cliente, para obtenção do
nível de aprovação sobre a manutenção solicitada.

Registro da solicitação atendida: Neste processo registra-se a solicitação

atendida no histórico do cliente. À partir dela pode-se ter acesso a todos os
processos internos que precederam o fechamento da solicitação.

Documentação de apoio aos processos

Utilização do software como ferramenta automatizada

10
 Sugestão de mudanças na cultura da empresa
A implantação, simplesmente, de um processo de manutenção
de software bem definido e com qualidade, não garantirá o sucesso e a
qualidade dos serviços e produtos se não houver um entendimento e
uma aceitação, por parte de todas as pessoas da organização, das
práticas de qualidade na execução dos trabalhos.
Assim, para poder conscientizar todas as pessoas envolvidas,
direta ou indiretamente, da necessidade de se ter uma qualidade de alto
nível e de suas responsabilidades por essa qualidade, um programa
cultural deverá ser executado paralelamente à implantação dos
processos, buscando garantir que as atividades, os documentos e as
ferramentas, definidas no processo, sejam executados, manipulados e
utilizados o mais corretamente possível. Geralmente, utilizam-se
treinamentos e reuniões como ferramentas para discutir qualidade
dentro das organizações.
Nosso plano de mudança cultural visa a delimitação dos
processos e a especificação dos papéis dentro dos processos,
especialmente no processo de manutenção.
Na delimitação dos processos deverá haver uma distinção entre
os processos de desenvolvimento e o processo de manutenção. Cada
processo deve ser bem definido e separado para que não haja
confusões nas atividades realizadas e não se perca o foco de cada
processo, já que cada um utiliza modelos próprios de qualidade. A
definição do processo de manutenção é caracterizada pela implantação
da proposta descrita nesse trabalho acompanhado de treinamentos para
esclarecer e orientar, as pessoas envolvidas, sobre a utilização das
técnicas e ferramentas aqui apresentadas.
A especificação de papéis visa determinar as funções
representadas dentro do processo. Um papel é uma função realizada por
uma pessoa, em um determinado momento do processo, independente
do seu cargo dentro da organização, ou seja, uma mesma pessoa pode
ser o analista, o desenvolvedor e mantenedor de um software, desde que
fique realmente claro onde, como e quando cada papel deverá ser
representado dentro do processo. Na organização demonstrada acima,
há a necessidade de uma ampliação na equipe e uma melhor definição
dos papéis dentro do processo de manutenção. As atribuições relativas a
cada papel devem ser descritas claramente e as atividades deverão ser
executadas conforme definido no processo de manutenção.
A partir da implantação do processo de manutenção, deverá haver
também, como parte do plano de mudança cultural, iniciativas da
administração e dos colaboradores da organização para aprimorar o
processo e aumentar o incentivo das pessoas envolvidas para realizarem
tarefas melhores e com mais qualidade.

CONCLUSÃO
Existe hoje, na área de produção de software, uma maior atenção
voltada para padrões de qualidade de produtos e serviços, visando
acompanhar os requisitos do mercado e atender as necessidades reais dos
clientes. Porém, o produto software possui características próprias bem
distintas e se difere de outros produtos que possuem linha de produção e

11
padrões já bem definidos de qualidade.
A Engenharia de software vem buscando modelos e padrões para
melhorar os processos de desenvolvimento dos produtos, tentando atingir
níveis mais altos de qualidade. Mas a qualidade do produto de software não
está apenas na sua produção e nos resultados por ele gerados, mas também
nos processos de manutenção desse produto, após sua entrega, que visa a
extensão dessa qualidade por toda vida útil do software, tentando sempre
corrigi-lo, adaptá-lo e aprimorá-lo para melhor atender às necessidades reais
de seus usuários e de seu ambiente, necessidades essas que se modificam
com o passar do tempo.
Deve-se entender que para garantir a qualidade do software durante sua
manutenção, devemos utilizar um modelo, um padrão de qualidade, como no
processo de desenvolvimento, para garantir a continuidade dos níveis de
qualidade dos serviços e produtos gerados após a entrega.
Neste trabalho apresentamos uma proposta de um simples processo de
manutenção visando atender as necessidades de organizações tradicionais
que desenvolvem e mantém softwares. Foram descritas as atividades
necessárias para atender uma solicitação de manutenção de um cliente,
iniciando à partir do recebimento da solicitação até sua conclusão. Alguns
documentos utilizados para dar apoio às atividades foram apresentados, bem
como uma ferramenta automatizada para gerência da seqüência das
atividades. Relatamos também a necessidade de uma mudança de cultura
dentro da organização, para conscientizar todas as pessoas envolvidas da
necessidade de se registrar todas as solicitações dos clientes, documentar as
alterações e, conseqüentemente, alcançar níveis mais altos de qualidade e
satisfação.

REFERÊNCIAS BIBLIOGRÁFICAS

[1] CAPELLI, Claudia; BORGES, Marcos R. S.; ARAUJO, Renata. Qualidade

do Processo de Manutenção de Software. Process Improvement
Technology; NCE & IM / UFRJ, 2000;

[2] FILHO, Vivaldo Mason. Qualidade de Software. Automotive Informatica,

1998;

[3] WEBER, Kival Chaves; ROCHA, Ana Regina Cavalcanti da; ABREU, Maria
Célia de. Qualidade e Produtividade em Software. 3 ed. MAKRON Books do
Brasil Editora Ltda, São Paulo, 2001.

[4] CORDEIRO, Marco Aurélio. Manutenibilidade de Software. Companhia de

Informática do Paraná – CELEPAR.

12
[5] GREYCK, Márcio. Material Didático apresentado nas aulas de
Manutenção de Software do Curso de Gestão em Tecnologia da
Informação. Faculdade ALFA, 2004;

ANEXOS
FIGURA 1

13
 TABELA I

Característica Subcaracterística
Adequação
Acurácia
Funcionalidade
Interoperabilidade
(satisfaz as necessidades?)
Conformidade
Segurança de acesso
Maturidade
Confiabilidade
Tolerância a falhas
(é imune a falhas?)
Recuperabilidade
Inteligibilidade
Usabilidade
Apreensibilidade
(é fácil de usar?)
Operacionalidade
Eficiência Tempo
(é rápido e “enxuto”?) Recursos
Analisabilidade
Manutenibilidade Modificabilidade
(é fácil de modificar?) Estabilidade
Testabilidade
Adaptabilidade
Portabilidade Capacidade p/ ser instalado
(é fácil de usar em outro ambiente?) Conformidade
Capacidade para substituir

TABELA II

Processos Fundamentais Processos de Apoio

Aquisição Documentação

Fornecimento Gerência de Configuração

Garantia da Qualidade

Operação Verificação

Validação
Desenvolvimento
Revisão Conjunta

Manutenção Auditoria

Resolução de Problema

Processos Organizacionais

Gerência Infra-estrutura

14
Melhoria Treinamento

15