visão geral cmm - profs. marcelo pessôa e mauro spinola fundaÇÃo carlos alberto vanzolini...

Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola

FUNDAÇÃO CARLOS FUNDAÇÃO CARLOS

ALBERTO VANZOLINIALBERTO VANZOLINI

Departamento de Departamento de

Engenharia de ProduçãoEngenharia de Produção

Escola Politácnica da USPEscola Politácnica da USPProf. Marcelo Pessôa

Prof. Mauro Spinola


Departamento de Departamento de Engenharia de ProduçãoEngenharia de Produção

Primeiro curso de Engenharia de Produção do país

45 professores 450 alunos de graduação 200 alunos de pós-graduação


Departamento de Departamento de Engenharia de ProduçãoEngenharia de Produção

Área de pesquisa em Tecnologia da Informação:

Planejamento e Implementação de Sistemas de Tecnologia da informação

Total de 30 alunos envolvidos Qualidade de software: 8 dissertações e

teses em andamento


Fundação VanzoliniFundação Vanzolini

Formada em 1967 pelos professores do Departamento de Engenharia de Produção da Escola Politécnica da USP

Entidade sem fins lucrativos

Opera em convênio com a Universidade de São Paulo.


Fundação Vanzolini Fundação Vanzolini OBJETIVOSOBJETIVOS::

Disseminar técnicas da engenharia de Produção e Administração Industrial

Prestar serviços à Comunidade– treinamento– assessoria– certificação– projetos.


• CertificaçãoCertificação• QualidadeQualidade• ProdutividadeProdutividade• ErgonomiaErgonomia• Gestão IndustrialGestão Industrial• LogísticaLogística

• InformáticaInformática• Mercado e ProdutoMercado e Produto• CursosCursos

CEAI, CEQP, PCEPCCCEAI, CEQP, PCEPCC

• Educação à DistânciaEducação à Distância• Desenvolvimento.Desenvolvimento.

Fundação VanzoliniFundação VanzoliniDiretorias


Visão Geral e Aspectos de Implantação do Modelo

CMM

Visão Geral CMM - Profs. Marcelo Pessôa e Mauro SpinolaVisão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola

SinopseSinopse

Introdução Qualidade de Software Abordagens de processo e de produto Modelo CMM Áreas-chave para o nível 2 Áreas-chave para o nível 3 A implantação


Introdução


inspeção 100% - anos 20

Controle Estatístico de Processos (CEP) - anos 30/40

Controle da Qualidade Total (TQC) - anos 50

Gestão da Qualidade Total (TQM)

IntroduçãoIntrodução


Qualidade de Software


Qualidade de Software:Qualidade de Software:ProdutoProduto

Defeito zero Grande Número de funções Codificação elegante Alto desempenho Baixo custo Desenvolvimento rápido Facilidade de uso Weinberg


Qualidade de software: Qualidade de software: processoprocesso

PROCESSOFerramentas e equipamentos

Pessoas habilitadas, treinadas, motivadas

Procedimentos e métodos que definem a relação entre as tarefas

A

B

C

D


Qualidade de software: Qualidade de software: processoprocesso

gerenciamento do processo

testes x prevenção


Como fazer ?Como fazer ?

A escolha de um modelo de Sistema da Qualidade :– ISO 9000– QS 9000– ISO 14000– Malcolm Baldridge / PNQ modelos TQM


Como fazer ?Como fazer ?

E os modelos para Software ?– ISO 9000-3– CMM– Trillium– Bootstrap– SPICE– S-Prime

isso só para citar alguns...


Modelo CMM


Os níveis de maturidadeOs níveis de maturidade

1-Inicial



1-Inicial

2-Repetitivo

Processo disciplinado



1-Inicial

2-Repetitivo

3-Definido

Processo consistente, padrão




1-Inicial

2-Repetitivo

3-Definido

4-GerenciadoProcesso consistente,

padrão

Processo previsível




1-Inicial

2-Repetitivo

3-Definido

4-Gerenciado

5-Otimizado

Processo consistente, padrão

Processo previsível

Melhoria continua do processo



modelo CMM - nível 1modelo CMM - nível 1

Entrada Saída

Nível 1:O produto flui para fora e (espera-se) funciona.



Entrada Saída

Nível 2: Processo de construção = série de caixas pretas com pontos de verificação definidos.


Áreas-chave do nível 2Áreas-chave do nível 2

Gerenciamento dos Requisitos - RM Planejamento do Projeto de Software - SPP Acompanhamento do Projeto de Software - SPTO Gerenciamento do Subcontrato de Software - SSM Garantia da Qualidade de Software - SQA Gerenciamento da Configuração de Software - SCM


