A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Qualidade de Software Prof a. Sandra C.P.F. Fabbri 1 o. semestre 1999.

Apresentações semelhantes


Apresentação em tema: "Qualidade de Software Prof a. Sandra C.P.F. Fabbri 1 o. semestre 1999."— Transcrição da apresentação:

1 Qualidade de Software Prof a. Sandra C.P.F. Fabbri 1 o. semestre 1999

2 Visão Geral de Qualidade Década de 90 - Fator Qualidade Necessidade básica na luta pelo mercado Não basta vender barato, as novas regras de mercado são orientadas à produção de bens e serviços com qualidade, prazo de entrega determinado, atendimento correto, além de um baixo custo (Werneck 1994).

3 Visão Popular de Qualidade Qualidade é vista como luxo, classe e questão de gosto. Produtos caros, sofisticados e mais complexos são considerados de maior qualidade que produtos similares mais simples Qualidade pode ser discutida, sentida e julgada, mas não pode ser medida. controlada, nem gerenciada.

4 Visão Profissional de Qualidade Qualidade está relacionada com os Requisitos designados para o produto. As não conformidades aos requisitos são consideradas defeitos, falta de qualidade Qualidade pode e deve ser definida, medida, monitorada, gerenciada e melhorada

5 Visão Profissional de Qualidaderequisitos PROCESSO DE CONSTRUÇÃO PRODUTO usuário requisitos atendidos PRODUTO COM QUALIDADE

6 Qualidade no Software Demanda da vida moderna - os computadores passam a integrar a rotina diária Produção de software vem tendo um aumento constante Exigência por qualidade estende-se à área de software

7 usuário Facilidade de Uso, Desempenho, Confiabilidade dos Resultados, Preço do Software, etc. desenvolvedor Taxa de defeitos, Facilidade de Manutenção e Conformidade em relação aos Requisitos de Usuários, etc organização Cumprimento de Prazo, Boa Previsão de Custo, Boa Produtividade Visões de Qualidade de Software

8 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto

9 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto Ele faz aquilo que eu quero?

10 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto Ele se comporta com precisão o tempo todo?

11 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto Posso consertá-lo?

12 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto Posso mudá-lo ?

13 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto Posso testá-lo?

14 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto Ele rodará no meu hardware tão bem quanto possível ?

15 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto Ele é seguro?

16 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto Ele foi projetado para o usuário?

17 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto Poderei usá-lo em outra máquina?

18 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto Poderei reutilizá-lo em outra máquina?

19 usuário desenvolvedor Adaptabilidade a Novos Ambientes Habilidade de ser Alterado Características Operacionais Corretitude Confiabilidade Manutenibilidade Flexibilidade Testabilidade Eficiência Integridade Usabilidade Portabilidade Reusabilidade Interoperabilidade Requisitos do Software Produto Poderei compor uma interface com outro sistema?

20 Qualidade de Software Produto desenvolvedor usuário requisitos de software produto Processo de Desenvolvimento de Software SOFTWARE PRODUTO requisitos atendidos SOFTWARE PRODUTO COM QUALIDADE

21 DEFINIÇÃO Análise de Sistema Planejamento Análise de Requisitos CONSTRUÇÃO Projeto Codificação Teste MANUTENÇÃO Entendimento Modificação Revalidação Processo de Desenvolvimento de Software

22 Requisitos Organizacionais REQUISITOS DE SOFTWARE PRODUTO CUMPRIMENTO DE PRAZO, BOA PREVISÃO DE CUSTO, BOA PRODUTIVIDADE Ferramentas Métodos Pessoas Políticas Responsabilidades Gerência Eficaz Controle das Atividades

23 Processo de Software Processo de Desenvolvimento Procedimentos e métodos que definem o relacionamento de tarefas. A C B D Pessoas com habilidades, treinamento e motivação Ferramentas e Equipamentos

24 Processo de Software Consiste em uma série de atividades, práticas, eventos, ferramentas e métodos que garantem, técnica e administrativamente que o software pode ser desenvolvido com qualidade e de maneira organizada, disciplinada e previsível.

