SlideShare uma empresa Scribd logo
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
1 - Introdução
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
7
8
Vamos começar pelo básico...
O que é qualidade?
9
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
15
Tá... mas e o CMMI?
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
17
Voltando no tempo...
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
22
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
31
Então o CMMI foi criado!
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
2 - Representações do CMMI
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
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.
40
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.
41
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.
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
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.
45
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.
46
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.
47
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.
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
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.
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
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.
52
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.
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
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.
56
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.
57
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).
58
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.
59
3 – Vantagens do CMMI
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
4 – Desvantagens do CMMI
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
5 – MPS.BR
• 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
69
Níveis de Maturidade
6 – MPS.BR vs CMMI
• 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
72
CMMI vs MPS.BR
7 – TOGAF
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.
Visão Geral
84
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.
Espírito Santo Informática
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
Espírito Santo Informática
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
Espírito Santo Informática
89
Nível de Maturidade Nº de meses (Média)
Nível 1 para Nível 2 19
Nível 2 para Nível 3 20
Nível 3 para Nível 4 25
Nível 4 para Nível 5 13
Espírito Santo Informática
90
Grande resistência por parte dos colaboradores!
Espírito Santo Informática
91
Pós CMMI - Problemas resolvidos e certificação.
Espírito Santo Informática
92
Mais processos formais, menos tempo!
Espírito Santo Informática
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
DÚVIDAS?
OBRIGADO!

Mais conteúdo relacionado

Mais procurados

Aula 4- Engenharia de Software
Aula 4- Engenharia de SoftwareAula 4- Engenharia de Software
Aula 4- Engenharia de Software
Rudson Kiyoshi Souza Carvalho
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
Luís Fernando Richter
 
1 requisitos funcionais e não funcionais ok
1  requisitos funcionais e não funcionais ok1  requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais okMarcos Morais de Sousa
 
Apresentação CMMi
Apresentação CMMiApresentação CMMi
Apresentação CMMi
Fabio Barnes
 
Gerenciamento de Integracao - Aula 1
Gerenciamento de Integracao - Aula 1Gerenciamento de Integracao - Aula 1
Gerenciamento de Integracao - Aula 1
Luthiano Vasconcelos
 
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOKAula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
Daniela Brauner
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
Marcelo Yamaguti
 
Gerenciamento de projetos aula 13 (riscos)
Gerenciamento de projetos   aula 13 (riscos)Gerenciamento de projetos   aula 13 (riscos)
Gerenciamento de projetos aula 13 (riscos)
Paulo Junior
 
Gestão da Tecnologia da Informação - Atividade: Governança de TI
Gestão da Tecnologia da Informação - Atividade: Governança de TIGestão da Tecnologia da Informação - Atividade: Governança de TI
Gestão da Tecnologia da Informação - Atividade: Governança de TI
Alessandro Almeida
 
As 7 novas ferramentas da qualidade
As 7 novas ferramentas da qualidadeAs 7 novas ferramentas da qualidade
As 7 novas ferramentas da qualidade
José Daniel Barros
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
Daniel Brandão
 
SOA - Uma Breve Introdução
SOA - Uma Breve IntroduçãoSOA - Uma Breve Introdução
SOA - Uma Breve Introdução
André Borgonovo
 
Gestão por processos
Gestão por processosGestão por processos
Gestão por processos
Coelho Assessoria
 
Extreme Programming (XP) e Scrum
Extreme Programming (XP) e ScrumExtreme Programming (XP) e Scrum
Extreme Programming (XP) e Scrum
Rafael Souza
 
Gestão de Projetos - 2. Processos de Iniciação
Gestão de Projetos - 2. Processos de IniciaçãoGestão de Projetos - 2. Processos de Iniciação
Gestão de Projetos - 2. Processos de Iniciação
elonvila
 
CMMI
CMMICMMI
Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1
Adriano Tavares
 
PMI, PMBOK, MPS.Br, CMMI, TOGAF e Certificações
PMI, PMBOK, MPS.Br, CMMI, TOGAF e CertificaçõesPMI, PMBOK, MPS.Br, CMMI, TOGAF e Certificações
PMI, PMBOK, MPS.Br, CMMI, TOGAF e Certificações
Antonio Carlos Jr.
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
Mauricio Cesar Santos da Purificação
 
