ANÁLISE QUANTITATIVA DO PROCESSO

O primeiro ponto que investigamos se refere a Q1.1, onde buscamos expandir nosso conhecimento acerca das rejeições em atividades. Inicialmente verificamos que 63% casos apresentaram ao menos uma rejeição, dentre estes, um único caso apresentou 18 rejeições. Resolvemos então identificar a origem das rejeições. Ou seja, em quais fases do processo as rejeições estão ocorrendo. A Figura 18 apresenta a distribuição das rejeições encontradas no sistema S a partir das fases do processo de software.

O gráfico nos mostra que 86% das rejeições ocorrem durante os testes ou homologação. Estas rejeições são decorrentes de falhas na implementação ou problemas no ambiente. Os outros 14% estão distribuídos entre as demais fases. Com isto, concluímos que as rejeições em testes e homologação devem ser consideradas como algo comum ao processo de desenvolvimento do sistema S. Já as rejeições nas demais fases são atípicas, e portanto não devem ser esperadas.

A partir desta conclusão partimos para entender melhor as rejeições em teste e homologação. Para isto, distribuímos as rejeições oriundas dos testes e homologações a partir da categoria dos casos e da prioridade atribuída ao caso. Esta análise teve o objetivo de verificar se estes fatores influenciam na quantidade de erros encontrados durante os testes e homologação. A Tabela 13 apresenta a

FIGURA 18 - Distribuição das rejeições a partir das fases do processo de software

74

média de rejeições em duas dimensões. Na primeira dimensão (colunas) temos as rejeições distribuídas a partir do nível de priorização atribuída ao caso rejeitado. Na outra dimensão (linhas) temos as rejeições distribuídas a partir da categoria à qual o caso rejeitado pertence. Cada célula informa o Valor médio (VM), o Desvio padrão (DP) e quantidade de casos para uma dada dupla (categoria/priorização). Ao final de cada linha ou coluna temos os valores acumulados na dimensão em questão.

TABELA 13 - Distribuição das rejeições por categoria e prioridade

Baixa Média Alta Urgente

Erro VM: 0,20 DP: 0,40 Casos: 5 VM: 1,24 DP: 1,46 Casos: 35 VM: 0,77 DP: 1,21 Casos: 26 VM: 1,20 DP: 2,24 Casos: 20 VM: 1,00 DP: 1,57 Casos: 86 Melhoria - VM: 1,79 DP: 1,78 Casos: 39 VM: 2,67 DP: 1,75 Casos: 6 VM: 0 DP: 0 Casos: 2 VM: 1,83 DP: 1,79 Casos: 47 Novo requisito - VM: 4,33 DP: 3,94 Casos: 9 VM: 2,67 DP: 3,06 Casos: 3 VM: 14,00 DP: 0 Casos: 1 VM: 4,69 DP: 4,50 Casos: 13 VM: 0,20 DP: 0,40 Casos: 5 VM: 1,80 DP: 2,17 Casos: 83 VM: 1,26 DP: 1,67 Casos: 35 VM: 1,65 DP: 3,42 Casos: 23

Observamos que existe uma variação significativa na média entre as categorias. É visível que as rejeições ocorrem em muito maior grau nos novos requisitos do que nas melhorias e erros. O nível de rejeições também é significativamente maior nos casos de melhoria do que nos erros. Inclusive, este fato é observado em quase todos os cenários: a exceção fica por conta das melhorias e novos requisitos com prioridade alta. Neste caso, os valores médios foram iguais, porém, esta informação não é confiável uma vez que a quantidade de amostras (casos) nestes dois cenários é baixa e a variabilidade (desvio padrão) no caso do novo requisito é muito grande. Com isto, concluímos que devemos esperar uma quantidade diferente de rejeições dada uma categoria. Este resultado pode ser

75

