pr00835-695-mba cmmi aula alunos

Prof. Josiane Bernardes CMMI

MBA EM GOVERNANÇA NAS TECNOLOGIAS DA INFORMAÇÃO

MODELOS DE MATURIDADE DO PROCESSO DE SOFTWARE CMMI CMMI_12/10

JOSIANE [email protected]

– Mestre


Josiane BernardesJosiane Bernardes

� Formação Acadêmica

� Bacharel em Ciência da Computação

� Mestre em Engenharia de Computação pelo IPT/SP

� Experiência Profissional

� Desde 1995 trabalha em Engenharia de Software

� Consultora de Engenharia de Software na ISD Brasil atuando em todo Brasil e

Portugal

� Instrutora e auditora do modelo CMMI

� Experiência Acadêmica

� Docente na UNIP por 7 anos na disciplina de Engenharia de Software.

� Docência na pós-graduação do curso de Engenharia de software com SOA: IBTA –

Qualidade de Software


ALGUNS DETALHES IMPORTANTES

CRONOGRAMA

Dia Semana Carga Horária

03/12 Sexta 18:00 h – 23:00 h

04/12 Sábado 8:30 h – 19:00 h

05/12 Domingo8:30 h – 13:00 h

Total 20 h

EMENTA

A crise do software e a necessidade de se melhorar a forma de desenvolver software; Modelos e

melhores práticas; CMMI – estrutura e níveis de maturidade; Conjunto de boas práticas por nível de

maturidade; Métodos ágil (SCRUM) x CMMI; Método para avaliação de maturidade nas organizações

(SCAMPI)

AVALIAÇÃO

� Exercícios aplicados ao longo das aulas


PPROGRAMAROGRAMA

� Entender a necessidade de se investir em melhoria do processo de

desenvolvimento de software

� Apresentar o conceito de Modelos e Melhores práticas

� Entender a estrutura do modelo CMMI e seus níveis de maturidade

� Entender cada uma das áreas de processo (PAs) do modelo e sua aplicação nas

organizações

� Apresentar a aplicabilidade de CMMI alinhado ao uso do método ágil SCRUM

� Apresentar quais são as etapas do método de avaliação SCAMPI

� Apresentar as etapas de um projeto de melhoria de processos: da definição dos

processos a avaliação de maturidade da organização


PPROGRAMAROGRAMA

� Dia 1 – Introdução e Conceitos

� Crise do Software

� Modelos e Melhores práticas

� Estrutura do modelo CMMI e níveis de maturidade

� Nível 1 de maturidade

� Dia 2 - Áreas de processo do modelo CMMI


� Nível 3 de maturidade: Engenharia


PPROGRAMAROGRAMA

� Dia 3 – Áreas de processo do modelo CMMI. Método de avaliação. Projeto de

melhoria de processo


� Altos níveis de maturidade: nível 4 e 5

� CMMI alinhado ao SCRUM

� O método de avaliação SCAMPI

� Projeto de melhoria de processos: da definição a obtenção da maturidade


OOBJETIVOBJETIVO PPRINCIPALRINCIPAL

. Entender o modelo CMMI e cada um de seus níveis de maturidade, bem como o

método SCAMPI, aplicado para avaliar a maturidade de uma organização.

Entender quais são as etapas de um projeto de melhoria de processos com base

no modelo CMMI para levar uma organização a um nível de maturidade.


A A EEVOLUÇÃOVOLUÇÃO DODO SSOFTWAREOFTWARE


SSOFTWAREOFTWARE -- AAPLICAÇÕESPLICAÇÕES


CCRISERISE DODO SSOFTWAREOFTWARE

• Refere-se a um conjunto de problemas encontrados nodesenvolvimento de software:

- Não entregávamos no Prazo; e/ou

- Não atendíamos ao Esforço planejado; e/ou

- Nem sempre atendíamos aos Requisitos do cliente

- Quais são HOJE os seus problemas no desenvolvimento e manutenção das soluções desenvolvidas?

10



(1) As estimativas de prazo e de custo freqüentemente são imprecisas

• “Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software”

• “Com poucos dados históricos como guia as estimativas tem sido a olho, com resultados previsivelmente ruins”

(2) A produtividade das pessoas da área de software não tem acompanhado a demanda por seus serviços

• “Os projetos de desenvolvimento de software normalmente são efetuados apenas com um vago indício das exigências do cliente”

(3) A qualidade de software às vezes é menos que adequada

• Só recentemente começam a surgir conceitos quantitativos sólidos de garantia de qualidade de software

(4) O software existente é muito difícil de manter

• A tarefa de manutenção devora o orçamento destinado ao software

• A facilidade de manutenção não foi enfatizada como um critério importante

11 Prof. Josiane Bernardes CMMI



PPROBLEMASROBLEMAS RRELACIONADOSELACIONADOS AOAO NNÃOÃO GGERENCIAMENTOERENCIAMENTO DEDE RREQUISITOSEQUISITOS

• Uma minoria de projetos de software é concluída no prazo e Orçamentos

– Taxa de Sucesso: 16,2%

– Projetos com conclusão tardia ou estouro de orçamento: 52,7%

– Projetos cancelados: 31,7%

• Causas principais:

– Definição incorreta dos requisitos no início do projeto

– Mau gerenciamento dos requisitos através do ciclo de vida (ou total ausência de gerenciamento)

• Fonte: www.standishgroup.com


CCAUSASAUSAS

• Os requisitos mudam

• As estimativas (esforço e prazo) são no “feeling”

• A qualidade é duvidosa. Software é construído de maneira precária,

• tornando as manutenções difícieis

• Testes são despriorizados

• Defeitos são identificados tardiamente

• Iniciamos o desenvolvimento mesmo que os requisitos não estejam muito claros

• um processo“irresponsável” de construir-entregar

• ...

14


““““A qualidade de um sistema é governada pela qualidad edo processo utilizado para desenvolvê-lo e mantê-lo “

Watts Humphrey

PPORQUEORQUE OO FFOCOOCO EMEM PPROCESSOSROCESSOS ??


Procedimentos e metodos

Ferramentas eequipamentos

Pessoascom conhecimento,

treinamento emotivação

PROCESSO

AB

CD

• Procedimento BOM: Pessoas mecanizadas. Mais trabalho (lentidão), menos informação

• Ferramenta BOM: Caos mais rápido. Baixa Qualidade.

• Pessoas BOM: Heroísmo!

DDEFINIÇÃOEFINIÇÃO DEDE PPROCESSOROCESSO

16


ImprevisibilidadeImprevisibilidade

SistemaSistemasemsem

HistHistóóricorico

ProcessoProcessoMaduroMaduro

EsforEsforççooHerHeróóicoico

PROCESSOPROCESSO

PPRROODDUUTTOO

RuimRuim

RRuuiimm

BBoomm

BomBom

ImprevisibilidadeImprevisibilidade

SistemaSistemasemsem

HistHistóóricorico

ProcessoProcessoMaduroMaduro

EsforEsforççooHerHeróóicoico

