Seis Sigma Aplicado à Software

Apresentação em tema: "Seis Sigma Aplicado à Software"— Transcrição da apresentação:

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 – Luiz Bernardes –

2 Parte I: Parte II: Agenda 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 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 Busca satisfação do cliente Objetivos:
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 Controle Estatístico de Processo
CEP Controle Estatístico de Processo

10 Método para manter o processo dentro de padrões estabelecidos
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 Walter A. Shewhart e Edwards Deming
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 Década de 50: indústrias japonesas – reconstrução do país (pós-guerra)
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 2 tipos de variação: de causa comum e de causa especial
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 Variação de causa especial:
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 Ajudam a detectar influência de causas especiais no processo
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 Definir Oportunidades:
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 Medir Desempenho: Etapas
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 Analisar Oportunidades:
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 Implementar Melhorias:
Etapas Implementar Melhorias: Avaliar e selecionar as soluções corretas de melhoria Desenvolver plano para gerenciar mudanças

27 Controlar Desempenho:
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 CMM Seis Sigma Foco na definição de processos Foco nos resultados Abordagem organizacional Projetos isolados de melhoria Difícil medir ROI ROI é parte do processo Gerência quantitativa e controle de processo só a partir dos níveis 4 e 5 Abordagem estatística em todos projetos

30 Seis Sigma e CMM para melhoria de processos de SW
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 Contexto 2004 Aplicando Six Sigma
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
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 M D A I C

34 Oportunidade de melhoria
Planejamento D M A I C Caso de negócio Objetivo organizacional de melhoria de produtividade e ciclo de vida em desenvolvimento de software. Tempo de build identificado como área com alto potencial de melhoria e impacto relevante. Oportunidade de melhoria x builds são rodadas mensalmente por y desenvolvedores, levando z horas. Tempo longo e com alta variância são considerados gargalos em desenvolvimento de SW. Objetivos Reduzir o tempo de build em 40% e reduzir a variância de maneira a tornar o processo estável e previsível. Desenvolver e implementar modelo para monitorar e avaliar o desempenho, minimizar necessidades futuras de recursos baseado na carga e caracterização de uso. Cronograma Mar Abr Mai Jun Jul Ago Definir Medir Analisar Melhorar Controlar

35 Green Belt Especialistas da área Gerentes Champion Equipe
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 Definição de indicadores de desempenho
Métricas M D A I C Definição de indicadores de desempenho 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

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

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

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

41 Causas válidas+Soluções Alternativas
M D 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
M D 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 Antes 5h 13min Sigma 3,74 Hoje 1h 09min Sigma 5,1
- Isolamento server - Redistribuição BDs - Versão CC - Build Manager Média 1h 39min UCL 3h 25min M D A I C 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 Junho Jan Fev Mar Julho Agosto Abr Maio Junho Setembro Antes 5h 13min Sigma ,74 Hoje h 09min Sigma ,1 Ganho total 78%

44 Melhoria acima das expectativas
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 Melhoria de Processo de Software
Contexto 2005 Melhoria de Processo de Software 2003 2004 2005 Modelo SEPG define prioridades. PIT concentra áreas chaves e distribui tarefas de granularidade mais baixa Híbrido: PITs e SEPG + Pilotos SS seguindo estrutura formal de projeto Dissolução dos PITs. SEPG prioriza/ acompanha projetos formais de melhoria: projetos SS (mais longos, escopo amplo) e forças tarefas (mais curtos, escopo limitado) Foco Adequação a CMM Foco no atingimento dos objetivos de melhoria de desempenho e qualidade de produto. Necessidades das áreas. Definição e Priorização PITs e SEPG Híbrido: PITs e SEPG + Definição de pilotos SS descentralizada Análise formal de processos críticos das áreas. Priorização SEPG. Times PITs: membros voluntários, tempo parcial Híbrido: PITs voluntários + Pilotos SS recursos convidados sob coordenação de belt tempo parcial Projetos SS mais complexos sob coordenação de BB tempo integral e recursos convidados. Outros projetos SS e forças tarefas sob coordenação de GBs, BBs e candidatos. Papel da gerência Suporte a CMM Definição de prioridades. Alocação de recursos.

47 Seis Sigma pode ser usado em melhoria de processos de SW
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 Seis Sigma: Links Interessantes
(Treinamento Seis Sigma)

49 Perguntas e Respostas