PMBOK
PMBOKPMBOK

Mais procurados (20)

Aula 4- Engenharia de Software
Aula 4- Engenharia de SoftwareAula 4- Engenharia de Software
Aula 4- Engenharia de Software
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
 
1 requisitos funcionais e não funcionais ok
1  requisitos funcionais e não funcionais ok1  requisitos funcionais e não funcionais ok
1 requisitos funcionais e não funcionais ok
 
Apresentação CMMi
Apresentação CMMiApresentação CMMi
Apresentação CMMi
 
Gerenciamento de Integracao - Aula 1
Gerenciamento de Integracao - Aula 1Gerenciamento de Integracao - Aula 1
Gerenciamento de Integracao - Aula 1
 
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOKAula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Gerenciamento de projetos aula 13 (riscos)
Gerenciamento de projetos   aula 13 (riscos)Gerenciamento de projetos   aula 13 (riscos)
Gerenciamento de projetos aula 13 (riscos)
 
Gestão da Tecnologia da Informação - Atividade: Governança de TI
Gestão da Tecnologia da Informação - Atividade: Governança de TIGestão da Tecnologia da Informação - Atividade: Governança de TI
Gestão da Tecnologia da Informação - Atividade: Governança de TI
 
As 7 novas ferramentas da qualidade
As 7 novas ferramentas da qualidadeAs 7 novas ferramentas da qualidade
As 7 novas ferramentas da qualidade
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
 
SOA - Uma Breve Introdução
SOA - Uma Breve IntroduçãoSOA - Uma Breve Introdução
SOA - Uma Breve Introdução
 
Gestão por processos
Gestão por processosGestão por processos
Gestão por processos
 
Extreme Programming (XP) e Scrum
Extreme Programming (XP) e ScrumExtreme Programming (XP) e Scrum
Extreme Programming (XP) e Scrum
 
Gestão de Projetos - 2. Processos de Iniciação
Gestão de Projetos - 2. Processos de IniciaçãoGestão de Projetos - 2. Processos de Iniciação
Gestão de Projetos - 2. Processos de Iniciação
 
CMMI
CMMICMMI
CMMI
 
Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1
 
PMI, PMBOK, MPS.Br, CMMI, TOGAF e Certificações
PMI, PMBOK, MPS.Br, CMMI, TOGAF e CertificaçõesPMI, PMBOK, MPS.Br, CMMI, TOGAF e Certificações
PMI, PMBOK, MPS.Br, CMMI, TOGAF e Certificações
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
PMBOK
PMBOKPMBOK
PMBOK
 

Destaque

Planeamento Temporal E Monitorização do Projecto de SW
Planeamento Temporal E Monitorização do Projecto de SW Planeamento Temporal E Monitorização do Projecto de SW
Planeamento Temporal E Monitorização do Projecto de SW
Rogerio P C do Nascimento
 
Gestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e PlanificaçõesGestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e Planificações
Rogerio P C do Nascimento
 
Métricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de SoftwareMétricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de Software
Rogerio P C do Nascimento
 
Gestão de Configuração de Software
Gestão de Configuração de Software Gestão de Configuração de Software
Gestão de Configuração de Software
Rogerio P C do Nascimento
 
Ferramentas CASE
Ferramentas  CASEFerramentas  CASE
Ferramentas CASE
Rogerio P C do Nascimento
 
CMM – Capability Maturity Model
CMM – Capability Maturity Model CMM – Capability Maturity Model
CMM – Capability Maturity Model
alef menezes
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de Software
Matheus Mendonça
 
Risk Management by Roger Pressman
Risk Management by Roger PressmanRisk Management by Roger Pressman
Risk Management by Roger Pressman
Rogerio P C do Nascimento
 
Gestão de Riscos by Lacertae SW
Gestão de Riscos by Lacertae SWGestão de Riscos by Lacertae SW
Gestão de Riscos by Lacertae SW
Rogerio P C do Nascimento
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
Instituto Federal de Sergipe
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
Matheus Costa
 