25 Gerenciamento de Processo de Software Processo de Desenvolvimento de Software requisitos organizacionais Controle das Atividades Gerência Eficaz Processo de Software muito bem Definido requisitos de software produto

26 Uma das maiores dificuldades encontradas pelas empresas de software é o gerenciamento de seus processos de softwareUma das maiores dificuldades encontradas pelas empresas de software é o gerenciamento de seus processos de software Modelos de Processo de Software Processo de Software

27 Modelos de Processo de Software Um modelo de processo procura descrever formalmente e de maneira organizada todas as atividades que devem ser seguidas para a obtenção segura de um produto de software É importante escolher um modelo apropriado às metas da organização e saber o grau em que esse modelo será implementado Modelos CMM e SPICE incluem modelos de processo de software

28 Benefícios de uma melhoria baseada em um modelo Estabelece uma linguagem comum. Constrói um conjunto de processos e procedimentos desenvolvidos com sugestões de uma ampla participação da comunidade de software. Oferece uma estrutura para se priorizar as ações Auxilia comparações em diversas indústrias.

29 Riscos de uma melhoria baseada em um modelo Modelos são simplificações do mundo real. Modelos não são suficientemente abrangentes. Interpretação e adaptação à situações particulares devem estar ajustadas aos objetivos do negócio. É necessário bom senso para se utilizar modelos corretamente e com visão.

30 A qualidade do processo de software pode ser analisada através do nível de maturidade do processo. A maturidade dos processos de software de uma organização influencia na sua capacidade de atingir metas de custo, qualidade e cronograma Qualidade de Processo de Software X Maturidade de Processo de Software

31 Um Processo de Software Imaturo Processo improvisado por profissionais e gerências. Não é rigorosamente seguido e o cumprimento não é controlado. Altamente dependente dos profissionais atuais. Baixa visão do progresso e da qualidade.

32 Um Processo de Software Imaturo A qualidade do produto pode ficar comprometida para que prazos sejam cumpridos. Arriscado do ponto de vista do uso de nova tecnologia. Qualidade difícil de se prever.

33 Organizações com Processo de Software Imaturo o fogo está sob controle, mas estão quase sempre apagando incêndios constantemente reagindo (e não agindo pró-ativamente) - não há tempo para melhoria os bombeiros se queimam as cinzas podem voltar a se incendiar mais tarde

34 Um Processo de Software Maduro Coerente com as linhas de ação, o trabalho é efetivamente concluído.Coerente com as linhas de ação, o trabalho é efetivamente concluído. Definido, documentado e melhorando constantemente:Definido, documentado e melhorando constantemente: –compreendido –utilizado –vivo e ativo

35 Um Processo de Software Maduro Tem o apoio visível da alta administração e outras gerências.Tem o apoio visível da alta administração e outras gerências. Bem controlado - fidelidade ao processo é objeto de auditoria e de controleBem controlado - fidelidade ao processo é objeto de auditoria e de controle São utilizadas medições do produto e do processo.São utilizadas medições do produto e do processo. Uso disciplinado da tecnologia.Uso disciplinado da tecnologia.

36 Processo Institucionalizado infra-estruturaExiste uma infra-estrutura que possui processos eficazes, utilizáveis e consistentemente aplicados em toda organização. permanecemProcessos institucionalizados permanecem, mesmo depois que as pessoas que originalmente os definiram, deixam a organização. cultura organizacionalA cultura organizacional transmite o processo. Essa é a maneira como fazemos as coisas aqui.

37 Edificação da Cultura Organizacional

38 Valor da Melhoria de Processo A melhoria do processo de software oferece um retorno no investimento que pode ser medido - quando é medido. O retorno típico no investimento está entre 5:1 e 8:1. Benefícios adicionais são intangíveis e não podem ser quantificados facilmente. O CMM é uma ferramenta útil para orientação no processo de melhoria.

39 Pontos Comuns no Movimento da Qualidade Melhoria tem o seu foco em ajustar o processo e não em culpar as pessoas. Melhoria deve ser medida e ter sua implementação periodicamente controlada. Melhoria requer constância de investimentos, recompensas e incentivos. Melhoria é um processo contínuo. Se o nível de desconforto não é suficientemente alto, as coisas não mudarão.

