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