Aula 2 - Planning for Web Engineering by Roger Pressman
Aula 2 -  Planning for Web Engineering by Roger PressmanAula 2 -  Planning for Web Engineering by Roger Pressman
Aula 2 - Planning for Web Engineering by Roger Pressman
Rogerio P C do Nascimento
 
Planificação do Projeto de Software
Planificação do Projeto de SoftwarePlanificação do Projeto de Software
Planificação do Projeto de Software
Rogerio P C do Nascimento
 
Plano de Projeto
Plano de ProjetoPlano de Projeto
Plano de Projeto
Anne Caroline
 
Plano deprojeto grupo1
Plano deprojeto grupo1Plano deprojeto grupo1
Plano deprojeto grupo1
Jéssica Silveira
 
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SWAula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
Rogerio P C do Nascimento
 
Aula 2 - Planning Practices by Roger Pressman
Aula 2 - Planning Practices by Roger PressmanAula 2 - Planning Practices by Roger Pressman
Aula 2 - Planning Practices by Roger Pressman
Rogerio P C do Nascimento
 
Aula 1 - Project Management Concepts by Roger Pressman
Aula 1 - Project Management Concepts by Roger PressmanAula 1 - Project Management Concepts by Roger Pressman
Aula 1 - Project Management Concepts by Roger Pressman
Rogerio P C do Nascimento
 
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - KanbanMetodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Matheus Costa
 
IT-CMF Overview
IT-CMF OverviewIT-CMF Overview
IT-CMF Overview
Vishal Sharma
 

Destaque (20)

Planeamento Temporal E Monitorização do Projecto de SW
Planeamento Temporal E Monitorização do Projecto de SW Planeamento Temporal E Monitorização do Projecto de SW
Planeamento Temporal E Monitorização do Projecto de SW
 
Gestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e PlanificaçõesGestão de Projectos de SW OO Métricas Estimações e Planificações
Gestão de Projectos de SW OO Métricas Estimações e Planificações
 
Métricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de SoftwareMétricas para o Processo e o Projecto de Software
Métricas para o Processo e o Projecto de Software
 
Gestão de Configuração de Software
Gestão de Configuração de Software Gestão de Configuração de Software
Gestão de Configuração de Software
 
Ferramentas CASE
Ferramentas  CASEFerramentas  CASE
Ferramentas CASE
 
CMM – Capability Maturity Model
CMM – Capability Maturity Model CMM – Capability Maturity Model
CMM – Capability Maturity Model
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de Software
 
Risk Management by Roger Pressman
Risk Management by Roger PressmanRisk Management by Roger Pressman
Risk Management by Roger Pressman
 
Gestão de Riscos by Lacertae SW
Gestão de Riscos by Lacertae SWGestão de Riscos by Lacertae SW
Gestão de Riscos by Lacertae SW
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE  para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
Aula 2 - Planning for Web Engineering by Roger Pressman
Aula 2 -  Planning for Web Engineering by Roger PressmanAula 2 -  Planning for Web Engineering by Roger Pressman
Aula 2 - Planning for Web Engineering by Roger Pressman
 
Planificação do Projeto de Software
Planificação do Projeto de SoftwarePlanificação do Projeto de Software
Planificação do Projeto de Software
 
Plano de Projeto
Plano de ProjetoPlano de Projeto
Plano de Projeto
 
Plano deprojeto grupo1
Plano deprojeto grupo1Plano deprojeto grupo1
Plano deprojeto grupo1
 
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SWAula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
Aula2 TEES UFS: Fases de Engenharia de SW e Gestão de Projectos de SW
 
Aula 2 - Planning Practices by Roger Pressman
Aula 2 - Planning Practices by Roger PressmanAula 2 - Planning Practices by Roger Pressman
Aula 2 - Planning Practices by Roger Pressman
 
Aula 1 - Project Management Concepts by Roger Pressman
Aula 1 - Project Management Concepts by Roger PressmanAula 1 - Project Management Concepts by Roger Pressman
Aula 1 - Project Management Concepts by Roger Pressman
 
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - KanbanMetodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
 
IT-CMF Overview
IT-CMF OverviewIT-CMF Overview
IT-CMF Overview
 

Semelhante a Slide apresentação CMMI-TOGAF

QUALIDADE DE SOFTWARE
QUALIDADE DE SOFTWAREQUALIDADE DE SOFTWARE
QUALIDADE DE SOFTWARE
CarlosDaniloLuz2
 