PROCESSOPROCESSO

PPRROODDUUTTOO

RuimRuim

RRuuiimm

BBoomm

BomBom

PPROCESSOROCESSO X X PPRODUTORODUTO


� Definido e documentado• compreendido• usado• “vivo”

� Visivelmente apoiado pela gerência e por todos

� Bem controlado. A fidelidade ao processo é auditadae enfatizada

� Consistente com a maneira pela qual o trabalho érealmente feito

� Medido

� Apoiado por tecnologia quando necessário

� Definido e documentado• compreendido• usado• “vivo”

� Visivelmente apoiado pela gerência e por todos

� Bem controlado. A fidelidade ao processo é auditadae enfatizada

� Consistente com a maneira pela qual o trabalho érealmente feito

� Medido

� Apoiado por tecnologia quando necessário

PPROCESSOROCESSO MMADUROADURO

18


PPORQUEORQUE MELHORIAMELHORIA BASEADABASEADA NOSNOS MODELOSMODELOS ??

• Para ajudar a definir os objetivos e prioridades da melhoria de processos,

• Para melhorar os processos com base nas melhores práticas mundiais,

• Para fornecer um guia visando assegurar processos maduros, capazes e estáveis.

– Um ponto de partida

– Compartilha os benefícios das experiências anteriores de uma determinada comunidade


RRISCOSISCOS DADA MELHORIAMELHORIA BASEADABASEADA EMEM MODELOSMODELOS

• Modelos são simplificações do mundo real.

• Modelos não são suficientemente abrangentes.

• Interpretações e adaptações a situações particulares devem estar ajustadas aos objetivos do negócio.

• É necessário bom senso para se utilizar modelos corretamente e com visão.

20


O MO MODELOODELO CMMICMMI

• O propósito do CMMI é prover um guia para melhoria dos processos de sua organização, visando melhorar continuamente as habilidades de gerenciamento do desenvolvimento, aquisição e manutenção de produtos e serviços de TI.


2

3

4

1

5

Níveis de Maturidade

Um conjunto de áreas de processo estãoorganizadas em níveis de maturidade

organizacional

2

3

4

1

5

0

Níveis de Capacidade

Cada área de processoencontra-se em um nível

de capacidade

Em otimização

Quantit. gerenciado

Definido

Gerenciado

Realizado

Incompleto

Em otimização

Quantit. gerenciado

Definido

Gerenciado

Inicial

Por Estágio Contínua

RREPRESENTAÇÕESEPRESENTAÇÕES DODO CMMICMMI

22


CMMI Níveis de Maturidade

QuantitativamenteGerenciado

Inicial

Gerenciado

Otimização

Definido

1

2

3

4

5

Processos são caracterizadospor ProjetoProjeto e as ações sãofreqüentemente reativas

Processos são Imprevisíveis, poucoControlado e reativo

Processos são caracterizadospara OrganizaçãoOrganização e são proativos

Processos são medidose controlados

Foco Contínuo na Melhoria dos Processos

RREPRESENTAÇÃOEPRESENTAÇÃO PORPOR EESTÁGIOSTÁGIO


Nível de Maturidade

Áreas de Processo 1 Áreas de Processo 2 Áreas de Processo n

Nível de Maturidade

Áreas de Processo 1 Áreas de Processo 2 Áreas de Processo n

Metas Específicas

Metas Genéricas

Metas Específicas

Metas Genéricas

Práticas Específicas Práticas Genéricas

EESTRUTURASTRUTURA

24


• Atividade de Fixação: Grupo


1 OutIn OutIn

Visão gerencial

In OutIn Out2

In OutIn Out3

4 In OutIn Out

5 In OutIn OutMelhoria de processos estáinstitucionalizada

Pro

babi

lity

Time/$/...

Targ

et N1

Pro

babi

lity

Time/$/...

Targ

et N1

2

Pro

babi

lity

Time/$/...

Targ

et N

+a

2

Pro

babi

lity

Time/$/...

Targ

et N

+a

3

Pro

babi

lity

Time/$/...

Tar

get N

-x

3

Pro

babi

lity

Time/$/...

Tar

get N

-x

4

Pro

babi

lity

Time/$/...

Tar

get N

-y

4

Pro

babi

lity

Time/$/...

Tar

get N

-y

5

Pro

babi

lity

Time/$/...

Tar

get N

-z

5

Pro

babi

lity

Time/$/...

Tar

get N

-z

O processo éinformal e imprevisível

Produto e processo são quantitativamente controlados

Processos de engenharia de software e gerenciamento definidos e integrados

Sistema de gerenciamento de projeto em funcionamento

Nível Características Desempenho

previsto

Inicial

Gerenciado

Definido

QuantitativamenteGerenciado

Otimizando

OOSS NNÍVEISÍVEIS DEDE MMATURIDADEATURIDADE

26





28


Nível 1 de Maturidade


NNÍVELÍVEL 1 1 DEDE MMATURIDADEATURIDADE

• Processos são executados, mas geralmente de forma improvisada.

• O desempenho dos processos (e projetos) é dependente “somente” da competência e heroísmo dos profissionais.

• Desempenho e qualidade excepcionais são possíveis desde que as melhores pessoas (heróis) estejam presentes.

• Desempenho é imprevisível.

30



• Desempenho é imprevisível

• Requisitos fluem para dentro do projeto.

• Um produto (ou solução) é produzido (as vezes) por um processo precário.

• O produto ou solução flui para fora e (nem sempre) funciona.

In Out



32


• Nível 2: vídeo YouTube - ISD



• A Gestão de Projetos é mais disciplinada;

• Políticas, procedimentos e planos são estabelecidos e seguidos;

• Os recursos são adequados e as responsabilidades são estabelecidas;

• Sucesso de projetos anteriores são repetidos em projetos similares;

• A disciplina imposta garante a existência das boas práticas em tempo de crise;

• Visibilidade de gestão aumenta consideravelmente.

34



• O processo é Gerenciado

• Os requisitos fluem para dentro do projeto;

• Planos são desenvolvidos de acordo com as políticas em vigor;

• As atividades são executadas de acordo com os planos;

• Medições e revisões ocorrem em etapas definidas;

• O produto ou solução flui para fora e (geralmente) funciona.

In OutIn Out



REQM – Requirement Management

Gerenciamento de Requisitos

36


Requisitos

Obter entendimento

dos Requisitos

Obter Compromissos

para os Requisitos

Matriz de Rastreabilidade ou Sistema para Controlar Requisitos

Manter Rastreabilidade

Bidirecional dos Requisitos

Identificar Inconsistências entre Produtos

de Trabalho do Projetos

e os Requisitos

Gerenciar Requisitos

Gerenciar Mudan ças em

Requisitos

PMCPP CM

NNÍVELÍVEL 2 2 –– REQMREQM



– Obter um entendimento dos requisitos:

– Incluir a definição de "requirements providers“. Definir quem são os responsáveis por parte do cliente por prover (definir, alterar, aprovar, decidir) requisitos ao projeto

