Melhoria de Processos de Software com o MPSersirj/wp-content/uploads/2014/11/Minicurso-12.pdf · Básicas ISO/IEC 12207:2008 e ISO/IEC 15504 Complementar CMMI-DEV Objetivo Descrever

Melhoria de Processos de Software com o MPS.BR

Prof. Dr. Marcos Kalinowski (UFF)[email protected]

Agenda do Curso

• Motivação para processos de software

• Visão geral do programa MPS.BR e do modelo MPS-SW

• Estratégias para alcançar a maturidade

• Os níveis de maturidade do MPS-SW

• Reflexão: maturidade e agilidade

• Capacitação e provas oficiais

Marcos Kalinowski Melhoria de Processos de Software com o MPS.BR 2

Agenda do Curso

Motivação para processos de software

• Visão geral do programa MPS.BR e do modelo MPS-SW






Motivação para o Processo de Software


Por que o foco está no processo?

Porque problemas no processo provavelmente geram defeitos no

produto ou serviço!


• O interesse no processo de software está baseado em duas premissas:

– A qualidade de um produto de software é fortemente dependente da qualidade do processo pelo qual ele é construído e mantido.

– O processo de software pode ser definido, gerenciado e melhorado.


Um processo definido está descrito em

detalhes de forma a poder ser usado de

forma consistente.


• 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

Qualidade do processo



• Uma Organização madura gasta maior parte de seu esforço na prevenção de problemas, enquanto uma Organização imatura gasta maior parte de seu esforço corrigindo sintomas em vez de causas de problemas

Precisamos aprender a atacar a doença e não os

sintomas: o processo e não os defeitos no software



• A implantação de um Programa de Qualidade começa pela definição e implantação de um processo de software


O processo de software deve estar

documentado, ser compreendido e

seguido.

Processo Imaturo


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

Processo Maduro


Características• 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

Consequências• papéis e responsabilidades claramente definidos

• acompanhamento da qualidade do produto e da satisfaçãodo cliente

• expectativas para custos, cronograma, funcionalidades equalidade do produto é usualmente alcançada

Pesquisa iMPS

• Pesquisa realizada anualmente para acompanhar e evidenciar resultados de desempenho nas empresas de software que adotaram o modelo MPS.

• Disponível em http://www.softex.br/mpsbr/


Travassos, G.H., Kalinowski, M. “iMPS 2013: Evidências

Sobre o Desempenho das Empresas que Adotaram o

Modelo MPS-SW”. Campinas: SOFTEX, 2014 (ISBN:

978-85-99334-75-1), 102p.

Resultados de Desempenho das Empresas que Adotaram o MPS-SW

• Maior satisfação dos seus clientes.

• Maior produtividade.

• Maior capacidade de desenvolver projetos maiores.

• Obtenção do retorno do investimento (ROI).

• Tendência à melhoria de custo e qualidade.


Possíveis Ganhos na Evolução nos Níveis de Maturidade do MPS-SW

• Maior número de clientes.

• Maior número de projetos.

• Maior número de funcionários.

• Capacidade de lidar com projetos de maior tamanho.

• Maior precisão nas estimativas de prazo.


14

• Investir na melhoria do processo garante a

qualidade do produto?

Momento de Reflexão

15

• Um estudo informal relacionando defeitos em testes

de aceitação com o nível de maturidade de

empresas no CMMI-Dev indicou tendência de

melhora na qualidade do produto (Wagner, 2013).

• Resultados da pesquisa iMPS indicam tendência

similar para o MPS-SW (Travassos e Kalinowski,

2014).

• mas ...


16


17

• Diversos fatores influenciam a qualidade do produto e ela

precisa ser avaliada e monitorada também diretamente.

(Wagner, 2013)

Requisitos de qualidade de produtos devem ser definidos e seu alcance

monitorado ao longo da execução do projeto.


“It is not necessary to change. Survival is notmandatory”

W. Edwards Deming


Agenda do Curso


Visão geral do programa MPS.BR e do modelo MPS-SW






Programa MPS.BR

Patrocinadores:


MPS.BR

Realidade das Empresas Brasileiras

ISO /IEC 12207

ISO /IEC 15504

CMMI

SOFTEX

Governo

Universidades

Base Técnica

Programa MPS.BR


Organização do Programa MPS.BR


SOFTEX

Equipe Técnica do

Modelo

(ETM)

Fórum de Credenciamento e Controle(FCC)

Coordenação do Programa MPS.BR(SOFTEX)

Comissão de Ética do

Programa

(CEP)

Equipe Técnica do Modelo (ETM)

• Equipe responsável pela definição e aprimoramento do:– MR-MPS-SW, MR-MPS-SV e MA-MPS e guias específicos.

– Programa anual de treinamento MPS.BR,

– Cursos, provas e workshops.


Estrutura do Modelo MPS


Adoção e Disseminação do MPS-SW


Base Técnica dos Modelos MPS


Modelo MPS

para Serviços

(MR-MPS-SV)

CMMI-SVC

Complementação

de Processos

MR-MPS-SW e ISO/IEC

20000

Definição de Processos

Propósitos e Resultados

ISO/IEC 15504

Definição da Capacidade

de Processos

Requisitos de Avaliação

Modelo MPS

para Software

(MR-MPS-SW)

CMMI-DEV

Complementação

de Processos

ISO/IEC 12207

Definição de Processos

Propósitos e Resultados

ISO/IEC 15504

Definição da Capacidade

de Processos

Requisitos de Avaliação

Descrição dos modelos

• O modelo é descrito nos guias do MPS.BR

• Os guias gerais possuem os requisitos que devemser atendidos durante a implantação dos modelos

• Os guias de implementação são orientativos

• Todos os guias estão disponíveis em http://www.softex.br/mpsbr


