Professor: Disciplina:

Transcrição

1 Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR Turma: 04º semestre Prof. Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com 1

2 Prof. Esp. Marcos Morais de Sousa 2

3 Já falamos sobre O que é Software Classificação e Tipo de Softwares O que é Engenharia de Software Métodos; Ferramentas e Processos 08 - Ciclo de Vida de um Software Qualidade de software Melhoria de Processos de Software Prof. Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com 3

4 Gerenciamento de Qualidade CMMI e MPS.BR Prof. Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com 4

5 Introdução Desenvolvimento orientado a objetos Utilização de ferramentas CASE Desenvolvimento de componentes Reusabilidade de software

6 Qualidade de Software? Não sabemos especificar certas características de qualidade, por exemplo, manutenibilidade, proteção, eficiência É muito difícil escrever especificações de softwares completas = insatisfação do cliente Qualidade é algo subjetivo Não se faz somente no começo e no final com testes Qualidade não é uma fase do ciclo de desenvolvimento de software... é parte de todas as fases Desenvolvimento de Normas e Padrões Representa a base da garantia da qualidade Cuidado com o excesso de burocracia

7 TQM (Total Quality Management) Elementos chave

8 Modelo de MacCall Os Fatores da Qualidade de McCall.

9 Colocações Pressman Definir explicitamente o termo qualidade de software, quando o mesmo é dito Criar um conjunto de atividades que irão ajudar a garantir que cada produto de trabalho da engenharia de software exiba alta qualidade Realizar atividades de segurança da qualidade em cada projeto de software Usar métricas para desenvolver estratégias para a melhoria de processo de software e, como conseqüência, a qualidade no produto final

10 Gerenciamento de Qualidade

11 Qualidade de processo e produto Qualidade de processo afeta a qualidade do produto No desenvolvimento de software é mais complexo Equipe de garantia de qualidade deve ir além do gerente de projetos Definir processo Desenvolver o produto Avaliar a qualidade do produto Aprimorar o processo Não Qualidade OK? Sim Padronizar o processo Modelo Processo manufatura

12 Atividades Principais Garantia de qualidade Estabelecimento de um framework de procedimentos organizacionais e padrões que conduzem a um software de alta qualidade Planejamento de qualidade Seleção de procedimentos e padrões apropriados deste framework, adaptados a um projeto de software específico Controle de qualidade Definição e aprovação de processos que assegurem que a equipe de desenvolvimento tenha seguido os procedimentos e padrões de qualidade de projeto

13 Garantia de Qualidade x Controle de Qualidade

14 Garantia de Qualidade Define como a qualidade do software pode ser atingida Define como a organização sabe que o software possui o nível de qualidade necessário Relacionada à definição e seleção de padrões que devem ser aplicados ao processo de desenvolvimento de software ou ao produto de software Padrões de produtos Documentos (Estrutura do documento de requisitos, documentações de classes), padrões de codificação Aplicam-se à saída do processo de software Padrões de processo Como os processos devem ser seguidos durante o desenvolvimento Descrição dos documentos que devem ser escritos ao longo dos processos.

15 Garantia de Qualidade Como iremos definir padrões?

16 Planejamento de Qualidade Deve selecionar os padrões de qualidade apropriados Como? Analisando o produto e o processo Plano de qualidade deve conter: Apresentação do produto Planos do produto Descrições do processo Metas de qualidade Riscos e gerenciamento de riscos

17 Planejamento de Qualidade (Atributos de qualidade) Segurança Modularidade Complexidade Proteção Adaptabilidade Portabilidade Confiabilidade Facilidade de Recuperação Robustez Facilidade de Testes Facilidade de Compreensão Facilidade de Aprendizado Facilidade de Uso Facilidade de Reuso Eficiência

18 Controle de Qualidade Monitoração do processo Produtos são verificados de acordo com os padrões definidos Abordagens para verificar a qualidade dos produtos de projeto: Grupo de pessoas Automatizado por meio de software

