Capítulo 2 – Análise de Desempenho de Processos
2.3 Uso da Análise de Desempenho de Processos em Software
O uso da ADP foi originalmente proposto na área de manufatura por Shewhart3 na década de 1920 (WHEELER e CHAMBERS, 1992). Devido aos benefícios advindos do seu uso, as técnicas da ADP começaram a ser utilizadas em outras áreas, tais como: química (ALBAZAZZ e WANG, 2004), alimentação (GRIGG e WALLS, 1999), negócios (BRIMSON, 2004) e saúde (FASTING e GISVOLD, 2003).
Por volta de 1970, a ADP começou a ser aplicada também para a área de desenvolvimento de software (MAHANTI e EVANS, 2012). No entanto, verifica-se ainda hoje que poucas organizações fazem uso da ADP nos seus processos (KOMURO, 2006; MAHANTI e EVANS, 2012). Na literatura, há poucas fontes que descrevem relatos de sucesso, detalhes de implementação e diretrizes implementadas para aplicar as técnicas da ADP de software (SARGUT, 2003; TARHAN e DEMIRÖRS, 2006).
A dificuldade sobre o uso das técnicas da ADP na área de software pode ser decorrente das diferenças existentes entre estes processos e os de manufatura (para os quais as técnicas de ADP foram inicialmente desenvolvidas). De acordo com MAHANTI e EVANS (2012), para realizar a ADP adequadamente, um processo deve possuir as seguintes características: (i) ser bem definido, de forma que sua execução seja consistente em toda a organização; (ii) ser mensurável, ou seja, deve possuir coletas de, pelo menos, um dos seus atributos; (iii) ser repetível; e (iv) ser crítico para a organização. A percepção destas características é diferente em um processo de software e em um processo de manufatura, conforme apresentado na Tabela 2.3.
2 DMAIC (Define-Measure-Analyze-Improve-Control) é um método sistemático de análise de problemas e melhoria de processo, utilizado quando um processo já existente na organização não atende às especificações do cliente ou não possui um desempenho adequado (SIMON, 2007; VASQUES, 2012). É um dos métodos do Six Sigma utilizado para a realização da análise de desempenho de processos.
3
34
Tabela 2.3 – Diferenças entre processos de software e de manufatura
Característica Processo de software Processo de manufatura Definição
As entradas e saídas do processo de software, geralmente, são diferentes a cada execução (LANTZY, 1992).
Processo é controlado por máquinas, sendo o mesmo a cada execução (BALDASSARRE et al., 2007).
Medição
Dimensão de especificações e tolerância do produto produzido é de difícil medição (MAHANTI e EVANS, 2012).
Medição é mais fácil, pois produtos possuem dimensões que são demonstráveis (BALDASSARRE et
al., 2007).
Repetibilidade
Pouco repetível, pois o processo de software envolve desenvolvimento de produtos únicos (normalmente customizados de acordo com a necessidade do cliente) (MAHANTI e EVANS, 2012). Além disto, por ser uma atividade cognitiva, há diversos fatores humanos que impactam no desempenho do processo (BALDASSARRE et al., 2007; KOMURO, 2006).
Altamente repetível, pois é uma atividade geralmente executada por máquinas (BALDASSARRE et al., 2007).
Criticidade
Possui nível de criticidade grande, pois o software é utilizado por várias pessoas e pode causar um maior dano (MAHANTI e EVANS, 2012).
Possui nível de criticidade pequeno, pois, em muitos casos, o produto pode ser descartado sem grandes danos (BALDASSARRE et al., 2007).
Devido a estas diferenças entre os processos de software e de manufatura, há na literatura muitas discussões sobre a aplicabilidade das técnicas da ADP em software (RACZYNSKI, 2009). Além disto, verificam-se na literatura alguns problemas relatados como obstáculos para a adequada execução da ADP em software. Os problemas mais citados estão listados na Tabela 2.4.
Tabela 2.4 – Problemas relatados durante a execução da ADP de software
Problema Referências
Dificuldade em controlar atividades intensas em conhecimento e criatividade
(LANTZY, 1992; KOMURO, 2006; CURTIS et al., 2008; BALDASSARRE et
al., 2009)
Dificuldade em obter uma quantidade adequada de dados homogêneos e que sejam importantes para o objetivo de negócio
(KOMURO, 2006; SARGUT e DEMIRÖRS, 2006; BORIA, 2007; RACZYNSKI, 2009)
Inadequação das bases de medidas da organização à aplicação das técnicas estatísticas
(CARD, 1994; KITCHENHAM et al., 2006; BORIA, 2007; WELLER e CARD, 2008; BARCELLOS, 2009)
Falta de conhecimento sobre as técnicas da ADP
(TARHAN e DEMIRÖRS, 2006; PAULK e HYDER, 2007; CARD, 2007; BORIA, 2007)
Análise dos dados realizada a partir de somente uma técnica da ADP
(EICKELMANN e ANANT, 2003; CARD, 2007; KITCHENHAM et al., 2007)
Uso incorreto das fórmulas para calcular os limites de controle do processo
(PAULK e HYDER, 2007; CARD et al., 2008)
35 Dificuldade em identificar processos críticos e com dados suficientes para serem analisados estatisticamente
(CARD et al., 2008; FERREIRA, 2009) Falta de material disponível na literatura com
exemplos e diretrizes para aplicar as técnicas da ADP em software
(FLORENCE, 2001; CARD, 1994) Tendência em focar na análise de pontos fora de
controle, ao invés de analisar as tendências (CARD, 1994) Dificuldade (principalmente nas pequenas e
médias empresas) em contratar ou treinar profissionais para implantar as técnicas de ADP
(CARD, 1994; FONSECA, 2010) Existência de múltiplas causas de variação,
levando a possíveis erros ao analisar dados de diferentes sistemas de causas
(KOMURO, 2006; PAULK e HYDER, 2007; CARD, 2007)
Dificuldade em identificar e eliminar todas as causas especiais do processo, pois a maioria delas possui caráter pessoal, ou seja, estão relacionadas à pessoa que está executando o processo
(RACZYNSKI, 2009)
No entanto, CARD (1994) e KOMURO (2006) sugerem que a maioria destes problemas pode ser resolvida se o foco da ADP em software for maior na análise de medidas de processo, ao invés de medidas de produto. Além disto, a maioria dos problemas relacionados à falta de homogeneidade e controle dos dados pode ser minimizada com a adoção de subprocessos, conforme apresentado na Seção 2.2.1. Desta forma, ao invés de se ter medidas relacionadas a um processo inteiro, coletam-se medidas relacionadas a uma pequena parte do processo, o que diminui a quantidade de variáveis envolvidas, além de aumentar a frequência de coleta destas medidas.
É possível utilizar a ADP em software, desde que alguns cuidados sejam tomados durante sua implantação. Neste sentido, há trabalhos que sugerem que alguns dos conceitos originais da ADP sejam adaptados para software, tais como: FLORAC e CARLETON (1999), TARHAN e DEMIRÖRS (2006) e FONSECA (2010). Algumas destas adaptações são apresentadas na Seção 2.5.
Há ainda trabalhos que apresentam a aplicação da ADP em diversos segmentos da área de software, tais como: manutenção (WELLER, 2000a), testes (CARD e BERG, 1989, WELLER, 2000b), inspeção e revisão (EBENAU, 1994; FLORAC et al., 2000; WELLER, 2000b; FLORENCE, 2001; JALOTE, 2002).
Verifica-se que, para realizar a ADP, a maioria dos trabalhos na área de software utiliza medidas referentes à fase de codificação e à fase de verificação (inspeção e testes) (BALDASSARRE et al., 2007). Este fato reforça o que foi sugerido por CARD
36
(1994), ao propor que a ADP comece a ser realizada em processos pequenos e que sejam repetidos com maior frequência.
Com relação ao uso do Six Sigma em organizações de desenvolvimento de software, muitas organizações que implementam os altos níveis de maturidade de modelos como o CMMI-DEV (CMMI Product Team, 2010) e o MR-MPS-SW (SOFTEX, 2016a), adotam o Six Sigma para atender aos resultados esperados. Por exemplo, TRINDADE et al. (2010) relatam como alcançaram o nível 5 do CMMI-DEV a partir da implementação dos métodos do Six Sigma: DMAIC para a melhoria do desempenho de alguns indicadores. Em (FACEMIRE e SILVA, 2004), é apresentado como as áreas de processo do CMMI dos níveis 4 e 5 – foram implementadas a partir de projetos DMAIC. Também em (TONINI et al., 2005), é relatada a implementação do Six Sigma em três organizações de desenvolvimento de software.
Há trabalhos que visam propor métodos que auxiliem a implementação dos conceitos do Six Sigma considerando as características próprias do processo de software. Um exemplo é o trabalho apresentado em (TONINI, 2006), no qual é proposto um roteiro para implementação do Six Sigma, denominado SW-DMAIC, combinando o método original e as adaptações do método realizadas em cinco organizações de desenvolvimento de software. Em (BEZERRA, 2009), é apresentado uma simplificação do método DMAIC – denominada MiniDMAIC – com o objetivo de auxiliar a implantação de análise de causas e resolução de problemas para o desenvolvimento de software. Esta simplificação se caracteriza pela diminuição da necessidade dos métodos estatísticos exigidos pelo método original.
Para a aplicação das técnicas apresentadas tanto no CEP como no Six Sigma, normalmente as organizações utilizam alguma ferramenta estatística como apoio. As principais ferramentas utilizadas com este propósito são: Minitab, Statistica e QIMacros, apresentadas a seguir.
O Minitab (MINITAB, 2016) é a ferramenta mais citada nos relatos identificados do uso da ADP na área de software. Esta ferramenta oferece apoio a diversas técnicas, tais como: testes estatísticos para identificar distribuição dos dados, gráficos de controle, gráfico de Pareto, histograma, regressão linear, análise de dependência dos dados etc. Oferece um assistente interativo que auxilia a identificação dos métodos estatísticos mais apropriados de acordo com os dados que estão sendo analisados.
37
O Statistica (STATSOFT, 2016) é um pacote de ferramentas que envolve desde a análise de dados com métodos estatísticos até procedimentos de visualização de informações. Dentre as ferramentas, há a Statistica Quality Control que apoia especificamente o uso das técnicas da ADP.
O QIMacros (QIMACROS, 2016) é um plug-in do Excel que permite a aplicação das técnicas do CEP e outras técnicas para solução de problemas, por meio da criação de gráficos de controle, gráfico de Pareto, histogramas, dentre outros. Assim como as demais ferramentas, apresenta assistentes (wizards) para cada técnica.