Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Na edição 33 da Engenharia de Software Magazine, conhecemos as características, tipos e desafios para a manutenção de software. Além disso, destacamos também as dificuldades encontradas na realização das atividades de manutenção de software. Para isso, um estudo de observação que foi conduzido com o objetivo de verificar os problemas de manutenção de software existentes em uma organização empenhada no desenvolvimento de software comercial.

Dando continuidade à discussão sobre o assunto, apresentaremos neste artigo algumas alternativas de respostas para os problemas de manutenção apresentados na edição anterior. Estas alternativas estão embasadas em três fontes distintas: na norma ISO/IEC 12207, nas soluções encontradas na organização analisada no estudo de caso, e nas propostas de outros autores que se dedicaram ao assunto.

Acredita-se que a norma seja um excelente veículo para conduzir uma organização de software pelas melhores práticas, já que seu conteúdo é resultado de um esforço fundamentado no que poderia se chamar estado-da-arte da engenharia de software. Outra consideração importante diz respeito à maneira como a norma se apresenta. Ela não é 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 alcançado. Dessa forma, a norma funciona como um guia para ser seguido por organizações interessadas em tratar sistematicamente seu processo de software.

O estudo de caso apresentado no artigo da edição passada será estendido neste artigo, expondo agora práticas adotadas pela organização que trouxeram resultados satisfatórios para a prevenção ou contenção de problemas de manutenção de software em seu ambiente de trabalho.

Extensão do Estudo de Caso

Neste tópico é apresentada a extensão do estudo de caso apresentado no artigo publicado na Engenharia de Software Magazine edição 33.

Essa extensão foi possível graças à constatação de que a organização estava em busca freqüente por melhorias em seu ambiente de trabalho, e em sua capacidade de resposta satisfatória aos clientes, que vinham crescendo em número, sem, no entanto, valer-se da adoção de um processo extenso e sistemático como o sugerido pela norma ISO/IEC 12207.

O objetivo foi verificar quais mudanças a organização vinha adotando no seu dia-a-dia que estivessem contribuindo positivamente para a diminuição de seus problemas de manutenção de software, ou ainda, o que os profissionais empenhados nessa atividade achavam que deveria ser feito para que essa redução ocorresse.

Metodologia

A metodologia aplicada na extensão do estudo de caso também foi baseada em questionários e entrevistas. O intuito principal desses questionários foi o de servirem para a abertura de uma discussão na qual exemplos de soluções eficientes fossem citados pelos entrevistados. Como o objetivo era que a organização mostrasse quais atitudes vinha adotando para tratar de maneira satisfatória sua atividade de manutenção, não havia como estipular questões prévias, por isso o questionário reduzido funcionou somente como recurso para início de entrevista.

De fato, as soluções citadas, bem como observações e todas as informações relevantes para o contexto da entrevista, foram registradas pelo entrevistador em documento a parte e posteriormente compiladas.

Soluções Identificadas

Os resultados obtidos foram organizados e utilizados para elaborar os itens a seguir, que apresentam soluções apontadas pelos entrevistados como favoráveis para a atividade de manutenção de software, contribuindo para reduzir um ou mais dos problemas conhecidos.

• Melhoria em treinamento: uma prática relevante adotada pela organização diz respeito a treinamento. A solução 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 certificações. A partir desse levantamento, a organização se comprometeu em comprar os livros necessários à preparação para alguns exames de certificação oficial. Como exemplo, tem-se uma das modalidades de certificação de DBA SQL Server da Microsoft. O gerenciador de banco de dados SQL Server corresponde ao utilizado pela organização, e sua configuração correta, seja em termos de desempenho ou de funcionalidades, é de fundamental importância. Assim, a organização comprou os livros necessários à preparação, e que normalmente têm um custo relativamente alto, se comprometendo ainda a reembolsar o valor pago para realização do exame, caso o profissional fosse aprovado. No momento das entrevistas, algumas pessoas já haviam conseguido aprovação no módulo inicial da certificação. Esse conhecimento adicional em banco de dados é de relevância para manutenção, já que o software da empresa tem muitas partes implementadas na forma de stored procedures, e muitas das manutenções são efetuadas nesses componentes;

• Gerenciamento do conhecimento: ligado diretamente ao problema da rotatividade elevada, a organização vinha se empenhando em sistematizar os problemas de manutenção, principalmente os problemas de atendimento ao cliente via suporte e help-desk, montando uma base de conhecimentos onde fosse possível consultar as soluções possíveis para um problema freqüente. Para isso, uma ferramenta web de colaboração on-line foi instituída, e nela registrado, na forma de perguntas e respostas, as maneiras de abordar inúmeros problemas. A atitude gerencial inicial para a composição das primeiras questões dessa base foi a obtenção, junto à equipe de suporte, de uma lista de problemas mais comuns. O passo seguinte foi reunir consultores da empresa que trabalham na cidade de São Paulo, para em reuniões conjuntas entre equipe de suporte e consultores, elaborar as primeiras respostas à lista de problemas de suporte. Tais questões foram posteriormente inseridas na ferramenta web, de forma que qualquer pessoa dentro da organização pudesse ter acesso e editar seu conteúdo, como forma de complementação;

