USO DE INDICADORES EM DESENVOLVIMENTO DE SOFTWARE: UM ESTUDO DE CASO SAJ/PRJ
Ricardo W. Gross1, Luiz Camargo2
Resumo: Este artigo apresenta um breve estudo sobre métricas de desenvolvimento de software, detalhando especificidades de cada métrica. Um estudo de caso empírico na empresa Softplan/Poligraph, no projeto SAJ/PRJ, foi desenvolvido para assim analisar tanto o comportamento quanto os resultados obtidos com a utilização das métricas, garantindo assim uma melhora no processo de desenvolvimento de software, visando uma diminuição no número de atendimentos em backlog.
Palavras-chave: Métrica. Desenvolvimento. Backlog.
1 INTRODUÇÃO
Com o passar dos anos os softwares tem ficado cada vez mais complexos. Desde a definição do termo “Engenharia de Software” pelo Comitê de Ciências da Organização do Tratado do Atlântico Norte (OTAN), esta disciplina vem evoluindo, com isso técnicas de desenvolvimento vêm surgindo e se sofisticando.
Técnicas como as de medição de esforço, indicadores, etc. Que tem como principal função mostrar o status do projeto, provendo aos gestores uma visão real da situação do projeto.
O objetivo deste trabalho é realizar um estudo sobre métricas de acompanhamento no desenvolvimento de software. Posteriormente a aplicação dessas métricas em um estudo de caso, para analisar o comportamento e utilização, visando uma diminuição no número de atendimentos em backlog.
Neste trabalho é apresentada uma breve explicação sobre os indicadores estudados na seção 2, o estudo de caso com aplicação dos indicadores é apresentado na seção 3 e na seção 4 são apresentadas as conclusões do trabalho.
2 INDICADORES
É preciso definir alguns conceitos que geralmente não são utilizados da forma correta, tendo seus significados muitas vezes trocados. Para entender e discutir indicadores é preciso conhecer as diferenças entre medidas, métricas e indicadores.
Segundo o IEEE (1990) medida é uma avaliação em relação a um padrão, um exemplo de medida é 4m, onde metro é o padrão e 4 é a medida. No desenvolvimento de software uma medida muito utilizada é o ponto por função, para medição de tamanho de software. Uma medida pode ser baseada em um padrão local ou universal, mas este padrão precisa ser bem definido.
Uma métrica é um método para determinar se um sistema, componente ou processo possui certo atributo (IEEE, 1990). Um exemplo de métrica é o número de erros encontrados pelo cliente durante a utilização do sistema em um determinado período de tempo.
Um indicador é um dispositivo ou variável que pode ser configurado para um determinado estado baseado no resultado de um processo ou ocorrência de uma condição específica. Por exemplo: um semáforo ou uma flag (IEEE, 1990). Normalmente esta relacionado a uma métrica e provê a interpretação daquela métrica numa determinada situação ou contexto.
1
Pós-graduando em Engenharia de Software pelo Instituto Superior Tupy – SOCIESC. E-mail:ricardowgross@gmail.com
2
2.1 Diagrama de fluxo cumulativo (Cumulative flow diagram - CFD)
É uma ferramenta utilizada na teoria das filas, ramo da probabilidade que estuda a formação de filas cuja demanda cresce aleatoriamente. Assim, a teoria das filas tenta, através de análises matemáticas detalhadas, encontrar um ponto de equilíbrio que satisfaça o cliente e seja viável economicamente para o provedor do serviço (COSTA, 2011).
Aplicado ao desenvolvimento de software, o CFD, é mais fácil de atualizar, que um gráfico de burn down, e fornece uma visão mais completa do status do projeto. Para aqueles que não estão familiarizados com o CFD, ele apresenta a quantidade total de trabalho no sistema (BOEG, 2011). Na figura 1 é mostrado um exemplo de CFD.
Figura 1- Exemplo de CFD, dados aleatórios
Fonte: Adaptado de BOEG (2011)
O gradiente representado por Done descreve sua velocidade ao longo do tempo, enquanto o espaço entre essa linha e a linha Backlog podem ser definidos como WIP (Work In Progress). Com isso é possivel chegar a algumas conclusões (BOEG, 2011)
Se a largura da área de WIP aumentar, pode ser um sinal de gargalo.
Se o gradiente de Backlog está mais inclinado que o gradiente de Done, é um sinal que está sendo adicionado mais trabalho do que o sistema suporta.
Projetar onde o Backlog cruza o Done será o melhor sugestão para a data de entrega.
Tempo de ciclo médio e quantidade na fila também pode ser estabelecida a partir do diagrama.
2.2 Tempo de ciclo (Cycle time)
O diagrama de tempo de ciclo, nada mais é do que um gráfico onde é possível marcar quanto tempo cada atividade demorou, gerando assim um gráfico de pontos. Embora seja possível visualizar o tempo de ciclo médio no CFD, acompanhar os tempos de ciclos individuais pode ser muito útil em termos de previsibilidade.
Porém, como lembrado por Boeg (2011), tempo de ciclo médio, é um indicador de atraso, isso significa que só será possível visualizar os problemas depois de eles terem ocorrido. Na figura 2 é mostrado um exemplo de diagrama de tempo de ciclo.
Figura 2- Exemplo de diagrama de tempo de ciclo, dados aleatórios
Fonte: Adaptado de BOEG (2011) 2.3 Taxa de defeitos (Defect rate)
Este diagrama é composto por duas linhas, onde uma mostra o número de novos erros e a outra o número total de erros do sistema. Manter um histórico de entrada de novos defeitos e o número total de erros é essencial, pois lhe diz muito sobre o status do projeto. É uma maneira fácil de manter o controle da qualidade. Boeg (2011), alerta para o cuidado em analisar dados individuais, devendo sempre analisar a tendência para verificar se está se movendo na direção correta. Na figura 3 é mostrado um exemplo de diagrama de taxa de defeito.
Questões que podem ser levantadas:
Porque o número de defeitos está aumentando?
Qual o impacto no fluxo de trabalho esses novos erros acarretaram?
Porque não está tendo vazão nos erros?
Figura 3- Exemplo de diagrama de taxa de defeito, dados aleatórios
2.4 Itens bloqueados (Blocked items)
Itens bloqueados são aqueles itens que por algum motivo não seguem o fluxo normal de desenvolvimento, seja por requisitos inconsistentes até falta de mão de obra. Estes itens sempre existirão, por períodos longos ou curtos e por várias razões. Mesmo sabendo que esta situação será verificada no CFD e no diagrama de Tempo de Ciclo, muitas equipes optam por uma forma explícita e visual para lidar e corrigir problemas de bloqueio (BOEG, 2011).
Este diagrama é constituído por duas linhas, uma indicando o tempo médio que os itens ficaram bloqueados e a outra indicando o número de itens bloqueados. Um exemplo de diagrama de itens bloqueados é apresentado na figura 4.
Figura 4- Exemplo de diagrama de itens bloqueados, dados aleatórios
Fonte: Adaptado de BOEG (2011)
2.5 Quadro de fluxo de trabalho (Dashboard workflow)
Muito conhecido e amplamente utilizado atualmente, o quadro de fluxo de trabalho fornece, de uma forma rápida e direta, muitas informações sobre o andamento do projeto. Todo o trabalho fica visível, inclusive servindo para limitar o WIP (Work in progress) de cada etapa. WIP descreve quanto trabalho está em andamento no seu sistema (BOEG, 2011).
O quadro é dividido em colunas, que são as etapas do projeto, por onde cada atividade deve passar para a sua efetiva conclusão, as atividades são representadas por tickets, ou cartões que percorrem o quadro da esquerda para a direita.
Figura 5- Exemplo de quadro de fluxo de trabalho, dados aleatórios
Fonte: BOEG (2011) 3 ESTUDO DE CASO
Nesta seção, um estudo de caso empírico é descrito com base em um projeto de desenvolvimento de software. O autor deste texto participa deste projeto desde 2009 no papel de analista implementador.
O principal objetivo deste estudo de caso é utilizar os indicadores apresentados na Seção 2 neste trabalho, pretendendo assim, obter resultados de acompanhamento para uma melhor gestão do projeto.
3.1 Projeto – SAJ/PRJ
Concebido pela Softplan/Poligraph, o sistema SAJ/PRJ é um sistema de cadastramento e atualização monetária, específico para precatórios, atuando como um gestor de processos e pagamentos. Entre as principais funcionalidades estão à geração de diversos relatórios de controle, controle da ordem de precatórios, controle de saldo devedor, etc.
Para o acompanhamento de seus trabalhos a Softplan/Poligraph utiliza um software interno de controle de atendimentos, SAC, e é deste sistema que foram colhidos os dados históricos apresentados na sequencia.
A equipe de desenvolvimento utiliza a metodologia ágil SCRUM (SCHWABER, 2011) para acompanhamento de atividades de manutenção evolutiva, porém para atividades de manutenção corretiva não se tem um acompanhamento efetivo e são estas atividades o foco de estudo.
O projeto foi monitorado durante os meses de Agosto, Setembro e Outubro de 2012, sem nenhuma intervenção no ritmo e forma de trabalho da equipe, focando assim apenas em acompanhar o projeto.
Diagrama de fluxo cumulativo
Como visto anteriormente o CFD apresenta a quantidade total de trabalho no sistema. Neste CFD, figura 6, é possível visualizar um trabalho constante nas áreas de “Teste”, “Desenvolvimento”, “Verificação”, porém, apesar da área de “Feito” aumentar, isto é, existe trabalho sendo entregue, a área de Backlog não diminui, mostrando que novos erros continuam entrando no sistema. Os dados apresentados na figura 6 foram colhidos diretamente do SAC e também coletados manualmente durante o período de acompanhamento.
Tempo de ciclo
Como o foco do estudo são os atendimentos de erro, seus tempos de desenvolvimento são em maioria baixos, como mostrado na figura 7. A linha vermelha no diagrama mostra a tendência dos tempos, com isso é possível visualizar que o tempo gasto para corrigir um problema tende a diminuir lentamente, porém é preciso ter cuidado, pois o período analisado é muito pequeno para ter a certeza de uma tendência. Os dados apresentados na figura 7 foram colhidos diretamente do SAC.
Figura 7- Diagrama de fluxo cumulativo
Taxa de defeitos
Como é possível ver na figura 8, a taxa de entrada de novos defeitos é relativamente baixa se comparada à quantidade de erros abertos não corrigidos, porém fica visível que a equipe de desenvolvimento não consegue dar vazão aos novos erros, o que acarreta em um acumulo de erros. Os dados apresentados na figura 8 foram colhidos diretamente do SAC e tratados para se chegar nos valores exatos que o gráfico necessita.
Figura 8- Diagrama de taxa de defeito
Itens bloqueados
Durante o período analisado não teve nenhum caso de item bloqueado. Porém, isso não significa que nunca existiram ou existirão esses problemas. Na verdade a equipe possui um gargalo na etapa final de testes o que faz acumular itens prontos aguardando teste, mas todos anteriores ao período analisado, e que estão sendo finalizados aos poucos.
Quadro de fluxo de trabalho
Várias opções de quadros vêm sendo discutidas pela empresa, desde quadros em papel até quadros virtuais como o LeanKit (http://leankit.com). Devido o grande número de atividades no
backlog deste projeto, o que tornaria a confecção dos tickets em papel muito trabalhosa, uma
possível solução é o LeanKit, já adotado por outras equipes da empresa.
Porém para as atividades de erro, foco deste estudo, o quadro ainda não está em utilização, será iniciado um trabalho neste sentido no mês de Dezembro de 2012. Pois para que o quadro fique sempre atualizado é necessário um esforço em conjunto de toda a equipe. Abaixo, na figura 9, é possível ver um exemplo de quadro gerado pela ferramenta LeanKit.
4 CONCLUSÃO
Este trabalho estudou métricas de desenvolvimento de software, além da discussão sobre os conceitos e teorias relacionados às métricas, um estudo de caso foi conduzido para avaliar a aplicação de algumas métricas.
No estudo de caso algumas questões foram percebidas, analisando o CFD, figura 6, ficou claro que a equipe tem parte de seus esforços voltados para o desenvolvimento das atividades de erro, porém o backlog da equipe se mantém, deixando claro que esse esforço não é suficiente. Uma sugestão de melhoria no SAC é a integração deste diagrama, eliminando a necessidade de um controle manual do andamento do atendimento.
Já no diagrama de tempo de ciclo, figura 7, foi possível visualizar uma grande variação nos tempos de resolução de cada atividade, mas com uma tendência baixa.
No diagrama de taxa de defeito, figura 8, ficou mais claro o baixo desempenho da equipe com relação aos itens de backlog e muito menos aos novos atendimentos que entram, pois no período analisado o backlog aumentou de tamanho. Este diagrama também poderia ser inserido no SAC.
Como já explicado anteriormente, não foi constatado nenhum item bloqueado e o quadro de fluxo será implantado a partir de dezembro de 2012.
Este estudo mostrou pontos fracos da equipe, principalmente por trabalhar tanto em manutenção evolutiva quanto corretiva, o que acaba consumindo recursos da equipe que poderiam ser utilizados na manutenção corretiva.
Futuramente serão analisados os atendimentos de manutenção evolutiva, sob esta mesma ótica, visando uma melhoria neste casos também.
REFERÊNCIAS
IEEE Std 610.12-1990. IEEE standard glossary of software engineering terminology. New York: 1990.
COSTA, L. C. Teoria das Filas, 2011, São Luís. Disponível em:
<http://www.deinf.ufma.br/ ~mario/grad/ filas/TeoriaFilas_Cajado.pdf>. Acesso em: 15 julho 2012. BOEG, Jesper. Priming Kanban: A 10 step guide to optimizing flow in your software delivery system. Copenhagen: 2011.
SCHWABER, Ken; SUTHERLAND, Jeff. The SCRUM Guide. 2011. Disponível em: < http://www.scrum.org/ScrumGuide.aspx>. Acesso em: 16 julho 2012.
USO DE INDICADORES EM DESENVOLVIMENTO DE SOFTWARE
Abstract: This article presents a brief study on software development metrics, detailing specifics of each metric. An empirical case study on the company Softplan / Poligraph, project SAJ / PRJ, was developed to analyze so much the behavior as the results obtained from the use of metrics, thus guaranteeing an improvement in the process of software development, targeting a decrease in the number of bugs to the backlog.