explicado pelo grau de complexidade maior apresentado por estas categorias. Corrigir um comportamento, em geral, é mais simples do que melhorar uma funcionalidade. Seguindo a mesma linha de raciocínio, geralmente, é mais simples implementar uma melhoria em algo existente do que implementar algo completamente novo. Isto não significa que estamos tentando comprovar o óbvio. Nosso objetivo foi quantificar esta variação e nossa análise nos permite estimar valores esperados para rejeições a partir da categoria ao qual o caso foi classificado. Analisando a Tabela 13 no tocante à dimensão priorização, observamos que a variação entre a priorização é pequena. Temos uma exceção que é o cenário de casos com prioridade baixa. Porém, temos poucos exemplos neste cenário para considerar este resultado confiável. Já os casos com prioridade urgente apresentaram, em média, um pouco menos rejeições que os casos com prioridade média e um pouco mais de rejeições que os casos com prioridade alta. Este fenômeno pode ser explicado por um único caso extremo que apresentou 14 rejeições em testes. Se desconsiderarmos este caso, a média cai para 1,09 com um desvio padrão de 2,16. Ou seja, embora discreta, podemos observar uma tendência a redução da quantidade de rejeições dada a prioridade do caso. A explicação para esta redução pode ter a seguinte explicação: os casos com mais alta prioridade, em geral, são oriundos de problemas descoberto em produção ou demandas com prazo fixo da alta gestão. Isto termina impactando na quantidade e qualidade dos testes e homologação realizada. Ou seja, aparentemente estes dados não estão indicando uma implementação de melhor qualidade para os casos com prioridade mais alta, o que temos é uma qualidade baixa nos testes e homologação. Desta forma, resolvemos não considerar esta variável para estimar a quantidade de rejeições.

Com base nestas conclusões podemos estipular valores de referência para rejeições nos casos. A partir do histórico de rejeições apresentados na Tabela 13, podemos considerar que existe uma alta probabilidade de um caso de erro apresentar uma (1) rejeição durante o processo de desenvolvimento. Observando o desvio padrão para os casos de erros, podemos considerar uma possibilidade média de haver nenhuma ou duas rejeições para estes casos. A partir de três rejeições já podemos considerar como algo com uma probabilidade baixa para este caso. Seguindo a mesma linha de raciocínio, para os casos de melhorias podemos

76

considerar duas rejeições como o valor esperado (alta probabilidade), uma ou três rejeições com uma probabilidade média e zero ou mais de três rejeições como uma probabilidade baixa de ocorrer. Para os novos requisitos temos uma situação um pouco mais complicada para definir, pois a variabilidade é bem maior nestes casos. Como já comentamos, um caso extremo compromete as análises dos novos requisitos. Desta forma, retiramos este caso e recalculamos o valor médio e o desvio padrão para os casos de novos requisitos. O resultado, após a eliminação deste caso, foi um média de 3,92 e um desvio padrão de 3,68. Ainda continuamos com uma variância alta. Desta forma, resolvemos ampliar o intervalo da nossa classificação do risco. Ou seja, consideramos de três até cinco rejeições como uma probabilidade alta de ocorrência. Para probabilidade média consideramos uma, duas, seis e sete rejeições. Para os demais valores, consideramos baixa probabilidade de ocorrência.

O nosso objetivo neste framework é emitir alertas quando algo atípico está ocorrendo e que pode impactar negativamente no projeto. Assim, não faz sentido emitir um alerta quando um caso que se esperava com duas rejeições não teve nenhuma. Então, organizamos os valores encontrados para os casos de acordo com esta perspectiva. A Tabela 14 apresenta os valores de referencia para as rejeições (Questão Q1.1).

TABELA 14 - Valores de referencia para a Q1.1

CATEGORIA VALORES DE REFERÊNCIA (PROBABILIDADE)

Alta Média Baixa

Erro 1 2 3

Melhoria 2 3 4

Novo requisito 4 6 8

A questão Q1.2 do nosso planejamento aborda a cobertura dos testes. Já havíamos observado na análise qualitativa do processo que cerca de 20% dos casos do sistema S não passaram por testes. Partimos então para analisar a cobertura dos testes a partir das categorias e priorização atribuídas ao caso. A Tabela 15

77

apresenta a cobertura de testes para todos os possíveis cenários de categorização e priorização dos casos implementados no sistema S.

TABELA 15 - Distribuição da cobertura de testes por categoria e prioridade

Baixa Média Alta Urgente

Erro 100% 86% 73% 50% 74%

Melhoria - 95% 100% 100% 94%

Novo requisito - 89% 100% 100% 92%

100% 90% 80% 52%