40 Modelos de Melhoria de Qualidade de Processo CMMCMM BOOTSTRAPBOOTSTRAP SPICESPICE ISOISO PSPPSP

41 Melhoria de Processo de SoftwareProcesso Avaliação do Processo Melhoria do Processo é examinado pela conduz à Estímulo Contexto e Patrocínio Infra- Estrutura INICIALIZAÇÃO 1 Abordagem IDEAL Recomen -dações DIAGNÓSTICO 2 Estado Atual e Desejado DIRETRIZES Abordagem Prioridades Plano de Ação 3 Teste Piloto Refinamento Implementação REALIZAÇÃO 4 Solução Analisar/ Validar Ações futuras ALAVANCAGEM5 IDEAL melhoria A abordagem IDEAL descreve as fases, atividades e recursos necessários para uma melhoria de processo com sucesso.

42 Estímulo Contexto e Patrocínio Infra- Estrutura INICIALIZAÇÃO 1 Teste Piloto Refinamento Implementação REALIZAÇÃO 4 Solução Analisar/ Validar Ações futuras ALAVANCAGEM 5 Abordagem IDEAL Recomen- dações DIAGNÓSTICO 2 Estado Atual e Desejado DIRETRIZES Abordagem Prioridades Plano de Ação 3CMM

43 O que é o CMM? elementos chavesprocessoeficazUma estrutura que descreve os elementos chaves de um processo de software eficaz. melhoramento evolucionário mudarem ad hoc disciplinado.Um caminho de melhoramento evolucionário (5 níveis de maturidade) para organizações de software mudarem de um processo de software imaturo, ad hoc, para um processo maduro, disciplinado.

44 CMM - Capability Maturity Model Capability Maturity ModelCapability Maturity Model (Modelo de Maturidade da Competência) Maturidade da CompetênciaMaturidade da Competência : competência em controlar o Processo de Software (desenvolvimento, gerenciamento e manutenção). Maturidade da Competência Maturidade do Processo de SoftwareMaturidade da Competência Maturidade do Processo de Software

45 Maturidade de Processo de Software maturidade dos processos custo qualidadecronogramaA maturidade dos processos de software de uma organização influencia na sua capacidade de atingir metas de custo, qualidade e cronograma qualidade do processo de software nível de maturidade do processoA qualidade do processo de software pode ser analisada através do nível de maturidade do processo.

46 CMM - Capability Maturity Model SEI l desenvolvido pela SEI (Instituto de Engenharia de Software) Carnegie Mellon University, Pittsburgh, PA SEI Software Engineering Institute SEI l Missão da SEI: Exercer liderança nos estágios avançados da prática de engenharia de software para melhorar a qualidade de sistemas que dependam de software.

47 A Evolução do CMM (a) início do desenvolvimento de um modelo de maturidade de processo, para ajudar as organizações a melhorar seus processos de software (por solicitação do governo federal) junho 1987 modelo de maturidadejunho liberação de breve descrição do modelo de maturidade de processo de software setembro 1987 questionáriosetembro versão preliminar do questionário de maturidade 1991CMM a versão do CMM (Versão 1.0)

48 A Evolução do CMM (b) 1993 CMM depois de 5 anos de experiência, o modelo de maturidade evoluiu para um modelo completamente definido, usando conhecimento adquirido das avaliações de processo de software e de extensivo retorno das indústrias e do governo CMM fevereiro 1993 CMMCapability Maturity Model for Softwarefevereiro Versão 1.1 do CMM - Capability Maturity Model for Software (atualmente usada)

49 Premissa Básica Premissa básica SEIPremissa básica que está por trás do trabalho da SEI sobre maturidade de processo: A qualidade de um software produto é profundamente determinada pela qualidade do processo de desenvolvimento e de manutenção usado para construí-lo.