– Descrever o conteúdo (por meio de exemplos) esperado e a intenção das definições dos critérios de aceitação:

• Em relação ao que se recebe do cliente (dados suficientes para estimar e construir)

• Em relação a como o cliente vai aceitar o produto entregue pela organização (critérios de aceite do que foi construído)

– Requisitos funcionais e não funcionais

38



– Gerenciar as mudanças nos requisitos:

– Manter registro das mudanças em requisitos;

– Realizar análise de impacto, considerando: esforço, tamanho, prazo, impactos em requisitos relacionados, itens de configuração;

– Obter as aprovações necessárias para a mudança;



– Manter a rastreabilidade dos requisitos:

– Rastreabilidade de requisitos significa mapear seus relacionamentos:

• Horizontais: Dependências e relacionamentos entre requisitos

• Verticais: Dependências e relacionamentos hierárquicos, do nível mais alto (visão macro) até o nível mais baixo (visão detalhada)

– Definir o nível de detalhamento para a rastreabilidade, de acordo com as necessidades da organização. Fatores de decisão: nível de dependência entre os requisitos e nível necessário/desejável de controle dos requisitos e seus desdobramentos

40



– Identificar inconsistências entre os artefatos e os requisitos:

– Deve-se avaliar periodicamente (ou nos eventos de mudança) se há inconsistências entre os requisitos do projeto e os artefatos produzidos;

– Definir quais são os pontos de verificação e como serão tratadas as inconsistências;

– Os pontos de verificação devem considerar:

• Mudanças: a implementação de mudanças causou algum efeito indesejado nos artefatos do projeto (planos, estimativas, cronograma)?

• Evolução de requisitos ao longo do ciclo de vida: ao final de cada fase recomenda-se realizar verificações quanto à consistência entre os requisitos e os artefatos de engenharia definidos



Recomendações

– Defina um processo robusto para entendimento e comprometimento dos requisitos, mas que seja também ágil, envolvendo as pessoas certas nos momentos certos: o processo tem que agregar valor para o negócio (não ser burocrático) e promover o verdadeiro comprometimento (conscientização, e não somente a obrigação)

– A sistemática para manter a rastreabilidade entre produtos do projeto, incluindo os requisitos, deve ser intrínseca às atividades realizadas (ou seja: não deve ser algo estanque e custoso)

– A rastreabilidade deve ter como principal propósito ser o instrumento para a realização de análises de inconsistência e impactos de mudanças

– Construa o produto sob um forte alicerce – requisitos entendidos, acordados e gerenciados

42



PP – Project Planning

Planejamento de Projeto


Dados do Planejamento

Estabelecer Estimativas

Desenvolver um plano para o

Projeto

Obter os compromissos

para o plano

Plano do Projeto

PMC

StakeholdersRelevantes

NNÍVELÍVEL 2 2 –– PPPP

44


Determinar Estimativas

de Esforçoe Custo

Dados dePlanejamento


Estimaro escopodo Projeto

EstabelecerEstimativas

dos Produtos de Trabalho e Atributos das

Tarefas

Definir Ciclo de Vida

do Projeto




• Identificação do Ciclo de Vida

• Cada projeto pode definir em tempo de planejamento seu próprio ciclo de vida, ou obviamente “apontar” para algum ciclo já definido na organização.

• O objetivo do ciclo de vida é prover ao projetos períodos(estágios/fases) e atividades que resultam em sub-produtos do projeto de software.

46



• O Escopo do Projeto

• WBS – Work Breakdown Structure

• Cada elemento recebe um identificador único;

• Os elementos de último nível são conhecidos como pacotes de trabalho;

• O WBS reduz os riscos associados a falta de uma etapa ou atividade crítica para o projeto;

• Ele exibe visualmente as atividades que devem ser realizadas e suas dependências, tornando portanto, sua compreensão muito mais fácil do que uma simples lista de atividades



• Realizar as Estimativas

• Estimativas de Tamanho:

• De uma maneira geral, use:

– Técnicas de mercado APF, UCP

– Estimativa por complexidade

– Estimativas análogas de projetos similares

– “É IMPORTANTE QUE AS INFORMAÇÕES SOBRE ESTIMATIVAS E MEDIÇÕES SEJAM GUARDADAS VISANDO O INÍCIO DA CONSTRUÇÃO DO “REPOSITÓRIO DE MEDIÇÕES” EXIGIDO NOS NÍVEIS POSTERIORES”

• “NENHUMA TÉCNICA DE ESTIMATIVA TEM VALOR SE NÃO HOUVER REALIMENTAÇÃO”

48


Phase1

Activity DActivity CActivity B

Task E Task F

1. Develop WBS 2. Develop Estimates for Tasks in WBS

3. Build Project Schedule

WBS Activities

Phase 1

Activity B

Activity C

Activity D

Task E

Task F

Effort

200h

80h

40h

80h

40h

40h

ID

1.0

1.1

1.2

1.3

1.3.1

1.3.2

2.0

3.0

WBS Activities

Phase 1

Activity B

Activity C

Activity D

Task E

Task F

Effort

200h

80h

40h

80h

40h

40h

ID

1.0

1.1

1.2

1.3

1.3.1

1.3.2

2.0

3.0

ID Task Name Work Duration Start Finish1 Phase 1 200 hrs 10 days 06/24/02 07/12/02

1.1 Activity B 80 hrs 80 hrs 06/24/02 07/05/021.2 Activity C 40 hrs 40 hrs 07/08/02 07/12/021.3 Activity D 80 hrs 5 days 06/24/02 07/05/02

1.3.1 Task E 40 hrs 40 hrs 06/24/02 06/28/021.3.2 Task F 40 hrs 40 hrs 07/01/02 07/05/02

Phase End 07/12/02

06/23/02 06/30/02 7/7/2002






Projeto


para o plano

Plano do Projeto

PMC



50


Dados de Planejamento

Desenvolver um Plano de Projeto

Planos do Projeto

PlanejarGestão de

Dados

Planejar Recursos do

Projeto

EstabelecerPlano do Projeto

Identificaros

Riscos do Projeto

PlanejarHabilidades e

Conhecimentos Necessários

Planejar Envolvimento Stakeholder

Estabelecero Orçamento

e Cronograma




• O Plano de Projeto

– Um documento formal, aprovado pelos indivíduos e grupos envolvidos, usado para guiar a execução e o controle do projeto.

– O plano pode ser representado por um documento ou um conjunto de documentos que sabemos que mudará ao longo do projeto, ao ponto que mais informações vão sendo disponibilizadas

52





Projeto


para o plano

Plano do Projeto

PMC




Obter Compromissopara o Planejado

ReconciliarTrabalho eRecursos

Planos do Projeto

RevisarPlanos que Afetem o Projeto

ObterCompromisso

para oPlanejado



54



• Compromissos

• Um compromisso deve levar em consideração o trabalho envolvido, os recursos e o prazo;

• Existe um acordo entre as partes sobre o que deve ser feito, quando e por quem;

• O compromisso é documentado e comunicado;

