Carregar apresentação
A apresentação está carregando. Por favor, espere
1
FUNDAÇÃO CARLOS ALBERTO VANZOLINI
Departamento de Engenharia de Produção Escola Politácnica da USP Prof. Marcelo Pessôa Prof. Mauro Spinola
2
Departamento de Engenharia 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
3
Departamento de Engenharia 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
4
Fundaçã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.
5
Fundação Vanzolini OBJETIVOS:
Disseminar técnicas da engenharia de Produção e Administração Industrial Prestar serviços à Comunidade treinamento assessoria certificação projetos.
6
Fundação Vanzolini Diretorias Qualidade Produtividade Ergonomia
Certificação Qualidade Produtividade Ergonomia Gestão Industrial Logística Informática Mercado e Produto Cursos CEAI, CEQP, PCEPCC Educação à Distância Desenvolvimento.
7
Visão Geral e Aspectos de Implantação do Modelo CMM
8
Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola
Sinopse 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 Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 2
9
Introdução
10
Introdução Gestão da Qualidade Total (TQM)
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)
11
Qualidade de Software
12
Qualidade de Software: Produto
Defeito zero Grande Número de funções Codificação elegante Alto desempenho Baixo custo Desenvolvimento rápido Facilidade de uso Weinberg Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 6
13
Qualidade de software: processo
B Procedimentos e métodos que definem a relação entre as tarefas A D C Ferramentas e equipamentos PROCESSO Pessoas habilitadas, treinadas, motivadas Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola EPUSP - Qualidade de Software 19 10
14
Qualidade de software: processo
gerenciamento do processo testes x prevenção Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 11
15
Como fazer ? A escolha de um modelo de Sistema da Qualidade : ISO 9000
QS 9000 ISO 14000 Malcolm Baldridge / PNQ modelos TQM 25
16
Como fazer ? E os modelos para Software ? ISO 9000-3 CMM Trillium
Bootstrap SPICE S-Prime isso só para citar alguns... 26
17
Modelo CMM
18
Os níveis de maturidade
1-Inicial Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 13
19
Os níveis de maturidade
Processo disciplinado 2-Repetitivo 1-Inicial Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 14
20
Os níveis de maturidade
Processo consistente, padrão 3-Definido Processo disciplinado 2-Repetitivo 1-Inicial Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 15
21
Os níveis de maturidade
Processo previsível 4-Gerenciado Processo consistente, padrão 3-Definido Processo disciplinado 2-Repetitivo 1-Inicial Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 16
22
Os níveis de maturidade
Melhoria continua do processo 5-Otimizado Processo previsível 4-Gerenciado Processo consistente, padrão 3-Definido Processo disciplinado 2-Repetitivo 1-Inicial Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 17
23
modelo CMM - nível 1 Saída Entrada
Nível 1:O produto flui para fora e (espera-se) funciona. 18
24
modelo CMM - nível 2 Entrada Saída
Nível 2: Processo de construção = série de caixas pretas com pontos de verificação definidos. 19
25
Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola
Á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 Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 20
26
Gerenciamento de Requisitos
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. Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 21
27
Planejamento de Projeto
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 Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 22
28
Acompanhamento de Projeto
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. Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 23
29
Gerenciamento de Subcontrato
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 Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 24
30
Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola
Garantia 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 Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 25
31
Gerenciamento da Configuraçã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 Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 26
32
Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola
modelo CMM - nível 3 Entrada Saída Nível 3: Processo bem definido Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 27
33
Áreas-chave do nível 3 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) 28
34
Foco no Processo da Organizaçã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 29
35
Definição do Processo da 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 30
36
Programa de Treinamento
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 31
37
Gerenciamento Integrado 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 32
38
Engenharia de Produto de 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 33
39
Coordenação Intergrupos
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 Visão Geral CMM - Profs. Marcelo Pessôa e Mauro Spinola 34
40
Revisões - Peer 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 35
41
Nível 4: Produto e processo são gerenciados quantitativamente
modelo CMM - nível 4 Entrada Saída Nível 4: Produto e processo são gerenciados quantitativamente 36
42
Áreas-chave do nível 4 Gerenciamento Quantitativo do Processo
Gerenciamento da Qualidade de Software
43
Gerenciamento Quantitativo 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
44
Gerenciamento da Qualidade 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
45
modelo CMM - nível 5 Entrada Saída
Nível 5: Mudança disciplinada é um meio de vida 37
46
Areas-chave do nível 5 Prevenção de Defeito
Gerenciamento da Mudança Tecnológica Gerenciamento da Mudança no Processo
47
Prevençã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
48
Gerenciamento de Mudanç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
49
Gerenciamento de Mudanç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
50
A implantação
51
A implantação Aspectos Gerais
52
Embasamento 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.
53
A implantação Estratégia: Casamento ISO 9001 e CMM
Abordagem com visão ISO 9000 Abordagem com o modelo CMM.
54
A implantação 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.
55
A implantação 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.
56
A implantação 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 .
57
A implantação Framework
58
Um 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
59
A implantação CMM
60
Processo Um processo é formado por três componentes: métodos
pessoas treinadas e habilitadas ferramentas e equipamentos B A D C PROCESSO
61
Processo: 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
62
Processo: 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
63
Processo: 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
64
Processo: 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
65
Processo: 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
66
O Processo de Implementação do CMM
67
O 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
68
O Processo do CMM Não adianta “brigar” com o modelo interpretando que uma prática-chave “não se aplica” O modelo precisa ajudar
69
Olhando as Práticas-chave
Observar as práticas-chave identificando a que grupo pertence: processo (infraestrutura da empresa) projeto (usuário do processo)
70
Prá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
71
Prá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
72
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
73
Exemplo: RM
74
Exemplo: RM 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.
75
Exemplo: RM 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)
76
Exemplo: RM 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)
77
Exemplo: RM 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
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.