Slide apresentação CMMI-TOGAF

Post on 09-Apr-2017

75 views 3 download

Transcript of Slide apresentação CMMI-TOGAF

Capability Maturity Model Integration (CMMI) e The Open Group

Architecture Framework (TOGAF)

Edton LemosAndré TeixeiraAlef MenezesDanilo Gois

Leandro Neto

UNIVERSIDADE FEDERAL DE SERGIPEDepartamento de Computação – DCOMP

Gerência de Projetos – T01 – 2016.2Prof. Dr. Rogerio Patrício Chagas do

Nascimento

2

GT3 - QUARENTA E DOIS UFS

www.quarentaedois-ufs.blogspot.com.br

3

ROTEIRO1. Introdução

a) Histórico b) O CMMI

2. Representações do CMMI3. Vantagens 4. Desvantagens 5. MPS.BR6. CMMI e MPS.BR 7. TOGAF8. Estudos de Caso e CMMI atualmente

1 - Introdução

5

Introdução: CMMI

• Capability Maturity Model Integration (CMMI) - Modelo Integrado de Capacitação e Maturidade;

• Melhores práticas direcionadas ao desenvolvimento e à manutenção de produtos e dos serviços de software;

• Abrange todo o ciclo de vida do produto.

6

Introdução: CMMI

• Modelo de maturidade mais aceito no mundo;

• Quanto mais maduro forem os processos, maior será a qualidade obtida no produto final;

• Prevendo o comportamento dos processos, torna-se a organização mais madura e competitiva no mercado.

7

8

Vamos começar pelo básico...

9

O que é qualidade?

10

Qualidade:

• Característica particular de um objeto ou de um indivíduo (bom ou mau);

• Atributo que designa uma característica boa de algo ou de alguém;

• Característica superior ou atributo distintivo positivo que faz alguém ou algo sobressair em relação a outros;

11

Qualidade

• O conceito de qualidade é relativo.

12

Qualidade em Engenharia de Software

• Garantia da qualidade do software como um processo de normalização dos processos com o intuito de atendimento dos requisitos funcionais e não funcionais;

"Qualidade de software é a conformidade com requisitos funcionais e de desempenho explicitamente declarados,

padrões de desenvolvimento explicitamente documentados e características implícitas, que são esperadas em todo

software desenvolvido profissionalmente" (PRESSMAN, 2002).

13

Qualidade de software

• Obter qualidade no desenvolvimento de software e nos processos relacionados a ele não é uma tarefa fácil;

• É decepcionante entregar um software que não satisfaça as necessidades dos clientes;

• Problemas são derivados da falta de atenção para a tarefa de definir e acompanhar a evolução dos requisitos durante o processo de construção de software.

14

Qualidade de software

• Para lidar com qualidade, é necessário conhecer claramente que o processo de produção deve ter qualidade e que o produto deve incorporá-la;

• O objetivo na Engenharia de Software é a qualidade do produto de software;

• Organização Internacional de Padronização (ISO):• ISO/IEC 9000; • ISO/IEC 12207; • ISO/IEC 15504.

15

Tá... mas e o CMMI?

16

O CMMI:

• Não é uma norma;

• É um dos modelos de qualidade de software atualmente mais difundido no mundo;

• Não deve ser entendido como sendo uma metodologia, pois não diz exatamente como fazer, mas sim o que deve ser feito;

• O CMMI foi baseado nas melhores práticas para desenvolvimento e manutenção de produtos.

17

Voltando no tempo...

18

Histórico

• Na década de 1930, Walter Shewhart começou a trabalhar na melhoria de processos com os seus princípios de controle estatístico da qualidade;

Walter Andrew Shewhart (New Canton, 18 de março de 1891 — 11 de março de 1967)

"pai do controle estatístico de qualidade"

19

Histórico

• Os princípios foram refinados por nomes como:

• Estenderam esses princípios ainda mais e começaram a aplicá-los aos softwares.

William Edwards Deming  Philip Crosby  Joseph Juran

20

Histórico: O CMM

