Seis Sigma Aplicado à Software Seis Sigma & CMM para Melhoria de Processo e Uma Aplicação Prática SPIN – Campinas 15

1. Seis Sigma Aplicado à Software Seis Sigma & CMM para Melhoria de Processo e Uma Aplicação Prática SPIN – Campinas 15-Mar-2005 Cibele Brunetto – Cibele.Brunetto@motorola.com Luiz Bernardes – Luiz.Bernardes@motorola.com

2. Agenda • Parte I: • Seis Sigma • Controle Estatístico de Processo • DMAIC • Seis Sigma & CMM • Parte II: • Aplicação prática • Lições aprendidas

3. Seis Sigma

4. Definição • Definição estatística: • Sigma (): desvio padrão (variação da média em distribuição normal) • Processo é Seis Sigma: ocorrência de valor fora da especificação é RARA: 3.4 ppm

5. Definição • Definição como metodologia:

6. Definição • Metodologia que fornece abordagem de medição orientada a dados para melhoria contínua de processos • Busca satisfação do cliente • Objetivos: • Mover o produto/atributos de serviço para dentro dos limites especificados pelo cliente • Reduzir a variação no processo (causa de defeitos)

7. Histórico • Surgiu na Motorola nos anos 80 aplicado a processos de manufatura • Primeiros “belts” em ferramental estatístico (CEP, análise de variância, métodos comparativos) • Nos anos 90 outras empresas adotaram Seis Sigma e diversificaram usos • Em anos recentes, novas ferramentas e modelos específicos para uso em várias áreas e fases de processos: desenvolvimento de produtos, serviços, finanças, marketing. • “Belts” com perfil menos estatístico e mais gerenciamento de mudança

8. Metodologias e Ferramentas • Conjunto de metodologias e ferramentas • Ferramental estatístico: • CEP (controle estatístico de processos), análise de variância, análise de capacidade, DOE • Técnicas tradicionais de análise de processo: • brainstorm, FMEA, diagrama de causa e efeito • Metodologia de melhoria de processos: • DMAIC, DMADV • Guias para estruturação de áreas: • DFSS, SDFSS, MFSS

9. CEP Controle Estatístico de Processo

10. O Que É – Definição • O que é CEP: • Método para manter o processo dentro de padrões estabelecidos • Padrões estabelecidos através de análise estatística de dados do processo • Discute tipos de variação que afetam o processo • Utiliza ferramentas estatísticas para análise de dados (histograma, gráficos de controle, avaliação dos sistemas de medição)

11. Histórico • Desenvolvido e primeiramente aplicado na indústria manufatureira como método para obter controle da qualidade em processos • Walter A. Shewhart e Edwards Deming • Primeira aplicação: 1924, Western Electric Co. • Objetivo: diminuir variação no processo de produção

12. Histórico • Década de 50: indústrias japonesas – reconstrução do país (pós-guerra) • Década de 80: indústrias manufatureiras do mundo todo • Atualmente: uso também no setor de software • Preencher lacunas dos métodos tradicionais de medição e análise de sw

13. Princípio • Princípio: processo realizado de maneira consistente gera resultados previsíveis • Apenas variação de causa comum está presente

14. Tipos de Variação • 2 tipos de variação: de causa comum e de causa especial • Variação de causa comum: • Inerente ao processo • Padrão estável nos dados • Variação aleatória entre limites previsíveis • Resultados inesperados são raros • Pode ser reduzida, mas não eliminada

15. Tipos de Variação • Variação de causa especial: • Causas específicas e identificáveis, porém imprevisíveis • Surge de eventos que não são parte do processo • Causa instabilidades no processo, afeta qualidade do produto

16. Análise de Estabilidade do Processo • Processo estável: • Está sob controle estatístico, apenas variações de causa comum estão presentes. Resultados são previsíveis -> melhor planejamento • Processo instável: • Causas especiais estão presentes, causando variações e resultados imprevisíveis • Para analisar estabilidade: • Gráficos de controle

17. Gráficos de Controle • Ajudam a detectar influência de causas especiais no processo • Agir e eliminar causas especiais • Trazer o processo novamente sob controle • Princípio: • Processo sob controle possui distribuição Normal: 99,73% dos valores distribuídos na faixa da média + ou – 3 desvios padrão ()

18. Gráficos de Controle • Elementos básicos: • Média (ou linha central) • Limite Superior de Controle (LSC): • média + 3  • Limite Inferior de Controle (LIC) • média - 3  • São estimativas calculadas de conjunto de observações coletadas durante uso do processo