Observando qualquer cenário para os casos de Melhoria e Novo requisito, percebemos que a não realização dos testes é uma exceção. Porém, para os erros não podemos dizer o mesmo, sobretudo os erros classificados com alta prioridade ou urgentes. Os valores destes dois cenários induzem a ideia que a priorização, independente da categoria, influencia na realização dos testes. Mas, analisando melhor os dados, fica claro que isto é reflexo da influência dos casos categorizados como erro. Ao buscar a explicação deste fato, identificamos algumas justificativas: alguns erros eram impossíveis de reproduzir no ambiente de testes, alguns erros (principalmente os urgentes) provocaram indisponibilidade em produção, então o processo foi “abreviado” para resolver mais rapidamente o problema e outros casos foram considerados muito simples para serem submetidos a testes. Como podemos observar, existe um alto grau de subjetividade nas justificativas para não realizar os testes. Isto é um fator de risco grave, pois, os impactos das mudanças podem estar sendo subestimados e um problema pequeno pode virar um grande problema. Mesmo assim, o processo de software não determina critérios para os casos passarem por testes. A equipe de testes é quem escolhe os casos que serão testados de acordo com sua capacidade. Porém, constamos que os analistas solicitam que determinados casos passem direto para homologação. Diante deste cenário consideramos todos os casos que não passam por testes como alto risco em relação qualidade.

78

uma instância específica do processo (caso) e de uma atividade específica respectivamente. Um ponto crucial para responder estas questões é estabelecer o que seria uma duração aceitável para o sistema S. Em nosso contexto, consideramos que uma duração aceitável é uma duração dentro da média, considerando as características da demanda. Julgar se algo é aceitável pressupõe que existe uma expectativa sobre os resultados. Em nosso caso, a expectativa é que as atividades transcorram dentro de um intervalo de normalidade. Ou seja, uma duração aceitável é equivalente a uma duração próxima da média. Seguindo esta linha, buscamos compreender melhor os fatores que afetam o desempenho dos casos e das atividades. A Tabela 16 apresenta a evolução semestral (não cumulativa) da duração em horas trabalhadas para conclusão dos casos.

TABELA 16 - Evolução semestral da duração total média dos casos em horas trabalhadas

[1] [2] [3] [4] [5] [6] Média 92 113 150 347 278 446 Desvio Padrão 45 99 149 423 469 694

Legenda: [1] – set/12 à fev/13; [2] – mar/12 à ago/12; [3] – set/11 à fev/12; [4] – mar/11 à ago/11; [5] – set/10 à fev/11; [6] – mar/10 à ago/10.

Analisando a Tabela 16 verificamos uma variabilidade muito alta na duração total dos casos o que inviabiliza qualquer conclusão a partir da duração média. Resolvemos então verificar a existência de valores discrepantes comprometendo a análise. Para tanto, elaboramos o histograma apresentado na Figura 19. A partir do histograma vimos que a grande maioria dos casos encontra-se com a duração dentro do primeiro decíl. Então, resolvemos considerar os demais valores como outliers. A Figura 20 apresenta o histograma eliminando os valores fora do primeiro decíl.

A Figura 20 mostra que os valores ficaram melhor distribuídos após a eliminação dos outliers. Então, partimos para calcular a duração total média o impacto da eliminação dos outliers. A Tabela 17 apresenta a evolução semestral (não cumulativa) da duração em horas trabalhadas para conclusão dos casos que não foram considerados outliers.

79

TABELA 17 - Evolução semestral da duração total média dos casos em horas trabalhadas (sem outliers)

[1] [2] [3] [4] [5] [6] Média 92 68 87 61 55 69 Desvio Padrão 45 70 67 53 47 35

Legenda: [1] – set/12 à fev/13; [2] – mar/12 à ago/12; [3] – set/11 à fev/12; [4] – mar/11 à ago/11; [5] – set/10 à fev/11; [6] – mar/10 à ago/10.

Como era de se esperar, a eliminação dos valores considerados outliers fez a variabilidade cair drasticamente. Porém, ainda existe uma grande variação no desvio padrão calculado entre os semestres. Observando as colunas [2] e [6] da Tabela 17

FIGURA 20 - Histograma da duração total média dos casos sem outliers FIGURA 19 - Histograma da duração total

80

percebemos que o desvio padrão no período de março à agosto de 2012 é o dobro do registrado no mesmo período do ano de 2010. Com isso, decidimos investigar se existe alguma fase do processo que em algum semestre influenciou o desempenho total. A Tabela 18 apresenta a evolução semestral (não cumulativa) da duração média, em horas, das fases do processo de desenvolvimento de software.

TABELA 18 - Evolução semestral da duração total média dos casos em horas trabalhadas (sem outliers)

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] set/12 à fev/13 0 11 15 0 5 39 0 1 1 20 25 mar/12 à ago/12 2 11 15 0 2 4 1 11 1 19 95 set/11 à fev/12 4 12 6 0 4 8 0 9 2 41 58 mar/11 à ago/11 0 21 4 1 1 15 0 2 2 17 25 set/10 à fev/11 0 8 7 3 0 2 0 1 5 28 17 mar/10 à ago/10 0 4 8 5 1 4 0 10 7 29 25 Legenda: [1] – Análise; [2] – Fila de Implementação; [3] – Implementação; [4] – Fila de Teste; [5] – Testes; [6] – Fila de Homologação; [7] – Homologação; [8] – Impedimento; [9] – Rejeitado; [10] – Liberação Interna; [11] – Liberação Externa.

