Motorola Confidential Proprietary 1 Seis Sigma Aplicado à Software Seis Sigma & CMM para Melhoria de Processo e Uma Aplicação Prática SPIN – Campinas 15-Mar-2005

Motorola Confidential Proprietary1

Seis Sigma Aplicado à

SoftwareSeis Sigma & CMM para Melhoria de Processo e

Uma Aplicação Prática

SPIN – Campinas

15-Mar-2005Cibele Brunetto – [email protected]

Luiz Bernardes – [email protected]


Agenda

Parte I:– Seis Sigma– Controle Estatístico de Processo– DMAIC– Seis Sigma & CMM

Parte II:– Aplicação prática– Lições aprendidas


Seis Sigma


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


Definição

Definição como metodologia:


Definição

Metodologia que fornece abordagem de medição orientada a dados para melhoria contínua de processos

Busca satisfação do clienteObjetivos:

– Mover o produto/atributos de serviço para dentro dos limites especificados pelo cliente

– Reduzir a variação no processo (causa de defeitos)


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


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


CEP

Controle Estatístico de Processo


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)


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


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


Princípio

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

presente


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


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


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


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 ()



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




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


DMAIC


Definição

DMAIC é uma metodologia para solução de problemas, visando melhoria de processo e qualidade, composta das seguintes etapas: DefinirMedirAnalisarImplementar MelhoriasControlar

Usa CEP


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


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


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


Etapas

Implementar Melhorias:– Avaliar e selecionar as soluções corretas de

melhoria– Desenvolver plano para gerenciar mudanças


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


Seis Sigma & CMM


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


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


Aplicação Prática


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


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

Melhoria de Ambiente de Compilação

MD A I C


Caso de negócioObjetivo 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 melhoriax 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.

ObjetivosReduzir 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

PlanejamentoMD A I C


Equipe

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

MD A I C


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

Definição de indicadores de desempenho

MD A I C


Desempenho de Referência (OPB)

CEP: Média e variância altas

MD A I C

0

200

400

600

800

1000

1200

Tem

po

de

com

pil

ação

[m

inu

tos]

Limite de controle superior

Limite de controle inferior

Média

Janeiro/2004 | Fevereiro/2004 | Março/2004


Causas Raízes – Método

1. Identificar todas as potenciais causas raízes e soluções de

ganho rápido

2. Redução e Priorização (reduzir o número de causas para análise)

3. Validação estatística das causas raízes. Identificar alternativas de soluções

Brainstorm e Diagramade causa e efeito

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.

Atividade Ferramenta/MétodoMD A I C


Ishikawa – Potenciais Causas Raízes

Tempo deBuild

Processo

Low level of wink-inLack 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

LoadOther 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 optimizedMVFS 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

MD A I C


Pareto - Prioridade de Investigação

0

1

2

3

4

5

6P

rio

rid

ade

Uso

inco

rret

o do

pro

cess

o

Ban

cos

de D

ados

Cle

arca

seE

stru

tura

da

Bui

ldR

ede

(latê

ncia

e b

anda

)

Tem

po d

e es

pera

de

IO

Rea

prov

eita

men

to (b

usca

lent

a, e

lem

.

antig

os)

V

ersã

o do

Cle

arca

se

Sob

reca

rga

(bui

lds

sim

ultâ

neas

)

Bai

xo g

rau

de re

apro

veita

men

to

Ser

vido

res

(ins

ufic

iênc

ia, m

emór

ia)

MD A I C


Causas válidas+Soluções Alternativas

Causas Soluções Alternativas

Uso incorreto do processo

válidas

parcialmente válidas

inválidas

1. Retreinamento no processo2. Rotinas pré-build3. Paralelismo forçado

Bancos de Dados Clearcase (distribuição dos DBs), Espera IO

4. Isolar servidores por função

5. Redistribuir bancos

Estrutura da Build6. Retrabalhar estrutura de Makefiles e GHDR

Reaproveitamento lento de elementos, Pouco reaproveitam.

7. Builds Expressas

8. Builds noturnas

Versão do Clearcase 9. Atualizar versão

Sobrecarga, Servidores10. Build Manager

11. DOE otimização

Rede (latência e banda)

MD A I C


Explorando Alternativas

Soluções Complex. Risco Retorno Decisão

1. Retreinamento no processo

4. Isolar servidores por função

6. Retrabalhar estrutura de

Makefiles e GHDR

7. Builds Expressas

9. Atualizar versão

10. Build Manager

2. Rotinas pré-build

3. Paralelismo forçado

5. Redistribuir bancos

8. Builds noturnas

11. DOE otimização

MD A I C


- Paralelismo sugerido

Média 3h 55minUCL 11h 36min

Soluções + Controle

UCL

Média

LCL

Benchmark

T

empo

[min

utos

]ANTES


Jan Fev Mar Abr Maio JunhoJunho Julho Agosto Setembro

- Isolamento server- Redistribuição BDs- Versão CC- Build ManagerMédia 1h 39minUCL 3h 25min

Antes 5h 13min Sigma 3,74

Ganho total 78%

Processo sob

controle

Hoje 1h 09min Sigma 5,1

- Builds expressas- Rotinas pré-build- Retreinamento- DOEMédia 1h 09minUCL 2h 17min

- Mudanças infra- Paralelismo forçado


MD A I C


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


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


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 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 Suporte a CMM Definição de prioridades. Alocação de recursos.


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


Links Interessantes

Seis Sigma:– http://www.motorola.com/content/0,,3006-248

0,00.html (Treinamento Seis Sigma)

– http://www.isixsigma.com/ – http://www.6siga.com/


Perguntas e Respostas

Documents

Motorola Confidential Proprietary 1 Seis Sigma Aplicado à Software Seis Sigma & CMM para Melhoria de Processo e Uma Aplicação Prática SPIN – Campinas 15-Mar-2005