Guia Geral MPS de Software


Referências

Básicas ISO/IEC 12207:2008 e ISO/IEC 15504

Complementar CMMI-DEV

Objetivo

Descrever de forma detalhada o Modelo MPS e detalha MR-MPS-

SW. Também contém algumas definições comuns aos diversos

documentos do MPS.BR

Público alvo

• Instituições interessadas em aplicar o MR-MPS-SW para

melhoria de seus processos de software

• Instituições implementadoras e avaliadoras segundo o MR-MPS-

SW

Guia de Implementação


Referências

• Básicas Guia Geral MPS de Software/Serviços

• Complementar diversas

Objetivo

Fornecer orientações para implementar nas organizações os níveis de

maturidade descritos nos Modelos de Referência MR-MPS-SW/MR-MPS-SV,

detalhando os processos contemplados nos respectivos níveis de maturidade e

os resultados esperados com a implementação dos processos.

Público-Alvo

• Instituições interessadas em aplicar o MR-MPS-SW/MR-MPS-SV para

melhoria de seus processos de software

• Instituições implementadoras e avaliadoras segundo o MR-MPS-SW/MR-MPS-

SV

Estrutura do MPS-SW


Níveis de maturidade

Capacidade

Resultado

Processo

Propósito

Resultado

Atributo


CAPACIDADE

PROCESSOS

Nível Processos Capacidades (AP)

A (sem processos adicionais) 1.1, 2.1, 2.2, 3.1, 3.2,4.1*, 4.2*, 5.1*, 5.2*

B Gerência de Projetos (evolução) 1.1, 2.1, 2.2, 3.1, 3.2,4.1*, 4.2*

C Gerência de Riscos, Desenvolvimento para Reutilização,Gerência de Decisões

1.1, 2.1, 2.2, 3.1, 3.2

D Desenvolvimento de Requisitos, Integração do Produto,Projeto e Construção do Produto, Validação, Verificação

1.1, 2.1, 2.2, 3.1, 3.2

E Avaliação e Melhoria do Processo Organizacional, Gerênciade Projetos (evolução), Gerência de Recursos Humanos,Gerência de Reutilização, Definição do ProcessoOrganizacional

1.1, 2.1, 2.2, 3.1, 3.2

F Aquisição, Garantia da Qualidade, Gerência de Configuração,Gerência de Portfólio de Projetos, Medição

1.1, 2.1, 2.2

G Gerência de Projetos, Gerência de Requisitos 1.1, 2.1

* Estes APs capacitam apenas um conjunto de processos selecionado pela organização deacordo com seus objetivos de melhoria. Os demais APs precisam capacitar todos os processosdo nível pretendido.

Entendendo os Atributos de Processo (Capacidade)

• AP 1.1 O processo é executado– Este atributo é uma medida do quanto o processo atinge o seu

propósito.

• AP 2.1 O processo é gerenciado– Este atributo é uma medida do quanto a execução do processo

é gerenciada.

• AP 2.2 Os produtos de trabalho do processo são gerenciados– Este atributo é uma medida do quanto os produtos de trabalho

produzidos pelo processo são gerenciados apropriadamente.



• AP 3.1. O processo é definido

– Este atributo é uma medida do quanto um processo padrão é mantido para apoiar a implementação do processo definido.

• AP 3.2 O processo está implementado

– Este atributo é uma medida do quanto o processo padrão é efetivamente implementado como um processo definido para atingir seus resultados.



• AP 4.1 O processo é medido– Este atributo é uma medida do quanto os resultados de

medição são usados para assegurar que o desempenho do processo apóia o alcance dos objetivos de desempenho relevantes como apoio aos objetivos de negócio definidos.

• AP 4.2 O processo é controlado– Este atributo é uma medida do quanto o processo é controlado

estatisticamente para produzir um processo estável, capaz e previsível dentro de limites estabelecidos.



• AP 5.1 O processo é objeto de inovações– Este atributo é uma medida do quanto as mudanças no

processo são identificadas a partir da análise de causas comuns de variação do desempenho e da investigação de enfoques inovadores para a definição e implementação do processo.

• AP 5.2 O processo é otimizado continuamente– Este atributo é uma medida do quanto as mudanças na

definição, gerência e desempenho do processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo.



CAPACIDADE

PROCESSOS

Nível Processos Capacidades (AP)

A (sem processos adicionais) 1.1, 2.1, 2.2, 3.1, 3.2,4.1*, 4.2*, 5.1*, 5.2*

B Gerência de Projetos (evolução) 1.1, 2.1, 2.2, 3.1, 3.2,4.1*, 4.2*

C Gerência de Riscos, Desenvolvimento para Reutilização,Gerência de Decisões

1.1, 2.1, 2.2, 3.1, 3.2

D Desenvolvimento de Requisitos, Integração do Produto,Projeto e Construção do Produto, Validação, Verificação

1.1, 2.1, 2.2, 3.1, 3.2

E Avaliação e Melhoria do Processo Organizacional, Gerênciade Projetos (evolução), Gerência de Recursos Humanos,Gerência de Reutilização, Definição do ProcessoOrganizacional

1.1, 2.1, 2.2, 3.1, 3.2

F Aquisição, Garantia da Qualidade, Gerência de Configuração,Gerência de Portfólio de Projetos, Medição

1.1, 2.1, 2.2

G Gerência de Projetos, Gerência de Requisitos 1.1, 2.1

* Estes APs capacitam apenas um conjunto de processos selecionado pela organização deacordo com seus objetivos de melhoria. Os demais APs precisam capacitar todos os processosdo nível pretendido.

Guias do MPS-SW

• Vamos dar uma olhada nos Guias ...


Agenda do Curso



Estratégias para alcançar a maturidade





Engenharia do Processo de Software (versão simplificada do ciclo)