19 Melhoria de Processo de Software É considerada hoje uma das grandes prioridades Busca por produtos com maior qualidade Entrega a curto prazo Menor custo de desenvolvimento Entender as características dos processos existentes e fatores que afetam a sua capacidade Planejar, justificar e implementar ações que modificarão os processos Avaliar os impactos e benefícios ganhos, comparando-os com os custos advindos das mudanças realizadas

20 Avaliação de Processo Contexto Interno Externa Terceiros fornecedor é avaliado Objetivos Melhoria dos processos Determinar a capacidade dos processos de uma organização Escopo Todos os processos da organização Um subconjunto selecionado de processos Um projeto em específico

21 Análise Causal de Defeitos É considerada na maioria das abordagens de melhoria de processo de software: MPS.BR, CMMI, Six Sigma, Lean

22 Análise Causal de Defeitos Causas podem revelar oportunidades de melhoria em ativos de processos organizacionais Uma das principais características de qualidade do produto são os defeitos encontrados em seus artefatos. O esforço para realizar a análise causal varia entre 0,5 e 1,5% A revisão média na taxa de defeitos tem sido superior a 50% Traz alto retorno de investimento para a organização

23 Análise Causal de Defeitos Pode ser resumida em seis passos: Selecionar a amostra do problema Classificar problemas selecionados Identificar erros sistemáticos Identificar principais causas Desenvolver proposta de ação Documentar resultados da Reunião

24 Análise Causal de Defeitos selecionar a amostra do problema Em organizações maduras a análise causal pode ser disparada por instabilidade detectada em um gráfico de controle estatístico.

25 Análise Causal de Defeitos classificar problemas selecionados Características: Tipo de defeito Omissão, informação estranha, ambiguidade, fato incorreto, informação inconsistente. Momento (ou fase de desenvolvimento) da sua introdução Momento da sua detecção Esforço necessário para removê-lo Uso de check-list Uso de tabelas cruzadas

26 Análise Causal de Defeitos identificar erros sistemáticos São aqueles que resultam na introdução de tipos de defeitos similares em diferentes ocasiões São geralmente relacionados a uma atividade específica ou parte de um produto Encontrar erros sistemáticos indica a existência de oportunidade de melhoria para os ativos de processos organizacionais

27 Análise Causal de Defeitos identificar principais causas Vários fatores podem gerar um erro sistemático Tratar todos os fatores pode ser inviável economicamente Esforço deve ser empregado a fim de encontrar as principais causas Conhecer o contexto organizacional é imprescindível Diagrama de Ishikawa ou espinha de peixe

28 Análise Causal de Defeitos desenvolver propostas de ação Propostas de ação devem ser desenvolvidas para evitar a ocorrência daquelas causas em iterações ou projetos futuros O número de propostas deve ser pequeno Métodos implicam em mudanças no processo Pessoas treinamento Entradas/Requisitos mudança no plano de comunicação com o cliente Ferramentas mudança no ambiente de desenvolvimento

29 Análise Causal de Defeitos Documentar resultados da reunião Registros são necessário para assegurar que as ações sejam implementadas Uma equipe de ação deve ser estabelecida de maneira que a implementação das ações possa ser gerenciada

30

31

32 Melhoria de Processo no Desenvolvimento Ágil Princípio: Em intervalos regulares o time deve refletir sobre como se tornar mais efetivo e ajustar seu comportamento de acordo com esta reflexão.

33 Melhoria de Processo no Desenvolvimento Ágil Todo o time é responsável pela melhoria de processo; As melhorias propostas são resultados da experiência do time sobre o que pode melhorar em seu próprio comportamento sem a necessidade de indicadores formais ou critérios bem definidos; As mudanças propostas pelo time entram em vigor a partir da próxima iteração, ou seja, já é incorporado ao processo da equipe não precisando de projetos pilotos;