Ao analisar a Tabela 18 observamos comportamentos variados entre as fases do processo. Dentre estes comportamentos podemos destacar:

• Análise: Em geral a duração média registrada na fase de análise é menor que uma hora. A exceção fica por conta do ano de 2012.

• Implementação: A duração média da fila da implementação variou bastante, mas nos últimos dezoito meses estabilizaram. Já implementação parece ter aumentado significativamente no último ano.

• Testes: A duração da fila de espera dos testes caiu significativamente e estabilizou nos últimos 18 meses em uma duração média inferior a uma hora. Já a execução dos testes tem apresentado uma variação alta, mas comparado as demais fases sua participação é baixa na duração total dos casos.

81

apresentou valores muito acima dos outros semestres, e isso fez com que se tornasse a fase com a maior duração média no semestre. A homologação apresentou tempo médio de até uma hora em todos os semestres.

• Liberações: Durante todo o período analisado, as liberações internas e externas estão entre as atividades de maior duração.

• Impedimento e Rejeições: A duração media no estado de impedimento variou drasticamente na comparação entre os semestres. Já a duração das rejeições apresentou quedas sistemáticas e a dois anos apresenta valores baixos considerando a duração média das demais fases.

O comportamento da fase de Análise e Homologação dos casos apresentaram, em geral, duração média inferior a uma hora. Este tempo é incompatível com a natureza destas atividades. Contudo, observamos que o problema está no registro destas atividades. No caso da análise o analista responsável só cria o caso quando análise foi finalizada, momento em que ele dispõe de todas as informações necessárias para criar o caso. Por tanto, não podemos considerar que existe registro desta atividade. Já no caso da homologação, verificamos que os analistas, em geral, não atualizam o status do caso ao iniciar a homologação. Ou seja, a homologação é iniciada com o status LIBERADO_PARA_HOMOLOGAÇÃO e quando da sua conclusão o status é atualizado para EM_HOMOLOGAÇÃO (é um estado obrigatório) e em seguida LIBERADO_PARA_GC. Assim, o tempo gasto com a homologação está sendo registrado como tempo de fila de espera para homologação.

Também consideramos a duração média das etapas de liberações incompatíveis com a sua natureza. Mas, nestes casos a duração registrada é maior do que a esperada. Ao verificar este fenômeno observamos que esta duração não é decorrente das operações necessárias para execução das operações, nem mesmo indisponibilidade da gerência de configuração. O processo de software define que as liberações para testes e homologação devem contemplar uma versão completa. O que ocorre é que os casos são implementados, testados e homologados em tempos diferentes e os que são finalizados primeiro esperam os demais no estado LIBERADO_PARA_GC. Isto impossibilita a análise sobre as liberações internas e externas a partir do método que estamos propondo.

82

Não conseguimos explicar os demais comportamentos, pois diversos fatores influenciam na duração das atividades, como: característica das demandas, disponibilidade de recursos, concorrência com outros projetos, demandas sazonais, mudanças de prioridade da alta gestão e etc. Com isto, constatamos o que já havíamos observado durante os estudos exploratórios. Análise quantitativa do processo de software possibilita uma valiosa aquisição de conhecimento sobre o desenvolvimento. Mas, não responde ao nosso objetivo de estabelecer valores esperados para uma determinada instância do processo (Q2.1). Por outro lado, podemos utilizar este conhecimento para estabelecer critérios para responder a Q2.2. Observando a Tabela 18 fica visível que no período de março à agosto de 2011 a fila de espera da implementação teve um contribuição importante na duração média dos casos. Se excluirmos da conta as liberações, a fila de implementação representou sozinha 45% da duração média dos casos no período. Algo semelhante ocorreu com a homologação nos últimos seis meses. O tempo de homologação (fila + execução) representou 54% da duração média dos casos no período. Estes fatos nos levaram a observar que somente em situações críticas uma atividade específica pode representar mais de 25% da duração média do caso. Assim, estabelecemos que o critério para responder a Q2.2 é: a duração líquida média de uma fase do processo nos últimos seis meses não pode ser superior a 25% da média da duração líquida total dos casos no mesmo período.