Estabelecer a

Infra-estrutura

para o

processoPlanejamento

da

implementação

e alteração do

processo

Avaliação

do

processo

Implementação

e alteração do

processo

Engenharia do Processo de Software

O 1o. Passo na Engenharia do Processo de Software é estabelecer uma infraestrutura adequada:

• Pessoal competente e atribuição de responsabilidades

• Ferramentas

• Recursos financeiros

» Indicadores do apoio da gerência

» Equipe específica para a Engenharia do Processo que pode envolver consultores


Grupo de Engenharia do Processo de Software

Atividades:• Obtém e mantém o apoio de todos os níveis gerenciais

• Facilita a avaliação do processo

• Trabalho com gerentes cujos projetos são afetados por mudanças naspráticas de engenharia de software

• Trabalha de forma colaborativa com os engenheiros de software

• Promove e apoia treinamento e formação continuada

• Monitora e relata o status dos esforços de melhoria

• Facilita a criação e manutenção de definições do processo

• Mantém a base de dados do processo

• Fornece consultoria

• Participa da integração dos processos de engenharia de software comoutros processos organizacionais



Executar o

Processo

Definir o

Processo

Medir o

Processo

Melhorar o

Processo

Controlar o

Processo

Ciclo: Definição, Uso, Medição, Controle e Melhoria

Definição do Processo

Razões para definição de processos de Engenharia de Software:

– facilitar o entendimento e a comunicação entre pessoas

– apoiar a melhoria dos processos

– apoiar a gerência dos processos

– fornecer apoio automatizado guiando no processo

– fornecer apoio na execução automatizada do processo

43Marcos Kalinowski Melhoria de Processos de Software com o MPS.BR


• Definir processos que apoiem os objetivos técnicos e de negócio.

• Identificar modelos e métricas relacionados ao desempenho do processo.

• Fornecer a infraestrutura necessária para apoiar as atividades do processo (métodos, práticas e pessoas).

• Assegurar que a organização possua as habilidades necessárias para executar o processo.



• Frameworks de Modelos de Ciclo de Vida

– Definição de alto nível das fases e atividades que ocorrem durante odesenvolvimento

• Modelos de Processos de Ciclo de Vida

– Definições mais detalhadas

– Podem ser mapeados para os diferentes modelos de ciclo de vida

– Principais referências: ISO/IEC 12207, ISO/IEC 15504

• Métodos para Definição de Processos

– Descrevem as atividades que devem ser realizadas para o desenvolvimento emanutenção de um processo


Definição do ProcessoRepositório

De Medidas doProcesso

Projeto 1Tam.$$$

DefeitosResult.Lições

Ativos deProcesso

Diretrizes e Critérios de

Adaptação doProcessoPadrão

Processo Padrão da

Organização

Elementos do Proc.

Arquitetura do Processo

Ciclos de Vida

SoftwareRequirements

SystemRequirements

PreliminaryDesign

Analysis

ProgramDesign

Coding

Operations

Testing


Entendendo os Relacionamentos entre Processos

• Conhecer as interações entre os diferentes processos ajuda a aplicar os modelos de maturidade de forma útil e produtiva

• O SEI/CMMI-Dev divide suas áreas de processo em quatro categorias:

– Gerência de Processos

– Gerência de Projetos

– Engenharia

– Apoio


Processos (básicos) da Categoria Gerência de Processos

48

Processo Padrãoe outros Ativos

DPO

Alta Gerência

Objetivos deNegócio da

Organização

Treinamento para Projetos e Grupos de Apoio ao Processo Padrão e Ativos

Necessidadede Treinamento

GRH

ProcessoPadrão e outrosAtivos

DPO +

AMPRecursos e

Coordenação

Propostas de Melhoria de

Processos; Participação

na definição, avaliação e

implantação de processos

Informações para Melhoria(e.g., lições aprendidas, dados, artefatos)

Processos de Gerência de Projetos,

Engenharia eApoio,

Necessidades e Objetivos de Processo da Organização

Marcos Kalinowski Melhoria de Processos de Software com o MPS.BR

Processos (básicos) da Categoria Gerência de Projetos

49

Plan. Proj.

Mon. Proj.

O que

monitorarReplanejar

Fornecedor

Acordo com o

Fornecedor

Aquisição

Ações

Corretivas

Planos

Processos de

Engenharia e

Apoio

Ações

Corretivas

O que fazer

Comprometimento

Requisitos de Produtos, questões

técnicas, componentes prontos, testes

de aceitação e revisões.

Necessidades de medição

Status,

resultados de

revisões


Processos da Categoria Engenharia

50

Cliente

Requisitos

DesReq

Necessidades do Cliente

GReq

Requisitos do Produto

ValVer

Componentes do Produto, pacotes de trabalho,

relatórios de verificação e validação

Componentes

De Produtos

Soluções

Alternativas

PCPRequire-

ments

IPProdutos


Processos da Categoria Apoio

51

Gar. Qual.

Todos os Processo

Processos e Produtos de Trabalho

Problemas deQualidade eNão Conformidade

Medição

NecessidadesDe Informação

Medidas e Análises

Ger. Conf

Baselines e Relatórios

Itens de Conf. e Solicitações de Mudança


Processos (avançados) da Categoria Apoio

52

GDE

Todos os Processos

QuestõesSelecionadas

DecisõesEstruturadas

ACR

Defeitos e Outros Problemas

Propostas de Melhoria de Processo



53

Executar o

Processo

Definir o

Processo

Medir o

Processo

Melhorar o

Processo

Controlar o

Processo


Medição do Processo

• Informação quantitativa sobre o processo é coletada,analisada e interpretada

• Medições são utilizadas para:

– Identificar desvios com relação ao desempenho aceitável para oprocesso