34 Melhoria de Processo no Desenvolvimento Ágil A avaliação das mudanças ocorre pelo sentimento da equipe durante o que aconteceu durante aquela iteração, então se a mudança funcionou, a equipe pode manter aquela mudança; As mudanças são propostas em intervalos bem definidos, esses intervalos podem durar de uma a poucas iterações; O time tem autonomia para se auto-organizar e determinar como o processo será seguido e determinar que ações realizar quando não conformidades forem encontradas.

35 Melhoria de Processo no Desenvolvimento Ágil Modelos organizacionais para melhoria de processo de software Modelo tradicional: A melhoria do processo tem um caráter organizacional As melhores práticas se tornarão parte do processo padrão da empresa. Existirão indicarão de quando usá-las Ocorre um aprendizado organizacional Modelo ágil: As melhores arquiteturas, requisitos e projetos surgem de times auto-organizados. No contexto ágil, as decisões do time são mais prioritárias do que aquelas vidas da organização Não há um processo padrão definido Podem utilizar a mesma abordagem: XP

36 Melhoria de Processo no Desenvolvimento Ágil Processos padrões e avaliação de processos Modelo Tradicional: Modelos como CMMI e MPS.BR são referências atuais no mercado Ajudam a medir a evolução da MPS na organização Todo programa de melhoria deve ser avaliado de forma objetiva, seguindo critérios bem definidos e não ambíguos Não existe nenhum método de avaliação que se mostre melhor para todos os casos Modelo Ágil: Não possui indicadores definidos Avaliações são realizadas de forma subjetiva A alteração no processo também é subjetiva e informal A experiência do time define o que será utilizado Nokia Test IEEE 1648

37 Adaptação de processos Modelo tradicional: Não se mostram universalmente aplicáveis Possuem boas práticas que podem ser adaptadas aos processos Modelo ágil: Melhoria de Processo no Desenvolvimento Ágil São adaptados com mais frequência e de forma não sistematizada O desenvolvimento é baseado em um ambiente com mudanças frequentes Cada projeto pode ter suas adaptações

38 Implantação de processos Modelo tradicional: Busca a melhoria de processo como um todo, abordando o processo organizacional Podem escolher a abordagem Big-Bem ou por pedaços Modelo ágil: Melhoria de Processo no Desenvolvimento Ágil Mudanças ocorrem normalmente como um todo em vez de partes

39 Medição Método tradicional: Entender o desenvolvimento e manutenção Controlar projetos Melhorar processos e produtos São baseados nas fases, atividades e produtos desenvolvidos ao longo do projeto Método ágil: Melhoria de Processo no Desenvolvimento Ágil Software funcionando é a primeira métrica de progresso

40 Experiência, conhecimento e aprendizado Modelo tradicional: Lições aprendidas em projetos correntes devem ser testadas em outros projetos e, se o resultado for positivo, o mesmo deve ser adicionado à base de conhecimento da organização É analisado em que contexto este resultado pode ser reproduzido Modelo ágil: Melhoria de Processo no Desenvolvimento Ágil Em intervalos regulares, o time deve refletir sobre como se tornar mais efetivo, então ajustar seu comportamento de acordo com a reflexão. A ênfase é dada ao aprendizado coletivo Os times são encorajados a mostrar seus erros e aprender com eles

41 Melhoria de Processo no Desenvolvimento Ágil - Considerações A MPS no desenvolvimento ágil é muito distinta daquela vista nos modelos tradicionais Pouco formalismo e forma não sistemática É focada na melhoria do comportamento em ambientes de mudanças constantes Os times podem se auto-organizar para se adaptar a uma situação

42 CMMI Capabiliy Maturity Model Integration SW-CMM criado pelo SEI (Software Engineering Institute) e -encomendado pelo Pentágono Foi criado focando no processo de engenharia de software Melhoria contínua Buscando a disciplina e controle no desenvolvimento e manutenção É uma das principais referências de modelo de qualidade