50 Visão Geral do Modelo (a) SEImodelo de5 níveisSEI desenvolveu um modelo de 5 níveis que orienta uma organização em como amadurecer seus processos de software. caminho indisciplinado disciplinadoO modelo descreve um caminho evolucionário que vai de um processo indisciplinado para um processo disciplinado. Sem a disciplina ineficientes fundamentos não foram estabelecidosSem a disciplina descrita no modelo, programas de melhoria podem mostrar-se ineficientes porque os fundamentos necessários para apoiar os melhoramentos sucessivos não foram estabelecidos.

51 Visão Geral do Modelo (b) 5 níveis de maturidade melhoria contínua do processo escala ordinalmedir a maturidadeOs 5 níveis de maturidade descrevem fundamentos sucessivos para melhoria contínua do processo e definem uma escala ordinal para medir a maturidade de processo de uma organização. vantagens prioridades claras atividades de melhoramento úteisAs vantagens dos níveis de maturidade é que eles fornecem prioridades claras, as quais orientam na seleção de algumas atividades de melhoramento que serão muito úteis se implementadas imediatamente. mportante poucas atividades cada vezIsso é importante porque a maioria das organizações podem focalizar somente algumas poucas atividades de melhoramento de cada vez.

52 Os 5 Níveis de Maturidade do CMM INICIAL Organizações Caóticas REPETÍVEL Organizações Disciplinadas DEFINIDO Organizações Padronizadas GERENCIADO Organizações Previsíveis OTIMIZADO Organizações com Melhoria Contínua

53 CMM: Nível 1 de Maturidade INICIAL Organizações Caóticas O processo de software é caracterizado como ad hoc, e ocasionalmente até mesmo caótico. Poucos processos são definidos e o sucesso depende de esforços individuais e heróicos.

54 CMM Nível 1 - O Gerenciamento de Software é uma Caixa Preta InOut l Requisitos fluem para dentro. algum processo disforme l Um produto de software é (normalmente) produzido através de algum processo disforme. l O produto flui para fora e (espera-se) funciona.

55 CMM - Nível 1 - Inicial Organizações Caóticas nãoambiente estável l A organização não provê um ambiente estável para o desenvolvimento e manutenção de software l Cronogramasorçamentos abandonados l Cronogramas e orçamentos são frequentemente abandonados por não serem beseados em estimativas realísticas criseetapas não são realizadas l Numa crise para cumprir cronograma, etapas planejadas do ciclo de vida não são realizadas prejudicando a qualidade do software

56 CMM - Nível 1 - Inicial Organizações Caóticas Desempenho heroísmoDesempenho basicamente em função da competência e heroísmo das pessoas que fazem o trabalho. processoimprevisível,O processo de software é imprevisível, já que é constantemente alterado no decorrer do projeto maiores problemas gerenciaisOs maiores problemas com os quais se defrontam as organizações de software são gerenciais e não técnicos.

57 CMM: Nível 2 de Maturidade REPETÍVEL Organizações Disciplinadas Processos administrativos básicos são estabelecidos para acompanhar custo, cronograma e funcionalidade. A disciplina de processo está em repetir sucessos anteriores em projetos com aplicações similares.

58 Está em vigor um Sistema de Gerenciamento de Projeto CMM Nível 2- Está em vigor um Sistema de Gerenciamento de Projeto InOut l Processo caixas pretaspontos de verificação l Processo de construção de software é uma série de caixas pretas com pontos de verificação definidos.

59 CMM - Nível 2 - Repetível Organizações Disciplinadas processo efetivoplanejamento e gerenciamento do projetoCaracterizado pela existência de um processo efetivo de planejamento e gerenciamento do projeto de software onde os controles sobre os procedimentos, compromissos e atividades são bem fundamentados. processos praticados na organizaçãoOs processos de planejamento e gerenciamento do projeto de software devem ser praticados na organização, documentados, treinados e controlados. ainda não há engenharia de softwareNeste nível ainda não há preocupação com o processo de engenharia de software

