Treinamento MPS.BrNível G- Gerência de Projetos e Requisitos

Origem - MPS.Br

● Criado pela SEI (Software Engineering Institute)

● Modelo para melhoria de processos de desenvolvimento de produtos e serviços

● 5 níveis de maturidade

CMMI

CMMI - Níveis de Maturidade

● Fornece uma arquitetura de alto nível para ciclo de vida de software, desde a concepção até sua descontinuidade.○ Definido em processos, atividades e tarefas

para aquisição, fornecimento, desenvolvimento, operação e manutenção de software.

ISO/IEC 12207

ISO/IEC 12207

Framework para:- Avaliação de Processo- Melhoria de Processo

Contextos:- Melhoria Contínia:

● avaliação identifica oportunidades de melhoria- Determinação da Capacidade:

● avaliação identifica riscos com o fornecedor

ISO/IEC 15504

● Prover uma referência padronizada para avaliação de processos

● Deve ser usada em conjunto com um Modelo de Referência de processos.

ISO/IEC 15504

Motivação - MPS.Br

Em 2003, dados do Ministério de Ciência e Tecnologia apontaram:- 30 empresas no Brasil possuíam avaliação CMM.

● 24 no nível 2;● 5 no nível 3;● 1 no nível 4; e● nenhuma no nível 5.

Como melhorar processo de software no Brasil a um custo acessível?

Problema

● Melhoria de Processo de Software em todo o país, a um custo acessível

● Definir um modelo que esteja em conformidade com normas e padrões internacionais

● Definir um modelo de avaliação que seja mais flexível e de acordo com a realidade brasileira

Objetivos do MPS.Br

Porque problemas no processo provavelmente geram defeitos no produto!

Por que o foco está no processo?

● Qualidade do processo- Aumento da qualidade do produto- Diminuição do retrabalho- Maior produtividade- Redução do tempo para atender o mercado- Maior competitividade- Maior precisão nas estimativas

Motivação para o foco no Processo de Software

● Características:- Ad hoc - Improvisado- Fortemente dependente dos profissionais- Indisciplinado

● Consequências:- Pouca produtividade- Qualidade de difícil previsão- Alto custo de manutenção- Risco na adoção de novas tecnologias

Características de Processo Imaturo

● Processo conhecido por todos● Apoio visível da alta administração● Auditagem da fidelidade ao processo● Medidas do produto e do processo● Adoção disciplinada de Tecnologias

Características de processo Maduro

● Papéis e responsabilidades claramente definidos

● Acompanhamento da qualidade do produto e da satisfação do cliente

● Expectativas para custos, cronograma, funcionalidades e qualidade do produto são usualmente alcançadas.

Características de processo Maduro

O que é um processo?

"Conjunto de atividades inter-relacionadas que transforma entradas em saídas" [ABNT, 1998]

Composto de:- Propósito: o principal objetivo da execução do processo e os prováveis resultados obtidos com sua efetiva implementação.- Resultados: resultado observável do sucesso do alcance do propósito do processo [ISO/IEC 12207:2008]

Processo

● Grau de melhoria de processo para um pré-determinado conjunto de processos no qual todos os objetivos dentro do conjunto são atendidos [ISO/IEC 15504-1, 2004]

● 7 Níveis:A. Em otimizaçãoB. Gerenciado quantitativamenteC. DefinidoD. Parcialmente definidoF. GerenciadoG. Parcialmente gerenciado

Nível de maturidade - MPS.Br

Níveis de Maturidade

CMMI x MPS.Br

Processo Requisito

É estabelecer e manter planos que definemas atividades, recursos e responsabilidadesdo projeto, bem como prover informaçõessobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto.

Gerencia de Projetos

● Escopo● Não Escopo● Restrições● Objetivos● Todos os produtos que serão entregues

GPR1 - O escopo do trabalho para o projeto é definido

● Método de estimativa● Detalhamento do Escopo ou não● Tamanho do projeto

GPR2 - As tarefas e o produtos de trabalho do projeto são dimensionados utilizando métodos apropriados

● Incremental ou cascata, por exemplo● Apresentar as fases e principais produtos● Facilita a definição de marcos

importantes

GPR3- O modelo e as fases do ciclo de vida do projeto são definidos

● Método de estimativa● Gerência + Equipe

GPR4 - O esforço e o custo para execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas (até nível F)

● Definição das atividades com início, duração e término.

● Recursos são alocados e o custo contabilizado.

● Definir pontos de controle, nos quais o orçamento e cronograma é revisto.

GPR5 - O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos

● Riscos identificados, com impacto, probabilidade e prioridade de tratamento.

● O acompanhamento dos riscos deve ser registrado, bem como as ações tomadas