• As pessoas envolvidas tentam cumprir o prometido;

• Se inviável, o compromisso é cancelado com antecedência e outro é estabelecido



PMC – Project Monitoring and Control

Acompanhamento de Projeto

56


Plano do Projeto

Monitorar o Gerenciamento

dos Dados

Monitorar o Gerenciamento

dos Dados Monitorar os

Compromissos Monitorar os

Compromissos

Monitorar os Parâmetros de Planejamento

do Projeto

Monitorar os Parâmetros de Planejamento

do Projeto

Conduzir Revisão dos Milestones

Conduzir Revisão dos Milestones

Monitorar os riscos do

Projeto

Monitorar os riscos do

Projeto

Analisar ISSUES

Analisar ISSUES

Tomar Ações

Corretivas

Tomar Ações

Corretivas

Monitorar o Projeto contra o Plano

Conduzir Revisão de Progresso

Conduzir Revisão de Progresso

Monitorar o Envolvimento Stakeholders

Monitorar o Envolvimento Stakeholders Gerenciar

as Ações Corretivas

Gerenciar as Ações Corretivas

PP

Gerenciar ações corretivas até o seu fechamento

NNÍVELÍVEL 2 2 –– PMCPMC


NNÍVELÍVEL 2 2 –– PMCPMC

• Monitorar o Projeto contra o Plano

– Monitorar os riscos identificados no Planejamento;

– Monitorar o envolvimento dos Stakeholders;

– Conduzir revisões de progresso;

– Conduzir revisões de Milestones

58



SAM – Supplier Agreement Management

Gerenciamento de Fornecedores


Produtos

Estabelecer acordos com os

Fornecedores

Revisar Produtos

e Processos do Fornecedor

Determinar o tipo de

aquisição

Entregar / Transição dos

Produtos Aceitar os Produtos

Adquiridos

Selecionar os Fornecedores

Requisitos do Fornecedor

Executaros acordos com

fornecedores

Estabelecer acordos com os Fornecedores

Satisfazer Acordos com fornecedores

Acordos com Fornecedores

PI

Produtos Produtos

Estabelecer acordos com os

Fornecedores

Revisar Produtos

e Processos do Fornecedor

Determinar o tipo de

aquisição


Produtos


Produtos Aceitar os Produtos

Adquiridos

Aceitar os Produtos

Adquiridos

Selecionar os Fornecedores

Requisitos do Fornecedor


fornecedores


fornecedores

Estabelecer acordos com os Fornecedores

Satisfazer Acordos com fornecedores

Acordos com Fornecedores

PI

NNÍVELÍVEL 2 2 –– SAMSAM

60



MA – Measurement and Analysis

Medição e Análise


NNÍVELÍVEL 2 2 –– MAMA

• Desenvolver e manter uma capacidade de medição que é usada para suportar as necessidades de informação dos “gestores” e demais “stakeholders”

• Atividades incluem

– Definição das medições a serem utilizadas, alinhadas aos objetivos de negócios

– Implementação da coleta, armazenamento, análise e comunicação

• Forte e complexo requisito do CMMI para empresas que iniciam as práticas de nível 2. Entretanto, esta Área de Processo é de grande potencial de “alavancagem de melhoria com base em fatos”

62


Profissionais de

Medição

Especificar as Medições

Repositório de Medições

ColetarDados das Medições

Resultados das Medições

Estabelecer objetivos

de Medição

Comunicar os Resultados

Especificar procedimentos

de análise

Objetivos das Medições

Armazenar os Dados e

Resultados

Analisaros dados

das medições

Especif.coleta de

dados e Proced. de Armazenam.

Procedimentos, Ferramentas

Alinhar medições e Atividades de Análise

Prover Resultados das Medições

NNÍVELÍVEL 2 2 –– MAMA


EEXEMPLOXEMPLO -- AARQUITETURARQUITETURA DODO SSISTEMAISTEMA DEDE MMEDIÇÕESEDIÇÕES

Planilha MensalConsolidada(projetos)

Planilha MensalConsolidada(organização)

Planilha Medição Projeto

Planilha MensalIndicadoresEstratégicos

Cronograma

Time-Sheet

Resultadosde Inspeção

Resultadosde Testes

Checklistsde QA

Time-Sheet

Log de Melhorias

Relatóriosde Auditorias

ExemploBase de Medições

Quem acessa o que?Quem armazena?Onde estão as especificações?Qual o contexto das informações?

64



CM – Configuration Management

Gerenciamento de Configuração


NNÍVELÍVEL 2 2 –– CMCM

• Estabelecer e manter a integridade dos produtos de trabalho usando identificação, controle, status e auditorias em itens e “baselines” de configuração.

• O uso de ferramenta ajuda de forma considerável, especialmente nesta disciplina

66


Database Solicitações de Mudança

Sistema de Gerenciamento de Configuração

Identificar Itens de

Configuração

EstabelecerRegistros de

Gerenciamento Configuração

Estabelecer um sistema de Gerenciamento

de Configuração

Executar auditorias de Configuração

Executar auditorias de Configuração

Solicitações de Mudança

Itens de Ação

Resultado dasAuditorias

Criar ou Liberar Baselines

Relatórios

Estabelecer Baselines

Estabelecer Integridade

ControlarItens de

Configuração

AcompanharSolicitações de

Mudanças

Acompanhar e Controlar Mudanças

NNÍVELÍVEL 2 2 –– CMCM



PPQA – Process and Product Quality Assurance

Garantia da Qualidade de Processo e de Produto

68


NNÍVELÍVEL 2 2 –– PPQAPPQA

• A finalidade é fornecer à gerência visibilidade apropriada dos processos que estão sendo utilizados e dos produtos que estãosendo construídos.

• Envolve:

– revisões e auditorias nos produtos de software e atividades para se assegurar que estão aderentes aos padrões e procedimentosaplicáveis

– fornecer ao gestor do projeto e outros gestores envolvidos osresultados das revisões e auditorias


Relatórios e Registros

Avaliar objetivamente Processos e Produtos de Traba lho

Prover Visão Objetiva

Avaliar

objetivamente os processos

Estabelecer os Registros

Comunicar e assegurar a

resolução das Não

Conformidades

Avaliar objetivamente

Produtos de Trabalho e Serviços


Relatórios e Registros

Avaliar objetivamente Processos e Produtos de Traba lho

Prover Visão Objetiva

Avaliar

objetivamente os processos

Estabelecer os Registros

Comunicar e assegurar a

resolução das Não

Conformidades

Avaliar objetivamente

Produtos de Trabalho e Serviços


NNÍVELÍVEL 2 2 –– PPQAPPQA

70


• Atividade de Fixação (exercício da forca): Grupo


• Vídeo YouTube: nível 3

72





• Este nível expande os “fundamentos” de gestão de projetos, criados no nível 2.

– Os processos de “engenharia” são efetivamente implementados.

– A organização se torna mais pró-ativa e usa “bases de conhecimentos” para seu aprendizado