• Capability Maturity Model (CMM ou Modelo de Maturidade em Capacitação), também conhecido como Software CMM (SW-CMM);

• Surgiu durante a década de 1980;

• Modelo para avaliação de risco na contratação de empresas de software pelo Departamento de Defesa dos Estados Unidos (DoD);

21

Histórico: O CMM

• O DoD desejava ser capaz de avaliar os processos de desenvolvimento utilizados pelas empresas que concorriam em licitações;

• Servia como indicação da previsibilidade da qualidade, custos e prazos nos projetos contratados;

22

Histórico: O CMM

23

Histórico: O CMM

• O Software Engineering Institute (SEI) é um centro de pesquisa e desenvolvimento patrocinado pelo Departamento de Defesa dos Estados Unidos da América que provê uma prática avançada de Engenharia de Software qualificando graus de qualidade de software;

• O Capability Maturity Model, é uma representação simplificada do mundo que contêm os elementos essenciais dos processos eficazes.

24

Histórico: O CMM

Conceitos Experiência da comunidade de software

25

Histórico: O CMM

• Um modelo de maturidade é uma coleção estruturada de elementos que descrevem certos aspectos da maturidade de uma organização;

• Um modelo de maturidade fornece, por exemplo:• um ponto de partida;• os benefícios dos usuários em experiências anteriores;• um vocabulário comum e uma visão compartilhada;• um framework para priorizar ações;• uma forma de definir as melhorias mais significativas para uma

organização.

26

Histórico: O CMM

• Um modelo de maturidade pode ser usado como base para avaliar diferentes organizações e estabelecer comparações;

• O SEI adotou a premissa de gestão de processos: "a qualidade de um sistema ou o produto é

altamente influenciada pela qualidade do processo utilizado para desenvolvê-lo e mantê-lo"

• Definiu CMMs que incorporaram essa premissa.

27

Os 5 Níveis de Maturidade do CMM

28

Problemas!

• Durante o sucesso e o crescimento do CMM no mercado americano, por volta de 1991, diversos outros “CMMs” foram criados, procurando cobrir outras áreas de interesse;

29

Surgiram os modelos:

• Software Acquisition CMM (SA-CMM): usado para avaliar a maturidade de uma organização em seus processos de seleção, compra e instalação de software desenvolvido por terceiros.

• Systems Engineering CMM (SE-CMM): avalia a maturidade da organização em seus processos de Engenharia de Sistemas, concebidos como algo maior que o software.

• Integrated Product Development CMM (IPD-CMM): ainda mais abrangente que o SE-CMM, inclui também outros processos necessários à produção e suporte ao produto, tais como suporte ao usuário, processos de fabricação etc.

• People CMM (P-CMM): avalia a maturidade da organização em seus processos de administração de recurso humanos no que se refere a software; recrutamento e seleção de desenvolvedores, treinamento e desenvolvimento, remuneração etc.

30

Problemas!

• Embora estes modelos tenham mostrado sua utilidade, o uso de múltiplos modelos se mostrou problemático;

• Nem todos usavam a mesma terminologia, de modo que um mesmo conceito poderia receber nomes diferentes em cada modelo, ou que o mesmo termo quisesse dizer coisas diferentes nos vários modelos;

• A estrutura carecia de um formato padrão. Os modelos tinham diferentes números de níveis ou formas diferentes de avaliar o progresso;

• Altos custos de treinamento, avaliação e harmonização para organização que tentassem usar mais de um modelo.

31

Então o CMMI foi criado!

32

O CMMI: Objetivos

• Suprir as limitações do modelo CMM, com a criação de um framework comum, eliminando inconsistências e permitindo a inclusão de novos modelos ao longo do tempo, sempre que surgirem necessidades específicas;

• Unificar os vários modelos CMM existentes;

• Implementar melhorias no SW-CMM.

33

CMMI: Dimensões

• O CMMI foi construído considerando três dimensões principais: • Pessoas; • Ferramentas; e • Procedimentos.

• O processo serve para unir essas dimensões.

34

CMMI: Disciplinas

• O processo inclui três disciplinas ou corpos de conhecimento (body of knowledges), sendo elas:

• Engenharia de Sistemas;• Engenharia de Software;• Engenharia de Hardware.

2 - Representações do CMMI

36

Representações do CMMI

Estágios: Níveis de Maturidade (Maturity Levels):

37

Representações do CMMI

Contínua: Níveis de Capacidade (Capability Levels):• Nível 0: Incompleto (Ad-hoc)• Nível 1: Executado• Nível 2: Gerenciado• Nível 3: Definido• Nível 4: Gerenciado quantitativamente• Nível 5: Em otimização

38

Representação por Estágios - Nível 2 (Gerenciado)

• São estabelecidos processos básicos de gerenciamento de projeto e compromissos são firmados e gerenciados.

• Alguns procedimentos técnicos escritos. • Acompanhamento de qualidade.• Gerência de configuração inicial. • Atividades básicas de medição e análise.

39

Representação por Estágios - Nível 2 – Áreas de Processo

1. Gerência de Requisitos (RM)•Gerenciar os requisitos (mudanças, inconsistências, rastreabilidade) dos produtos e do projeto.

2.  Planejamento de Projeto (PP)•Estabelecer, desenvolver e manter planos que definem as atividades do projeto.

40

Representação por Estágios - Nível 2 – Áreas de Processo

3. Monitoramento e Controle do Projeto (PMC)•Oferecer um entendimento do progresso do projeto.

4 . Garantia da Qualidade do Processo e do Produto (PPQA)

•Entendimento objetivo dos processos e feedback para a equipe do projeto e gerentes.

41

Representação por Estágios - Nível 2 – Áreas de Processo

5. Gerência de acordo com fornecedores (SAM)•Gerenciar fornecedores externos (acordos, contrato).

6. Gerência de Configuração (CM)• Controlar as mudanças nos itens de configuração,

mantendo a integridade dos produtos de trabalho.

42

Representação por Estágios - Nível 2 – Áreas de Processo

7. Medição e Análise (MA)• Especificar os objetivos de medições e análises.• Implementar a coleta, armazenagem, análise e relatórios

sobre os dados.• Fornecer resultados objetivos.

43

Representação por Estágios - Nível 3 (Definido)

Os processos utilizados são estabelecidos e padronizados para a organização.• Processos são geralmente descritos de forma mais rigorosa

que no nível 2.• Adaptado para as necessidades do projeto.

44

Representação por Estágios - Nível 3 – Áreas Processo

1. Desenvolvimento de Requisitos (RD)• Produzir e analisar os requisitos de cliente, de produto e de

seus componentes.

2. Solução Técnica (TS)• Projetar, desenvolver e implementar soluções para

requisitos levantados.

45

Representação por Estágios - Nível 3 – Áreas Processo

3. Integração de Produtos (IP)• Montar o produto a partir dos seus componentes e garantir

que o produto integrado execute as funções de forma apropriada.

4 .Verificação (VER)• Assegurar que os componentes construídos atendem aos

requisitos especificados.

46

Representação por Estágios - Nível 3 – Áreas Processo

5. Validação (VAL)• Demonstrar que um produto ou componente de produto atende

ao seu uso pretendido quando colocado em seu ambiente alvo.6. Gerenciamento Integrado de Projetos (IPM)• Gerenciar os projetos de forma consistente utilizando indicadores

padronizados e informações da base histórica.7. Gerenciamento de Riscos (RSKM)• Identificar potenciais problemas antes que ocorram.• Tratar os riscos com mais rigor, reforçando ações de

contingência.

47

Representação por Estágios - Nível 3 – Áreas Processo

8. Foco no Processo Organizacional (OPF)• Planejar, implementar e implantar melhorias do processo

organizacional com base a compreensão dos pontos fortes e pontos fracos atuais dos processos.

9. Definição do Processo Organizacional (OPD)• Estabelecer e manter um conjunto de processo da

organização e padrões de ambiente de trabalho disponíveis para uso.

48

Representação por Estágios - Nível 3 – Áreas Processo

10. Treinamento Organizacional (OT)• Desenvolver as habilidades e o conhecimento da equipe.