– Identificar oportunidades de melhoria para o do processo

54

ProcessoResultados

do Processo

Contexto



• Podemos medir a qualidade do processo– medindo o próprio processo

– medindo os produtos do processo

• ImportanteOutros fatores além do processo tem impacto sobre o produto (pessoas, ferramentas, etc)


Medição do Processo (Abordagens)

• Metodologia para medição do processo (GQM & PSM)

• Paradigmas para medição do processo– Paradigma analítico

baseia-se em evidência quantitativa para determinar onde as melhorias são necessárias e se as iniciativas de melhoria foram bem sucedidas

• estudos experimentais• simulação• classificação de defeitos (análise causal)• controle estatístico do processo

– Benchmarkingenvolve medir a maturidade de uma organização ou a capacidade de seus processos

• Modelos para avaliação de processos: ISO 9001, CMM, CMMI, ISO 15504, MPS-SW• Métodos para avaliação de processos : SCAMPI para avaliações baseadas no CMMI,

MA MPS para avaliações baseadas no MPS-SW



• Exemplos de Objetivos:

– Acompanhar melhorias do processo para assegurar que software seja entregue dentro do prazo, do custo e da qualidade esperados.

• Conhecer o tamanho do problema a ser resolvido.

• Conhecer o esforço e prazo para resolver o problema.

• Conhecer o custo.

• Conhecer a produtividade.

• Conhecer a qualidade.



• Exemplos de Medidas

– Tamanho do Software• Pontos de Função; Pontos de Caso de Uso.

– Esforço• Horas Trabalhadas (por Atividade)

– Prazo:• Precisão de Estimativa do Prazo

– SPI – Performance do Cronograma

– Custo:• Precisão de Estimativa do Custo

– CPI – Performance do Planejamento de Custos



• Exemplos de Medidas (cont.)

– Produtividade• Produtividade Horas por Ponto de Função.

– Qualidade• Número de defeitos* por fase de desenvolvimento

• Número de falhas* reveladas nos testes

• Número de falhas* em produção

* Normalizados por unidade de tamanho e por hora de esforço de

Verificação/Validação


60

Exercício

• Qual a tendência apresentada neste gráfico de controle do tipo U-chart? Este comportamento é positivo?

Gráfico extraído de Kalinowski et al. (2014).

61

Resposta

• Não é possível responder à pergunta somente com a informação apresentada.

Medindo a Qualidade


Monitorando Introdução & Detecção

0

1

2

3

4

5

6

Requisitos Projeto Implementação Integração Testes Produção

Estimados

Introdução

Detecção

Real

Introdução

Detecção

#D

efe

ito

s/

Caso

de U

so


63

Executar o

Processo

Definir o

Processo

Medir o

Processo

Melhorar o

Processo

Controlar o

Processo


Controle do Processo

• Manter o processo dentro dos seus limites normais de desempenho.

• O processo deve se comportar de forma consistente.

• Controlar o processo envolve:– Medir o processo.– Detectar variações no processo decorrentes de causas

atribuíveis.– Corrigir variações no processo através da remoção de causas

atribuíveis.



65

Executar o

Processo

Definir o

Processo

Medir o

Processo

Melhorar o

Processo

Controlar o

Processo


Melhoria do Processo

• Processos podem e devem ser melhorados continuamente.

• Melhorar o processo envolve:

– Entender as características dos processos existentes e os fatores que afetam a capacidade do processo.

– Planejar e implementar ações que modifiquem o processo para atender melhor as necessidades de negócio.

– Avaliar os impactos e benefícios.


Agenda do Curso




Os níveis de maturidade do MPS-SW




Gerenciado Quantitativamente

Parcialmente

Gerenciado

Gerenciado

Parcialmente

Definido

Largamente

Definido

Definido

Em Otimização

Níveis de Maturidade MPS-SW


Medição - MED / Gerência de Configuração - GCOAquisição - AQU / Garantia da Qualidade - GQAGerência de Portfólio de Projetos - GPP

Avaliação e Melhoria do Processo Organizacional - AMPDefinição do Processo Organizacional - DFPGerência de Reutilização - GRUGerência de Recursos Humanos - GRHGerência de Projetos - GPR (evolução)

Desenvolvimento de Requisitos - DREProjeto e Construção do Produto - PCPIntegração do Produto - ITPVerificação - VER / Validação - VAL

Gerência de Decisões - GDEDesenvolvimento para Reutilização - DRUGerência de Riscos - GRI

G

F

E

D

C

Gerência de Requisitos - GRE

Gerência de Projetos - GPR

A

BGerência de Projetos - GPR (evolução)

(sem processo específico)

MPS-SW: Níveis de Maturidade


Gerência de Projetos – GPR

AP 1.1

AP 2.1

Gerência de Requisitos – GREG

Aquisição – AQU

Gerência de Configuração – GCO

Gerência de Portfólio de Projetos – GPP

Garantia da Qualidade – GQA AP 1.1

AP 2.1

AP 2.2

Medição – MED

F

Avaliação e Melhoria do Processo Organizacional – AMP

Definição do Processo Organizacional – DFP

Gerência de Recursos Humanos – GRH

Gerência de Reutilização – GRU AP 1.1

AP 2.1

AP 2.2

AP 3.1

AP 3.2

Gerência de Projetos – GPR (evolução)

E

Atributos de

ProcessoProcessosNível

MPS-SW: Níveis de Maturidade

70

Atributos de ProcessoProcessosNível

Desenvolvimento de Requisitos – DRE

Integração do Produto – ITP

Projeto e Construção do Produto – PCP

Validação – VALAP 1.1

AP 2.1

AP 2.2

AP 3.1

AP 3.2

Verificação – VER

D

Gerência de Decisões – GDE

Desenvolvimento para Reutilização – DRU

