Utilização de Gráficos de Controle para Gerência
Quantitativa de Processos de Software
Paula Moreira, Cleidson de Souza
Programa de Pós-Graduação em Ciência da Computação (PPGCC) – Centro de Ciências Exatas e Naturais (CCEN) – Universidade Federal do Pará (UFPA)
Rua Augusto Corrêa, No. 1 – 66075-110 – Belém – PA – Brasil pdanni@gmail.com, cdesouza@ufpa.br
Abstract. Quantitative management is a practice used by process evaluation
models as a way to obtain feedback about software process behavior. Many organizations collect measures about their processes, but, they are not aware or do not use statistical techniques to evaluate the achieved results. In this context, the control chart is one statistic tool, still underused in software engineering, that is efficient for evaluate the process performance. So, the goal of this paper is to present the control chart features, emphasizing its applicability in software process performance evaluation and develop one software to facilitate control chart creation and analysis. One case study was realized using two control charts to evaluate the projects adhesion to a process, emphasizing main the peculiarities of control charts.
Resumo. A gerência quantitativa é uma das práticas citadas por modelos de
avaliação de processos para obter feedback a respeito do comportamento do processo. Muitas organizações coletam medidas a respeito de seu processo, porém, desconhecem ou não utilizam técnicas estatísticas para avaliar os resultados alcançados. Nesse contexto, o gráfico de controle é uma ferramenta estatística, ainda pouco utilizada na área de engenharia de software e que se mostra eficiente para avaliar o desempenho de processos. Assim, este artigo objetiva estabelecer as características dos gráficos de controle, ressaltando a sua aplicabilidade na avaliação do desempenho de processos de software e desenvolver um software para auxiliar na geração dos gráficos de controle. Um estudo de caso foi realizado utilizando-se dois gráficos de controle para avaliar a aderência de projetos a um processo, ressaltando principalmente as peculiaridades dos gráficos de controle utilizados.
1. Introdução
Em desenvolvimento de software, a qualidade pode ser entendida como um conjunto de características a serem satisfeitas de modo que o software atenda às necessidades explícitas e implícitas de seus usuários. Para avaliar a qualidade de um produto é necessário gerenciá-lo quantitativamente para se obter medidas que quantifiquem o grau de uma característica de qualidade, sendo também necessária a utilização de um mecanismo de coleta e análise dessas medidas. Entretanto, a qualidade do produto depende fortemente da qualidade de seu processo de desenvolvimento (Fuggetta, 2000). Sendo assim, tão importante quanto avaliar a qualidade do produto é identificar o desempenho do processo de desenvolvimento seguido. Porém, o que se observa hoje na maioria das organizações é uma grande quantidade de dados coletados que não são utilizados para acompanhar o desempenho dos processos. Desta forma, não é possível determinar se os objetivos pretendidos pela organização estão sendo alcançados e se o processo é capaz de alcançá-los (Chrissis et al., 2003).
Por outro lado, os principais modelos de avaliação de processo de software, a saber, o CMMI (Chrissis et al, 2003) e o MPS.Br (SOFTEX, 2008), em seus níveis mais altos exigem que o processo esteja sob controle estatístico, ou seja, que algum método estatístico seja utilizado para gerenciar o mesmo. Segundo Ramos (2003), um método estatístico eficiente para controlar a estabilidade de processos industriais é a abordagem conhecida como Controle Estatístico de Processo, ou simplesmente CEP, que envolve sete ferramentas estatísticas: Estratificação, Folha de Verificação, Diagrama de Ishikawa, Gráfico de Pareto, Histograma, Diagrama de Correlação e Gráficos de Controle. Dentre essas ferramentas, as mais difundidas devido à facilidade para aplicação e interpretação são os gráficos de controle (Ramos, 2003), (Costa et al., 2005). Existem diferentes tipos de gráficos de controle que podem ser aplicados a processos, todavia, para engenharia de software, esses métodos são considerados relativamente inexplorados (Card, 2004). A exceção são pesquisadores, como Card (2007 e 2008), Cerdeiral et al (2007), Komuro (2006) e Florac (2000) entre outros, que têm testado a utilização dos gráficos de controle em processos de software, com resultados bastante positivos. Entretanto, ainda existem dificuldades para aplicação dos gráficos de controle para processo de software, tanto no sentido da identificação do tipo de gráfico adequado para avaliar o desempenho do processo estudado quanto para sua interpretação na busca do entendimento das causas que provocaram variações indesejáveis no processo. Seguramente, melhorar os gráficos de padrões propostos por Shewhart1 e/ou propor novas metodologias de construção e utilização, tornou-se um desafio para os pesquisadores e usuários do controle estatístico. Neste sentido surgiram os gráficos de controle de regressão (Ramos (2003) apud DiPaola (1945)), gráficos de controle multivariados (Ramos (2003) apud Hotelling (1947)) e os gráficos de controle para pequenas variações no processo (Ramos (2003) apud Page (1954)).
Baseado nas três considerações acima – a necessidade de gerenciar quantitativamente os processos, a necessidade das empresas brasileiras atingirem níveis mais elevados de maturidade que exigem gerência quantitativa e a eficiência da abordagem de controle estatístico de processo – o objetivo deste projeto é apresentar uma abordagem para aplicação dos gráficos de controle como instrumento a ser utilizado para a avaliação do desempenho de processos de software. Este projeto prevê também a implementação de uma ferramenta para gerência quantitativa de processos de software que gere automaticamente os gráficos de controle. Uma vantagem desta abordagem é fornecer uma forma para obtenção do entendimento a respeito do comportamento dos processos, o que pode ajudar no gerenciamento das causas de variação dos mesmos e assim auxiliar na tomada de decisões sobre as ações corretivas ou adaptativas a serem tomadas. A abordagem proposta também pode, e deve, ser utilizada por organizações que desejam melhorar seus processos desde os níveis iniciais de maturidade dos modelos de avaliação (Florac e Carleton, 1999; Radice, 1998; Sargut e Demirörs, 2007).
Além da introdução, este artigo está dividido nas seguintes seções: Os gráficos de controle são apresentados na seção 2. Um estudo de caso realizado é apresentado na seção 3, enquanto que na seção 4 são realizadas as considerações finais e por fim, na seção 5 o andamento das atividades deste trabalho é revelado.
1
Gráficos de controle do tipo Shewhart utilizam somente o resultado amostral atual, estes são conhecidos como gráficos de controle sem memória.
2. Controle Estatístico de Processo
Para Montgomery (2004) o controle estatístico de processo é uma poderosa coleção de ferramentas utilizada para resolução de problemas úteis na obtenção da estabilidade do processo e na melhoria da capacidade por meio da redução da sua variabilidade. Controle estatístico de processo é uma metodologia utilizada para avaliar se um dado processo se encontra sob controle estatístico, ou seja, se ele possui desempenho, custo e qualidade previsíveis, além de auxiliar na melhoria contínua da qualidade e do desempenho do processo (Florac, 1999).
Quando o processo não se encontra estável, devem-se estudar as causas que estão fazendo com o processo fique instável no sentido de determinar se as causas para tal fato são causas comuns ou causas atribuíveis. As causas comuns traduzem as variações normais que ocorrem o tempo todo em qualquer processo, e são geradas pela iteração entre os componentes do processo (pessoas, máquinas, ambiente, material, ambientes e métodos) e são difíceis de ser controladas. As causas especiais são geradas por alguma situação ou ação que pode justificar a variação ocorrida, sendo que estas causas podem ser controladas (Florac, 1999). Os gráficos de controle buscam mostrar justamente se o processo está sendo influenciado por causas especiais ou atribuíveis para que, eliminando as mesmas se consiga garantir previsibilidade aos processos.
2.1. Gráficos de Controle
Os gráficos de controle surgiram a partir da necessidade de encontrar métodos mais rigorosos de controle da qualidade que pudessem gerar mais confiança nos produtos e serviços. Assim, em 1924, Walter Andrew Shewhart introduziu o conceito de gráficos de controle, que mais tarde veio a ser chamado o primeiro gráfico de controle de Shewhart (Banks, 1989). Os gráficos de controle são utilizados para auxiliar no controle dos processos, permitindo a identificação de quaisquer variações ou desvios.
Estes gráficos são baseados em estatísticas como a média amostral, o desvio padrão amostral, a mediana amostral, dentre outras. Um gráfico de controle tipo Shewhart usualmente contém uma linha central paralela à abscissa. A altura desta linha central (LC) é dada pelo valor alvo do processo essa linha reflete o nível de operação do processo. Este valor pode, por exemplo, ser um valor nominal exigido por lei, um padrão ou especificações de produção. Pode ser também um valor baseado na experiência passada do processo ou um valor estimado tomado de um processo sob condições sem perturbações. O limite superior de controle (LSC) e o limite inferior de controle (LIC) definem os valores - máximo e mínimo - de uma variável. Esses valores são estabelecidos a três desvios-padrões (), fazendo com que a probabilidade de um ponto está dentro dos limites seja 99,74%. Assim, no estado de estabilidade, a probabilidade de um ponto cair fora dos limites de controle torna-se muito pequena (Montgomery, 2004).
Quando há pontos além dos limites inferior e superior, considera-se o processo como instável, ou fora de controle, ou imprevisível. Fatos estes explicados pela presença de causas especiais que atuam sobre o processo e que ocorrem de forma independente e sem controle. Quando todos os pontos estão distribuídos aleatoriamente sobre os limites inferior e superior, diz-se que o processo está estável, ou sob controle ou ele é previsível. Assim, as variações se devem apenas por causas comuns. Existem outras regras para análise do comportamento de processos que vão além da ocorrência de um valor excedendo os limites de controle.
Existem diferentes tipos de gráficos de controle, que são diferenciados pelo tamanho das observações, periodicidade da coleta das observações e tipo de informações
analisadas (variáveis ou atributos). O controle da média do processo ou do nível médio da qualidade é usualmente feito através do gráfico de controle das médias, ou gráfico X-bar (Montgomery, 2004). Os gráficos de controle X-X-bar e seu gráfico de amplitude (R) são utilizados quando a coleta de múltiplos dados sob as mesmas condições e num pequeno período de tempo é possível. Os gráficos de controle XmR (moving range) e seu gráfico de amplitude móvel são utilizados quando o período de tempo entre a coleta dos dados é grande, ou quando existe a necessidade de investigar dado a dado (Montgomery, 2004). Os dados são exibidos individualmente, sem grupamentos, e, através da amplitude móvel entre os valores mais próximos no tempo, deste modo, o desempenho do processo pode ser analisado. Quando as características da qualidade não podem ser expressas através de valores numéricos de modo conveniente, elas são expressas através dos atributos. Existem três tipos de gráficos de controle aplicados a atributos amplamente usados (Montgomery, 2004). O primeiro desses gráficos se relaciona à fração de itens não-conformes ou defeituosos, produzidos por um processo, e é chamado de gráfico de controle para fração não - conforme, ou gráfico p. Esse gráfico é indicado para situação em que se deseja trabalhar com o número de defeitos e não-conformidades observadas, em vez de fração dos dados não-conformes. O segundo tipo de gráfico de controle para atributos é o chamado gráfico de controle para não-conformidades, ou gráfico c. O terceiro tipo de gráfico é o gráfico de controle para não-conformidades por unidade, ou gráfico u, que é útil em situações onde o número médio de não conformidades por unidades é uma base mais conveniente para o processo de controle.
As pesquisas realizadas até hoje envolvendo gráficos de controle revelam muitos outros tipos de gráficos com características peculiares. Ramos (2003) apud DiPaola (1945) cita os gráficos de controle de regressão para descrever e representar o controle simultâneo entre duas variáveis. Mason e Young (2002) mostram uma metodologia baseada nos gráficos de controle multivariados, que se distinguem dos gráficos univariados por levar em conta a inter-relação entre os dados. Ramos (2003) apud Pignatiello e Runger (1990) incentivaram a utilização do gráfico de controle de Soma Acumulada como complemento aos gráficos de controle padrão de Shewhart, uma vez que estes gráficos conseguem, através da soma acumulada, detectar pequenas variações no processo. O gráfico da média móvel ponderada exponencialmente (EWMA) consiste em outra alternativa para detectar pequenas mudanças de deslocamento da média do processo, sendo usualmente utilizado em observações individuais. Esses dois últimos gráficos de controle são considerados com memória, pois eles utilizam os dados das amostras precedentes para avaliar a estabilidade do processo.
3. Estudo de Caso
Um estudo de caso já foi realizado para mostrar uma possível aplicação dos gráficos de controle no sentido de avaliar a aderência ao processo de software seguido. Mais detalhes podem ser encontrados em (Moreira et al , 2008). Para a verificação da aderência dos projetos ao processo, foram utilizados os resultados das não conformidades identificadas nas revisões realizadas pelo grupo de garantia da qualidade da empresa estudada. Essas não conformidades foram coletadas a partir de um sistema implantado na empresa que armazena as quantidades de não conformidades em cada artefato que compõe o processo de desenvolvimento.
As amostras coletadas e utilizadas neste estudo referem-se às quantidades de não conformidades apontadas nos resultados de 128 revisões da Garantia da Qualidade de Software realizadas no pólo da Regional Belém no período de janeiro de 2005 a Fevereiro de 2008, ou seja, 38 observações normalmente distribuídas. Foram
selecionados para a coleta 26 projetos de software de alta complexidade com esforço a partir de 150 homens-dia. Os períodos das coletas correspondem a três etapas de maturidades do pólo de software: a primeira de janeiro a dezembro de 2005 onde ocorreram estudos, treinamentos e disseminação do CMM-SW nível 2; a segunda etapa, de janeiro a dezembro de 2006, período onde ocorreram as avaliações corporativas do nível de maturidade do processo e a terceira etapa de janeiro de 2007 a fevereiro de 2008, período posterior a certificação CMM-SW nível 2.
A partir da coleta das quantidades de não conformidades armazenadas no sistema
Revisa aplicou-se o inicialmente o gráfico de controle para observações individuais
(XmR). A Figura 1 mostra o gráfico gerado com as informações das não conformidades coletadas, observa-se que as quantidades de não conformidades estão sob controle. Vale observar que dentre as regras que identificam instabilidade no processo existe uma que afirma que quando mais de oito pontos estão abaixo ou acima da linha central o processo pode ser considerado como fora de controle estatístico (Montgomery, 2004) Mas, no contexto dessa aplicação, quanto menor a quantidade de não conformidades, mais aderente ao processo os projetos estão, logo esse gráfico mostra que o processo está se comportando como desejado pela organização e que existem apenas duas observações discrepantes, as observações 17 e 39. Mas mesmo com um aumento das não conformidades nestas observações, o processo pode ser considerado sob controle.
Figura 1. Gráfico de Controle XmR para a quantidade de Não Conformidades Apontadas nos Resultados das Revisões GQS no Período de janeiro de 2005 a fevereiro de 2008.
Segundo Bravo (1995), o gráfico de controle de somas acumuladas indica rapidamente a ocorrência de pequenas mudanças em um processo. Os gráficos de soma acumulada têm como principal característica detectar pequenas mudanças na distribuição da característica de qualidade e são aplicados tanto para observações individuais (n = 1) quanto para as médias das observações amostrais. No gráfico de soma acumulada (CUSUM), à medida que as amostras são retiradas, os desvios de Xi em relação ao valor
da média (0) são acumulados. Os gráficos CUSUM não são considerados gráficos de
controle por não apresentarem os limites de controle. Dentre as várias maneiras de representar os CUSUM’s, destaca-se o gráfico CUSUM Tabular, o qual é considerado um gráfico de controle, pois estabelece seu limite de controle igual a H e supõe que os dados coletados seguem distribuição normal com média e desvio padrão . O gráfico de controle CUSUM Tabular utiliza as estatísticas C+i (detecta mudanças positivas) e C-i
(detecta mudanças negativas) denominadas de CUSUM’s unilaterais superior e inferior, respectivamente. C+i e C-i acumulam desvios em relação a 0 e são igualados a zero
quando se tornam negativos. O intervalo de decisão ou limite de controle utilizado no gráfico de controle CUSUM Tabular é H. Se o valor de C+i ou C-i exceder esse intervalo
encontrar as causas atribuíveis que levaram o processo a tal estado e estimar seu valor médio para que se possa fazer o ajuste adequado (Alves, 2003). Geralmente, utiliza-se um valor para H igual a cinco vezes o desvio padrão do processo (H = 5). Portanto, no algoritmo do gráfico de controle CUSUM Tabular, existem os contadores denominados
N+i e N-i que indicam o número de períodos consecutivos em que os CUSUM’s C+i e C-i
assumem o valor diferente de zero. Costa et al. (2005) afirmam que esses indicadores são muito úteis para indicar o momento em que a média do processo alterou, sendo importante para auxiliar no diagnóstico dessa alteração. Para determinar o momento estimado da mudança, deve-se subtrair N+i ou N-i do número da observação que sinalizou
um estado fora de controle estatístico.
Assim, o gráfico de controle de Soma Acumulada para observações individuais foi utilizado, como uma alternativa a complementar a análise do. A Figura 2 apresenta as estatísticas CUSUM Superior (C+i) e CUSUM Inferior (C-i) para a quantidade de não conformidades apontadas nos resultados das revisões GQS no período de janeiro de 2005 a fevereiro de 2008. O limite superior H igual a 5 foi considerado, pois este é um valor condizente com a literatura da área. Como o valor do desvio padrão foi 6,25, o valor do limite superior H foi 31,25.
Figura 2. Gráfico de Controle CUSUM Tabular para a quantidade de Não Conformidades Apontadas nos Resultados das Revisões GQS no Período de janeiro de 2005 a fevereiro de 2008.
Observa-se que com relação aos valores C+i, que a observação referente ao mês de
maio de 2006 (observação 17), encontra-se acima do limite superior de controle (LSC=31,25), com N+i =17 (17 - 17 = 0). Com isso, estima-se que o aumento das não
conformidades inicia desde janeiro de 2005 (observação 1), pois a subtração do número da observação que sinalizou o aumento de N+i indica o momento estimado da mudança.
Isso é importante para que as causas atribuíveis sejam identificadas e a organização possa tomar decisões baseada não somente nos fatos ocorridos no período em que a observação referente ao mês de maio de 2006 excedeu os limites, mas que uma análise mais detalhada possa ser realizada, a partir do período de início da variação. Com relação aos valores do CUSUM Inferior (C-i), observa-se que a partir da observação referente ao mês
de junho de 2007 (observação 30) a quantidade de não conformidades nas revisões GQS encontra-se acima do limite superior de controle, com N-i = 13 (30-13= 17). Logo,
estima-se que essa redução inicia entre maio de 2006 (observação 17) e junho de 2006 (observação 18), pois a subtração do número da observação que sinalizou a diminuição de N-i indica o momento estimado da mudança.
3.1. Análise e Interpretação dos Resultados
A partir da aplicação dos dois gráficos de controle: gráfico para observações individuais e o gráfico de Soma Acumulada, pode-se notar que para o primeiro gráfico os projetos se mostraram como aderentes ao processo. Porém, a partir do gráfico de controle CUSUM Tabular, observa-se um aumento na quantidade de não conformidades de janeiro de 2005 a maio de 2006. Entrevistas com os envolvidos na gerência das equipes de GQS foram realizadas e constatou-se que uma possível razão para o aumento na quantidade de não conformidades nesse período foi que a equipe de desenvolvimento estava em fase de aprendizado, portanto, os artefatos não eram bem elaborados/atualizados. Além disso, novas pessoas foram admitidas na organização, o que conseqüentemente trouxe dificuldade para os novos integrantes em seguir o processo de desenvolvimento utilizado pela empresa. Assim como os revisores adquiriam mais experiência a partir das medidas adotadas pela organização para melhorar a revisão (treinamentos, mentorias, etc.), os desenvolvedores e líderes de projetos também evoluíram na elaboração/atualização dos artefatos, uma vez que a organização estava investindo na certificação, o que motivou os desenvolvedores e gerentes a seguirem o processo definido. Com estas medidas, a quantidade de não conformidades diminuiu e a partir do gráfico CUSUM Tabular, observa-se que essa diminuição começa entre os meses de maio e junho de 2006.
Uma observação importante foi que os projetos tiveram um aumento da aderência ao processo definido, já que a quantidade de não conformidades diminuiu. Em Dezembro de 2006, a organização conseguiu a certificação CMM-SW nível 2, quando a avaliação foi realizada, acreditava-se que os projetos estavam sendo seguidos de acordo com o estabelecido no processo, contudo, não se tinha uma forma de confirmar tal fato. Com a utilização da abordagem sugerida pôde-se perceber que a certificação poderia ter sido alcançada antes do período, pois desde junho de 2006 os projetos estavam mais aderentes ao processo.
Foi possível ratificar também que o gráfico de controle de Soma Acumulada é mais eficiente na identificação de pequenas causas de variação no processo, uma vez que um menor número de amostras se faz necessária para detectar as pequenas variações na média da característica da qualidade monitorada, o seu processo de decisão baseia-se na soma acumulada dos resultados e não em observações isoladas de amostras, como o gráfico para observações individuais e os gráficos de Soma Acumulada ponderam igualmente todas as amostras coletadas do processo ao passo que os gráficos de Shewhart tem como memória do processo apenas o último ponto no gráfico. Porém, é válido afirma que os gráficos de Soma Acumulada não são substitutivos aos gráficos de Shewhart, eles podem atuar como complemento, umas vez que eles permitem que a organização estabeleça ações corretivas ou adaptativas ao processo levando em consideração as pequenas variações no processo.
4. Considerações Finais
Florac (1999) estabelece que um processo de software ideal deve ter as seguintes características: i) ser previsível, ou seja, ter custo estimado de forma precisa, ter compromisso com o cronograma estabelecido e produzir produtos com boa qualidade; ii) propiciar controle estatístico de processo , princípio básico da gerência de processo e iii) fornecer medidas, já que não é possível ter CEP sem medidas, e produzi-las de maneira alinhada às metas e às necessidades da organização. Portanto, organizações que usam medidas são capazes de entender melhor seus problemas e suas capacidades reais, manter compromissos firmados, prever tendências, antecipar problemas e finalmente melhorar o processo de desenvolvimento de software (Florac, 1999). Ou seja, as medidas coletadas
por uma empresa permitem entender o processo de desenvolvimento de software e os produtos que ele produz e tomar melhores decisões. Organizações com programas bem-sucedidos de medição possuem ferramentas para coletar os dados automaticamente, sem exigir esforço e sem interferência humana. No entanto, é muito comum encontrar organizações de software que: a) coletam dados que ninguém utiliza; b) coletam dados que são desconhecidos pelas pessoas que deveriam utilizá-los, e c) coletam dados que não são utilizados para tomar decisões (Mendonça, 1997). Desta forma, muitas organizações comprometem seus produtos por não analisar os dados coletados.
A contribuição deste trabalho é a utilização de gráficos de controle para a gerência quantitativa de processos de software para atender as necessidades de gerencia quantitativa de processos. Esta proposta está alinhada com estudos recentes na área de processo de software Card (2008), Eickelman (2003), Jalote e Saxena (2002) e Florac et
al. (2000)). Visando facilitar a adoção de gráficos de controles por empresas, pretende-se
implementar uma ferramenta para a geração e análise de gráficos de controle. A motivação para criação da ferramenta que automatiza a geração dos gráficos de controle está no fato de não existirem ferramentas livres que auxiliem na geração automática dos gráficos de controle, o que torna a utilização desses gráficos bastante complicada, já que os cálculos dos limites de controle, bem como outras estatísticas, devem ser realizados manualmente. Vale ressaltar também que as ferramentas existentes (dentre elas, o WinSPC e o Minitab) não implementam todos os tipos conhecidos de gráficos de controle.
Este trabalho visa também facilitar com que empresas locais de desenvolvimento de software atinjam níveis de maturidade mais altos do modelo CMMI, ou seja, implantem a gerência quantitativa e utilizem esta abordagem para avaliar e controlar o desempenho dos seus processos de desenvolvimento de software desde suas fases iniciais de concepção. De fato, Florac e Carleton (1999), Radice (1998) e Sargut e Demirörs (2007) afirmam que é possível alcançar os benefícios de CEP mesmo para organizações que ainda encontram-se em baixos níveis dos modelos de avaliação de processo, o que é uma realidade das empresas locais. Ao atingir estes níveis mais altos de maturidade, conseqüentemente a produtividade da empresa aumenta assim como sua qualidade e produtividade. Porém, ainda existem muitos problemas para aplicação dos gráficos de controle a processo de software, principalmente relacionados à coleta dos dados para sua aplicação, que não serão detalhadas neste trabalho, mas uma proposta para tratar esses problemas pode ser encontrada em Barcellos (2008), sendo que as sugestões deste autor serão consideradas neste trabalho.
5. Cronograma
Tabela 1. Cronograma de Atividades Cronograma
Atividade Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez Jan Fev Mar
1
2
3 4 5 Atividades Concluídas Atividades em Andamento
5.1. Andamentodas Atividades
1. Pesquisa relacionada ao levantamento dos tipos de gráficos de controle e questões relacionadas à sua aplicabilidade a processo de software.
2. Escrita de artigos
a. Um artigo (Moreira et al, 2008)foi publicado no XII Simpósio Brasileiro de Qualidade de Software (SBQS);
b. Dois artigos, do tipo pôster, foram escritos em eventos relacionados à área de Estatística, a saber: CNMAC (XXXI Congresso Nacional de Matemática Aplicada e Computacional) e SINAPE (18º Simpósio Nacional de Probabilidade e Estatística). Estes artigos referem-se à ferramenta desenvolvida.
3. Implementação da ferramenta que gere automaticamente os gráficos sugeridos a. O gráfico de controle de regressão e o gráfico da mediana já foram
implementados;
b. Os gráficos de controle utilizados no estudo de caso serão implementados. 4. Avaliação da Proposta por meio de estudos de caso.
a. O primeiro estudo de caso foi realizado e seus resultados foram descritos no artigo publicado e na seção estudo de caso deste documento. Este artigo foi expandido, para se tornar um capítulo da dissertação.
b. A coleta dos dados para o segundo estudo de caso está sendo realizada. c. Falta definir o terceiro estudo de caso.
5. Escrita da Dissertação.
a. O primeiro estudo de caso já foi escrito, que encontra-se em revisão. b. A escrita do capítulo sobre Controle Estatístico de Processo foi iniciada e
deve ser concluída até o final do mês.
6. Agradecimentos
Ao CNPQ pelo apoio a pesquisa.
Referências
Barcellos, M. P., 2008. Uma Abordagem para Controle Estatístico de Processos de Software em Organizações de Alta Maturidade, Exame de Qualificação para Tese de D.Sc. COPPE/UFRJ, Rio de Janeiro, Brasil.
Bravo, P. C. Controle Estatístico da Qualidade, Ribeirão Preto - São Paulo, 18- 21/07/1995. Anais da 40ª RBRAS e 6º SEAGRO, UNESP - Faculdade de ciências agrárias, Ribeirão Preto, 1995.
Card, D.N. Statistical Techniques for Software Engineering Practice. Software Productivity Consortium. Proceedings of the 26th International Conference on Software Engineering, 2004.
Card, D.N. Challenges in Applying Statistical Process Control in Software Engineering. Software Measure Handbook, C. Ebert et al., eds., Springer, 2007, pp. 413-418.
Card, D.N, Domzalski, K. e Davies, G. Making Statistcs Part of Decision Making in an Engineering Organization. IEEE Software – Quantitative Project Management. May/June 2008, pp. 37-47.
Cerdeiral, C., Figueiredo, S., Santos, G. Montoni, M. Pinto, R. Rocha, A. C. Uma Abordagem para Controle Estatístico do Processo e Gerência Quantitativa de Projetos. Simpósio Brasileiro de Qualidade de Software (SBQS), 2007.
Chrissis, M. B., Konrad, M., Shrum, S. CMMI: Guidelines for Process Integration and Product Improvement, Addison Wesley, 2003.
Costa, A. F.; Epprecht, E. K.; Carpinetti, L. C. R. Controle Estatístico de Qualidade. Atlas, 2005, 2a Edição.
Florac, A. W., C., Barnard, A. D. Measuring the Software Process: Statistical Process Control for Software Process Improvement. Addison Wesley, 1999.
Florac, A.W., Carleton, A.D., Barnard, J.R. (2000). Statistical Process Control: Analyzing a Space Shuttle Onboard Software Process, IEEE Software, pp. 97–106.
Fuggetta, A. Software Processes: A Roadmap. Future of Software Engineering, Limerick, Ireland, 2000.
Komuro, M., 2006, Experiences of Applying SPC Techniques to Software Development, Proceedings of the 28th International Conference on Software Engineering - ICSE’06, pp. 577-584.
Montgomery, D. Introdução ao Controle Estatístico da Qualidade. 4a. Ed. Rio de Janeiro: LTC, 2004.
Moreira, P. D. O. ; Pinheiro, L. ; et al. Aplicação dos Gráficos de Controle CUSUM Tabular para Avaliação da Aderência dos Projetos ao Processo de Software. In: Simpósio Brasileiro de Qualidade de Software, 2008, Florianópolis. Anais do Simpósio Brasileiro de Qualidade de Software, 2008.
Radice, R. 1998. Statistical Process Control for Software Projects, 10th Software Engineering Process GroupConference.
Ramos, E. M. L. S. Aperfeiçoamento e Desenvolvimento de Ferramentas do Controle Estatístico da Qualidade utilizando Quartis para estimar o Desvio Padrão. Tese de Doutorado, Universidade Federal de Santa Catarina, Abril, 2003.
Sargut, K. U., Demirörs, O. (2006) Utilization of statistical process control (SPC) in emergent software organizations- Pitfalls and suggestions. Software Qual J (2007) 4: 135–157 DOI 10.1007/s11219-006-7599-x, 2006.
SOFTEX - Associação para Promoção da Excelência do Software Brasileiro. MPS.BR - Guia Geral, v1.2, 2008. Disponível em www.softex.br.