11. Análise de Decisão e Resolução (DAR)• Decisões importantes são tomadas de maneira

estruturada.

49

Representação por Estágios - Nível 4 (Quantitativamente Gerenciado)

São estabelecidas metas quantitativas para os processos e produtos.•Medidas de qualidade e produtividade são coletadas em todos os projetos.•Controle estatístico de processos.•Gestão passa a ser feitas com bases quantitativas.

50

Representação por Estágios - Nível 4

1. Desempenho de Processo Organizacional - OPP (Organizational Process Performance)• Determinar se os processos estão se comportando de forma

consistente.• Identificar a implementação de um processo que funciona melhor.2. Gerenciamento Quantitativo de Projeto - QPM (Quantitative Project Management)•Gerenciar quantitativamente o processo definido do projeto.• Registrar dados de gerenciamento estatístico e de qualidade no

repositório de medidas da organização.

51

Representação por Estágios - Nível 5 (Otimização)

Organização está engajada na melhoria contínua de seus processos.•Identificação de pontos fracos e defeitos.•Ações preventivas sobre causas.•Mudanças mais significativas de processos e/ou tecnologias são feitas a partir de análise de custo/benefício com base em dados quantitativos.

52

Representação por Estágios - Nível 5

1. Inovação Organizacional - OID (Organizational Innovation and Deployment)

Selecionar e implementar melhorias incrementais e inovadoras significativas.• Qualidade, produtividade aumentada, maior satisfação. • Desenvolvimento ou tempo de produção mais curto.• Diminuir o tempo de entrega.

53

Representação por Estágios - Nível 5

2. Análise Causal e Resolução - CAR (Causal Analysis and Resolution)• Identificar causas de defeitos de problemas e tomar ações

para evitar que ocorram no futuro.

54

Representação por Estágios

Esta representação é indicada quando:

•Empresa já utiliza algum modelo de maturidade por estágios.

•Quando deseja utilizar o nível de maturidade alcançado para comparação com outras empresas.

•Quando pretende usar o nível de conhecimento obtido por outros para sua área de atuação.

55

Representação Contínua

Nível 0 - Incompleto• O processo não é executado ou é parcialmente executado.

Nível 1 - Executado• Todas as metas específicas da área de processo foram

satisfeitas.• Estão sendo executadas as tarefas necessárias para

produzir os artefatos definidos.

56

Representação Contínua

Nível 2 - Controlado• Todos os critérios do nível 1 foram satisfeitos.• Trabalho está de acordo com a política definida em termos da

organização.• Pessoas tem acesso a recursos adequados.• Os interessados são envolvidos ativamente na área de

processo.• Todas as tarefas e produtos são monitorados, controlados, e

revisados e avaliados quanto à conformidade com a descrição do processo.

57

Representação Contínua

Nível 3 – Definido• Todos os critérios do nível 2 foram satisfeitos.• O processo é adaptado com base no conjunto de processos

padronizados da organização.Nível 4 - Controlado Quantitativamente• Todos os critérios do nível 3 foram satisfeitos.• A área de processo é controlada e melhorada usando

medição e avaliação quantitativa.

58

Representação Contínua

Nível 5 - Otimizado• Todos os critérios do nível 4 foram satisfeitos.• A área de processo é adaptada e otimizada usando meios

quantitativos (estatísticos).

59

Representação Contínua

Esta representação é indicada quando:• Quando a empresa deseja tornar apenas alguns processos

mais maduros.• Quando já utiliza algum modelo de maturidade contínua.• Quando não pretende usar a maturidade alcançada como

modelo de comparação com outras empresas.

3 – Vantagens do CMMI

61

Vantagens do CMMI

• Modelo reconhecido internacionalmente (diferencial competitivo);

• Referência no mercado;• Desenvolvimento de software com qualidade

(prazo, custo e interesses dos clientes);• Eliminação de inconsistências e redução de

duplicidade;

62

Vantagens do CMMI

• Utilização de terminologia comum e estilo consistente;• Consistente com norma ISO/IEC 15504 (SPICE – Processo de

Desenvolvimento de Software);• Certificação com validade de 3 anos;

4 – Desvantagens do CMMI

64

Desvantagens do CMMI

• Modelo proprietário;• Auto custo para adoção/obtenção da

certificação;• Demanda alta de tempo para

adoção/obtenção da certificação;• Dificuldades que contrastam com a

realidade das empresas brasileiras;• Certificação com validade de 3 anos;

65

CMMI no Brasil

• Apesar de todas a vantagens e desvantagens observadas, devemos adotar o CMMI?• Depende de cada organização;• Depende do objetivo desejado;

• Modelo paralelo ao CMMI.

5 – MPS.BR

67

• MPS.BR - Melhoria do Processo de Software Brasileiro é um programa da Softex - Associação para Promoção da Excelência do Software Brasileiro, com apoio do Ministério de Ciência, Tecnologia, Inovações e Comunicação(MCTIC);

• Iniciou em 2003;• Objetiva-se melhorar:• capacidade de desenvolvimento de software;• serviços; e • as práticas de gestão na indústria de TIC.

68

• Vantagens• Mais rápido de ser adquirido;• Implantação mais gradual e adequada a pequenas e médias

empresas;• Compatível com o CMMI;• Integração entre universidade-empresa;• Custo reduzido;

• Desvantagens• Certificação não é suficiente para se tornar competitiva

internacionalmente;

69

Níveis de Maturidade

6 – MPS.BR vs CMMI

71

• Mesmo propósito, porém o foco de atuação dos modelos são diferentes um do outro.

• MPS.BR é um modelo criado em função das micro, pequenas e médias empresas;

• O CMMI tem um foco global mais voltado para as empresas de maior porte;

• Modelos complementares para atender a realidade brasileira; e

• No Brasil o MPS.BR é mais adotado que o CMMI.

CMMI vs MPS.BR

72

CMMI vs MPS.BR

7 – TOGAF

74

TOGAF - Introdução

• O TOGAF é um framework de arquitetura. É uma ferramenta para auxiliar a criar, detalhar, avaliar e construir uma arquitetura de TI;

• É um modelo conceitual de arquitetura corporativa, provendo uma linguagem comum de comunicação entre os arquitetos;

• Processo Iterativo;• Melhores Praticas;• Reutilização de Ativos de Arquiteturas.

75

TOGAF - Histórico

• Desenvolvido e mantido pelo Fórum de Arquitetura do The Open Group;

• Primeira versão em 1995;• Versão atual 9.1 publicada em 2011.• Em 2014 existiam 36.435 certificações pelo mundo (Brasil

184);• Em 2015 existiam 47.400 certificações pelo mundo (Brasil

248).

76

TOGAF - Divisão

• Introdução;• Método para o Desenvolvimento de Arquiteturas (ADM);• Técnicas e diretrizes associadas ao ADM;• Estruturas para conteúdo de arquitetura;• Ferramentas e o Enterprise Continuum;• Modelos de referência;• Framework das capacidades de arquitetura.

77

TOGAF - Tipos de Arquiteturas

• O TOGAF abrange o desenvolvimento de quatro tipos de arquiteturas que são subconjuntos de uma arquitetura corporativa total;

• Arquitetura de Negócio;• Arquitetura de Dados;• Arquitetura de Aplicativos;• Arquitetura de Tecnologia.

78

Método de Desenvolvimento de Arquitetura - ADM

• Descreve como obter uma arquitetura corporativa específica;

• O ADM é o principal componente do TOGAF;

• Fornece as fases de desenvolvimento de arquitetura;• Fornece uma narrativa de cada fase de arquitetura;• Fornece resumos das fases responsáveis pelo

gerenciamento de requisitos.

79

Técnicas e Orientações do ADM

• Fornece uma serie de instruções para apoiar a aplicação do ADM;

• Diversos cenários de uso;• Diferentes estilos de processos;• Determinadas arquiteturas de especialidades (segurança).

80

Framework de Conteúdo de Arquitetura

• Fornece um modelo detalhado dos produtos do trabalho de arquitetura;