AP 1.1

AP 2.1 AP 2.2

AP 3.1 AP 3.2

Gerência de Riscos – GRI

C

AP 1.1AP 2.1 AP 2.2AP 3.1 AP 3.2AP 4.1 AP 4.2

Gerência de Projetos – GPR (evolução)B

AP 1.1 AP 2.1 AP 2.2

AP 3.1 AP 3.2 AP 4.1

AP 4.2 AP 5.1 AP 5.2

(sem processo específico)A



Parcialmente

Gerenciado

Gerenciado

Parcialmente

Definido

Largamente

Definido

Definido

Em Otimização






G

F

E

D

C



A




Nível G – Parcialmente Gerenciado

Nível Processos Capacidade

G

Gerência de ProjetosGPR 1; GPR2; GPR 3; GPR 4 (até F); GPR 5; GPR 6; GPR 7; GPR 8 (até F); GPR 9; GPR 10; GPR 11; GPR12; GPR 13; GPR 14; GPR 15; GPR 16, GPR 17, GPR 18 e GPR 19

AP1.1 e AP2.1:

RAP 1 RAP 2RAP 3 RAP 4 (G) RAP 5 RAP 6 (até F)RAP 7 RAP 8RAP 9 (até F)RAP 10 (G)

Gerência de Requisitos

GRE 1; GRE 2; GRE 3; GRE 4 e GRE 5


Processos do Nível G

• Gerência de Projetos (GPR)

• Propósito

– O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. O propósito deste processo evolui à medida que a organização cresce em maturidade.


Visão Geral do Processo Gerência de Projetos


Plano do Projeto

Escopo (EAP)

Estimativas de

Tamanho,

Esforço e Custo

Modelo e Fases

do Ciclo de Vida

Orçamento e

CronogramaRiscos

Recursos Humanos,

Hardware e Software

Dados

Avaliação da

Viabilidade

Revisão e

Comprometimento

Monitoração e

Revisão em Marcos

Problemas Ações


Resultados esperados

GPR 1. O escopo do trabalho para o projeto é definido;

GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados;

GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos;




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

GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos;




GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados;

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




GPR 8. (Até o nível F) Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados;

GPR 9. 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;




GPR 10. Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos;

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

GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido e mantido;




GPR 13. O escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados em relação ao planejado;

GPR 14. Os recursos materiais e humanos bem como os dados relevantes do projeto são monitorados em relação ao planejado;

GPR 15. Os riscos são monitorados em relação ao planejado;




GPR 16. O envolvimento das partes interessadas no projeto é planejado, monitorado e mantido;

GPR 17. Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento;

GPR 18. Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas;




GPR 19. 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é a sua conclusão;


Processos do Nível G

Gerência de Requisitos (GRE)

• Propósito

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


Visão Geral do Processo Gerência de Requisitos – GRE


Requisitos

FornecedoresRastreabilidade

Bidirecional entre

Requisitos e Produtos

Avaliação com

Critérios

Comprometimento

com a Equipe

Técnica

Inconsistências

Revisão em Planos

e Produtos de

Trabalho

Gerência de

Mudanças

Gerência de Requisitos – GRE


GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos;

GRE 2. Os requisitos são avaliados com base em critérios objetivos e um comprometimento da equipe técnica com estes requisitos é obtido;

GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida;


Gerência de Requisitos – GRE


GRE 4. 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;

GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.


Capacidade AP 1.1 O processo é executado

Resultado esperado do Atributo do Processo

RAP 1. O processo atinge seus resultados definidos

Este atributo evidencia o quanto o processo atinge o seu propósito

* RAP – Resultado do Atributo de Processo


Capacidade AP 2.1 O processo é gerenciado

Resultados esperados do Atributo do Processo

RAP 2. Existe uma política organizacional estabelecida e mantida para o processo

RAP 3. A execução do processo é planejada

RAP 4. (Para o Nível G) A execução do processo é monitorada e ajustes são realizados

Este atributo evidencia o quanto a execução do processo é gerenciada


Capacidade AP 2.1 O processo é gerenciadoResultados esperados do Atributo do Processo

RAP 5. As informações e os recursos necessários para a execução do processo são identificados e disponibilizados

RAP 6. (Até o Nível F) As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas

RAP 7. As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência


Capacidade AP 2.1 O processo é gerenciadoResultados esperados do Atributo do Processo

RAP 8. A comunicação entre as partes interessadas no processo é planejada e executada de forma a garantir o seu envolvimento

RAP 9. (Até o Nível F) Os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização

RAP 10. (Para o Nível G) O processo planejado para o projeto é executado


Requisitos para o Nível de Maturidade G


Nível Processo Capacidade

G

Gerência de ProjetosAP 1.1, AP 2.1:

RAP 1 RAP 2

RAP 3 RAP 4 (G)

RAP 5 RAP 6

RAP 7 RAP 8

RAP 9 RAP 10 (G)Gerência de Requisitos


Parcialmente

Gerenciado

Gerenciado

Parcialmente

Definido

Largamente

Definido

Definido

Em Otimização

Níveis de Maturidade MR-MPS





G

F

E

D

C



A




Processos do Nível F

Aquisição (AQU)

• Propósito

– O propósito do processo Aquisição é gerenciar a aquisição de produtos que satisfaçam às necessidades expressas pelo adquirente.


Visão Geral do Processo Aquisição – AQU

Necessidades de

Aquisição de

ProdutoMetas e Critérios

de Aceitação

Acordo com Fornecedor

Selecionado

Avaliação de

Fornecedores

com Critérios

Seleção do

Fornecedor

Monitoração

Tipos e Estratégia

de Aquisição

Ações

Produto Entregue e

Incorporado no

Projeto



Gerência de Configuração (GCO)