– Necessidades organizacionais de treinamento são identificadas e executadas.

– A organização possui um “conjunto de processos padronizados” (arquitetura ou sistema de processos) que é utilizado e adaptado pelos projetos.

74


NNÍVELÍVEL 3 3 –– O O PPROCESSOROCESSO ÉÉ DDEFINIDOEFINIDO

• Os “pontos comuns” aos projetos permitem uma maneira mais uniforme de estimar seus desempenhos.

In OutIn Out


REQMREQM

RD

Requisitos

Requisitos do Produto eComponentes do Produto

RD

Requisitos


RDRD

Requisitos


ValVer

Comp. Produto, produtos de trabalho, relatórios de verificações/validações

ValValVerVer

Comp. Produto, produtos de trabalho, relatórios de verificações/validações

PI

Componentesdo produto

PIPI

Componentesdo produto

TS

Soluçõesalternativas

Requisit.

TSTS

Soluçõesalternativas

Requisit.

Necessidades do Cliente

ClienteProduto

Necessidades do Cliente

ClienteProduto

ClienteClienteProduto

Legenda:

REQM – Gerenciamento de Requisitos

RD – Desenvolvimento de Requisitos

TS – Solução Técnica

PI – Integração de Produtos

Ver – Verificação

Val - Validação

NNÍVELÍVEL 3 3 –– PPROCESSOSROCESSOS DEDE EENGENHARIANGENHARIA

76



RD – Requirements Development

Desenvolvimento de Requisitos


NNÍVELÍVEL 3 3 -- RDRD

• A finalidade é produzir e analisar os requisitos do cliente e do produto

– Desenvolver os requisitos do cliente

– Desenvolver os requisitos do produto

– Analisar e validar os requisitos

78


Analisar e Validar os Requisitos

Desenvolver os Requisitos do

Cliente

Requisitos do ClienteRequisitos do Cliente

RequisitosValidadosRequisitosValidados

Requisitos do Produto, Componentes do

Produto e Interfaces




Produto

Necessidades dos Stakeholders



Desenvolver osRequisitos do

Cliente

Requisitos do Cliente

Requisitos do Cliente

Desenvolver os Requisitos do Cliente

ExtrairNecessidades


REQM

Rastreabilidade


80




Cliente








Produto




Estabelecer os Requisitos do Produto e

seus Componentes



Desenvolver os Requisitos do Produto

Alocar os Requisitos aos Componentes

do Produto

Identificar Requisitos de

Interface

Requisitos do Cliente TS

Soluções Alternativasselecionadas

Rastreabilidade

REQM


82




Cliente








Produto




EstabelecerConceitos e

Cenários Operacionais

Estabelecer uma definição

das Funcionalidades

requeridas

AnalisarRequisitos

para obter umBalanceamento

Analisar os Requisitos







Validar os Requisitos

com um MétodoAbrangente

Validação


84



TS – Technical Solution

Solução Técnica


NNÍVELÍVEL 3 3 -- TSTS

• Projetar, desenvolver e implementar soluções para os requisitos.

• Soluções, arquitetura, protótipos, desenhos (design) e implementações envolvem produtos, componentes de produtos, e produtos relacionados aos processos do ciclo de vida.

• Ênfase em desenvolver soluções alternativas e então selecionar a melhor partir delas (Análise e Tomada de Decisão - DAR)

• Práticas de verificação e também validação são utilizadas para checar o progresso do “Design”

• Análise: desenvolver, comprar ou reusar (DAR)

• Aqui construímos a solução (desenvolvemos o código).

86


Alternativas de Projetoe Critérios de Avaliação

ProdutoDesenvolvido

Selecionar Soluções para os Componentes do

Produto

Desenvolver o Projeto

do Produto

Implementar o Produto Projetado

Projeto Detalhadoe Documentação

RD




• Selecionar as soluções técnicas para o produto

– Análise interna sobre a arquitetura a ser implementada

– Análise Make or Buy

– Verificar as condições de reuso dos componentes

– Análise das bibliotecas a serem utilizadas

88



ProdutoDesenvolvido


Produto


do Produto



RD




• Desenvolver o Projeto do Produto

– Representação da Arquitetura técnica

– Design Patterns

» Sun J2EE, CORBA, etc

– Views

• Use Case

• Módulos

• Run-time

• Implementation

• Deployment

• Data

90



ProdutoDesenvolvido


Produto


do Produto



RD




• Implementar o Produto Projetado

– Métodos de implementação: OOP, Programação Estruturada,etc

– Padrões de código: nomes, variáveis

– Documentação de suporte

92



PI – Product Integration

Integração do Produto


NNÍVELÍVEL 3 3 -- PIPI

• Montar (testar) o produto a partir dos componentes de produto, assegurando que o produto, uma vez integrado, funciona apropriadamente; e entregar o produto.

• Pode ser feita de uma vez ou de forma incremental.

• Aqui se faz o “empacotamento e entrega” dos produtos

94


Preparar Integração do

Produto

Garantir Compatibilidade

entre as Interfaces

Montagens

Sub-Montagens

Montar componentes do produto e

entregá-lo

TS

DAR

NNÍVELÍVEL 3 3 -- PIPI



VER – Verification

Verificação

96


NNÍVELÍVEL 3 3 -- VERVER

• Assegurar que produtos de trabalho selecionados atendem seus requisitos especificados

– Assegura que o produto foi construído corretamente em relação aos requisitos especificados.

– Trata os recursos e ambientes específicos que são requeridos para o processo de verificação a ser desenvolvido

– Incorpora idéias de “Revisão entre Pares”

» “FAÇA CERTO AS COISAS”


Preparar para a Verificação Ações

CorretivasAções

Corretivas

Verificar Produtos de Trabalho SelecionadosVerificar Produtos de Trabalho Selecionados

Realizar Revisões entre Pares

NNÍVELÍVEL 3 3 -- VERVER

98



VAL – Validation

Validação


NNÍVELÍVEL 3 3 -- VALVAL

• Demonstrar que o produto ou componente de produto atende ao seu uso pretendido quando colocado no ambiente pretendido.

• Assegura que o produto certo foi construído em relação aos requisitos do cliente

• Inclui a seleção do ambiente operacional e a execução da validação.

• Enquanto VER está focada na checagem contra os requisitos do componente em si, VAL está focada na checagem contra os requisitos do cliente.

“FAÇA AS COISAS CERTAS”

100


- Conformidade- Deficiência

Preparar para Validação

Validar Produtos ou Componentes

do Produto

RD

NNÍVELÍVEL 3 3 -- VALVAL



IPM – Integrated Project Management

Gerenciamento Integrado de Projeto

102


NNÍVELÍVEL 3 3 -- IPMIPM

• Estabelecer e gerenciar o projeto e o envolvimento dos “stakeholders relevantes” de acordo com um processo integrado definido que é customizado (adaptado) a partir do conjunto de processos padrão da organização

• Caracteriza-se por uma gestão mais quantitativa dos projetos


Use o Processo Definido para o Projeto (PDP)