GPR6 - Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentos

● Mapa de competências● Currículos● Identificação de treinamentos

GPR7 - Os recursos humanos para o projeto são planejados considerando o perfil e conhecimento necessários para executá-lo;

● Recursos para execução de cada tarefa, mesmos os já existentes;

● Recursos especiais;

GPR8 - As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados

● Plano do projeto, Backlog do produto, Ata de Reunião, artefatos, etc...

● Controle de acesso● Identificar dados confidenciais● Estabeler sistema

GPR9 - Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança

Plano de projeto contendo escopo, cronograma, viabilidade, recursos, etc..

GPR10 - Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos

● Monitoramento da viabilidade em pontos de controle

● Análise de viabilidade quando houver mudança de escopo

● Definição de critérios para viabilidade ● Pontos para se fazer análise de

viabilidade (escopo, aspectos técnicos, financeiros, humanos,restrições)

GPR11 - A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados;

● Envolvidos relevantes – Revisão● Compromisso – Todos (custos,

cronograma e desempenho) – Kick off

GPR - 12 O plano do projeto é revisado com todos os interessados e o compromisso com ele é obtido

● Previsto x realizado● Cumprimento de marcos● Esforço, cronograma, recursos,

orçamento, estimativas.

GPR13 - O escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados em relação ao planejado

● Previsto x realizado● Cumprimento de marcos● Pessoas previstas● Aumento de equipe● Inclusão de dados relevantes

GPR14 - Os recursos materiais e humanos bem como os dados relevantes do projeto são monitorados em relação ao planejado

● Variação do mapa de riscos de acordo com os relatórios de acompanhamento

● Ações devem ser planejadas (GPR18 e GPR19) para corrigir os problemas.

GPR15 - Os riscos são monitorados em relação ao planejado

● Plano de comunicação○ Comunicação envolve: Prazos, custos,

recursos, requisitos, comprometimento.● Cronograma

GPR16 - O envolvimento das partes interessadas no projeto é gerenciado

● Não confundir com acompanhamento GPR13

● Pode ocorrer no início ou fim de uma fase

● Geralmente, analisa-se a viabilidade● Presença de patrocionadores

GPR17 - Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento

● Template para identificação de problemas

● Dados do GPR13, 14, 15 e 17 são analisados

● Problemas são identificados, analisados e registrados

GPR18 - Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependência críticas, são estabelecidos e tratados com as partes interessadas

● Monitoramento das ações corretivas● Avaliar a efetividade da ação corretiva

GPR19 - Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até sua conclusão

O propósito do processo Gerência de Requisitos é gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.● 5 Resultados

Gerência de Requisitos

● Validação de requisitos com a origem

"Esse registro pode ser tratado como um marco do projeto a partir do qual mudanças nos requisitos devem ser tratadas formalmente para minimizar o impacto dessas mudanças no projeto em termos de escopo, estimativas e cronograma, bem como compromissos já estabelecidos"

GRE1 - O entendimento dos requisitos é obtido junto aos fornecedores de requisitos

● Requisitos apresentados a Equipe na reunião de kick-off

● Novo comprometimento caso haja mudança nos requisitos

"Além disso, um comprometimento formal da equipe técnica com os requisitos deve ser obtido e registrado, por exemplo, na forma de ata de reunião, e-mail ou algum outro mecanismo."

GRE2 - os requisitos são avaliados com base em critérios objetivos e um comprometimento da equipe técnica com estes requisitos é obtido

Rastreabilidade horizontal: requisito x requisito

Rastreabilidade vertical: requisito x artefatos

"Ter definida a rastreabilidade facilita a avaliação do impacto das mudanças de requisitos que possam ocorrer, por exemplo, nas estimativas do escopo, nos produtos de trabalho ou nas tarefas do projeto descritas no cronograma."

GPR3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida

● Identificar inconsistências● Planejar ações corretivas● Pode ser verificado no marco do projeto

"A consistência entre os requisitos e os produtos de trabalho do projeto deve ser avaliada e os problemas identificados devem ser corrigidos."

GRE4 - Revisões em planos e produtos de trabalho do projeto são realizadas visando a identificar e corrigir inconsistências em relação aos requisitos

● Necessidades de mudanças devem ser registradas

● Análise de impacto + Rastreabilidade

"Durante o projeto, os requisitos podem mudar por uma série de motivos. Desta forma, requisitos adicionais podem ser incorporados no projeto, requisitos podem ser retirados do projeto e/ou mudanças podem ser feitas nos requisitos já existentes. Ressalta-se que, devido às mudanças, os requisitos podem ter que ser revistos, conforme definido no GRE4."

GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto