Como mencionado, os formulários eletrônicos para a coleta de métricas e armazenamento de dados são providos por dois softwares – o sistema DMS e o Autoanswer. Esse último é um programa que permite a personalização de campos para cadastramento de chamados de defeitos em software feitos por usuários. Esse aplicativo foi adquirido pelo TST e as equipes de desenvolvedores de software não têm acesso ao seu código fonte.
Já o sistema DMS foi inteiramente projetado e implementado pela unidade produtora de software do TST, o que o faz um sistema com maior potencial de adaptação, se comparado ao software Autoanswer.
Maiores detalhes dessas ferramentas de apoio aos processos de mensuração, e que também auxiliam os novos processos de software, são apresentados no Apêndice L.
5.3.5 Interpretação
Esta seção apresenta os resultados das mensurações do plano GQM criado e faz considerações sobre a melhoria do processo de Gerência de Configuração. Tal programa de mensuração também buscava incrementar o nível de satisfação do usuário com as manutenções solicitadas para o Sistema de Informações Judiciárias (SIJ). Os resultados são baseados em três meses de mensurações, maio, junho e julho de 2002.
Esses resultados são preliminares, nenhuma ação de melhoria do processo ou do programa de mensuração foi tomada. Contudo, espera-se que a análise desses resultados venha futuramente embasar decisões em prol de uma melhoria contínua e progressiva da qualidade de software do TST.
Capacidade de atendimento a pedidos de manutenção
Em primeiro plano, tomando-se como exemplo a questão Q1 e as métricas M1, M2 e M3 pôde-se obter uma projeção da evolução da capacidade de atendimento de pedidos de manutenção para o SIJ nos três meses de medição. Essa informação é importante, na medida em que se deseja mensurar como os novos processos estão colaborando para aumentar a satisfação dos usuários com as manutenções no SIJ. Dessa forma, o gráfico abaixo (Figura 5.16) demonstra que de maio a junho, o nível de satisfação do usuário provavelmente tenha piorado, uma vez que aumentou a fila de pedidos pendentes e diminuiu o número de pedidos atendidos.
Contudo, essa informação deve ser tomada com reserva, considerando que entre maio e junho de 2002 os funcionários do poder judiciário permaneceram em greve, realizando somente atividades emergenciais e com um quantitativo de pessoal 80% menor. Nesse sentido, embora as informações sejam úteis para análises futuras, o gráfico abaixo não espelha a realidade cotidiana da unidade produtora de software no que tange à capacidade de atendimento a pedidos de manutenção de software.
Capacidade de atendimento de pedidos de manutenção
0 5 10 15 20 25 30
maio junho julho
meses Q t. p e d id o s Pedidos pendentes Pedidos em execução Pedidos atendidos
Figura 5.16. Capacidade de atendimento a pedidos de manutenção. Demora no atendimento de pedidos de manutenção
É razoável pensar que a variação do tamanho de uma fila de pedidos de manutenção pode indicar uma melhora ou piora do nível de satisfação do usuário com relação a esse serviço. A mensuração dessa variável ao longo do tempo permite ainda supor o grau de contentamento do usuário em relação ao próprio sistema, na medida em que uma fila muito grande de pedidos de manutenção sugere um software deficiente e com muitos defeitos.
Por outro lado, dada a formalização de vários processos de software na organização, em especial, o de Gerência de Configuração de Software, é preciso saber se os novos procedimentos de trabalho burocratizaram a atividade de manutenção de software na UPS aumentando a fila dos pedidos.
Portanto, o monitoramento do tamanho dessa fila é essencial para permitir a otimização dos novos processos em direção ao aumento da satisfação do usuário.
Abaixo, o gráfico (Figura 5.17) apresenta a evolução do tempo médio em que um pedido permanece na fila de pendentes até entrar em execução e a média de tempo gasto para encerrar um pedido de manutenção em execução.
Enfileiram ento de pedidos
0 200 400 600 800
maio junho julho m eses T e m p o m éd io (h o ra s ) Tempo na fila de pendentes (média) Tempo na fila em execução (média)
Criticidade dos defeitos de software
O conhecimento da complexidade e criticidade dos pedidos de manutenção permite inferir a gravidade dos defeitos com que os usuários estão se deparando, bem como, o grau de competência dos desenvolvedores para solucionarem esses problemas.
Um pedido “fixado” no Quadro de Controle de Mudanças (QCM), por exemplo, sugere um tempo maior para que ele comece a ser executado, uma vez que são necessárias várias pessoas para validá-lo, considerando as implicações advindas de sua implementação. Nessa direção, um número maior de pedidos com o qualificador QCM indica um potencial crescimento do enfileiramento de pedidos.
Nesse contexto, com o auxílio das métricas de contabilização do número de pedidos urgentes e colocados em QCM, foi possível formar uma opinião sobre o peso dessas solicitações para um incremento do tempo gasto nesses atendimentos.
Abaixo, a Figura 5.18 mostra a evolução desses pedidos ao longo do período inicial de mensuração.
Classificação dos pedidos
14 20 41 1 3 1 1 0 5 10 15 20 25 30
maio junho julho
m eses Q t. p e d id o s Pedidos QCM Pedidos urgentes Pedidos comuns
Figura 5.18. Classificação dos pedidos de manutenção. Precisão das estimativas
Como se sabe, a organização não possuía processos formais de software, muito menos gerência quantitativa de processos. Nesses ambientes é difícil predizer o prazo para entrega de artefatos de software. Obviamente que as estimativas são muito imprecisas, pois dependem unicamente da experiência e bom senso dos desenvolvedores.
Contudo, embora inexista qualquer mecanismo totalmente preciso de estimação, os engenheiros de software são obrigados a prever o término de seus projetos. Muitas vezes isso é condição para se obter um relacionamento com usuário capaz de mantê-los no cargo.
Nesse sentido, o sistema DMS representa a primeira iniciativa para a formação de uma base histórica de estimativas, que aliada à repetição dos processos de software da organização, permitirão obter maior precisão nas previsões. De acordo com o Plano GQM criado, a estratégia de mensuração da evolução dessa acurácia levou à necessidade de medir o erro dessas estimativas ao longo do tempo.
O gráfico abaixo (Figura 5.19) permite visualizar a média de erro dessas estimativas. Nota-se que no mês de junho, tal medida aumentou significativamente, provavelmente em razão do atraso imposto a todas as atividades do setor.
Erro médio percentual nas estimativas 0 20 40 60 80 100
maio junho julho
meses E rro ( % ) Erro estimativa (média)
Figura 5.19. Erro médio percentual nas estimativas.
Dessa forma, a gerência e demais lideranças da UPS podem considerar essas informações para firmarem compromissos de entrega de software mais realistas. O fato dos processos de software estarem sendo repetidos também colabora nessa direção.
Indicativo de realização dos novos processos
Vários processos foram formalizados na organização, algumas práticas e ferramentas foram introduzidas, contudo deve se ter certeza que todas as ações de melhoria futuras tenham respaldo nessa arquitetura. Para tal, é necessário garantir que os novos processos de software sejam seguidos.
Uma estratégia para obtenção dessa informação consistiu na contabilização dos pedidos atendidos, do número de emails de homologação recebidos e da quantidade de versões de Configuração de Produção geradas. Em tese, a quantidade de pedidos atendidos deveria ser idêntica à quantidade de emails de homologação recebidos. E a quantidade de versões de configuração deveria estar bem próxima do número de emails de homologação recebidos. Não exatamente igual, para o caso em que um pedido de mudança fosse aprovado no ambiente de homologação, mas não em produção. Isso seria difícil de ocorrer, uma vez que o ambiente de homologação foi criado para simular o ambiente de produção do usuário.
Abaixo, a Figura 5.20 mostra essa mensuração sugerindo que embora os desenvolvedores estivessem em greve, os processos de software, especialmente o de controle de mudanças, foram seguidos.
Repetição dos processos
0 5 10 15 20 25 30
maio junho julho
meses
Pedidos atendidos Qt. emails homologação Qt. versões de Configuração
Manutenções concorrentes
As manutenções simultâneas foram praticamente eliminadas (Tabela 5.4). A única ocorrência dessa natureza se deu em virtude da novidade do processo e pela necessidade de manutenção urgente em um módulo de programa. Contudo, após a segunda semana de maio não houve registro desse problema devido à integral execução do processo de controle de versão e pela ação efetiva dos mecanismos de Checkin, Checkout e Locking do Oracle Repositório. É importante destacar que esse indicador sugere que o número total de defeitos tende a diminuir.
Tabela 5.4 – Resultados do novo processo relativos à métrica M20. M20 Manutenção Simultânea Processo antigo Jan/1997 à abr/2002 META (mensal) Meses
Maio Junho Julho
Quantidade 8 por mês (média) 0 1 nenhuma Nenhuma
Reaparecimento de defeitos
Os mecanismos de controle de versão e de mudanças, formalizados e automatizados, garantem que um defeito corrigido não reapareça em decorrência de conflitos entre versões ou pela perda de informação sobre o estado de um pedido. Nesse sentido, infere-se que a satisfação do usuário tende a aumentar em virtude da eliminação desses problemas.
Em razão da greve e conseqüente subutilização dos sistemas, a probabilidade do aparecimento de defeitos diminuiu juntamente com o número de pedidos de manutenção solucionados. Nesse cenário, a Tabela 5.5 mostra a quantidade de ocorrências dessa natureza.
Tabela 5.5 – Resultados do novo processo relativos à métrica M22. M22 Reincidência de defeito corrigido Processo antigo Jan/1997 à abr/2002 META (mensal) Meses
Maio Junho Julho
Quantidade 4 por mês (média) 0 nenhuma nenhuma nenhuma
Controle de mudanças
O controle de mudanças impede que um pedido seja esquecido ou permaneça na fila de espera indefinidamente. O sistema que trata esses pedidos (sistema DMS) possibilita a redefinição de prioridades se necessário. Isso contribui significativamente para flexibilizar o atendimento a usuários sem perder o controle sobre os pedidos de mudança.
A Tabela 5.6 confirma, já a partir do mês de junho, a expectativa criada para essa métrica.
Tabela 5.6 – Resultados do novo processo relativos à métrica M12. M12 Pedido de mudança esquecido ou perdido Processo antigo Jan/1997 à abr/2002 META (mensal) Meses
Maio Junho Julho
É importante destacar que embora no período de greve haja uma diminuição natural do fluxo de pedidos, tal redução não influenciou a interpretação desse resultado, considerando que o controle provido pelo sistema DMS independe da quantidade de pedidos feitos.
Satisfação do usuário
Todos esses gráficos e tabelas auxiliam na formação de uma opinião segura sobre o nível de satisfação do usuário em relação aos pedidos de mudança na configuração do SIJ.
É importante ressaltar que essa estratégia não utiliza uma medida direta que indique o grau de satisfação do usuário com tal serviço. No momento da definição das métricas GQM, chegou-se a pensar em disponibilizar na Intranet um formulário estruturado que pudesse captar as opiniões dos usuários sobre as manutenções no SIJ. Essa solução previa a criação de atributos discretos como: ruim, boa, muito boa e excelente para avaliar diretamente a satisfação do usuário em relação à manutenção.
Contudo, essa abordagem foi descartada, pois poderia afastar-se da realidade em razão de não haver um controle efetivo sobre a entrada e consistência dos dados. Para realizar tal tarefa seria necessária a criação de mecanismos mais apurados de validação das informações fornecidas pelos usuários. Além disso, o usuário poderia não dispor de tempo suficiente para responder o questionário.
Nessa perspectiva, preferiu-se mensurar o nível de satisfação dos usuários por meio de medidas indiretas, pois acreditava-se que assim fosse possível formar uma opinião mais realista do grau de satisfação deles em relação aos seus pedidos de manutenção. Obviamente, já conhecendo esse nível de contentamento, as decisões no sentido da melhoria contínua seriam tomadas com mais segurança.
Na fase de planejamento da análise da mensuração foram elaborados outros gráficos para interpretação do GQM. Esses elementos formam a arquitetura de comunicação dos resultados das mensurações.
5.4
Lições aprendidas
Ponto de vista tecnológico
A implantação de um processo de gerência de configuração não é trivial. A gerência de implantação desse processo tem de ser efetiva, pois requer muito esforço, principalmente para a modelagem dos processos. Essa tarefa foi crítica especialmente para o caso do TST que teve a sua maturidade da capacidade em software avaliada no nível 1 do CMM.
Foi necessário muito tempo para aprender a lidar com a ferramenta Oracle Repository. Embora a cultura de software da organização esteja baseada em Oracle, as atividades de GC eram totalmente novas e a ambientação com a ferramenta levou tempo. A constatação de que o Oracle Repository não provia acompanhamento de mudanças fez com que a autoridade em GC repensasse a sua adoção como ferramenta de suporte a esse processo. Contudo, a quantidade de esforço já despendido para o seu aprendizado pesou para confirmar a sua escolha.
Além disso, a escolha do Oracle Repository representou fator de risco para o projeto. Foi encontrado um defeito no software quando este trabalhava sob o sistema operacional Windows 98. Essa falha atrasou o cronograma e mostrou a dependência que ainda existe entre os modelos teóricos e práticos das soluções em Tecnologia da Informação. Hoje essa dificuldade está superada, pois o sistema operacional das máquinas foi atualizado para uma versão que eliminou o problema detectado.
Ponto de vista organizacional
Embora todo o processo de mensuração tenha começado num momento em que a instituição passava por um período de greve, e considerando todas as implicações que isso trouxe para as rotinas de trabalho, tais mensurações serviram para mostrar que o processo de análise e interpretação de métricas está consistente e adequado. Mais ainda, que poderá servir para balancear a carga de trabalho em situações similares.
A direção de informática foi sensível em perceber a necessidade de designar servidores exclusivamente para o desenvolvimento do programa de melhoria. Um fator que pode ter contribuído para essa decisão é que esse tipo de consultoria, quando fornecida por pessoal externo, requer considerável soma de recursos e não garante resultados.
Implantar um programa de melhoria apoiado por um programa de mensuração constitui-se num verdadeiro antídoto contra as resistências internas que surgem dessas iniciativas. Nesse sentido, é mais fácil convencer as pessoas a seguirem rigidamente os novos processos se elas estiverem cientes de que a mensuração é instrumento capaz de confirmar a eficiência de um processo ou de extinguir uma prática de software indesejada.
Enfim, essa experiência sugere a viabilidade de se implementar programas de melhoria nos órgãos públicos utilizando recursos humanos próprios. Com a motivação para a qualidade, competência técnica e apoio da direção é possível que a administração pública obtenha resultados satisfatórios.
Nesse contexto, é importante destacar que o TST atualmente possui nos cargos de gerência e diretoria de informática funcionários de carreira que decidem prioritariamente por critérios técnicos. Não existe terceirização de serviços da área de informática. O quadro de analistas e programadores é composto exclusivamente por funcionários selecionados por concurso público. É provável que isso tenha elevado o nível de comprometimento das pessoas com o programa de melhoria. Contudo, o mais importante dessa iniciativa é que sem o apoio incondicional da alta e média gerências as possibilidades de fracasso aumentariam significativamente.
Custo de implantação do GQM
O programa de mensuração GQM é eficiente, mas requer bom planejamento e uma quantidade de horas razoável para a sua implementação. No caso do TST não havia tempo para treinar os servidores nessa metodologia, sendo assim tal programa foi conduzido apenas por uma pessoa – o condutor do programa de qualidade. Os líderes de projeto e o gerente sênior da UPS contribuíram durante as reuniões de qualidade, entretanto as suas participações ficaram restritas à validação de algumas métricas GQM.
Abaixo, a Tabela 5.7 apresenta os custos de implantação do programa GQM implementado no TST. Considera ainda o previsto e o utilizado em termos de pessoas e horas.
Tabela 5.7 – Custo de implementação do programa de mensuração GQM no TST.
Atividade Pessoas Horas
previstas utilizadas previstas utilizadas
1- Preparar o programa de mensuração 6 1 120 480
2- Identificar e definir metas GQM 6 1 40 192
3- Preparar e conduzir entrevistas GQM 2 1 48 20
4- Desenvolver um Plano GQM 1 1 80 240
5- Desenvolver um Plano de Mensuração 1 1 72 185
6- Coletar dados 20 4 8 2
Como se pode perceber, a implantação de um programa de mensuração inédito no TST e a falta de experiência da organização nessa área, levou a previsões de custos pouco precisas. Contudo, essa informação é extremamente útil para esse e outros programas de mensuração futuros, na medida em que contribui efetivamente para a formação de uma base de memória para a organização.
Destaque-se que as atividades 3, 6 e 7 consumiram menos horas do que as previstas inicialmente. Acredita-se que esse fato decorreu da facilidade com que foram obtidas informações pela abordagem GQM, e pelo grau de automatização conseguido na especificação do processo de coleta de métricas. Some-se a isso o elevado nível de detalhes conseguido para o Plano de Análise e Interpretação.
5.5
Considerações finais
A instituição aceitou bem a imposição dos métodos de trabalho peculiares aos programas formais de melhoria da qualidade de software. Isso foi motivado principalmente pelo caráter participativo que permeou todo o processo de melhoria. Ademais a unidade produtora de software mostrou-se receptiva à iniciativa, tendo em vista já estar consciente de seus problemas e da conveniência do momento para aplicação de tal programa.
O novo processo de Gerência de Configuração de Software encontra-se implantado no Serviço de Desenvolvimento e Manutenção de Sistemas do TST. Ele continuará sendo medido, avaliado e melhorado ao longo do tempo. Assim pretende-se garantir a sustentabilidade da solução, na medida em que o processo poderá ser constantemente monitorado e ações corretivas e evolutivas poderão ser tomadas com base em dados objetivos.
A próxima etapa consistirá no armazenamento dessa solução na Fábrica de Experiências, tornando-a disponível para que outros projetos possam utilizá-la.
Este capítulo fornece uma visão geral da implantação do projeto de melhoria e descreve os marcos dessa iniciativa. Nele são traçadas perspectivas para trabalhos futuros. Por fim o capítulo apresenta a conclusão do trabalho ressaltando o ambiente em que foi implementado.
6.1
Visão Geral do trabalho realizado
Nesse trabalho foi apresentado o desafio de implementar um programa de melhoria da qualidade de software em um órgão público. Tal iniciativa contou desde o início com orçamento reduzido e capacidade limitada de negociação junto à presidência do órgão.
Negociar recursos, mesmo nas empresas privadas, para realizar atividades não diretamente ligadas ao “negócio” da organização, naturalmente é difícil. Geralmente os administradores preferem subcontratar essas tarefas e colocá-las sob a responsabilidade de outras organizações (terceirização). Entretanto, tão incerta como a diminuição de riscos de fracasso está a melhoria da relação custo-benefício. No decorrer desse trabalho esse fator sempre foi considerado como um elemento chave.
Nessa direção, havia consciência de que os recursos disponíveis para realização do projeto seriam limitados tal como as suas chances de sucesso, pois em geral, os programas de melhoria da qualidade de software requerem grandes investimentos (treinamento, ferramentas, pessoal).
Contudo, ainda que o TST não alocasse recursos financeiros especialmente para esse fim, a diretoria e gerência de informática foram sensíveis em perceber a necessidade de melhorar e acreditar numa solução que, a rigor, utilizaria somente a força de trabalho de seus servidores. Por outro lado, tinha certeza que não deveria começar um programa de melhoria da qualidade de software sem planejamento, sem método e sem objetivos possíveis de serem alcançados.
Para tanto, foi necessário analisar e sintetizar técnicas atuais de melhoria de qualidade de software de modo a fazer a melhor escolha para a organização. A solução encontrada não apareceu pronta, saída de um manual, ela foi construída, reformulada e adaptada ao longo do tempo. Durante esse período foram feitas pesquisas sobre abordagens descendentes (top- down) e ascendentes (bottom-up) de melhoria de processos de software, métodos de avaliação de processos e técnicas de mensuração.
Antes de propor uma solução, sobre quais abordagens e métodos utilizar, ficou claro que a organização precisava conhecer a sua forma de trabalho e avaliar a sua capacidade na