PLM-Summit 2014 | 8-9 abril | Apresentação 07/14 | Evandro Gama | Cadware-Tec...
PLM-Summit 2014 | 8-9 abril | Apresentação 07/14 | Evandro Gama | Cadware-Tec...PLM-Summit 2014 | 8-9 abril | Apresentação 07/14 | Evandro Gama | Cadware-Tec...
PLM-Summit 2014 | 8-9 abril | Apresentação 07/14 | Evandro Gama | Cadware-Tec...
CADWARE-TECHNOLOGY
 
Aula 07 qs - cmmi
Aula 07   qs - cmmiAula 07   qs - cmmi
Aula 07 qs - cmmi
Junior Gomes
 
Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2
Fernando Vargas
 
CMMI 7
CMMI 7CMMI 7
CMMI 7
Aleh Santos
 
FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010
nathan85
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
Tiago Antônio da Silva
 
Outras Metodologias Ágeis Parte 3
Outras Metodologias Ágeis Parte 3Outras Metodologias Ágeis Parte 3
Outras Metodologias Ágeis Parte 3
Elaine Cecília Gatto
 
Isa Show 2009 Cr 259.09 Francisco Salvador
Isa Show 2009   Cr 259.09   Francisco SalvadorIsa Show 2009   Cr 259.09   Francisco Salvador
Isa Show 2009 Cr 259.09 Francisco Salvador
Francisco Salvador
 
Cmmi e mps.Br
Cmmi e mps.BrCmmi e mps.Br
Cmmi e mps.Br
Jefferson Bessa
 
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"
Alessandro Almeida
 
Apres. eng. de software
Apres. eng. de softwareApres. eng. de software
Apres. eng. de software
William Gomes
 
CMMI
CMMICMMI
Aula 25 - CMMI.ppt
Aula 25 - CMMI.pptAula 25 - CMMI.ppt
Aula 25 - CMMI.ppt
GustavoBarrosLins1
 