Coordene e Colabore com

os StakeholdersRelevantes

Stakeholders

Requisitos do Produto

Plano de Projeto

baseado no PDP

Contribuições para o ativo de Processos da Organização

OPD


104



• 1) Utilizar dados de projetos anteriores similares

• tamanho dos projetos e produtos

• esforço e custo

• produtividade

• prazo

• defeitos, etc

• 2) Identificar e registrar as similaridades

• produtos de trabalho

• domínio da aplicação

• ambiente operacional

• experiência dos profissionais

• 3) Documentar “racional”, contingências, hipóteses utilizadas naestimativa


�


• Estabelecimento de “gatilhos gerenciais” (threshold) nos principaisatributos do projeto.

• Gerenciamento mais efetivo das dependências críticas e caminhoscríticos do projeto

106


Tamanho(PF)

Esforço(HS)

produtividade esperada2,5 horas/PF

produtividade real3/PF

1000

400

P1

P1

gatilho =exceder 10%

1200

EstimadoRealizado




RSKM– Risk Management

Gerenciamento de Riscos

108


NNÍVELÍVEL 3 3 -- RSKMRSKM

• Identificar problemas potenciais antes que eles ocorram, a fim de que as atividades de tratamento de riscos possam ser planejadas e disparadas quando necessário por todo o ciclo de vida do produto ou projeto para mitigar impactos indesejáveis ao atendimento dos objetivos.

• Atividades incluem:

– Preparação para gestão de riscos

– Identificação do risco

– Análise e alternativas para os riscos

– Mitigação dos riscos

– Planejamento da contingência dos riscos


Determine as Fontes

e Categorias dos Riscos

Defina os Parâmetros

dos Riscos Identifique os Riscos

Avalie, Categorize e priorize os

Riscos Desenvolva Planos

para Mitigar os Riscos

Implemente os Planos

de Mitigação dos Riscos

Repositório de Riscos

Preparar para a Gestão de Riscos Identificar e Anali sar Riscos

Mitigar Riscos

Estabeleça uma Estratégia para Gerenciar

os Riscos

PP


110



– Determine as fontes e categorias dos Riscos

– Permite uma visão mais sistemática que facilita a identificação dos riscos;

– Explora o benefício de aprendizado com projetos passados – dados históricos;

– Tipos de Riscos:

• Técnicos, gestão, organizacionais, externos



– Defina os parâmetros dos Riscos

– Definição dos parâmetros utilizados para analisar e categorizar os riscos, bem como, os parâmetros para controlar o esforço de gerenciamento dos riscos

– Probabilidade do risco

– Impacto e severidade

112



• Durante a Fase de Identificação:

• Sessão de Brainstorm

– Listar categorias e procurar riscos específicos em uma determinada categoria;

– Ideal se realizada entre o gerente a equipe do projeto

• Utilização de questionários

– Taxonomia de Riscos



• Monitoramento dos Riscos

• São os processos para acompanhamento dos riscos identificados, monitoramento dos ricos e identificação de novos riscos, garantindo a execução dos planos e avaliando sua efetividade na redução dos riscos.

114



DAR– Decision Analysis and Resolution

Análise e Tomada de Decisão

NNÍVELÍVEL 3 3 -- DARDAR


Estabelecer Diretrizes

para Analisar Decisões

Diretrizes

Avaliar Alternativas

Selecionar Método de Avaliação

Métodos Critérios

Estabelecer Critérios de Avaliação

Selecionar Soluções

Identificar Soluções

Alternativas

Alternativas Propostas

Avaliar Alternativas

OutrasPAs


116



• Analisar possíveis decisões usando um processo de avaliação formal que avalie as alternativas identificadas em relação aos critérios estabelecidos.

Critérios de resultados/Benefícios da empresa10 9 8 8 7 6 6

Título do Projetoestratégia

da empresa, posição competitiva

Relação com os processos centrais

da empresa

Relação com necessidades dosclientes externos

Sequência ou dependência

Adiciona valor (curto e longo

prazo)

Urgência (diferente de importância)

ser deixado de lado

ou está piorando?)

TOTAL

Projeto 1 1 9 9 262Projeto 2 9 3 9 9 9 786Projeto 3 3 3 9 525Projeto 4 9 1 206Projeto 5 9 9 3 366Projeto 6 3 1 3 3 233Projeto 7 1 61Projeto 8 3 1 126Projeto 9 1 3 3 1 187Projeto 10 1 9 1 98


NNÍVELÍVEL 3: OPD 3: OPD –– DDEFINIÇÃOEFINIÇÃO DODO PROCESSOPROCESSO ORGANIZACIONALORGANIZACIONAL

118

Estabelecer repositório de medições da organização

Estabelecer a biblioteca de

ativos de processos

organizacionais

Usuários dos processos

Estabelecer guias e critérios

de adaptação

Estabelecer descrições de

modelos de ciclo de vida

Estabelecer processos padrão

Estabelecer ativos de processos

organizacionaisModelos de ciclo de

vida

Processos padrão da organização

Biblioteca organizacional de documentação dos

processos

Repositório de medições da organizacão

Melhorias

OPF

Utilização na prática

Guias de adaptação


NNÍVELÍVEL 3: OPF 3: OPF –– FFOCOOCO NONO PPROCESSOROCESSO OORGANIZACIONALRGANIZACIONAL

Descobertas e resultados

119

Melhorias selecionadas

Iniciativas de melhoria

Pilotos, Equipes de Trabalho

Avaliar processos

organizacionais

Identificar melhorias de processo da organização

Estabelecer necessidades de

processo da organização

Necessidades e objetivos de processos

Determinar oportunidades de melhorias de processo

Estabelecer planos de ação para os

processos

Implementar planos de

ação para os processos

Planos de ação para os processos

Ativos de processo usáveis

Ativos de processos (revisados)

Incorporar experiências

relacionadas ao uso dos

processos

Experiências com os processos

Utilizar ativos dos processos

da organização

Planejar e implementaratividades de melhoria de processos


NNÍVELÍVEL 3: OT 3: OT –– TTREINAMENTOREINAMENTO OORGANIZACIONALRGANIZACIONAL

120

Realizar treinamento

Avaliar efetividade

dos treinamentos

Estabelecer registros de treinamento

SG2 – Prover treinamento necessário

Estabelecer as necessidades estratégicas

de treinamento

Determinar quais necessidades de

treinamento são de responsabilidade da

organização

Repositório de Treinamento

SG1 – Estabelecer capacidade de treinamento organizacion al

Estabelecer capacidade

de treinamento

Estabelecer um plano tático de

treinamento organizacional


• Atividade de Fixação (forca): Grupo


Altos Níveis de Maturidade

122


ORGANIZAÇÃO PROJETOS

PROCESSOS

PRODUTOS

OPP QPM

ORGANIZAÇÃO PROJETOS

PROCESSOS

PRODUTOS

CAROID

NÍVEL 4

NÍVEL 5