60 CMM - Nível 2 - Repetível Organizações Disciplinadas experiência obtida com projetos similares l O planejamento e gerenciamento de novos projetos são baseados na experiência obtida com projetos similares, que tenham obtido sucesso no passado dependência das experiências anteriores l Um fator relevante para a organização nesse nível é a dependência das experiências anteriores. novos tipos desequilíbrio l O desenvolvimento de novos tipos de produtos pode causar um desequilíbrio no projeto, nas estimativas de custos e nos cronogramas

61 CMM: Nível 3 de Maturidade DEFINIDO Organizações Padronizadas Os processos de software, tanto para atividades administrativas quanto para de engenharia estão documentados, padronizados e integrados em um processo de software padrão para a organização. Todos os projetos usam uma versão aprovada do processo de software padrão da organização para desenvolvimento e manutenção de software.

62 Desenvolvimento de software de acordo com um processo bem definido CMM Nível 3- Desenvolvimento de software de acordo com um processo bem definido InOut l Funções e responsabilidades entendidas l Funções e responsabilidades no processo são bem entendidas. produção do produto visível l A produção do produto de software é visível através do processo de software.

63 CMM - Nível 3 - Definido Organizações Padronizadas processo de engenharia padrão l Caracterizado principalmente pela existência de um processo de engenharia de software bem definido, documentado e padrão para a empresa. saídasfluem entradas l As saídas de uma atividade fluem naturalmente para as entradas da próxima atividade utiliza base para implementar l Cada projeto de software utiliza o processo padrão da organização como base para implementar seu próprio processo.

64 CMM - Nível 3 - Definido Organizações Padronizadas grupo para processos de software l Existe um grupo para processos de software (SEPG) responsável por facilitar atividades de definição e melhoria de processos. programa de treinamento l Existe um programa de treinamento que assegura que todos tenham o conhecimento e a capacidade requerida para desenvolver suas tarefas, utilizando as ferramentas e os métodos disponíveis poderes l Processos que dêem poderes as pessoas para realizarem o trabalho

65 CMM: Nível 4 de Maturidade GERENCIADO Organizações Previsíveis São coletadas medidas detalhadas da qualidade do processo e do produto. Tanto o processo de software quanto os produtos são quantitativamente compreendidos e controlados.

66 Produto e processo são gerenciados quantitativamente CMM Nível 4- Produto e processo são gerenciados quantitativamente InOut gerência bases objetivas l A gerência tem bases objetivas para tomada de decisão. prever o desempenho l A gerência é capaz de prever o desempenho dentro de limites quantificados.

67 CMM - Nível 4 - Gerenciado Organizações Previsíveis processos passíveis de medida l Caracterizado pela existência de processos de software passíveis de medida. produtividadequalidademedidas l A produtividade e a qualidade são medidas em todas as etapas do processo de software e para todos os projetos da organização. controle sobre produtos e processos l O controle sobre produtos e processos de todos os projetos são adquiridos através da diminuição da variação do seu desempenho para dentro de limites quantitativos aceitáveis.

68 CMM - Nível 4 - Gerenciado Organizações Previsíveis aplicar métricas de controle de qualidade l A organização começa a aplicar métricas de controle de qualidade para aumentar a qualidade e a produtividade do software entregue aos clientes. conhecimento sobre o produto removerfontes de comprometimento l À medida que a organização adquire mais conhecimento sobre o produto, tem a oportunidade de remover várias fontes de comprometimento da qualidade final colocar controle estatístico de qualidade l Isto proporciona a oportunidade de colocar o produto sob um controle estatístico de qualidade.

69 CMM: Nível 5 de Maturidade OTIMIZADO Organizações com Melhoria Contínua Contínua melhoria de processo é possível por retornos quantitativos dos processos e das idéias e tecnologias inovativadoras

70 Foco na melhoria contínua do processo CMM Nível 5- Foco na melhoria contínua do processo InOut l Mudança disciplinada l Mudança disciplinada é um meio de vida.

71 CMM - Nível 5 - Otimizado Melhoria Contínua processos contínua melhoria l Caracterizado pela existência de processos de software com contínua melhoria. processosavaliados prevenir l Os processos de software são avaliados para prevenir tipos de defeitos conhecidos devido à recorrência, e as lições aprendidas são disseminadas para outros projetos. l Tecnologias introduzidas, gerenciável l Tecnologias que proporcionem mais retorno para processos específicos, utilizados pela organização, são selecionadas para serem introduzidas, de maneira gerenciável na organização.

