Aula 2 Gerência de Projeto no Contexto do Modelo de Maturidade e Capacidade de Software - CMM.

Apresentação em tema: "Aula 2 Gerência de Projeto no Contexto do Modelo de Maturidade e Capacidade de Software - CMM."— Transcrição da apresentação:

1 Aula 2 Gerência de Projeto no Contexto do Modelo de Maturidade e Capacidade de Software - CMM

2 Agradecimentos Ao Prof. Alexandre Vasconcelos por permitir a cópia e utilização das transparências do restante desta aula. © Fabio Silva - DI-UFPE

3 Objetivos Introduzir os principais conceitos sobre o modelo de maturidade e capacidade do processo de software - CMM Situar a Gerência de Projeto de Software no contexto do CMM Conteúdo conceitos iniciais descrição do CMM projeto de software: planejamento e execução © Fabio Silva - DI-UFPE

4 Aplicando TQM (Total Quality Management) ao Software
CMM TQM Projeto B Projeto C Projeto A hardware software Organização Projeto X O CMM é um modelo desenvolvimento para aplicação específica ao software, dentro de um contexto de qualidade total no âmbito de uma organização. É uma estrutura, para avaliação e melhoria, aplicada somente ao processo de software. O processo de melhoria se aplica em todo o contexto do negócio - o CMM se aplica especificamente ao software. © Fabio Silva - DI-UFPE 4

5 Conceitos Fundamentais
Processo Capacidade Performance e Maturidade do Processo de Software © Fabio Silva - DI-UFPE 7

6 O que é um processo? processo - uma sequência de passos realizados para um determinado propósito. (IEEE) processo de software - um conjunto de atividades, métodos, práticas e tecnologias que as pessoas utilizam para desenvolver e manter software e produtos relacionados. (CMM) © Fabio Silva - DI-UFPE

7 Um Processo imaturo Ad hoc: processo improvisado por profissionais e gerências. Não é rigorosamente seguido e o cumprimento não é controlado. Altamente dependente dos profissionais atuais. Baixa visão do progresso e da qualidade. A funcionalidade e a qualidade do produto podem ficar comprometidas para que prazos sejam cumpridos. Arriscado do ponto de vista do uso de novas tecnologias Custos de manutenção muito altos. Qualidade difícil de se prever. Na nota de aula, CMU/SEI-93-TR-24, item 1.1, páginas 1 e 2, estão descritos os conceitos de uma organização ou processo imaturo. © Fabio Silva - DI-UFPE 8

8 Anatomia do Caos A maioria das organizações de
software estão “apagando incêndios” o fogo não está sob controle constantemente reagindo (e não agindo pró-ativamente) - não há tempo para melhoria os “ bombeiros” se queimam as cinzas podem voltar a se incendiar mais tarde sua única forma de controle - prevenção de incêndio Na nota de aula, CMU/SEI-93-TR-24, item 1.1, páginas 1 e 2, estão descritos os conceitos de uma organização ou processo imaturo. © Fabio Silva - DI-UFPE 9

9 Um Processo maduro Coerente com as linhas de ação, o trabalho é efetivamente concluído. Definido, documentado e melhorando constantemente. Com o apoio visível da alta administração e outras gerências. Bem controlado - fidelidade ao processo é objeto de auditoria e de controle. São utilizadas medições do produto e do processo. Uso disciplinado da tecnologia. Na nota de aula, CMU/SEI-93-TR-24, item 1.1, páginas 1 e 2, estão descritos os conceitos de uma organização ou processo maduro. © Fabio Silva - DI-UFPE 10

10 Definição Operacional - CMM
Nível de Maturidade Indica Capacidade Contém Atinge Áreas-chave de Processos Objetivos Organizadas em Enfatiza Características Comuns O CMM é composto de cinco níveis de maturidade. Com exceção do nível 1, cada nível de maturidade é composto de várias áreas -chave de processo (KPA). Cada área-chave de processo é organizada em 5 partes chamadas características comuns. A característica comum especifica as práticas-chave que, quando endereçadas coletivamente realiza as metas daquela KPA. O item 3.1 do CMU/SEI-93-TR-24, página 27, e o item 2.3 do CMU/SEI-93-TR-25, página O-8, descrevem os componentes CMM.. Implementação Contêm Descreve Praticas Chave Infraestrutura Atividades © Fabio Silva - DI-UFPE 11

11 5 Níveis de Maturidade Otimizando Gerenciado Definido Repetitível
Inicial Repetitível Definido Gerenciado Otimizando Processo disciplinado standard e consistente predizível Processo em otimização Processo caótico e ad hoc Processos estabelecidos por experiências anteriores Processos documentados, standard e integrados Medidas de qualidade Feedback Este diagrama representa graficamente os 5 níveis de maturidade definidos no modelo CMM.: Inicial, Repetível, Definido, Gerenciado e o de Otimização. Inicial - o processo de software possui poucos procedimentos definidos e ocasioanalmente é considerado caótico. Repetível - são estabelecidos alguns procedimentos para o gerenciamento do projeto. Definido - procedimentos para o gerenciamento e engenharia de software são padronizados e documentados. Gerenciado - são realizadas medições da qualidade dos processos e produtos de software. de Otimização - é possível uma melhoria contínua do processo atráves da realimentação dos resultados. O capítulo 2 - “The five levels of software process maturity” do CMM/SEI-93-TR-24, página 8, faz uma descrição sucinta dos níveis de maturidade. © Fabio Silva - DI-UFPE 13