Legenda:OPP – Desempenho do Processo OrganizacionalQPM – Gerenciamento Quantitativo de ProjetosCAR – Análise de Causas e ResoluçãoOID – Inovação Organizacional e Implantação

AALTOLTO NNÍVELÍVEL DEDE MMATURIDADEATURIDADE


In OutIn Out

NNÍVELÍVEL 4 4

• O comportamento dos processos é “previsível” e quantitativamentecompreendido.

• Duas Áreas de Processos:

• Organizational Process Performance - OPP

• Quantitative Project Management - QPM

124


In Out

NNÍVELÍVEL 55

• Melhoria “contínua e mensurável”

• Duas Áreas de Processos:

• Causal Analysis and Resolution

• Organizational Innovation and Deployment


CMMI e o SCRUM (aplicabilidade)

126


EESTRUTURASTRUTURA DODO SSCRUMCRUM

Product Owner ScrumMaster Time

PP sp 1.2

PP sp 3.2REQM

PMC

Eng


Resultados

128


.

0 %

140%

-140%

....

.

..

. ... .

.

. .

. . . .

.. . .

. .

.

.. . . .. .. . . . . .... . . .. .

.. .

. ...

..

. .. .. ...... . .. . ... . .. . .. ..

Without Historical Data With Historical DataVariance between + 20% to - 145% Variance between - 20% to + 20%

(Mostly Level 1 & 2) (Level 3)

Ove

r/U

nder

Per

cent

age

.

(Based on 120 projects in Boeing Information System s)

.. . .

.

.. .

...

. .

. ..

.. .

..

.. .. . .. . . . . .. . . . . .. .

... . .. . . . . . .. . . .. . . . .

. . . . .. . . . .. . . . . .. . . . .. . . . . .

. . . . . .. . . . .. . .

. . . . . . . .

. . . . . . . . .

. . . . . .. . . . . .

. . . . . .

Reference: John D. Vu. “Software Process Improveme nt Journey: From Level 1 to Level 5.”7th SEPG Conference, San Jose, March 1997.

Resultados: Estimativa de Esforço

MMELHORIAELHORIA DEDE PPRAZORAZO EE OORÇAMENTORÇAMENTO


43 ,5

5

6

5 ,2

66 ,4

5

8 ,8

3,5

0

1

2

3

4

5

6

7

8

9

O rg. 1 O rg. 2 O rg. 3 O rg. 4 O rg. 5

RO I A nos em Processo de M elhor ia de Softw are

Fonte - Benefits of CMM-Based Software Process Improvement - SEI - 08/94

43 ,5

5

6

5 ,2

66 ,4

5

8 ,8

3,5

0

1

2

3

4

5

6

7

8

9

O rg. 1 O rg. 2 O rg. 3 O rg. 4 O rg. 5

RO I A nos em Processo de M elhor ia de Softw are

Fonte - Benefits of CMM-Based Software Process Improvement - SEI - 08/94

ROI ROI –– RRETURNETURN OONN IINVESTMENTSNVESTMENTS

130


Index

Data

1413121110987654321

10.0

9.5

9.0

8.5

8.0

7.5

7.0

Var iab le

Satisfação

Satisfação P rev ista po r SQ A

Satisfação vs S atisfação Prev ista por SQA

Referência: ISD Brasil Customers Conference 2004

SSATISFAÇÃOATISFAÇÃO DODO CCLIENTELIENTE X X AADERÊNCIADERÊNCIA AOAO PPROCESSOROCESSO


Referência: ISD Brasil Customers Conference 2004

0

5

10

15

20

25

30

35

40

M ar Abr M ai Jun Jul Ago Set Out Nov Dez

0

0,2

0,4

0,6

0,8

1

1,2

1,4

Jun Jul Ago Set Out Nov Dez

Média de não conformidades no ano de 2003 Média de d efeitos por casos de uso em testes sistêmicos no ano de 2003

SSATISFAÇÃOATISFAÇÃO DODO CCLIENTELIENTE X X AADERÊNCIADERÊNCIA AOAO PPROCESSOROCESSO

132


Método de Avaliação SCAMPI


SCAMPI = Standard CMMI Appraisal Method for Process Improvement

• Desenvolvido com o objetivo de fornecer avaliações de benchmarking de alto nível relativas ao CMMI (Capability Maturity Model Integration);

• Utilizado por uma empresa que queira calcular seus próprio processos (assim como o de outras empresas) utilizando o CMMI como modelo de referência;

• O SCAMPI oferece suporte também às avaliações ISO/EIC 15504;

• Similar aos métodos CBA IPI e ao Software Capability Evaluation

134


EESCOPOSCOPO DADA AAVALIAÇÃOVALIAÇÃO

• Definindo a “unidade organizacional”

• Selecionando o modelo CMMI, representação e escopo


TTIPOSIPOS DEDE IINDICADORESNDICADORES DEDE IIMPLEMENTAÇÃOMPLEMENTAÇÃO DADA PPRÁTICARÁTICA

Tipo Evidência Descrição Exemplo

Direto resultado tangível proveniente diretamente da implementação de uma prática

Produtos de trabalho típicos

Indireto Artefatos ou indicativos da realização de uma prática

Produtos de trabalho típicos, minutas de reuniões, revisões, logs e reports

Afirmativo Declarações orais ou escritas confirmando ou aprovando a implementação da prática

Entrevistas, questionários, briefings, demonstrações

136


FFASESASES EE TERMOSTERMOS CHAVECHAVE

Fase 1:Planejamento e preparação paraavaliação

Fase 2:Condução daavaliação

Fase 3:Relato dosresultados da avaliação

•Objetivos de negócios•Objetivos do patrocinador•Recursos•Restrições

•Metas da avaliação•Escopo do modelo•Escopo da organização•Comprometimento do patrocinador

•Seleção do líder de equipe•Plano da avaliação•Identificação dos membros da equipe •Pacote de informações do local•Análise das respostas dos instrumentos•Seleção dos locais, projetos, participantes

•Plano de coleta de dados•Entrevistas•Revisão de documentos•Apresentações

•Observações•Consolidação•Versão preliminar das descobertas•Classificação

•Apoio às atividades seguintes•Eliminação de dados


VVISÃOISÃO GGERALERAL DADA CCONDUÇÃOONDUÇÃO

• Condução de uma avaliação

Mapeamentodos processos

Documentos(Definições,

Organizacionais,Projetos)

Entrevistas,Apresentações,Demonstrações

AVALIAÇÃO Classificações

AvaliadoresPartner

AvaliadoresOrganização

Equipe de Avaliação

APOIO(Organização)

Entrevistados

PIID

138


DDESCOBERTASESCOBERTAS

“Implementation Gap” (*)Pequenos problemas relativos às sub-práticas ou pequenas frações da prática ou

artefatos diretos, etc. Não altera a situação da institucionalização da prática na instância

“Weakness” (*)Problema na implementação da prática (parcial ou toda a prática)

“Strength” (*)Melhor prática: algo feito de forma “extraordinária”

“Compliant/Normative”Prática implementada de acordo com o CMMI