43 CMMI Capabiliy Maturity Model Integration Observou-se com o passar do tempo que poderia ser aplicado em outras disciplinas: Engenharia de sistemas Aquisição de software Gestão e desenvolvimento de mão-de-obra Desenvolvimento integrado de produtos e processos Em 2000, foi criado o primeiro modelo CMMI, combinando suas várias disciplinas em uma única estrutura, flexível e componentizada

44 CMMI Capabiliy Maturity Model Integration

49 CMMI Capabiliy Maturity Model Integration Definição e objetivos É um modelo de maturidade de melhoria de processos para desenvolvimento de produtos e serviços Apresenta as melhoras práticas voltadas para atividades de desenvolvimento e manutenção Abrange todo o ciclo de vida, desde a concepção até a manutenção Envolve a avaliação da maturidade da organização, a capacitação das suas áreas de processo, estabelecimento de prioridades e a implementação de ações de melhorias

50 CMMI Capabiliy Maturity Model Integration Constelações CMMI for Development CMMI-DEV CMMI for Services CMMI-SVC CMMI for Acquisition CMMI-ACQ Processos: Monitoração Medição Gerenciamento Serviços: Entrega Interna Entrega Externa Produtos e Serviços: Aquisição

51 CMMI Capabiliy Maturity Model Integration Componentes do Modelo Componentes Requeridos Componentes Esperados Componentes Informativos O que devemos fazer para satisfazer uma área do processo? O que podemos implementar para alcançar um componente requerido? Como podemos começar a se aproximar dos componentes requeridos e esperados? Metas (específicas e genéricas) Práticas Produtos de Trabalho e subpráticas

53 CMMI Capabiliy Maturity Model Integration O propósito da área de processo denominada Definição do Processo Organizacional (OPD) é Estabelecer e manter um conjunto utilizável de ativos de processos organizacionais, padrões no ambiente de trabalho, e as regras e diretrizes para as equipes."

54 CMMI Capabiliy Maturity Model Integration Um exemplo das notas introdutórias do Controle e Monitoração do Projeto é: "Quando o estado atual se desvia significativamente dos valores esperados, medidas adequadas devem ser tomadas como ações corretivas"

55 CMMI Capabiliy Maturity Model Integration Um exemplo de uma referência encontrada na seção Áreas de Processo Relacionadas da área de processo Planejamento do Projeto é "Consulte a área de processo Gestão de Riscos para obter mais informações sobre a identificação,análise de riscos e mitigação de riscos."

56 CMMI Capabiliy Maturity Model Integration Uma das metas ou objetivos específicos da área de processo Gerenciamento de Configuração é "integridade das baselines é estabelecida e mantida."

57 CMMI Capabiliy Maturity Model Integration Um exemplo de uma meta ou objetivo genérico é: "O processo é institucionalizado como um processo definido."

58 CMMI Capabiliy Maturity Model Integration Uma prática específicas na área de Controle e Monitoração do Projeto é: Monitorar os compromissos confome identificados no plano de projeto.

59 CMMI Capabiliy Maturity Model Integration Uma prática genérica para o objetivo genérico O processo é institucionalizado como um processo definido é Disponibilizar recursos adequados para executar o processo, desenvolvendo os produtos do trabalho e fornecer os serviços do processo

60 CMMI Capabiliy Maturity Model Integration Um produto de trabalho para a prática específica Monitorar parâmetros do planejamento do projeto na área de processo denominada Controle e Monitoração do projeto é Registros dos desvios significativos

61 CMMI Capabiliy Maturity Model Integration Uma subprática para a prática especifica tomar uma ação corretiva na área de processo denominada Controle Monitoração do Projeto é Determinar e documentar as ações apropriadas necessárias para enfrentar os problemas identificados

62 CMMI Capabiliy Maturity Model Integration uma elaboração de prática genérica depois da prática genérica "Estabelecer e manter uma política organizacional para planejar e executar o processo" para a área de processo Planejamento do Projeto é "Esta política estabelece expectativas organizacionais para estimar os parâmetros de planejamento, tomada de compromissos internos e externos, e desenvolver o plano de gerenciamento do projeto. "

