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

Aula 2

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

© Fabio Silva - DI-UFPE 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

Aplicando TQM (Total Quality Management) ao Software

• O processo de melhoria se aplica em todo o contexto do negócio - o CMM se aplica especificamente ao software.

CMM

TQMProjeto B Projeto CProjeto A

hardware

software

Organização

Projeto X

© Fabio Silva - DI-UFPE

Conceitos Fundamentais

Processo

Capacidade

Performance e

Maturidade do Processo de Software

© Fabio Silva - DI-UFPE

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

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.

© Fabio Silva - DI-UFPE

Anatomia do Caos

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

A maioria das organizações de software estão “apagando incêndios”

© Fabio Silva - DI-UFPE

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.

© Fabio Silva - DI-UFPE

Definição Operacional - CMM

Áreas-chave deProcessos

Nível deMaturidade

CaracterísticasComuns

PraticasChave

Contém

Organizadas em

Contêm

Indica

Capacidade

Objetivos

Implementação

InfraestruturaAtividades

Atinge

Enfatiza

Descreve

© Fabio Silva - DI-UFPE

5 Níveis de Maturidade

Inicial

Repetitível

Definido

Gerenciado

Otimizando

Processodisciplinado

Processostandard econsistente

Processopredizível

Processo emotimização

Processo caótico e ad hoc

Processos estabelecidos porexperiências anteriores

Processos documentados,standard e integrados

Medidasde qualidade

Feedback

© Fabio Silva - DI-UFPE

Evolução do processo

Otimizado

Gerenciado

Definido

Repetível

Melhoria do processo éinstitucionalizada.

Inicial

Produto e processo são con-trolados quantitativamente.

Engenharia de software egerenciamento de processosdefinidos e integrados.

Sistema de gerenciamentode projetos em vigor;desempenho é repetido.

Processo é informal eimprevisível.

Nível Características do processo

1

2

3

45

© Fabio Silva - DI-UFPE 13

Áreas-chave de processo (KPA)Áreas-chave de processo (KPA)

Gerência de Configuração de SoftwareGarantia de Qualidade de SoftwareGerência de Contrato de SoftwareSupervisão e Acompanhamento de Projeto de SoftwarePlanejamento de Projeto de SoftwareGerência de Requisitos

Revisão por Parceiros Coordenação entre gruposEngenharia de Produto de SoftwareGerência de Software IntegradaPrograma de TreinamentoDefinição do Processo da OrganizaçãoFoco no Processo da Organização

Gerência de Qualidade de Software

Gerência Quantitativa de Processos

Gerência de Evolução de ProcessosGerência de Evolução da TecnologiaPrevenção de Defeitos

Nível 1 - INICIALNível 1 - INICIAL

Nível 4 - GERENCIADONível 4 - GERENCIADO

Nível 5 - OTIMIZADONível 5 - OTIMIZADO

Nível 3 - DEFINIDONível 3 - DEFINIDO

Nível 2 - REPETITIVONível 2 - REPETITIVO

© Fabio Silva - DI-UFPE

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

• 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

Áreas-chave de processo (KPAs) - Estrutura

KPA

Metas

Compromissopara realizar

Medição e análise

Capacidadede realizar

Verificarimplementação

Atividadesrealizadas

Com

mon

fea

ture

s

© Fabio Silva - DI-UFPE

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.• Cada prática-chave mapeia uma ou mais metas.

© Fabio Silva - DI-UFPE

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

© Fabio Silva - DI-UFPE

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.

• São organizadas por característica comum.

• Existem 316 práticas-chave no CMM .

CMM

Nível 2 - Repetível

© Fabio Silva - DI-UFPE

Áreas-chave de processo (KPA) - Nível Repetível

Repetível (2)

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 SoftwareGerenciamento de Requisitos

© Fabio Silva - DI-UFPE 21

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

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

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.