12 Evolução do processo 5 4 3 2 1 Otimizado Gerenciado Definido Repetível
Melhoria do processo é institucionalizada. Inicial Produto e processo são con- trolados quantitativamente. Engenharia de software e gerenciamento de processos definidos e integrados. Sistema de gerenciamento de projetos em vigor; desempenho é repetido. Processo é informal e imprevisível. Nível Características do processo 1 2 3 4 5 O quadro deste slide mostra os níveis de maturidade, sua caracterização e a previsibilidade do desempenho do processo ou organização de acordo com o nível de maturidade onde se encontra. O item 2.4 do CMU/SEI-93-TR-24, página 22, faz considerações sobre os 5 níveis e a capacitação dos processos como indicado pelo nível de maturidade. © Fabio Silva - DI-UFPE 14

13 Áreas-chave de processo (KPA)
Gerência de Evolução de Processos Gerência de Evolução da Tecnologia Prevenção de Defeitos Nível 5 - OTIMIZADO Gerência de Qualidade de Software Gerência Quantitativa de Processos Nível 4 - GERENCIADO Revisão por Parceiros Coordenação entre grupos Engenharia de Produto de Software Gerência de Software Integrada Programa de Treinamento Definição do Processo da Organização Foco no Processo da Organização Nível 3 - DEFINIDO Gerência de Configuração de Software Garantia de Qualidade de Software Gerência de Contrato de Software Supervisão e Acompanhamento de Projeto de Software Planejamento de Projeto de Software Gerência de Requisitos Nível 2 - REPETITIVO Nível 1 - INICIAL © Fabio Silva - DI-UFPE

14 Áreas-chave de processo do CMM (KPAs)
Identificam um grupo de atividades correlatas que, quando realizadas coletivamente, alcançam um conjunto de metas consideradas importantes na implementação da competência do processo. Definidas para serem alocadas em um único nível de maturidade. Área-chave de processo indica áreas de uma organização que deverão ser focalizadas para a melhoria de seu processo de software. O item 3.3 do CMU/SEI-93-TR-24, página 30, e o item 2.3 do CMU/SEI-93-TR-25, página O-10, definem área-chave de processo. Ver item 2.5 do CMU/SEI-93-TR-25, página O-18. Identificam as questões que devem ser abordadas para se alcançar um nível de maturidade. São definidas 18 KPAs no CMM. © Fabio Silva - DI-UFPE 34

15 Áreas-chave de processo (KPAs) - Estrutura
Metas Compromisso para realizar Medição e análise Capacidade de realizar Verificar implementação Atividades realizadas Common features Esta figura representa a estrutura de uma KPA . A área-chave de processo é organizada por características comuns, que são atributos que indicam se a implementação ou institucionalização da KPA é efetiva, repetida e permanente. As metas sintetizam as práticas chave de uma KPA e podem ser usadas para determinar se uma organização ou projeto tem efetivamente implementada a KPA. © Fabio Silva - DI-UFPE 38

16 Metas Resume as práticas-chave das áreas-chave de processo.
São consideradas importantes para intensificar o processo de competência para aquele nível de maturidade. Podem ser usadas para orientar organizações e equipes de avaliação para realizarem avaliações na implementação das KPAs. O apêndice A do CMU/SEI-93-TR-24, página 59, relaciona todas as metas das áreas-chave de processo de todos os níveis de maturidade. Cada prática-chave mapeia uma ou mais metas. © Fabio Silva - DI-UFPE 36

17 Características comuns
Utilizadas para organizar as práticas-chave em cada KPA Características comuns são: compromisso para realizar capacidade para realizar atividades realizadas medições e análises verificar a implementação O item 3.4 do CMU/SEI-93-TR-24, página 37, e o item 2.8 do CMU/SEI-93-TR-25, página O-27, definem as características comuns. © Fabio Silva - DI-UFPE 37

18 Práticas-chave Estabelece as políticas fundamentais, procedimentos e
atividades para uma área-chave de processo (KPA). Descreve o “que” deve ser feito, embora elas não devam ser interpretadas enquanto “como” definitivo. Cada prática-chave consiste de uma simples frase, frequentemente seguida por uma descrição detalhada, a qual pode incluir exemplos. O item 4.1 do CMU/SEI-93-TR-25, página O-35, interpreta as práticas-chave. São organizadas por característica comum. Existem 316 práticas-chave no CMM . © Fabio Silva - DI-UFPE 39

19 CMM Nível 2 - Repetível

20 Áreas-chave de processo (KPA) - Nível Repetível
Gerenciamento da Configuração de Software Garantia da Qualidade de Software Gerenciamento de Subcontrato de Software Acompanhamento de Projeto de Software Planejamento de Projeto de Software Gerenciamento de Requisitos © Fabio Silva - DI-UFPE