64 CMMI Capabiliy Maturity Model Integration Nível Níveis de Capacidade da Abordagem Contínua Níveis de Maturidade da Abordagem por Estágios Nível 0 Incompleto --- Nível 1 Executado Inicial Nível 2 Gerenciado Gerenciado Nível 3 Definido Definido Nível Gerenciado Quantitativamente Nível Otimizando

67 CMMI Capabiliy Maturity Model Integration Nível Níveis de Capacidade da Abordagem Contínua Níveis de Maturidade da Abordagem por Estágios Nível 0 Incompleto --- Nível 1 Executado Inicial Nível 2 Gerenciado Gerenciado Nível 3 Definido Definido Nível Gerenciado Quantitativamente Nível Otimizando Um processo incompleto é um processo que, ou não é executado ou está parcialmente cumprido. Um ou mais dos objetivos específicos da área de processo não está satisfeito e não existem objetivos genéricos para este nível, pois não há razão para institucionalizar um processo parcialmente cumprido.

68 CMMI Capabiliy Maturity Model Integration Nível Níveis de Capacidade da Abordagem Contínua Níveis de Maturidade da Abordagem por Estágios Nível 0 Incompleto --- Nível 1 Executado Inicial Nível 2 Gerenciado Gerenciado Nível 3 Definido Definido Nível Gerenciado Quantitativamente Nível Otimizando Na capacidade de nível 1, o processo é caracterizado como um processo executado. Um processo executado é um processo que realiza o trabalho necessário para produzir produtos de trabalho, os objetivos específicos da área de processo estão satisfeitos.

69 CMMI Capabiliy Maturity Model Integration Nível Níveis de Capacidade da Abordagem Contínua Níveis de Maturidade da Abordagem por Estágios Nível 0 Incompleto --- Nível 1 Executado Inicial Nível 2 Gerenciado Gerenciado Nível 3 Definido Definido Nível Gerenciado Quantitativamente Nível Otimizando Na capacidade de nível 2, o processo é caracterizado como um processo gerenciado. Um processo gerenciado é um processo executado que é planejado e executado de acordo com uma política; emprega pessoas qualificadas e tem recursos adequados para produzir saídas controladas; envolve as partes interessadas; é monitorado, controlado e revisto, e é avaliada para a adesão à sua descrição do processo.

70 CMMI Capabiliy Maturity Model Integration Nível Níveis de Capacidade da Abordagem Contínua Níveis de Maturidade da Abordagem por Estágios Nível 0 Incompleto --- Nível 1 Executado Inicial Nível 2 Gerenciado Gerenciado Nível 3 Definido Definido Nível Gerenciado Quantitativamente Nível Otimizando Na capacidade de nível 3, o processo é caracterizado como um processo definido. Um processo definido é um processo gerenciado que é adaptado do conjunto da organização de processos padronizados de acordo com as diretrizes da organização; tem uma descrição do processo mantida; e contribui com as experiências relatadas para os ativos de processos organizacionais.

71 CMMI Capabiliy Maturity Model Integration Nível Níveis de Capacidade da Abordagem Contínua Níveis de Maturidade da Abordagem por Estágios Nível 0 Incompleto --- Nível 1 Executado Inicial Nível 2 Gerenciado Gerenciado Nível 3 Definido Definido Nível Gerenciado Quantitativamente Nível Otimizando Na nível de maturidade 1, os processos são caóticos. A organização geralmente não fornecem um ambiente estável para apoiar os processos. Sucesso nestas organizações depende da competência e heroísmo das pessoas na organização e não sobre o uso de processos comprovados. Apesar do caos, a maturidade de nível 1 nas organizações muitas vezes produz produtos e serviços que funcionam, mas eles freqüentemente ultrapassam o orçamento e cronograma documentados nos seus planos. No nível de maturidade 1 as organizações são caracterizadas por uma tendência de abandonar os seus processos em tempo de crise, e ser incapaz de repetir seus sucessos.