Gerenciamento de Gerenciamento de RequisitosRequisitos

Entendimento comum dos requisitos que serão abordados

Envolve:– documentar e controlar os requisitos – planos, produtos e atividades são mantidos

consistentes com os requisitos.


Planejamento de Planejamento de ProjetoProjeto

Estabelecer planos razoáveis – para desenvolver o software e

– para gerenciar o projeto de software.

Envolve:– desenvolver estimativas para o trabalho a

ser executado– determinar os compromissos necessários– definir o plano para realizar o trabalho


Acompanhamento de Acompanhamento de ProjetoProjeto

Visibilidade adequada no progresso real:– o gerente pode tomar medidas efetivas no caso de desvios do

plano.

Envolve: acompanhar e revisar os resultados e realizações do

software confrontando com as estimativas documentadas, compromissos e planos;

ajustar os planos com base em resultados e realizações efetivamente alcançados.


Gerenciamento de Gerenciamento de SubcontratoSubcontrato

Selecionar subfornecedores qualificados de software e gerenciá-los eficazmente.

Envolve: selecionar um subfornecedor de software estabelecer compromissos com o subfornecedor acompanhar e revisar o desempenho do

subfornecedor e os resultados conseguidos


Garantia da QualidadeGarantia da Qualidade

Oferecer gerenciamento com visibilidade apropriadaÇ– no processo que está sendo utilizado e

– nos produtos que estão sendo construidos.

Envolve: revisões e auditorias nos produtos de software e

atividades para se assegurar que estão em conformidade com os padrões e procedimentos aplicáveis

fornecer ao gerente do projeto e outros gerentes envolvidos os resultados das revisões e auditorias


Gerenciamento da Gerenciamento da ConfiguraçãoConfiguração

A finalidade é estabelecer e manter a integridade dos produtos do projeto de software ao longo do ciclo de vida do software.

Envolve: identificar ítens/unidades de configuração controlar sistematicamente as alterações manter integridade e rastreabilidade da configuração

ao longo do ciclo de vida do software



Entrada Saída

Nível 3: Processo bem definido



•Foco no Processo da Organizacão•Definição do Processo da Organizacão•Programa de Treinamento•Gerenciamento de Software Integrado•Engenharia de Produto de Software•Coordenação de Intergrupos•Revisões (peer review)


Foco no Processo da Foco no Processo da OrganizaçãoOrganização

Determinar a responsabilidade organizacional para as atividades de software que melhoram a capacidade do processo de software como um todo na organização.

Envolve: desenvolver e manter uma compreensão dos processos

de software do projeto e da organização coordenar as atividades de avaliação, desenvol-

vimento, manutenção e melhoria desses processos


Definição do Processo Definição do Processo da Organizaçãoda Organização

Desenvolver e manter um conjunto utilizável de bens de processo de software que melhore o desempenho do processo e ofereça uma base para benefícios cumulativos e de longo prazo.

Envolve:– desenvolver e manter o processo de software

padrão da organização e outros bens de processo a ele relacionados


Programa de Programa de TreinamentoTreinamento

Desenvolver as habilidades e aumentar os conhecimentos dos indivíduos no sentido deles poderem desempenhar seus papéis ou funções eficiente e eficazmente.

Envolve:– identificar as necessidades de treinamento

da organização, dos projetos e dos indivíduos

– desenvolver e/ou contratar treinamento para preencher essas necessidades


Gerenciamento Gerenciamento Integrado de SoftwareIntegrado de Software

Integrar a engenharia de software do projeto e as atividades de gerenciamento em um processo de software definido e coerente, adaptado a partir dos bens do processo de software da organização.

Envolve:– desenvolver o processo de software definido do projeto

adaptando o processo de software padrão da organização– gerenciar o projeto de software de acordo com esse

processo de software definido


Engenharia de Produto Engenharia de Produto de Softwarede Software

Realizar de maneira consistente, um processo de engenharia bem definido que integre todas as atividades de engenharia de software para produzir, de forma eficiente e eficaz, produtos de software consistentes e adequados.

Envolve:– desempenhar as tarefas de engenharia para

construir e manter software utilizando ferramentas e métodos adequados


Coordenação Coordenação IntergruposIntergrupos

A finalidade é estabelecer meios para que o grupo de engenharia de software participe ativamente com outros grupos de engenharia a fim de que o projeto possa melhor satisfazer as necessidades do cliente, eficaz e eficientemente.