“Improvement Activity” (*)Prática está planejada para ocorrer ou ocorreu poucas vezes na organização

“Alternate Practice” (*)A prática está implementada de forma diferente daquela descrita no CMMI, porém

atendendo seu objetivo

“Not there yet” (*)O projeto ainda não atingiu o ponto no ciclo de vida para executar a prática

* Devemos escrever estas observações por instância sem no entanto “documentar atribuição”

FOCO : INSTÂNCIA


FFERRAMENTAERRAMENTA DEDE AAVALIAÇÃOVALIAÇÃO

Mini-times

� Obter consenso sobre os pontos identificados por sua equipe

� Caracterizar a implementação das práticas no nível de suasinstâncias (ex: Projeto ou organizacional) FI/LI/PI/NI/NY

FOCO : INSTÂNCIA

Uma prática será atendida se for classificada como FI/LI

140


Execução do Plano de Ação

• Cronograma detalhado• Institucionalização: Ações sendo realizadas nos projetos

• Plano de Ação inicial ajustadoDiagnóstico Intermediário(Classe B)

Treinamento no método deavaliação SCAMPI

• Nível de maturidade definido

• Cronograma atualizado• Ações sendo realizadas

Execução do Plano de Ação

• Nível de maturidade previsto

Avaliação Final(avaliação oficial ou Classe A)

Levantamento daSituação Atual

• Classe C (foco na melhoria de processo)e Plano de Ação• Cronograma detalhado

MMELHORIAELHORIA DEDE PROCESSOSPROCESSOS: : DADA DEFINIÇÃODEFINIÇÃO

AA OBTENÇÃOOBTENÇÃO DADA MATURIDADEMATURIDADE


CCARACTERÍSTICASARACTERÍSTICAS DEDE UMUM PPROGRAMAROGRAMA DEDE MMELHORIAELHORIA

SEPG

• Software/System Engineering Process Group (SEPG) ou simplesmente EPG, é composto por profissionais com experiência em gestão de projetos e engenharia de software. Historicamente, seu tamanho é de 1 a 3% do tamanho da organização;

• O número de participantes do grupo depende do escopo organizacional e das necessidades específicas do projeto de melhoria. Alguns exemplos reais para referência:

– Para 15 executores, somente 1 profissional do SEPG full time, sendo o restante (mais 3 pessoas) part time durante a fase de definição;

– Para 150 executores, foi montado um SEPG composto de 5 pessoas full time;

– Para cerca de 70 executores em sites remotos, 5 profissionais de SEPG full time;

– Para 50 executores de projetos (sem desenvolvimento), 1 profissional de SEPG fulltime e 4 profissionais part time;

• Algumas organizações usam o conceito de SEPG part time (profissionais não exclusivos), para garantir o envolvimento dos profissionais que atuam nos projetos (delivery)

• Poucas pessoas sabem escrever de forma clara e objetiva, sendo esta uma das dificuldades da fase de definição dos processos

142



Grupo de Qualidade• Normalmente liderado por um coordenador ou profissional sênior

que tenha conhecimento sólido em gestão de projetos e processos. Muitas vezes este profissional é formado ao longo do programa de melhoria, participando do SEPG;

• O grupo pode contar com mais integrantes, de acordo com o escopo organizacional e quantidade de projetos. Estes profissionais são gerentes de projeto ou analistas. Recomendam-se para esta função os profissionais com perfil detalhista e negociador;

• O grupo costuma variar de 1 a 5 integrantes e podem ou não ser alocados full time;

• As avaliações do PPQA nos projetos costuma ser realizada através de checklists com perguntas objetivas (sim/não) sobre os processos e produtos da organização. O resultado da análise objetiva é quantificado e transformado em métrica e relatórios de acompanhamento.



• Grupo de Qualidade

• As medições obtidas durante as atividades são utilizadas para avaliar o andamento do programa de melhoria ou mesmo a eficiência do trabalho do SEPG na criação, treinamento e institucionalização dos processos da organização;

• As medições mais comuns são:

o Número de não-conformidades (por projeto, por processo, por produto);

o Esforço gasto em atividades de PPQA.;

o Percentual de aderência ao processo/produto organizacional;

o Ocorrências de não-conformidade mais comuns;

• Uma das funções mais nobres do grupo de PPQA é auxiliar o SEPG na institucionalização dos processos, através das avaliações periódicas. Os componentes deste grupo devem atuar como suporte na institucionalização dos processos da organização.

144



Responsáveis pela Configuração• Grupo responsável pela manutenção da integridade dos dados de

configuração. Normalmente delegam-se as atividades de gestão do repositório dos dados (incluindo backup, controle de acesso, etc.) ao grupo de Infraestrutura;

• O grupo de CM deve estar fortemente ligado ao SEPG, para alinhamento das práticas descritas nos processos e as atividades do dia-a-dia dos projetos;

• Em alguns casos há responsáveis específicos por CM dentro de um projeto, podendo ser um desenvolvedor ou coordenador, realizando mais de um papel;

• Os sistemas de gestão de configuração são tipicamente implementados através de ferramentas como o VSS, OpenDoc e ClearCase.



• Treinamento

• A fase de institucionalização inclui a realização de treinamentos. Antes da institucionalização propriamente dita devem ser preparados treinamentos dos processos e ferramentas;

• Dependendo da abrangência do escopo organizacional em relação ao número de profissionais envolvidos para prover treinamento, é interessante elaborar um treinamento dos processos em nível mais alto e investir no mentoring durante o processo de institucionalização. É no dia-a-dia que as pessoas realmente aprendem!

• É necessário o treinamento em todos os processos, procedimentos, técnicas a serem utilizadas

146



– Envolvimento

– Comitê Executivo

– Normalmente composto pelo Patrocinador, Líder do SEPG e a Gerência Sênior da Consultoria;

• A comunicação de status é feita através de reuniões periódicas (mensais);

• A ocorrência deste tipo de atividade é vital para o sucesso do programa

– Equipe de Projeto

• A participação da equipe de projetos é muito importante para vencer a resistência na institucionalização;

• Além da participação nas reuniões de validação com o SEPG (definição dos processos) é importante realizar reuniões ou mini-seminário (2 horas) para apresentar ao grupo o andamento das atividades

• 147 Prof. Josiane Bernardes CMMI


• Um Programa de Melhoria bem-sucedido é composto de:

– Participação efetiva e supervisão da alta administração;

– Bom planejamento;

– Profissionais treinados e com competências apropriadas;

– Comunicado a todos na organização;

– Medição realizada com indicadores ligados ao negócio;

– Gerenciamento durante todo o projeto;

– Base na avaliação da situação atual da organização

148


• Vídeo de mudanças

Josiane Bernardes

[email protected]

“Há quem passe pelo bosque e só veja lenha para a fogueira.”

Tolstói


MBA EM GOVERNANÇA NAS TECNOLOGIAS DA INFORMAÇÃO

OBRIGADA!

JOSIANE [email protected]

– Mestre

pr00835-695-mba cmmi aula alunos

Documents