72 CMMI Capabiliy Maturity Model Integration Nível Níveis de Capacidade da Abordagem Contínua Níveis de Maturidade da Abordagem por Estágios Nível 0 Incompleto --- Nível 1 Executado Inicial Nível 2 Gerenciado Gerenciado Nível 3 Definido Definido Nível Gerenciado Quantitativamente Nível Otimizando No nível de maturidade 2, os projetos têm garantido que os processos são planejados e executados de acordo com a política, os projetos empregam pessoas qualificadas que tenham recursos adequados para produzir saídas controladas; envolver as partes interessadas relevantes; são monitorados, controlados e revisados, e são avaliados para aderência às descrições de seu processo. A disciplina de processo refletida por nível de maturidade 2 ajuda a garantir que as práticas existentes são mantidas durante os períodos de stress. Quando estas práticas estão no local, os projetos são executados e geridos de acordo com seus planos documentados. Também no nível de maturidade 2, o status dos produtos de trabalho são visíveis para a gestão em pontos definidos (por exemplo, nos marcos principais, após a conclusão das tarefas principais). Compromissos são estabelecidos entre as partes interessadas relevantes e são revisados conforme necessário. Produtos de trabalho são controlados adequadamente. Os produtos de trabalho e serviços de satisfazer as suas descrições de processo especificadas, normas e procedimentos.

73 CMMI Capabiliy Maturity Model Integration Nível Níveis de Capacidade da Abordagem Contínua Níveis de Maturidade da Abordagem por Estágios Nível 0 Incompleto --- Nível 1 Executado Inicial Nível 2 Gerenciado Gerenciado Nível 3 Definido Definido Nível Gerenciado Quantitativamente Nível Otimizando No nível de maturidade 3, os processos são bem caracterizados e compreendidos, e estão descritos nas normas, procedimentos, ferramentas e métodos. Define os processos padrões da organização, que é a base para o nível de maturidade 3, é estabelecido e melhorado ao longo do tempo. Estes processos padrões são usados para estabelecer coerência em toda a organização. Projetos estabelecem seus processos definidos de acordo com os processos padronizados da organização.

74 CMMI Capabiliy Maturity Model Integration Nível Níveis de Capacidade da Abordagem Contínua Níveis de Maturidade da Abordagem por Estágios Nível 0 Incompleto --- Nível 1 Executado Inicial Nível 2 Gerenciado Gerenciado Nível 3 Definido Definido Nível Gerenciado Quantitativamente Nível Otimizando No nível de maturidade 4, a organização e projetos estabelecem objetivos quantitativos para a qualidade e o desempenho de processos e usá-los como critérios na gestão de projetos. Objetivos quantitativos são baseados nas necessidades do cliente, os usuários finais, organização e implementadores do processo. Desempenho de qualidade e processo é entendido em termos estatísticos e é gerido ao longo da vida de projetos.

75 CMMI Capabiliy Maturity Model Integration Nível Níveis de Capacidade da Abordagem Contínua Níveis de Maturidade da Abordagem por Estágios Nível 0 Incompleto --- Nível 1 Executado Inicial Nível 2 Gerenciado Gerenciado Nível 3 Definido Definido Nível Gerenciado Quantitativamente Nível Otimizando No nível de maturidade 5, uma organização melhora continuamente seus processos com base em um entendimento quantitativo dos seus objetivos de negócio e as necessidades de desempenho. A organização utiliza uma abordagem quantitativa para entender a variação inerente ao processo e as causas dos resultados do processo.

76 CMMI Capabiliy Maturity Model Integration Resultados obtidos com a implementação do CMMI

77 MPS.BR

78 MPS.BR

79 MPS.BR

80 MPS.BR

81 MPS.BR

82 Até a próxima! Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Prof. Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com 82