19. Gráficos de Controle

20. Análise de Capacidade • Se o processo está estatisticamente estável: o processo é capaz? • Processo pode estar estável, mas não ser capaz • Um processo “capaz” produz resultados consistentes com as metas de negócio e é avaliado como eficiente (nível sigma) • É capaz de atingir especificações do cliente • Análise de capacidade possibilita e direciona identificação de oportunidades de melhoria de processo • Se o processo não é capaz: • Reduzir variação • Deslocar a média

21. DMAIC

22. Definição • DMAIC é uma metodologia para solução de problemas, visando melhoria de processo e qualidade, composta das seguintes etapas: • Definir • Medir • Analisar • Implementar Melhorias • Controlar • Usa CEP

23. Etapas • Definir Oportunidades: • Visa identificar e/ou validar a oportunidade de melhoria alvo do projeto DMAIC • Definir metas e objetivos do projeto • Identificar requisitos críticos do cliente • Preparar equipe do projeto • Identificar/mapear processos envolvidos

24. Etapas • Medir Desempenho: • Identificar medições críticas para avaliar sucesso no atendimento dos requisitos mínimos do cliente • Criar plano de medição (como coletar dados para medir desempenho dos processos) • Fazer medições e colocar em gráficos de controles • Analisar os gráficos (causas especiais agindo?) • Análise de capacidade do processo

25. Etapas • Analisar Oportunidades: • Identificar e validar causas raízes das fontes de variação • Garantir a eliminação das causas raízes reais para aumentar a capacidade do processo (atingir especificações do cliente) • Propor alternativa de soluções que eliminem causas raízes validadas ou reduzam seu impacto

26. Etapas • Implementar Melhorias: • Avaliar e selecionar as soluções corretas de melhoria • Desenvolver plano para gerenciar mudanças

27. Etapas • Controlar Desempenho: • Executar piloto do plano de gerência de mudanças -> garantir que resultados almejados são atingidos • Analisar resultados do piloto • Identificar oportunidades de replicação da solução na organização

28. Seis Sigma & CMM

29. Comparação

30. Seis Sigma & CMM • Seis Sigma e CMM para melhoria de processos de SW • São complementares • É possível usar Seis Sigma desde primeiros níveis do CMM, em iniciativas isoladas • Seis Sigma fornece ferramental para construir os níveis 4 e 5 • Uso conjunto: resultados concretos da melhoria de processos • Ambos exigem comprometimento da alta gerência da organização

31. Aplicação Prática

32. Aplicando Six Sigma • Contexto 2004 • Abordagem de PITs sob coordenação SEPG com foco em certificação CMM4 • 4 projetos DMAIC pilotos de melhoria propostos não vinculados a CMM4 • Melhoria de ambiente de compilação • Redução de defeitos escapados • Redução de defeitos duplicados e terminados • Redução de ciclo de testes de campo

33. Melhoria de Ambiente de Compilação D M A I C • Contexto • Plataforma de desenvolvimento de SW • Clearcase Unix • Gerência de Configuração • Ambiente de Compilação(Build) • Tempo Médio e Variância altos • Impacto em produtividade • Metodologia DMAIC • Otimizar processo de forma estruturada

34. Planejamento D M A I C

35. Equipe D M A I C • Green Belt • Análise estatística • Ferramentas de solução de problemas • Gerência do projeto • Especialistas da área • Suporte técnico e implementação • Gerentes • Recursos e prioridades • Champion • Alinhamento estratégico e análise crítica

36. Métricas Operacionais Tempo de compilação # de elementos compilados # de elementos reaproveitados Parâmetros de compilação Monitoramento do Ambiente Memória Carga Tempo de E/S Rede D M A I C • Definição de indicadores de desempenho

37. Desempenho de Referência (OPB) D M A I C • CEP: Média e variância altas Limite de controle superior Média Limite de controle inferior Janeiro/2004 | Fevereiro/2004 | Março/2004

38. Causas Raízes – Método D M A I C Atividade Ferramenta/Método 1. Identificar todas as potenciais causas raízes e soluções de ganho rápido Brainstorm e Diagrama de causa e efeito 2. Redução e Priorização (reduzir o número de causas para análise) Votação e Pareto Análise estatística (fontes de variância, métodos comparativos, análise de dados categóricos) aplicada a dados históricos e simulações. Pesquisa por alternativa de soluções. 3. Validação estatística das causas raízes. Identificar alternativas de soluções