21 Planejamento do Processo
Nível 2 - PPS Planejamento do Processo de Software © Fabio Silva - DI-UFPE

22 Objetivos Estabelecer planos exequíveis para desenvolver um determinado software, para gerenciar o projeto de desenvolvimento de software segundo estes planos Definir o plano de realização do trabalho (plano de desenvolvimento/projeto de software) Realizar estimativas de software, estabelecendo compromissos com as partes envolvidas © Fabio Silva - DI-UFPE

23 PPS - Metas Documentar as estimativas de software a serem usadas no planejamento e acompanhamento do projeto de software Planejar e documentar as atividades e compromissos do projeto de desenvolvimento de software Obter a concordância dos grupos e das pessoas envolvidos quanto aos respectivos compromissos relacionados ao projeto de desenvolvimento © Fabio Silva - DI-UFPE

24 PPS - Compromissos Um gerente de projeto de software é responsável pelos compromissos e pelo plano de desenvolvimento de software Seguir uma política organizacional de PPS © Fabio Silva - DI-UFPE

25 PPS - Habilitações Ter uma declaração de trabalhos documentada e aprovada Ter responsáveis pela elaboração do plano de desenvolvimento de software Ter recursos e fundos disponíveis para PPS Ter gerentes de software, engenheiros de software e outros envolvidos treinados em procedimentos de planejamento e estimativa de software © Fabio Silva - DI-UFPE

26 PPS - Atividades Participar da proposição do projeto
Iniciar o planejamento do projeto de software Participar do planejamento do projeto Revisar os compromissos externos do projeto de software Identificar ou definir o ciclo de vida de software Elaborar o plano de desenvolvimento de software Documentar o plano de desenvolvimento de software Identificar os artefatos de software © Fabio Silva - DI-UFPE

27 PPS - Atividades Estimar o tamanho dos artefatos de software
Estimar esforço e custo do projeto de software Estimar recursos computacionais críticos Estabelecer cronograma de software de projeto Identificar, avaliar e documentar os riscos de software Planejar as facilidades e ferramentas de suporte ao projeto Registrar, gerenciar e controlar dados de planejamento © Fabio Silva - DI-UFPE

28 PPS - Medições & Verificação
Medições e Análise Determinar o estado das atividades do PPS Verificação da Implementação Revisar atividades de PPS (gerência sênior) Revisar atividades de PPS (gerente de projeto) Revisar e/ou auditar atividades e artefatos de PPS (Grupo de GQS) © Fabio Silva - DI-UFPE

29 Supervisão e Acompanhamento
Nível 2 - SAPS Supervisão e Acompanhamento do Projeto de Software © Fabio Silva - DI-UFPE

30 SAPS - Metas Acompanhar os resultados e desempenhos reais confrontando-os com o plano de desenvolvimento de software Tomar ações corretivas e gerenciá-las até sua conclusão, sempre que houver desvio nos resultados e desempenhos reais do plano de desenvolvimento do software Assegurar que as alterações nos compromissos de software de dêem através de acordo entre grupos e pessoas envolvidas © Fabio Silva - DI-UFPE

31 SAPS - Compromissos Designar um gerente de projeto de desenvolvimento de software Seguir uma política organizacional de SAPS © Fabio Silva - DI-UFPE

32 SAPS - Habilitações Ter um plano de desenvolvimento de software
Ter responsabilidades designadas para a execução das atividades de software Ter recursos e fundos disponíveis para SAPS Ter gerentes de software treinados em gerência de projeto Ter gerentes de software de primeira linha orientados em aspectos técnicos do projeto de software © Fabio Silva - DI-UFPE

33 SAPS - Atividades Utilizar o plano de desenvolvimento de software como base para SAPS Revisar o plano de desenvolvimento de software Revisar compromissos e alterações de compromissos Comunicar alterações nos compromissos Acompanhar tamanho dos artefatos de software Acompanhar esforço e custos de software Acompanhar a utilização de recursos computacionais críticos © Fabio Silva - DI-UFPE

34 SAPS - Atividades Acompanhar cronograma de software
Acompanhar atividades técnicas de engenharia de software Acompanhar riscos de software Registrar dados de medições e replanejamento Acompanhar o andamento do projeto Conduzir revisões formais nos marcos de acompanhamento de progresso do projeto © Fabio Silva - DI-UFPE

35 SAPS - Medições & Verificação
Medições e Análise Determinar o estado das atividades de SAPS Verificação da Implementação Revisar atividades de SAPS (gerência sênior) Revisar atividades de SAPS (gerente de projeto) Revisar e/ou auditar atividades e artefatos de SAPS (Grupo de GQS) © Fabio Silva - DI-UFPE

36 Conclusões A melhoria do processo de software oferece um retorno no investimento que pode ser medido - quando é medido. O retorno típico no investimento está entre 5:1 e 8:1. Benefícios adicionais não podem ser quantificados facilmente. O CMM é uma ferramenta útil para orientação no processo de melhoria. Fazer um resumo e revisão dos principais pontos apresentados neste módulo. © Fabio Silva - DI-UFPE 40