• Propósito

– O propósito do processo Gerência de Configuração é estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos.


Visão Geral do Processo Gerência de Configuração – GCO

Sistema de

Gerência de

ConfiguraçãoItens de

Configuração

Baselines

Registro da

situação

Controle de

Modificações,

Armazenamento,

Manuseio e

Liberação

Auditorias de

Configuração

Garantia da

Integridade,

Completude e

Consistência



Garantia da Qualidade (GQA)

• Propósito

– O propósito do processo Garantia da Qualidade é assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos, procedimentos e padrões estabelecidos.


Visão Geral do Processo Garantia da Qualidade – GQA

Produtos de

TrabalhoAvaliações de

Aderência

Problemas e Não-

conformidades

Processos

Ações corretivas

Escalonamento

para níveis

superiores



Gerência de Portfólio de Projetos (GPP)

• Propósito

– O propósito do processo Gerência de Portfólio de Projetos é iniciar e manter projetos que sejam necessários, suficientes e sustentáveis, de forma a atender os objetivos estratégicos da organização.


Visão Geral do Processo Gerência de Portfólio de Projetos - GPP

Necessidades

Identificação,

Qualificação e

Priorização

Objetivos

estratégicos

Oportunidades de

negócio

Recursos e

Orçamento

Monitoração

Investimentos

Projetos

mantidos no

portfólio

Critérios

Ações Tratamento e

Resolução de

ConflitosComunicação da

Situação



Medição (MED)

• Propósito

– O propósito do processo Medição é coletar, armazenar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a apoiar os objetivos organizacionais.


Visão Geral do Processo Medição –MED

Objetivos de

Negócio

Objetivos de

Medição

Objetivos

estratégicos

Procedimentos

para coleta e

armazenamento

Procedimentos

para análise

Necessidades de

Informação

Medidas

Dados coletados e

analisados

Armazenamento e

comunicação

Tomada de Decisão


Requisitos para o Nível de Maturidade F


F

Gerência de ProjetosAP 1.1, AP 2.1 e AP 2.2:

RAP 1

RAP 2

RAP 3

RAP 4 (F)

RAP 5

RAP 6

RAP 7

RAP 8

RAP 9

RAP 10 (F)

RAP 11

RAP 12

RAP 13

RAP 14


Aquisição

Gerência de Configuração

Garantia da Qualidade

Gerência de Portfólio de Projetos

Medição



Parcialmente

Gerenciado

Gerenciado

Parcialmente

Definido

Largamente

Definido

Definido

Em Otimização






G

F

E

D

C



A




Processos do Nível E

• Definição do Processo Organizacional (DFP)

• Propósito

– O propósito do processo Definição do Processo Organizacional é estabelecer e manter um conjunto de ativos de processo organizacional e padrões do ambiente de trabalho usáveis e aplicáveis às necessidades de negócio da organização.



Avaliação e Melhoria do Processo Organizacional (AMP)

• Propósito– O propósito do processo Avaliação e Melhoria do

Processo Organizacional é determinar o quanto os processos padrão da organização contribuem para alcançar os objetivos de negócio da organização e para apoiar a organização a planejar, realizar e implantar melhorias contínuas nos processos com base no entendimento de seus pontos fortes e fracos.



Gerência de Recursos Humanos (GRH)

• Propósito

– O propósito do processo Gerência de Recursos Humanos é prover a organização e os projetos com os recursos humanos necessários e manter suas competências adequadas às necessidades do negócio.



Gerência de Reutilização (GRU)

• Propósito

– O propósito do processo Gerência de Reutilização é gerenciar o ciclo de vida dos ativos reutilizáveis.



E

Gerência de Projetos

GPR 4 e GPR 8 (evoluídos), GPR 20, GPR 21 e GPR 22 (incorporados)

AP1.1, AP2.1, AP2.2,AP3.1 e AP3.2:

RAP 1 RAP 2RAP 3 RAP 4 RAP 5 RAP 6 RAP 7 RAP 8RAP 9 RAP 10RAP 11 RAP 12RAP 13 RAP 14RAP 15 RAP 16RAP 17 RAP 18RAP 19 RAP 20RAP 21



Medição


Gerência de Portfólio

Aquisição

Avaliação e Melhoria do Processo Organizacional

Definição do Processo Organizacional

Gerência de Recursos Humanos

Gerência de Reutilização

Requisitos para o Nível de Maturidade E



Parcialmente

Gerenciado

Gerenciado

Parcialmente

Definido

Largamente

Definido

Definido

Em Otimização






G

F

E

D

C



A




Processos do Nível D

Desenvolvimento de Requisitos (DRE)

• Propósito

– O propósito do processo Desenvolvimento de Requisitos é definir os requisitos do cliente, do produto e dos componentes do produto.



Projeto e Construção do Produto (PCP)

• Propósito

– O propósito do processo Projeto e Construção do Produto é projetar, desenvolver e implementar soluções para atender aos requisitos.



Integração do Produto (ITP)

• Propósito

– O propósito do processo Integração do Produto é compor os componentes do produto, produzindo um produto integrado consistente com seu projeto, e demonstrar que os requisitos funcionais e não-funcionais são satisfeitos para o ambiente alvo ou equivalente.



Verificação (VER)

• Propósito

– O propósito do processo Verificação é confirmar que cada serviço e/ou produto de trabalho do processo ou do projeto atende apropriadamente os requisitos especificados.



Validação (VAL)

• Propósito

– O propósito do processo Validação é confirmar que um produto ou componente do produto atenderá a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido.


Requisitos para o Nível de Maturidade D


D

Gerência de Projeto

AP1.1,AP2.1, AP2.2, AP3.1 e AP3.2:

RAP 1 RAP 2RAP 3 RAP 4 RAP 5

