Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Slide apresentação CMMI-TOGAF

421 views

Published on

Apresentação do seminário realizado em sala para a disciplina de Gestão de Projetos da UFS 2016.2

Published in: Technology
  • Be the first to comment

Slide apresentação CMMI-TOGAF

  1. 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. 2. GT3 - QUARENTA E DOIS UFS 2 www.quarentaedois-ufs.blogspot.com.br
  3. 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
  4. 4. 1 - Introdução
  5. 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. 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. 7
  8. 8. 8 Vamos começar pelo básico...
  9. 9. O que é qualidade? 9
  10. 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. 11. Qualidade • O conceito de qualidade é relativo. 11
  12. 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. 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. 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. 15 Tá... mas e o CMMI?
  16. 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
  17. 17. 17 Voltando no tempo...
  18. 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. 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. 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. 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
  22. 22. Histórico: O CMM 22
  23. 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. 24. Histórico: O CMM 24 Conceitos Experiência da comunidade de software
  25. 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. 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. 27. Os 5 Níveis de Maturidade do CMM 27
  28. 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. 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. 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. 31 Então o CMMI foi criado!
  32. 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. 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. 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
  35. 35. 2 - Representações do CMMI
  36. 36. Representações do CMMI Estágios: Níveis de Maturidade (Maturity Levels): 36
  37. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 60. 3 – Vantagens do CMMI
  61. 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. 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
  63. 63. 4 – Desvantagens do CMMI
  64. 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. 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
  66. 66. 5 – MPS.BR
  67. 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. 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
  69. 69. 69 Níveis de Maturidade
  70. 70. 6 – MPS.BR vs CMMI
  71. 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
  72. 72. 72 CMMI vs MPS.BR
  73. 73. 7 – TOGAF
  74. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
  84. 84. Visão Geral 84
  85. 85. 8 – Caso de Estudo ESI - Espírito Santo Informática
  86. 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. 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. 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. 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. 90. Espírito Santo Informática 90 Grande resistência por parte dos colaboradores!
  91. 91. Espírito Santo Informática 91 Pós CMMI - Problemas resolvidos e certificação.
  92. 92. Espírito Santo Informática 92 Mais processos formais, menos tempo!
  93. 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. 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. 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
  96. 96. DÚVIDAS?
  97. 97. OBRIGADO!

×