Envolve:– Interação disciplinada e coordenação dos grupos de

engenharia do projeto para que sejam abordados requisitos a nível do sistema, objetivos e planos


Revisões - Revisões - Peer ReviewsPeer Reviews

Remover defeitos de produtos do desenvolvimento de software com antecedência e eficientemente. Um efeito corolário importante é desenvolver uma melhor compreensão dos produtos do desenvolvimento de software e de defeitos que possam ser evitados.

Envolve: um exame metódico de produtos de desenvolvimentos por

pessoas da área do produtor para identificar defeitos e áreas onde mudanças são necessárias

produtos que se submeterão a “peer review” são identificados no processo de software definido do projeto



Entrada Saída

Nível 4: Produto e processo são gerenciadosquantitativamente



•Gerenciamento Quantitativo do Processo

•Gerenciamento da Qualidade de Software


Gerenciamento Gerenciamento Quantitativo do ProcessoQuantitativo do Processo

Controlar quantitativamente o desempenho do processo de software do projeto

Envolve: determinar metas para o desempenho do

processo medir o desempenho do projeto analisar as medições fazer ajustes para manter a performance do

processo dentro de limites aceitáveis


Gerenciamento da Gerenciamento da Qualidade de SoftwareQualidade de Software

Desenvolver uma compreensão quantitativa dos produtos de software do projeto e alcançar metas específicas da qualidade.

Envolve: definir metas da qualidade para os produtos de

software determinar planos para alcançar estas metas monitorar e ajustar os planos de software, produtos do

desenvolvimento de software e metas da qualidade para satisfazer as necessidades e desejos do cliente/usuário final



Entrada Saída

Nível 5: Mudança disciplinada é um meio de vida


Areas-chave do nível 5Areas-chave do nível 5

•Prevenção de Defeito•Gerenciamento da Mudança Tecnológica•Gerenciamento da Mudança no Processo


Prevenção de DefeitosPrevenção de Defeitos

A finalidade é identificar a causa de defeitos e evitar que eles aconteçam novamente.

Envolve: analisar defeitos que foram encontrados no

passado realizar ações específicas para evitar a

ocorrência desses tipos de defeitos no futuro


Gerenciamento de Gerenciamento de Mudanças TecnológicasMudanças Tecnológicas

A finalidade é identificar novas tecnologias (i.e., ferramentas, métodos e processos) e transferí-las para a organização de uma forma ordenada.

Envolve:– identificar, selecionar e avaliar novas

tecnologias– efetiva incorporação de tecnologias na

organização


Gerenciamento de Gerenciamento de Mudanças de ProcessoMudanças de Processo

Melhorar continuamente os processos de software utilizados na organização com o objetivo de melhorar a qualidade de software, aumentando a produtividade e diminuindo o tempo do ciclo para o desenvolvimento do produto.

Envolve: definição de metas de melhoria do processo identificação, avaliação e implementação sistemática

de melhorias no processo de software padrão da organização e nos processos de software definidos dos projetos


A implantação


A implantaçãoAspectos Gerais


EmbasamentoEmbasamento

Depoimentos de casos reais de implantação em publicações especializadas

Experiência na implantação em diversas empresas: telecomunicações, área financeira

Experiência com grupos de empresas que se cotizaram para implantar um sistema da qualidade: Softsul, ITS.


A implantaçãoA implantação

Estratégia: Casamento ISO 9001 e CMM

– Abordagem com visão ISO 9000

– Abordagem com o modelo CMM.



Visão ISO 9000: Norma amplamente conhecida Alto grau de abstração Permite construir um sistema da qualidade

para qualquer tipo de empresa Exige grande dose de interpretação e

adaptação para empresas de software.



Visão CMM: Especialmente desenvolvido para software Um dos modelos mais antigos Muito sofisticado para empresas que não

possuem uma estrutura para a qualidade Provoca “amor à primeira vista” para os

profissionais de software Permite customização para pequenos

projetos.



Casamento ISO / CMM: Implantar a ISO 9000 na empresa de software

utilizando o modelo CMM como guia Depois da certificação, a empresa poderá

melhorar seu sistema da qualidade implantando o próprio modelo CMM .


A implantaçãoFramework


Um Framework para o CMMUm Framework para o CMM

Considerar o trabalho como um projeto de engenharia:– definição de uma política para implantação– constituição de uma equipe responsável– planejamento completo com cronograma,

dedicação, atividades bem definidas, etc.– gerenciamento do projeto– controle e ação corretiva – registro o número de horas trabalhadas


A implantaçãoCMM