RAP 6 RAP 7 RAP 8RAP 9 RAP 10RAP 11 RAP 12RAP 13 RAP 14RAP 15 RAP 16RAP 17 RAP 18RAP 19 RAP 20RAP 21


Aquisição




Medição





Desenvolvimento de Requisitos

Projeto e Construção do Produto

Integração do Produto

Validação

Verificação


Gerenciado

Quantitativamente

Parcialmente

Gerenciado

Gerenciado

Parcialmente

Definido

Largamente

Definido

Definido

Em Otimização






G

F

E

D

C



A




Processos do Nível C

• Gerência de Decisões (GDE)

• Propósito

– O propósito do processo Gerência de Decisões é analisar possíveis decisões críticas usando um processo formal, com critérios estabelecidos, para avaliação das alternativas identificadas.



Desenvolvimento para Reutilização (DRU)

• Propósito

– O propósito do processo Desenvolvimento para Reutilização é identificar oportunidades de reutilização sistemática de ativos na organização e, se possível, estabelecer um programa de reutilização para desenvolver ativos a partir de engenharia de domínios de aplicação.



Gerência de Riscos (GRI)

• Propósito

– O propósito do processo Gerência de Riscos é identificar, analisar, tratar, monitorar e reduzir continuamente os riscos em nível organizacional e de projeto.


Requisitos para o Nível de Maturidade CNível Processo Capacidade

C

Gerência de Projeto

AP1.1,AP2.1, AP2.2, AP3.1 e AP3.2:

RAP 1 RAP 2RAP 3 RAP 4 RAP 5 RAP 6 RAP 7 RAP 8RAP 9 RAP 10RAP 11 RAP 12RAP 13 RAP 14RAP 15 RAP 16RAP 17 RAP 18RAP 19 RAP 20RAP 21 RAP 22


Aquisição




Medição








Verificação

Validação

Gerência de Decisões

Desenvolvimento para Reutilização

Gerência de Riscos


Parcialmente

Gerenciado

Gerenciado

Parcialmente

Definido

Largamente

Definido

Definido

Em Otimização






G

F

E

D

C



A




Processos do Nível B

Gerência de Projetos (GPR)

• Propósito

– O propósito do processo Gerência de Projetos para o nível B é gerenciar quantitativamente o projeto, refletindo a alta maturidade da organização.


Capacidade

• AP 4.1 O processo é medido– Este atributo é uma medida do quanto os resultados de

medição são usados para assegurar que o desempenho do processo apóia o alcance dos objetivos de desempenho relevantes como apoio aos objetivos de negócio definidos.

• AP 4.2 O processo é controlado– Este atributo é uma medida do quanto o processo é controlado

estatisticamente para produzir um processo estável, capaz e previsível dentro de limites estabelecidos.



B

Gerência de Projetos GPR 22, GPR 23, GPR 24, GPR 25, GPR 26, GPR 27 e GPR 28

AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1 e AP 4.2:

RAP 1 a RAP 22

RAP 22 e RAP 25

(todos os processos)

RAP 26 a RAP 34 (processos selecionados)


Aquisição




Medição








Verificação

Validação



Gerência de Riscos


Parcialmente

Gerenciado

Gerenciado

Parcialmente

Definido

Largamente

Definido

Definido






G

F

E

D

C



A


(sem processo específico)Em Otimização


Capacidade

• AP 5.1 O processo é objeto de inovações– Este atributo é uma medida do quanto as mudanças no

processo são identificadas a partir da análise de causas comuns de variação do desempenho e da investigação de enfoques inovadores para a definição e implementação do processo.

• AP 5.2 O processo é otimizado continuamente– Este atributo é uma medida do quanto as mudanças na

definição, gerência e desempenho do processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo.



A

Gerência de Projeto AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2,AP 5.1, AP 5.2:

RAP 1 a RAP 22 RAP 22 e RAP 25

(todos os processos)



Pelo menos um dos processos selecionados para análise de desempenho deve satisfazer integralmente AP 5.1 e AP 5.2 .


Aquisição



Medição









Verificação

Validação



Gerência de Riscos

Agenda do Curso





Reflexão: maturidade e agilidade



E os métodos ágeis?• Scrum

• XP

• OpenUP

• Feature-Driven Development

• Lean

• Kanban


Não são concorrentes! Há inúmeros relatos de empresas que implementaram o modelo de referência MPS-SW com base em métodos ágeis.

Exemplos de Práticas Ágeis

• Planning Poker

• Priorização de backlog

• Quadro Kanban

• Releases e iterações, sprints

• Test-driven development

• Programação pareada

• Integração contínua

• ...


A questão não é qual método seguir, mas quais práticas incluir no seu processo de desenvolvimento para que ele gere o resultado pretendido!

Agenda do Curso





Capacitação e provas oficiais


C1 - Curso

Introdução Ao MPS.BR-SW

C2 – Curso Implementadores

MR-MPS-SW

P2 - Prova

Implementadores

MR-MPS-SW

C3 - Curso

Avaliadores MA-MPS

P3 - Prova

Avaliadores MA-MPS

Implementador MR-MPS Avaliador Adjunto MA-

MPS

WAMPS: Workshop Anual do MPS

Capacitação MPS.BR


C1 - Curso

Introdução ao MPS.BR-SV

C2 – Curso Implementadores

MR-MPS-SV

P2 - Prova

Implementadores

MR-MPS-SV

Implementador MR-MPS

Capacitação MPS.BR


Curso de Introdução

ao MPS.BR SV/SW

(C1: 16h)

Curso de Implementadores

MR-MPS-SV e MR-MPS-SW

(C2: 24h)

Prova de Implementadores

MR-MPS SV/SW

(P2: 4h, c/ consulta)

Curso de Avaliadores

MA-MPS