CMMI: Para além do desenvolvimento de Software - Carlos Sánchez Fernández (...
 CMMI: Para além do desenvolvimento de Software  - Carlos Sánchez Fernández (... CMMI: Para além do desenvolvimento de Software  - Carlos Sánchez Fernández (...
CMMI: Para além do desenvolvimento de Software - Carlos Sánchez Fernández (...
Paula Gomes
 
Melhoria de processos do software brasileiro
Melhoria de processos do software brasileiroMelhoria de processos do software brasileiro
Melhoria de processos do software brasileiro
ingrid_fatec
 
Introdução à Qualidade de Software
Introdução à Qualidade de SoftwareIntrodução à Qualidade de Software
Introdução à Qualidade de Software
Cloves da Rocha
 
Qualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normasQualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normas
Alex Camargo
 
CMM e CMMI
CMM e CMMICMM e CMMI
CMM e CMMI
felipegaraujo
 
CMM e CMMI
CMM e CMMICMM e CMMI

Semelhante a Slide apresentação CMMI-TOGAF (20)

QUALIDADE DE SOFTWARE
QUALIDADE DE SOFTWAREQUALIDADE DE SOFTWARE
QUALIDADE DE SOFTWARE
 
PLM-Summit 2014 | 8-9 abril | Apresentação 07/14 | Evandro Gama | Cadware-Tec...
PLM-Summit 2014 | 8-9 abril | Apresentação 07/14 | Evandro Gama | Cadware-Tec...PLM-Summit 2014 | 8-9 abril | Apresentação 07/14 | Evandro Gama | Cadware-Tec...
PLM-Summit 2014 | 8-9 abril | Apresentação 07/14 | Evandro Gama | Cadware-Tec...
 
Aula 07 qs - cmmi
Aula 07   qs - cmmiAula 07   qs - cmmi
Aula 07 qs - cmmi
 
Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2
 
CMMI 7
CMMI 7CMMI 7
CMMI 7
 
FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Outras Metodologias Ágeis Parte 3
Outras Metodologias Ágeis Parte 3Outras Metodologias Ágeis Parte 3
Outras Metodologias Ágeis Parte 3
 
Isa Show 2009 Cr 259.09 Francisco Salvador
Isa Show 2009   Cr 259.09   Francisco SalvadorIsa Show 2009   Cr 259.09   Francisco Salvador
Isa Show 2009 Cr 259.09 Francisco Salvador
 
Cmmi e mps.Br
Cmmi e mps.BrCmmi e mps.Br
Cmmi e mps.Br
 
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"
 
Apres. eng. de software
Apres. eng. de softwareApres. eng. de software
Apres. eng. de software
 
CMMI
CMMICMMI
CMMI
 
Aula 25 - CMMI.ppt
Aula 25 - CMMI.pptAula 25 - CMMI.ppt
Aula 25 - CMMI.ppt
 
CMMI: Para além do desenvolvimento de Software - Carlos Sánchez Fernández (...
 CMMI: Para além do desenvolvimento de Software  - Carlos Sánchez Fernández (... CMMI: Para além do desenvolvimento de Software  - Carlos Sánchez Fernández (...
CMMI: Para além do desenvolvimento de Software - Carlos Sánchez Fernández (...
 
Melhoria de processos do software brasileiro
Melhoria de processos do software brasileiroMelhoria de processos do software brasileiro
Melhoria de processos do software brasileiro
 
Introdução à Qualidade de Software
Introdução à Qualidade de SoftwareIntrodução à Qualidade de Software
Introdução à Qualidade de Software
 
Qualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normasQualidade de Software: Modelos e normas
Qualidade de Software: Modelos e normas
 
CMM e CMMI
CMM e CMMICMM e CMMI
CMM e CMMI
 
CMM e CMMI
CMM e CMMICMM e CMMI
CMM e CMMI
 

Slide apresentação CMMI-TOGAF

  • 1. 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
  • 2. GT3 - QUARENTA E DOIS UFS 2 www.quarentaedois-ufs.blogspot.com.br
  • 3. 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
  • 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. 5
  • 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. 6
  • 7. 7
  • 9. O que é qualidade? 9
  • 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; 10
  • 11. Qualidade • O conceito de qualidade é relativo. 11
  • 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). 12
  • 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. 13
  • 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. 14
  • 15. 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. 16
  • 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; 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"
  • 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. 19 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); 20
  • 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; 21
  • 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. 23
  • 24. Histórico: O CMM 24 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. 25
  • 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. 26
  • 27. Os 5 Níveis de Maturidade do CMM 27
  • 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; 28
  • 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. 29
  • 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. 30
  • 31. 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. 32
  • 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. 33
  • 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. 34
  • 36. Representações do CMMI Estágios: Níveis de Maturidade (Maturity Levels): 36
  • 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 37
  • 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. 38
  • 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. 39
  • 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. 40
  • 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. 41
  • 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. 42
  • 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. 43
  • 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. 44
  • 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. 45
  • 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. 46
  • 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. 47
  • 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. 48
  • 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. 49
  • 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. 50
  • 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. 51
  • 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. 52
  • 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. 53
  • 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. 54
  • 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. 55
  • 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. 56
  • 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. 57
  • 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). 58
  • 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. 59
  • 60. 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; 61
  • 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; 62
  • 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; 64
  • 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. 65
  • 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. 67
  • 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; 68
  • 70. 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. 71 CMMI vs MPS.BR
  • 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. 74
  • 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). 75
  • 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. 76
  • 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. 77
  • 78. 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.
  • 79. 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).
  • 80. 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.
  • 81. 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.
  • 82. 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).
  • 83. 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.
  • 85. 8 – Caso de Estudo ESI - Espírito Santo Informática
  • 86. 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. Espírito Santo Informática 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. Espírito Santo Informática 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. Espírito Santo Informática 89 Nível de Maturidade Nº de meses (Média) Nível 1 para Nível 2 19 Nível 2 para Nível 3 20 Nível 3 para Nível 4 25 Nível 4 para Nível 5 13
  • 90. Espírito Santo Informática 90 Grande resistência por parte dos colaboradores!
  • 91. Espírito Santo Informática 91 Pós CMMI - Problemas resolvidos e certificação.
  • 92. Espírito Santo Informática 92 Mais processos formais, menos tempo!
  • 93. Espírito Santo Informática 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
  • 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; 94
  • 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.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