ProcessoProcesso Um processo é formado por três

componentes:– métodos– pessoas treinadas e habilitadas– ferramentas e equipamentos

PROCESSO

A

B

C

D


Processo: MétodosProcesso: Métodos

Os métodos são concretizados em procedimentos, ou seja, documentos que descrevem as tarefas e sua relação

Precisam ser simples e coerentes com a prática da empresa e do ambiente de trabalho


Processo: PessoasProcesso: Pessoas Todo processo, para funcionar direito,

precisa treinar e qualificar as pessoas As pessoas precisam compreender e acreditar

no processo As pessoas precisam achar que o processo

ajuda seu trabalho Esse é o ponto mais nevrálgico de qualquer

implantação de sistemas da qualidade


Processo: FerramentasProcesso: Ferramentas

As ferramentas podem ser manuais como formulários, fichários

As ferramentas podem ser tão sofisticadas quanto um CASE integrado

Os métodos embutidos nas ferramentas precisam ser conhecidos


Processo: AmeaçasProcesso: Ameaças Papel descrevendo o processo não é

processo, é intenção de possuir um processo Ferramenta CASE que ninguém sabe usar

não é processo, é dinheiro jogado fora Algumas pessoas seguindo processo não ;e

processo, é bagunça Pessoas que seguem o processo mas não

acreditam que ele seja bom significa baixa produtividade


Processo: RecomendaçõesProcesso: Recomendações O sucesso na implementação de qualquer

atividade, de qualquer processo depende dos três fatores citados:

procedimento que descreve o método escolhido

ferramentas para darem apoio e facitlitarem o trabalho

pessoas que sejam treinadas, compreendam e usem o processo


O Processo de O Processo de Implementação do CMMImplementação do CMM


O Processo do CMMO Processo do CMM

Todas as práticas-chave precisam ser implementadas

Todas as práticas-chave precisam ser interpretadas para uma implementação inteligente

O modelo não pode atrapalhar, burocratizando


O Processo do CMMO Processo do CMM

Não adianta “brigar” com o modelo interpretando que uma prática-chave “não se aplica”

O modelo precisa ajudar


Olhando as Práticas-chaveOlhando as Práticas-chave

Observar as práticas-chave identificando a que grupo pertence:

– processo (infraestrutura da empresa)

– projeto (usuário do processo)


Práticas-chave de ProcessoPráticas-chave de Processo

Identificar que ações devem ser tomadas para cada uma delas:– procedimentos– verificações do processo– treinamento e orientação das pessoas

envolvidas– ferramentas


Práticas-chave de ProjetoPráticas-chave de Projeto

Identificar que ações devem ser tomadas para cada uma delas:– documentos do projeto– atribuição de responsabilidades– atividades de revisão e aprovação– ações no projeto– ferramentas


Escrever o que aonde ?Escrever o que aonde ?

Compreendido o que o modelo precisa, é necessário organizar quantos e quais procedimentos deverão ser escritos.

Uma forma natural para o nível 2 seria um procedimento para cada KPA

Olhando a ISO no 4.4 entrariam SPP e SPTO por exemplo


Exemplo: RMExemplo: RM

Proc Ver Trein Tool Doc Resp Revis Partic AçãoCo1 XAb1 XAb2 XAb3 XAb4 X XAc1 XAc2 XAc3 XMe1 XVe1 XVe2 XVe3 X



Co1 - política escrita

Escrever no procedimento RM que todo projeto deve ter seus requisitos escritos e que toda alteração deve ser controlada de forma que a qualque momento pode-se saber quais requisitos são válidos.



Ab1 - responsabilidade para analisar

Escrever no procedimento RM , ou PP, que todo projeto deve ter um responsável para analisar os requisitos (processo)

No plano do projeto deve estar definido o nome do responsável (projeto)



Ac3 - as mudanças são revistas e incorporadas

Escrever no procedimento RM que todas as mudanças de requisitos devem ser analisadas pelo responsável antes de serem incorporadas ao projeto (processo).

Cada alteração com rubrica e data de aprovação. Usar template ou formulário (projeto)



Me1 - medidas para determinar status

Escrever no procedimento RM formações ou SPTO que todo projeto deve ter um relatório periódico contendo o total de alterações solicitadas, aprovadas e rejeitadas. (processo)

No plano deve estar definido a periodicidade dos relatótios

Colocar as informações nos relatórios


[email protected]@usp.br

[email protected]@usp.br

visão geral cmm - profs. marcelo pessôa e mauro spinola fundaÇÃo carlos alberto vanzolini...

Documents