CMMI e TOGAF

Capability Maturity Model
Integration (CMMI) e The Open
Group Architecture Framework
(TOGAF)
Edton Lemos
André Teixeira
Alef Menezes
Danilo Gois
Leandro Neto
UNIVERSIDADE FEDERAL DE SERGIPE
Departamento de Computação – DCOMP
Gerência de Projetos – T01 – 2016.2
Prof. Dr. Rogerio Patrício Chagas do
Nascimento

GT3 - QUARENTA E DOIS UFS
2
www.quarentaedois-ufs.blogspot.com.br

ROTEIRO
1. Introdução
a) Histórico
b) O CMMI
2. Representações do CMMI
3. Vantagens
4. Desvantagens
5. MPS.BR
6. CMMI e MPS.BR
7. TOGAF
8. Estudos de Caso e CMMI atualmente
3

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.
5

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.
6

8
Vamos começar pelo básico...

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;
10

Qualidade
• O conceito de qualidade é
relativo.
11

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).
12

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.
13

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.
14

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. 16

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;
18
Walter Andrew Shewhart
(New Canton, 18 de março de 1891 — 11 de março de 1967)
"pai do controle estatístico de qualidade"

Histórico
• Os princípios foram refinados por nomes como:
• Estenderam esses princípios ainda mais e começaram a aplicá-los
aos softwares.
19
William Edwards Deming Philip Crosby Joseph Juran

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);
20

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;
21

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.
23

Histórico: O CMM
24
Conceitos Experiência da comunidade de software

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.
25

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.
26

Os 5 Níveis de Maturidade do CMM
27

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;
28

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.
29

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.
30

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.
32

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.
33

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.
34

Representações do CMMI
Estágios: Níveis de Maturidade (Maturity Levels):
36

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
37

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.
38

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.
39

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.
40

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.
41

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.
42

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.
43

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.
44

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.
45

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.
46

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.
47

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.
48

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.
49

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.
50

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.
51

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.
52

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.
53

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.
54

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.
55

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.
56

Nível 3 – Definido
• O processo é adaptado com base no conjunto de processos
padronizados da organização.
Nível 4 - Controlado Quantitativamente
• A área de processo é controlada e melhorada usando medição e
avaliação quantitativa.
57

Nível 5 - Otimizado
• A área de processo é adaptada e otimizada usando meios
quantitativos (estatísticos).
58

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.
59

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;
61

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;
62

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;
64

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.
65

• 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.
67

• 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;
68

• 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.
71
CMMI vs MPS.BR

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.
74

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).
75

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.
76

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.
77

Método de Desenvolvimento de Arquitetura - ADM
78
• 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.

Técnicas e Orientações do ADM
79
• 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).

Framework de Conteúdo de Arquitetura
80
• Fornece um modelo detalhado dos produtos do trabalho de
arquitetura;
• Entregáveis, artefatos, Blocos de Construção de Arquitetura.

Continuum Corporativo
81
• 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.

Modelos de Referência do TOGAF
82
• Modelo de Referência Técnico (MRT);
• Modelo de Referência de Infraestrutura de Informação Integrada
(III-MR).

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

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

Espírito Santo Informática
86
• Diagnóstico de áreas CMMI
• Nível 2
• Nível 3
• Desenvolvimento de Requisitos;
• Verificação;
• Validação.

87
• 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
Fase Processo Período Visibilidade para
patrocinadores
Etapa 1 • Planejamento e definição 1º Quinzena de
Abril
Nenhuma
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
Nível de Maturidade Nº de meses (Média)
Nível 1 para Nível 2 19

90
Grande resistência por parte dos colaboradores!

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

92
Mais processos formais, menos tempo!

93
País Nível 1 Nível 2 Nível 3 Nível 4 Nível 5
Brasil 0 5 14 1 5
• CMMI Institute - 2016

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;
94

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.pd
f . 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;
95

CMMI e TOGAF

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie CMMI e TOGAF

Ähnlich wie CMMI e TOGAF (20)

CMMI e TOGAF