72 CMM - Nível 5 - Otimizado Melhoria Contínua contínuas melhorias l Apesar de o processo ser maduro, ele é alvo de contínuas melhorias. causas dos defeitos l Os grupos de projetistas analisam o rendimento do projeto para determinar as causas dos defeitos. ambiente de excelência l Nesse nível foi atingido um ambiente de excelência em engenharia de software

73 Como Melhorar o Processo de Software ? l Realizando um grupo de atividades correlatas, denominadas ÁREAS-CHAVE DE PROCESSO - (Key process areas - KPA) que, quando efetuadas coletivamente, alcançam um conjunto de metas consideradas importantes na implementação da competência do processo.

74 Mudança de Nível de Maturidade INICIAL Organizações Caóticas REPETÍVEL Organizações Disciplinadas Atividades de gerenciamento do projeto são estabelecidas para rastrear custo, prazos e funcionalidade inicial => repetível KPAs 6- Gerenciamento da Configuração de Software 5- Garantia da Qualidade de Software 4- Gerenciamento de Subcontrato de Software 3- Acompanhamento de Projeto de Software 2- Planejamento de Projeto de Software 1- Gerenciamento de Requisitos

75 Exemplo: Áreas-chave de Processo Inicial RepetívelDefinidoGerenciadoOtimizado CMM TOTAL 18 Áreas-chave de Processo GCS GQS GSS APS PPS GR atividades

76 Níveis de maturidade não podem ser omitidos l Processos dos níveis mais altos de maturidade podem ser realizados até mesmo por organizações do nível 1 (embora talvez ineficazmente). l Competência estágios l Competência em processos é construída em estágios, uma vez que alguns processos não são eficazes quando outros não estão estáveis. nível fundamento l Cada nível oferece um fundamento necessário para melhorias a serem implementadas no nível seguinte.

77 Níveis de maturidade não podem ser omitidos l Semgerenciamento sacrificado l Sem a disciplina de gerenciamento o processo de engenharia é sacrificado. inconsistentes l Medidas detalhadas são inconsistentes sem um processo definido. não é claro l O efeito de inovação de processo não é claro em um processo cheio de ruído.

78 As Inspirações do CMM estrutura princípios de qualidade de produtoA estrutura do modelo de maturidade de processo de software está baseada nos princípios de qualidade de produto que existem há 60 anos controle estatístico de qualidade Shewart (AT&T) promulgou os princípios de controle estatístico de qualidade. desenvolvidos e demonstradosOs princípios de Shewart foram posteriormente desenvolvidos e demonstrados com sucesso no trabalho de Deming e Juran. TQM l O trabalho desses pioneiros princípios do TQM (Total Quality Management)

79 Gerenciamento da Qualidade Total Gerenciamento da Qualidade Total (TQM métodos quantitativosrecursos humanosmelhorarGerenciamento da Qualidade Total (TQM) é a aplicação de métodos quantitativos e recursos humanos para melhorar : - o material e serviços fornecidos por uma organização - todos os processos dentro de uma organização - o nível de atendimento das necessidades do cliente, no presente e no futuro

80 Princípios do TQM adaptados no Modelo CMM CMMestágios iniciaisadministração do projeto fundamentos de engenharia estágios mais avançados controle quantitativo do processoO CMM estabelece, durante os estágios iniciais, a administração do projeto e os fundamentos de engenharia e durante os estágios mais avançados de maturidade, o controle quantitativo do processo de software.

81 Aplicando TQM ao Software CMM TQM Projeto C Projeto A hardware software Organização Projeto X Projeto B processo de melhoria CMM software. O processo de melhoria se aplica em todo o contexto do negócio - o CMM se aplica especificamente ao software.


Carregar ppt "Qualidade de Software Prof a. Sandra C.P.F. Fabbri 1 o. semestre 1999."

Apresentações semelhantes


Anúncios Google