39. Ishikawa – Potenciais Causas Raízes Load Infraestrutura # of builds Other concurrent processes limit of parallelism 6 slowness processor Servers Processo # of servers Inadequate use of bldsrc vs lib Topology No info to run partial builds Inadequate use of parallelism Latency Network misuse of build process Bandwidth Inadequate use of official version Inadequate use of debug low response time view/vob Low level of wink-in IO wait Lack of mechanism to maximize wink-in Tempo de Build ENOENT cache not optimized Header file structure Makefile (not optimized, no debug off, no link) Tuning lack of release libs view cache not optimized MVFS cache not optimized Arquitetura das Builds Instability of environment overload Multisite 24X7 update scheme lack of vob servers to distribute load all platforms over the same databases vobs large version trees large bottleneck vobs view and vob on same machine vob load among servers Not enough RAM CC version slowness to generate CR wink-in slowness to match very old DOs Build load distribution among build servers D M A I C Ferramenta Clearcase

40. Pareto - Prioridade de Investigação 6 5 4 Prioridade 3 2 1 0 Uso incorreto do processo Rede (latência e banda) Estrutura da Build Servidores (insuficiência, memória) Versão do Clearcase Tempo de espera de IO Baixo grau de reaproveitamento Sobrecarga (builds simultâneas) Reaproveitamento (busca lenta, elem. antigos) Bancos de Dados Clearcase D M A I C

41. Causas válidas+Soluções Alternativas D M A I C válidas Causas Soluções Alternativas parcialmente válidas inválidas 1. Retreinamento no processo 2. Rotinas pré-build 3. Paralelismo forçado Uso incorreto do processo Bancos de Dados Clearcase (distribuição dos DBs), Espera IO 4. Isolar servidores por função 5. Redistribuir bancos 6. Retrabalhar estrutura de Makefiles e GHDR Estrutura da Build 7. Builds Expressas 8. Builds noturnas Reaproveitamento lento de elementos, Pouco reaproveitam. 9. Atualizar versão Versão do Clearcase 10. Build Manager 11. DOE otimização Sobrecarga, Servidores Rede (latência e banda)

42. Explorando Alternativas D M A I C Soluções Complex. Risco Retorno Decisão 1. Retreinamento no processo 2. Rotinas pré-build 3. Paralelismo forçado 4. Isolar servidores por função 5. Redistribuir bancos 6. Retrabalhar estrutura de Makefiles e GHDR 7. Builds Expressas 8. Builds noturnas 9. Atualizar versão 10. Build Manager 11. DOE otimização

43. Soluções + Controle D M A I C - Isolamento server - Redistribuição BDs - Versão CC - Build Manager Média 1h 39min UCL 3h 25min ANTES Média 5h 13min UCL 26h 30min • Builds expressas • Rotinas pré-build • Retreinamento • DOE • Média 1h 09min • UCL 2h 17min - Paralelismo sugerido Média 3h 55min UCL 11h 36min UCL - Mudanças infra - Paralelismo forçado Média 1h 53min UCL 3h 42min Processo sob controle Tempo [minutos] Média Bench mark LCL Julho Junho Jan Fev Mar Agosto Abr Maio Junho Setembro Antes 5h 13min Sigma 3,74 Hoje 1h 09min Sigma 5,1 Ganho total 78%

44. Resultados • Melhoria acima das expectativas • 78% (obtido) x 40% (meta inicial) • De desempenho mediano a “benchmark” • Ganhos significativos em processo • Previsibilidade e estabilidade • Redução de ciclo de desenvolvimento, melhoria de produtividade • Economia • Investimentos somente em áreas de alto retorno • Novos investimentos somente em 2006

45. Lições Aprendidas • Metodologia e ferramentas Six Sigma são adequadas a ambientes de desenvolvimento de software • Êxito devido a: • Alinhamento com objetivos organizacionais • Comprometimento da alta gerência • Time de projeto: belts + especialista • Status de projeto “formal” da organização • Gerência de projeto • Acompanhamento estreito dos patrocinadores • Objetivos do projeto mapeado nas metas individuais dos membros

46. Contexto 2005

47. Conclusão • Seis Sigma pode ser usado em melhoria de processos de SW • São necessários recursos treinados e suporte organizacional • Ferramentas adequadas para definição de prioridades, avaliação de ganhos, garantia de resultados e satisfação dos clientes

48. Links Interessantes • Seis Sigma: • http://www.motorola.com/content/0,,3006-2480,00.html (Treinamento Seis Sigma) • http://www.isixsigma.com/ • http://www.6siga.com/

49. Perguntas e Respostas