• Melhoria na documentação oferecida ao cliente: da mesma forma que foi criado um repositório de problemas e soluções para a própria organização, também se criou algo semelhante em relação aos clientes. Com o uso da mesma ferramenta web, uma interface de consulta foi disponibilizada aos clientes, permitindo a obtenção de respostas a problemas comuns que o suporte vinha reiteradas vezes atendendo, com uma linguagem padronizada e uniforme. Questões de caráter técnico, que envolvesse informações de código-fonte ou configuração de banco de dados, não ficavam disponíveis aos clientes (essa classificação de o que o cliente podia consultar e o que não podia, era feita principalmente pela equipe de suporte, mas de uma forma geral todos podiam interferir);

• Padronização no fluxo de informações: buscando corrigir problemas de comunicação com os usuários, muitas vezes por motivos de o usuário informar partes de seu problema para pessoas diferentes do suporte, o que tornava a compreensão do todo dificultada e muitas vezes gerava insatisfação desse cliente, foi uniformizada a maneira como esse tipo de informação fluiria na organização. O fluxo estabelecido foi o seguinte: todo problema de software deveria ser primeiramente cadastrado no sistema de help-desk, para então algum contato via telefone ou e-mail poder ser estabelecido. O sistema de help-desk possuía recurso de interação entre usuário e suporte, registrando-se ali (e não por e-mail, como antes) todas as interações e detalhes do problema em questão. Com isso evitou-se a perda de informações passadas pelo cliente, o que impactava na manutenção, pois chamados de alteração eram estabelecidos sem o devido detalhamento, o que causava má especificação de requisitos de alteração, gerando conflitos do próprio suporte com a equipe de manutenção;

• Melhoria em cronogramas: um dos grandes problemas em manutenção é a questão de prazos e o cumprimento de cronogramas estabelecidos junto aos clientes. A organização, visando minimizar esse tipo de problema, adotou a postura de assumir de fato o cronograma junto ao cliente, garantindo isso da seguinte forma: após serem agendadas as datas de entrega de manutenções, cada profissional responsável pela implementação deveria informar, diariamente, ao coordenador o andamento de suas atividades. Ao menor sinal de contratempos que fossem levar a um não-cumprimento da data de entrega estipulada, o coordenador indicava alguém ou ele próprio assumia a responsabilidade de auxiliar na manutenção para que o prazo fosse cumprido. Essa postura forçou a contratação de novos programadores;

• Divisão de tarefas: o sistema de registro de chamados de manutenções passou a abrigar mais um campo de informação: o nível de complexidade da manutenção, estipulado pelo coordenador. Isso permitiu um melhor controle do problema da sobrecarga de tarefas, o que seguramente foi auxiliado pela contratação de novos programadores;

• Melhoria em testes: essa foi uma das mudanças significativas para a redução do número de problemas de software que acabavam no ambiente de produção dos clientes. A medida adotada foi a de insistir no uso de teste beta (testes pelo cliente, em seu ambiente), porém a maneira de negociação foi alterada. A organização se comprometeu a preparar todo ambiente paralelo ao de produção, necessário para efetuar os testes, sempre que uma versão de testes fosse disponibilizada, ficando a cargo do cliente apenas proceder com os testes, sem necessidade de qualquer configuração de software. O cliente deveria oferecer apenas os recursos de hardware (computador, espaço em disco rígido para replicação do banco de dados de produção etc.). Além disso, a liberação da versão inicial de testes passou a ocorrer somente após revisões mais rígidas realizadas internamente na organização por uma pessoa dedicada exclusivamente a essa tarefa.

Por fim, verificou-se que a questão da documentação interna das manutenções era uma das preocupações da organização, porém ainda sem solução satisfatória implementada, portanto não citada aqui.

Embora não se tenha adotado um processo de manutenção complexo e rígido, a lista de modificações internas citada contribuiu para a diminuição daqueles problemas mais simples e que causavam grande impacto negativo junto aos clientes.

No entanto, uma nova dificuldade parece ter surgido, e também já estava sendo combatido pela gerência através de maiores exigências, 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 soluções adotadas para problemas que ainda não constavam dessa base.

Considerações Gerais

As soluções encontradas pela organização pesquisada não representam o resultado do emprego de alguma norma ou processo bem definido, como dito anteriormente.

Foi justamente esse fato que permitiu utilizar essas soluções como alternativas para abordar os problemas de manutenção de software. Isso porque é importante que seja mostrado tanto o aspecto rigorosamente formal proposto pela norma ISO/IEC 12207, como também alternativas de soluções. É valioso destacar que alternativas como as aqui apresentadas podem até mesmo serem mais viáveis do que a adoção da própria norma, dependendo do porte da organização e de sua estruturação.

O fundamental é que as organizações de software se empenhem em compreender as características e dificuldades de si próprias, buscando continuamente por falhas e possíveis formas de tratá-las, o que muitas vezes pode ocorrer pela simples mudança de atitudes e controle mais rígido de tarefas. O uso de ferramentas de software também é um ponto importante, e nesse exemplo houve o uso de ferramentas para auxílio no tratamento de informações.

Soluções com base na Norma ISO/IEC 12207

O relacionamento entre os problemas de manutenção de software mostrados na edição passada pode ser estendido para especificar também a qual processo do grupo o problema de manutenção de software se relaciona (lembre-se que essa relação é devida ao não cumprimento de tarefas do processo correspondente).

Para criar esse relacionamento, a Tabela 1 foi construída. Nela são apresentados todos os grupos e processos da norma, mostrando em quais desses processos os problemas de manutenção de software se encaixam, de forma individual.