(C3: 24h)

Prova de Avaliadores

MA-MPS SV/SW

(P3: 4h, c/ consulta)

Requisitos para Avaliador Adjunto

• Formação acadêmica:– Formação acadêmica sólida (desejável: especialização, mestrado ou doutorado concluídos) e

– Conhecimento comprovado em processos

• Treinamento MPS.BR:– Aprovação na Prova de Implementadores Serviços/Software (P2-MPS-SV e/ou P2-MPS-SW) e

– Participação no Curso para Avaliadores MA-MPS (C3-MPS) e

– Aprovação na Prova para Avaliadores (P3-MPS-SV e/ou P3-MPS-SW).

• Experiência profissional:– Experiência comprovada de, no mínimo, 3 (três) anos em processos voltados a serviços de TI e

– Experiência comprovada em 3 (três) implementações de processos onde a unidade organizacional obteve oficialmente nível de maturidade do MR-MPS-SV/MR-MPS-SW ou Experiência comprovada de, no mínimo, 3 (três) anos em gerência de projetos de serviços de TI ou software


Requisitos para Avaliador Líder

• Formação Acadêmica: – Os mesmos requisitos exigidos para avaliador adjunto MR-MPS-SW e MR-

MPS-SV

• Treinamento MPS.BR: – Além do exigido para avaliador adjunto MR-MPS-SW/MR-MPS-SV: – Participação em, no mínimo, 6 (seis) avaliações MR-MPS-SW como avaliador

adjunto– Treinamento para avaliador líder realizado por uma Instituição Avaliadora e– Aprovação como avaliador líder após conduzir 1 (uma) avaliação observada

níveis G ou F (preferencial) do MR-MPS-SW/MR-MPS-SV por um avaliador líder experiente indicado pela ETM-Avaliação.

• Experiência Profissional:– Os mesmos requisitos exigidos para avaliador adjunto MR-MPS-SW/MR-

MPS-SV


Requisitos para Avaliador Líder

• Avaliador Líder Inicial

– Habilitado para liderar avaliações níveis G e F

– Requisitos básicos descritos anteriormente

• Avaliador Líder Intermediário

– Habilitado para liderar avaliações níveis G, F, E, D e C

– Requisitos adicionais

• Avaliador Líder Experiente

– Habilitado para liderar avaliações de qualquer nível

– Requisitos adicionais


Agenda do Curso





Capacitação e provas oficiais


Referências• Este material fez uso autorizado de parte do material do curso

oficial de introdução ao MPS (C1).

• Guias do MPS para Software, disponíveis em http://www.softex.br/mpsbr

• R. Prikladnicki, R. Willi e F. Milani “Métodos Ágeis para Desenvolvimento de Software”. Porto Alegre: Bookman, 2014 (ISBN: 978-85-8260-207-2), 289p.

• G.H. Travassos e M. Kalinowski “iMPS 2013: Evidências Sobre o Desempenho das Empresas que Adotaram o Modelo MPS-SW”. Campinas: SOFTEX, 2014 (ISBN: 978-85-99334-75-1), 102p.

• S. Wagner “Software Product Quality Control”. Springer, 2013 (ISBN 978-3-642-38570-4), 219p.


Leituras Sugeridas

• M. Kalinowski, K.C. Weber, N. Franco, E. Barroso, V. Duarte, D. Zanetti, G. Santos, “Results of 10 Years of Software Process Improvement in Brazil Based on the MPS-SW Model”. International Conference on the Quality of Information and Communications Technology (QUATIC), Guimarães, Portugal, 2014.

• M. Kalinowski, S. Biffl, R.O. Spinola, S. Reinehr, “From Project-Oriented to Service-Oriented Software Development: An Industrial Experience Guided by a Service Reference Model”. Journal of Software Engineering Research and Development, 2 (10), ISSN: 2195-1721, Springer, 2014.

• G. Santos, M. Kalinowski, A.R. Rocha, G.H. Travassos, K.C. Weber, J.A. Antonioni. “MPS.BR program and MPS model: main results, benefits and beneficiaries of software process improvement in Brazil”, In 8th Int. Conf. on the Quality in Information and Communications Technology (QUATIC), Lisbon, Portugal, 2012.

• M. Kalinowski, G. Santos, R. Prikladnicki, A. R. Rocha, K. C. Weber, J. A. Antonioni, “From software engineering research to Brazilian software quality improvement”, 25th Brazilian Symposium on Software Engineering, SBES 2011, São Paulo, Brazil, pp. 120-125, 2011.


Leituras Sugeridas (cont.)

• M. Kalinowski, G. Santos, S. Reinehr, M. Montoni, A.R. Rocha, K.C. Weber, G.H. Travassos, “MPS.BR: promovendo a adoção de boas práticas de engenharia de software pela indústria brasileira”. XIII Congreso Iberoamericano en "Software Engineering" (CIBSE), Cuenca, Ecuador, 2010.

• M.A. Montoni, A.R. Rocha, K.C. Weber, “MPS.BR: A successful program for software process improvement in Brazil”. Software Process: Improvement and Practice, Vol. 14, Issue 5, pp. 289-300, 2009.

• M. Kalinowski, K. Weber, G.H. Travassos, “iMPS: an experimentation based investigation of a nationwide software development reference model”, 2nd International Symposium on Empirical Software Engineering and Measurement (ESEM), Kaiserslautern, Germany, 2008.


Melhoria de Processos de Software com o MPS.BR

Prof. Dr. Marcos Kalinowski (UFF)[email protected]

Documents

Melhoria de Processos de Software com o MPSersirj/wp-content/uploads/2014/11/Minicurso-12.pdf · Básicas ISO/IEC 12207:2008 e ISO/IEC 15504 Complementar CMMI-DEV Objetivo Descrever