Primeira meta (G1)
Analisar: o Processo de Gerência de Configuração, com o propósito: de melhorá-lo,
com respeito: ao controle de versão e de mudanças,
do ponto de vista: do gerente de desenvolvimento e engenheiros de software, no contexto: do Serviço de Desenvolvimento e Manutenção de Sistemas. Segunda meta (G2)
Analisar: a satisfação do usuário, como o propósito: de aumentá-la,
com respeito: aos pedidos de manutenção,
do ponto de vista: do gerente de desenvolvimento e engenheiros de software, no contexto: do Serviço de Desenvolvimento e Manutenção de Sistemas.
1.2. Questões e hipóteses do plano GQM
Q1. Qual a capacidade de atendimento de pedidos de manutenção? (Hipótese: 15 pedidos por semana, em média)
Q1.1 Qual o tamanho da fila de pedidos de manutenção pendentes? Hipótese: 6 pedidos em qualquer dia.
Q1.2 Qual o tamanho da fila de pedidos de manutenção em execução? Hipótese: 3 pedidos em qualquer dia.
O conhecimento quantitativo da capacidade de atendimento dos pedidos de manutenção, possibilita dimensionar apropriadamente os recursos humanos e técnicos destinados à produção de software na UPS.
Q2. O tempo para o atendimento de um pedido de manutenção tem diminuído? Q2.1 Qual o tempo médio que um pedido de manutenção permanece pendente? Q2.2 Qual o tempo médio de execução de um pedido de manutenção?
Q2.3 Qual o tempo médio gasto para completar um pedido de manutenção?
A idéia de quanto tempo se leva para atender um pedido de manutenção e executá-lo permite saber quanto tempo se gasta para entregar pedidos de manutenção. Com efeito, é possível direcionar esforços para a redução geral desses tempos, visando possibilitar um melhor gerenciamento da área com vista a aumentar a satisfação do usuário com os pedidos de manutenção de software.
Q3. Há precisão nas estimativas de tempo de realização de um pedido de manutenção?
Conhecer a precisão de estimativas permite um melhor gerenciamento da unidade produtora de software, na medida em que se pode assumir compromissos com bases em dados objetivos e a repetição de processos formais de software.
Q4. Qual o percentual de pedidos submetidos ao Quadro de Controle de Mudanças? Hipótese: 1% do total dos pedidos
Q4.1 Há algum que seja por motivo de insuficiência de informação? Hipótese: nenhum
O conhecimento desse indicador permite formar uma opinião sobre a complexidade e grau de impacto dos pedidos. Fornece ainda informações sobre o nível de cooperação e integração que deve existir entre as equipes de desenvolvimento de software. Permite ainda concluir que houve necessidade de tempo adicional para que o pedido saísse da fila de pedidos pendentes e fosse para a de “pedidos em execução”.
Q5. Qual a proporção de rejeição de pedidos de mudanças feitos pelos usuários? Hipótese: 1% do total dos pedidos
Q51. Qual a proporção entre pedidos de mudança aceitos e arquivados (rejeitados)? Q52. Qual a distribuição relativa ao tipo de manutenção (Corretiva, adaptativa evolutiva)?
Essa informação permite balancear e canalizar esforços de forma a não frustrar a expectativa do usuário relativa às correções e melhorias nos sistemas. Esse conhecimento possibilita ainda obter um parâmetro sobre a pertinência dos pedidos de modificação no contexto do ciclo de vida dos sistemas. Fornece também uma idéia sobre a complexidade existente para modificar a configuração de um sistema. Finalmente, elucida o grau com que os requisitos dos usuários estão se modificando.
Q6. A maioria dos pedidos de manutenção é atendido por um único desenvolvedor? Q6.1 Quantos pedidos de manutenção requerem mais de um desenvolvedor?
Q6.2 Qual o desenvolvedor que atendeu mais pedidos de manutenção? Q6.3 Qual o desenvolvedor que atendeu menos pedidos de manutenção?
Q6.4 Qual a distribuição relativa ao tipo de manutenção (Corretiva, adaptativa evolutiva)?
Essas informações, possibilitam tomar de decisões no sentido de equilibrar o nível de conhecimento dentro da unidade produtora de software. Também permite conhecer a complexidade dos pedidos de manutenção.
Q7. Há retorno de pedidos de manutenção “em execução” para a fila de pendentes? Q7.1 Quantos são retornados em decorrência de insuficiências de informações
Hipótese: nenhum
O conhecimento da devolução de pedidos para a lista de pendentes, permite saber se há alguma outra influência para o aumento da fila de pendentes ou aumento do tempo total para atendimento de um pedido. Esse questionamento também possibilita conhecer se há algum tipo de insegurança ou despreparo por parte de alguns desenvolvedores dentro da unidade produtora de software.
Q8. Os pedidos de modificação contêm informações suficientes para a sua implementação?
Hipótese: sempre.
Q 8.1 Qual o percentual de registro da ocorrência, “Solicitação de maiores informações” sobre pedidos de mudança?
Hipótese: baixa.
O conhecimento desse fato permite implementar ou modificar o formulário eletrônico de cadastramento de pedidos de mudanças, bem como o de relato de defeitos. Serve ainda para detectar o nível de influência que tem uma comunicação deficiente no contexto dos processos de manutenção de software. E a partir disso, desenvolver meios para melhorar essa comunicação e a forma de captação desses defeitos.
Q9. Há registro de pedidos de manutenção esquecidos ou há muito tempo na lista de espera?
Hipótese: nunca.
Esse questionamento, visa sobretudo identificar se o processo de controle de mudanças está sendo capaz de cumprir a sua função básica – controlar os pedidos de alteração.
Q10. Qual o tipo de manutenção mais freqüente?
Q10.1 A quantidade de manutenções corretivas tem diminuído? Q10.2 Novas funcionalidades ao software têm sido implementadas?
O conhecimento dessa informação permite canalizar esforços no sentido de melhorar a eficiência no tratamento dos diferentes tipos de manutenção. Possibilitam inclusive apoiar a decisão de descontinuar ou mesmo fazer uma reengenharia no sistema. Essa informação é estratégica para o planejamento de atividades da unidade produtora de software, na medida em que a finalidade precípua desse setor é desenvolver novos produtos e dar manutenção em outros.
Q11. Existe alguma concentração de pedidos de manutenção por módulo? Hipótese: não há concentração, é bem distribuído.
Q11.1 Quantidade total de módulos/programas de um sistema? Q11.2 Qual o módulo que sofreu maior quantidade de manutenções? Q11.3 Que módulo sofreu menor quantidade de manutenções?
A concentração de pedidos de manutenção em um item de configuração pode sugerir a sua reconstrução. Isso pode ser um indicativo de que houve falha na sua concepção, ou ainda que há requisitos de sistema que foram implementados incorretamente. Nesse sentido, saber aonde se concentram os pedidos, identificando os itens de configuração que mais sofreram manutenções e os que menos foram alterados, permite tomar decisões práticas no que tange à remodularização do software.
Q12. Há muitos problemas críticos de software?
Q12.1 Existem muitos pedidos urgentes de manutenção?
Q12.2 Os pedidos urgentes são atendidos dentro do prazo previsto? Hipótese: sempre.
Essa informação permite saber o nível de criticidade global dos pedidos de manutenção. Essa informação é relevante, na medida em que um problema crítico influi diretamente no nível de satisfação do usuário e na própria qualidade do sistema. Ou seja, esses pedidos de manutenção urgentes implicam num desgaste considerável da imagem da unidade produtora de software frente aos usuários. Por outro lado, se há um número excessivo de pedidos críticos, o conhecimento gerado pelo sistema de controle de mudanças pode não estar sendo bem utilizado.
Q13. Há registro de manutenções simultâneas de código? Hipótese: nunca.
O conhecimento dessas situações permite concluir que o processo de gerência de configuração de software não está sendo cumprido com tanto rigor, ou ainda, que está sendo
burlado. Na prática, se o processo for seguido, não há como acontecer uma manutenção concorrente em um item de configuração, em virtude do mecanismo de Checkout/checkin estar disponível na ferramenta de controle de versões – Repositório Oracle.
Q14. Recorre-se ao backup para recuperar código-fonte perdido corrompido? Q14.1 Há perda de código fonte com necessidade de reprogramação?
Hipótese: nunca.
A resposta negativa a esse questionamento permite reforçar a idéia de que o processo de gerência de configuração, em especial, o de controle de versões está sendo seguido fielmente. Não se pode conceber que seja necessário recuperar versões de itens de configuração em arquivos de backup, existindo um processo formal de controle de versões apoiado por uma ferramenta segura de GCS – Repositório Oracle. Vale lembrar que tal ferramenta possui um interface GUI que acessa um repositório (biblioteca de itens) de maneira segura, conforme as funcionalidades de um SGBD profissional.
Q15. Depois que um defeito é corrigido ele reaparece? Hipótese: não há reapacerimento de defeitos.
Q15.1 Existe reincidência de defeitos de software? Hipótese: não há relato de reincidência de defeitos.
Q15.2 Depois que um defeito é corrigido, aparece outro em conseqüência da correção? Hipótese: não há efeitos colaterais na correção de um defeito.
Essa informação permite concluir que o processo de controle de modificações está sendo executado a contento, bem como o de controle de versões. Não há como reaparecer um defeito de software já corrigido, uma vez que isso só seria possível se não houvesse um controle rigoroso da versão dos itens de configuração e do processo de mudanças desses itens. Existindo tal controle, somente seria possível surgir um outro defeito em virtude da modificação efetuada no software. Isso indicaria mais uma degradação do software do que propriamente uma falha no processo implementado. Contudo, essa informação também seria útil para apoiar a decisão de reconstrução de um software, por aumentar o custo indireto das manutenções.
Q16. A quantidade de versões de itens de configuração tem se mantido estável? Q16.1 Qual proporção de criação de itens de configuração face aos pedidos de manutenção?
Q16.2 Tem se criado mais itens de configuração do que modificado?
O conhecimento desse indicador permite saber se um conjunto de novas funcionalidades estão sendo incluídas em um sistema. Isso contribui para reforçar a idéia do crescimento de manutenções perfectivas em relação às corretivas.
O outro refinamento (Q16.2) permite se obter um panorama geral da complexidade do processo de manutenção do software. Também fornece uma idéia sobre o nível atual de satisfação do usuário relativo ao produto de software instalado. Um número muito grande de manutenções em um software que já foi entregue ao cliente há tempo, indica um potencial desgaste no nível de contentamento do usuário com o sistema que possui. Dessa forma, esse indicador pode também suscitar idéias no sentido da reconstrução ou reformulação profunda na estrutura do software.
Enfim, permite equilibrar tendências dirigidas para a reconstrução do produto ou continuação de procedimentos corretivos.
Q17. Os novos processos de software estão sendo seguidos? Hipótese: sim, todos estão.
Essa informação permite verificar se o alcance ou não dos resultados tem alguma relação com o cumprimento dos novos processos. A idéia é trazer efetividade para a gestão dos processos, fazendo com que medidas corretivas e adaptativas possam ser tomadas na direção certa. Se o processo não é repetido, as mensurações falham, e as medidas corretivas não serão eficazes.
1.3. Teste de consistência das questões em relação às metas
A construção da matriz de relacionamento entre as metas G1 e as questões Q1..Q17 é fundamental para validar a pertinência e correção das questões com relação ao programa de mensuração GQM. Dessa forma, a Tabela K-I abaixo apresenta o resultado dessa avaliação, apontando o grau de relacionamento existente entre metas e questões.
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 G1 G2 Legenda Muito relacionada Relacionada Pouco relacionada
Figura K-1. Matriz de relacionamento entre metas e questões GQM.