• Entregáveis, artefatos, Blocos de Construção de Arquitetura.

81

Continuum Corporativo

• Fornece um modelo para estruturar um repositório virtual e métodos para classificar artefatos de arquitetura e de solução;

• Baseado em arquiteturas e soluções que existem dentro da organização e do seguimento da indústria em geral.

82

Modelos de Referência do TOGAF

• Modelo de Referência Técnico (MRT);• Modelo de Referência de Infraestrutura de Informação

Integrada (III-MR).

83

Framework de Capacidade de Arquitetura

• É um conjunto de recursos, orientações, templates, fornecidos para ajudar o arquiteto a estabelecer uma prática de arquitetura dentro de uma organização.

84

Visão Geral

8 – Caso de EstudoESI - Espírito Santo Informática

86

Espírito Santo Informática

• Diagnóstico de áreas CMMI• Nível 2

• Nível 3• Desenvolvimento de Requisitos;• Verificação;• Validação.

87

Espírito Santo Informática

• Problemas pré CMMI• Falta ou modelos diferentes de documentação dos

projetos• Falta de documentação e reúso de testes• Falha no entendimento dos requisitos

88

Espírito Santo Informática

Fase Processo Período Visibilidade para

patrocinadoresEtapa 1 • Planejamento e definição 1º Quinzena de

AbrilNenhuma

Etapa 2 • Gestão de Requisitos• Gestão de Projetos Set - Out 2007 Média

Etapa 3 • Subcontratação de Fornecedores

• Métricas• Gestão de

Configuraçãoes• Controle de Qualidade

Jan - Fev 2008 Baixa

89

Espírito Santo Informática

Nível de Maturidade Nº de meses (Média)Nível 1 para Nível 2 19Nível 2 para Nível 3 20Nível 3 para Nível 4 25Nível 4 para Nível 5 13

Espírito Santo Informática

90Grande resistência por parte dos colaboradores!

Espírito Santo Informática

91Pós CMMI - Problemas resolvidos e certificação.

Espírito Santo Informática

92Mais processos formais, menos tempo!

93

Espírito Santo Informática

País Nível 1 Nível 2 Nível 3 Nível 4 Nível 5Brasil 0 5 14 1 5

• CMMI Institute - 2016

94

REFERÊNCIAS BIBLIOGRAFICAS

• Princípios e valores CMMI. Disponível em: https://msdn.microsoft.com/pt-br/library/hh765978(v=vs.120).aspx. Acessado em 03 de março de 2017;

• CMMI para iniciantes . Disponível em: http://www.linhadecodigo.com.br/artigo/1401/cmmi-para-iniciantes.aspx. Acessado em 03 de março de 2017;

• http://www.opengroup.org/subjectareas/enterprise/togaf. Acessado em 03 de março de 2017;

• TOGAF®, an Open Group standard. Disponívem em: https://www.ibm.com/developerworks/community/blogs/tlcbr/entry/togaf. Acessado em 03 de março de 2017;

• Por que utilizar a Arquitetura Corporativa? Disponívem em: https://www.youtube.com/watch?v=FgQ3Mo00Oj0. Acessado em 03 de março de 2017;

95

Referencias

• Oliveira, Camila da Silva. Comparando CMMI x MPS.BR: as vantagens e desvantagens dos modelos de qualidade no Brasil;

• Softex. MPS.BR. Disponível em: http://www.softex.br/mpsbr/. Acessado em 03 de março de 2017;

• Devmedia. Maturidade no desenvolvimento de software: CMMI e MPS-BR. Disponível em: http://www.devmedia.com.br/maturidade-no-desenvolvimento-de-software-cmmi-e-mps-br/27010. Acessado em 03 de março de 2017;

• Repositório da UTAD. Disponível em: https://repositorio.utad.pt/bitstream/10348/204/1/msc_metliberato.pdf . Acessado em 03 de março de 2017;

• CMMI Institute. Disponível em: https://sas.cmmiinstitute.com/pars/pars.aspx. Acessado em 03 de março de 2017;

DÚVIDAS?

OBRIGADO!