Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

(1)

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Prof.:

Monalessa Perini Barcellos

(monalessa@inf.ufes.br)

Disciplina:

INF5008 – Engenharia de Software

Conteúdo

2. Qualidade do Processo de Software

2.1 Definição de Processos de Software

2.2 Modelos de Ciclo de Vida (Modelos de Processo)

2.3 Normas e Modelos de Apoio à Definição de Processos de Software 2.3.1 Série ISO 9000

2.3.2 ISO/IEC 12207 2.3.3 CMMI 2.3.4 MR MPS.BR 2.3.5 ISO/IEC 15504

(2)

Processos

de

software

devem

ser

estabelecidos

e

institucionalizados.

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.

Mas...

Como definir um processo de software?

2.1 Definição de Processos de Software

- As características do produto, projeto, organização, cliente, ambiente, tecnologias e equipe, dentre outros, devem ser levados em consideração.

- Modelos de ciclo de vida provêm um esqueleto para o processo.

- Existem normas e modelos de qualidade que apoiam a definição de processos de software.

Engenharia de Software Monalessa Perini Barcellos

Definição de Processos de Software em Níveis

•

Embora diferentes projetos requeiram processos com características específicas

para atender às suas particularidades, é possível estabelecer um conjunto de

ativos de processo* a ser utilizado na definição de processos de software de

uma organização.

•

As normas e modelos preconizam a definição e institucionalização de processos

padrão nas organizações.

*

Subprocessos, atividades, subatividades, artefatos, recursos e procedimentos, dentre outros.

Processo Padrão

Normas e Modelos de Qualidade

Cultura Organizacional, Política Organizacional, Características da Organização etc

2.1 Definição de Processos de Software

(3)

Definição de Processos de Software em Níveis

Processo Padrão Normas e Modelos de Qualidade,

Cultura Organizacional, Características da Organização

Tipo de Software, Domínio do Problema, Paradigma e Tecnologia de Desenvolvimento

Particularidades do Projeto, Modelo de Ciclo de Vida

Definição

Especialização

Processo Especializado 1 Processo Especializado n

Instanciação

Processo de Projeto m Processo de Projeto 1

2.1 Definição de Processos de Software

Modelo de Ciclo de Vida de Software ou Modelo de Processo de Software

• Representação abstrata de um esqueleto de processo, incluindo tipicamente algumas atividades principais, a ordem de precedência entre elas e, opcionalmente, artefatos requeridos e produzidos.

• É um importante ponto de partida para definir como o projeto deve ser conduzido, mas a sua adoção não é o suficiente para guiar e controlar um projeto de software na prática. • Geralmente envolve as seguintes fases: Análise e Especificação de Requisitos, Projeto,

Implementação, Testes, Entrega e Implantação, Operação, Manutenção.

• Os principais modelos de ciclo de vida podem ser agrupados em três categorias principais: modelos sequenciais, modelos incrementais e modelos evolutivos.

2.2 Modelos de Ciclo de Vida

(4)

Modelos Sequenciais – Modelo Cascata (Modelo de Ciclo de Vida Clássico)

Análise e Especificação de Requisitos Implementação e Teste de Unidade Testes Entrega e Implantação Projeto

• Uma fase só deve ser iniciada após a conclusão daquela que a precede. • Uma vez que, na prática, essas fases

se sobrepõem de alguma forma, geralmente, permite-se um retorno à fase anterior para a correção de erros encontrados.

• A entrega do sistema completo ocorre somente ao final da fase de Entrega e Implantação.

• O uso de revisões ao fim de cada fase permite o envolvimento do usuário. • Cada fase serve como uma base

aprovada e documentada para o passo seguinte, facilitando bastante a gerência de configuração.

É o modelo de ciclo de vida mais antigo e mais amplamente usado. Indicado para problemas bastante pequenos e bem definidos, onde os desenvolvedores conhecem bem o domínio do problema e os requisitos podem ser claramente estabelecidos.

2.2 Modelos de Ciclo de Vida

Modelos Sequenciais – Modelo Cascata (Modelo de Ciclo de Vida Clássico)

Problemas:

• Projetos reais muitas vezes não seguem o fluxo sequencial que o modelo propõe.

• Os requisitos devem ser estabelecidos de maneira completa, correta e clara logo

no início de um projeto. A aplicação deve, portanto, ser entendida pelo

desenvolvedor desde o início do projeto.

• O usuário precisa ser paciente. Uma versão operacional do software não estará

disponível até o final do projeto.

• A introdução de certos membros da equipe, tais como projetistas e

programadores, é frequentemente adiada desnecessariamente. A natureza linear

do ciclo de vida clássico leva a “estados de bloqueio” nos quais alguns membros

da equipe do projeto precisam esperar que outros membros da equipe completem

tarefas dependentes.

2.2 Modelos de Ciclo de Vida

(5)

Modelos Sequenciais – Modelo em V

• Testes de unidade e integração devem garantir que todos os aspectos do projeto do sistema foram implementados corretamente no código.

• Teste de sistema busca verificar se o sistema atende aos requisitos definidos na especificação. • Testes de aceitação, conduzidos

tipicamente pelos usuários e clientes, validam os requisitos, confirmando que os requisitos corretos foram implementados no sistema .

Variação do Cascata que procura enfatizar a estreita relação entre as atividades de teste (teste de unidade, teste de integração, teste de sistema e teste de aceitação) e as demais fases do processo. Análise e Especificação de Requisitos Implementação Teste de Sistema Projeto da Arquitetura Projeto Detalhado Testes de Unidade e Integração Teste de Aceitação (Entrega e Implantação)

A conexão entre os lados direito e esquerdo do modelo em V implica que, caso sejam encontrados problemas em uma atividade de teste, a correspondente fase do lado esquerdo e suas fases subsequentes podem ter de ser executadas novamente para corrigir ou melhorar esses problemas.

2.2 Modelos de Ciclo de Vida

Modelos Incrementais – Modelo Incremental

Seu princípio fundamental é que, a cada ciclo ou iteração, uma versão operacional do sistema será produzida e entregue para uso ou avaliação detalhada do cliente.

Variações

Análise e Especificação de

Requisitos

Implementação e

Teste de Unidade Testes

Entrega e Implantação Projeto Levantamento Preliminar de Requisitos (Planejamento) Versão Operacional (a) Análise Implementação e

Teste de Unidade Testes _{Implantação}Entrega e Projeto Especificação de Requisitos Versão Operacional (b) Projeto da Arquitetura Implementação e

Teste de Unidade Testes _{Implantação}Entrega e Projeto Detalhado Análise e Especificação de Requisitos Versão Operacional (c)

2.2 Modelos de Ciclo de Vida

(6)

Modelos Incrementais – Modelo Incremental

Vantagens:

• Menor custo e menos tempo são necessários para se entregar a primeira

versão;

• Os riscos associados ao desenvolvimento de um incremento são menores,

devido ao seu tamanho reduzido;

• O número de mudanças nos requisitos pode diminuir devido ao curto tempo

de desenvolvimento de um incremento.

Desvantagens:

• Se os requisitos não são tão estáveis ou completos quanto se esperava, alguns

incrementos podem ter de ser bastante alterados;

• A gerência do projeto é mais complexa, sobretudo quando a divisão em

subsistemas inicialmente feita não se mostrar boa.

2.2 Modelos de Ciclo de Vida

Modelos Incrementais – RAD (Rapid Application Development)

Prima por um ciclo de desenvolvimento curto (tipicamente de até 90 dias). Os incrementos são desenvolvidos em paralelo por equipes distintas e apenas uma única entrega é feita.

Análise Implementação e Testes Integração Entrega e Implantação Projeto Especificação de Requisitos Sistema Análise Implementação e Testes Projeto Análise Implementação e Testes Projeto Equipe 1 Equipe 2 Equipe n • Exige disponibilidade de equipes. • Os requisitos têm de ser bem definidos, o escopo do projeto tem de ser restrito e o sistema modular.

2.2 Modelos de Ciclo de Vida

(7)

Modelos Evolutivos – Modelo Espiral

• O sistema é desenvolvido em ciclos, sendo que nos primeiros ciclos nem sempre todas as atividades são realizadas (por exemplo, o produto resultante do primeiro ciclo pode ser uma especificação do produto ou um estudo de viabilidade). • As passadas subsequentes ao longo da espiral podem ser usadas para desenvolver

protótipos, chegando progressivamente a versões operacionais do software, até se obter o produto completo.

• A cada ciclo, o planejamento deve ser revisto com base no feedback do cliente, ajustando, inclusive, o número de iterações planejadas. • Pode ser difícil convencer clientes,

especialmente em situações envolvendo contrato, que a abordagem evolutiva é gerenciável.

Especificação de Requisitos Análise Projeto Implementação Testes Entrega e Implantação

2.2 Modelos de Ciclo de Vida

Modelos Evolutivos – Prototipação

• Muitas vezes, clientes têm em mente um conjunto geral de objetivos para

um sistema de software, mas não são capazes de identificar claramente as

funcionalidades ou informações (requisitos) que o sistema terá de prover ou

tratar.

• A prototipação é uma técnica para

ajudar engenheiros de software e

clientes a entender o que está sendo

construído quando os requisitos não

estão claros.

• Pode ser aplicada no contexto de

qualquer modelo de processo (na

figura: modelo Cascata com

Prototipação).

Análise e Especificação de Requisitos Implementação e Teste de Unidade Testes Entrega e Implantação Projeto Prototipação

2.2 Modelos de Ciclo de Vida

(8)

- Os modelos de ciclo de vida fornecem um „esqueleto‟ para o processo.

- Para „rechear‟ o processo, podem ser utilizadas normas e modelos de processo.

Algumas normas e modelos podem ajudar.

2.2 Modelos de Ciclo de Vida

Fase Atividades Recursos Humanos Resultado

Especificação de Requisitos

Realizar levantamento de requisitos Analista de Sistemas Registro inicial de requisitos Elaborar Especificação de Requisitos Analista de Sistemas Especificação de Requisitos do Sistema Avaliar Especificação de Requisitos (externa) Analista de Sistemas, Usuário Relatório de não conformidades ou aceitação da Especificação de _{Requisitos do Sistema pelo usuário}

Avaliar Especificação de Requisitos (interna) Equipe de Qualidade Relatório de não conformidades ou aceitação da Especificação de _{Requisitos do Sistema}

Análise

Elaborar Modelos de Classes Analista de Sistemas Modelo de Classes do Sistema Elaborar Diagramas de Estados Analista de Sistemas Diagramas de Estados

Avaliar Modelos de Análise Equipe de Qualidade Relatório de não conformidades ou aceitação dos Modelos de _Análise

Projeto

Elaborar Projeto de Arquitetura Projetista de Sistemas Projeto de Arquitetura Avaliar Projeto de Arquitetura Equipe de Qualidade Relatório de não conformidades ou aceitação do Projeto de _Arquitetura

Elaborar Projeto de Dados Projetista de Sistemas Projeto de Dados Avaliar Projeto de Dados Equipe de Qualidade Relatório de não conformidades ou aceitação do Projeto de _Dados Elaborar Projeto de Interfaces Projetista de Sistemas Projeto de Interfaces

Avaliar Projeto de Interfaces Equipe de Qualidade Relatório de não conformidades ou aceitação do Projeto de Interfaces Implementar unidades de software Programador Unidades de software implementadas Implementação e Testar unidades de software Tester Registro de Testes de Unidade Testes de Unidade Implementar banco de dados Programador Banco de dados implementado Testar banco de dados Tester Registro de Testes do Banco de Dados Realizar interação do sistema Programador Sistema integrado

Testes

Planejar Testes de Integração Tester Plano de Testes de Integração Avaliar Plano de Testes de Integração Equipe de Qualidade Relatório de não conformidades ou aceitação do Plano de Testes

de Integração Realizar Testes de Integração Tester Registro de Testes de Integração

Planejar Testes de Sistema Tester Plano de Testes de Sistema Avaliar Plano de Testes de Sistema Equipe de Qualidade Relatório de não conformidades ou aceitação do Plano de Testes _{de Sistema}

Realizar Testes de Sistema Tester Registro de Testes de Sistema Avaliar Testes Equipe de Qualidade Relatório de não conformidades ou aceitação dos testes _realizados Entrega e

Implantação

Realizar Implantação do Sistema Analista, Programador Sistema implantado no ambiente operacional Obter aceitação do Sistema Gerente Termo de Homologação do Sistema

Existem diversas normas e modelos que apoiam a definição (e melhoria) de processos de software 2.3.1 Série ISO 9000 2.3.2 ISO/IEC 12207 2.3.3 CMMI 2.3.4 MR MPS.BR 2.3.5 ISO/IEC 15504

(9)

• Desenvolvida para apoiar organizações, de todos os tipos, tamanhos e

segmentos , na implementação e operação de um Sistema de Gestão da Qualidade

(SGQ) eficaz.

• Ênfase na gestão da qualidade (“é melhor prevenir do que remediar”), ou seja, é

melhor prevenir falhas e corrigir a causa dos problemas do que tratar seus

sintomas.

2.3.1 A Série ISO 9000

Histórico

• A 1ª versão foi publicada em 1987 (9000, 9001, 9002, 9003) - foco no produto.

• Em 1994 ocorreu a primeira revisão, visando melhorar os requisitos e enfatizar a natureza preventiva da garantia da qualidade – foco nas inspeções.

• Em 2000 ocorreu a segunda revisão, mais adequada aos princípios de Controle da Qualidade Total e com maior foco no cliente (9000, 9001, 9004) – foco no cliente.

• Em 2005 foram realizadas algumas revisões pontuais (apenas ISO 9000).

• Em 2008 ocorreu uma revisão da ISO 9001, a fim de compatibilizá-la com a ISO 14000 (Gestão Ambiental) e permitir exclusão de requisitos.

• Em 2009 ocorreu uma revisão da ISO 9004, que passou a incluir o conceito de sucesso sustentável – foco na melhoria contínua e sustentável.

“A sustentabilidade é o resultado da capacidade da organização em alcançar seus objetivos em longo prazo com

análise equilibrada das necessidades e expectativas das partes interessadas.” (Boletim ABNT, 10/2009)

2.3.1 A Série ISO 9000

(10)

• NBR ISO 9000: 2005 - Sistemas de Gestão da Qualidade - Conceitos e

Terminologia: descreve os fundamentos de sistemas de gestão da qualidade e estabelece a terminologia para esses sistemas;

• NBR ISO 9001:2008 - Sistemas de Gestão da Qualidade – Requisitos: especifica os

requisitos para um sistema de gestão da qualidade com enfoque na satisfação do cliente. Para uma organização ser certificada ISO 9001, ela precisa demonstrar sua capacidade para fornecer produtos que atendam aos requisitos do cliente (explícitos e implícitos) e os requisitos regulamentares aplicáveis;

• NBR ISO 9004:2010 - Gestão para o sucesso sustentado de uma organização — Uma Abordagem da Gestão da Qualidade (ISO 9004:2009): fornece diretrizes que

ampliam os requisitos estabelecidos pela ISO 9001, buscando melhoria contínua de desempenho e sucesso sustentável.

• NBR ISO 19011:2002 - Diretrizes para Auditoria de SGQ e/ou Ambiental: fornece

diretrizes para a condução das auditorias e determinação da competência dos auditores.

Normas da Série ISO 9000

2.3.1 A Série ISO 9000

Estabelece requisitos para:

i.

Sistema de Gestão da Qualidade



Requisitos Gerais



Requisitos de Documentação

ii.

Responsabilidades da Direção

iii. Gestão de Recursos

iv. Realização do Produto

v.

Medição Análise e Melhoria

A ISO 9001 - Sistemas de Gestão da Qualidade - Requisitos

2.3.1 A Série ISO 9000

(11)

Certificação ISO 9001

2.3.1 A Série ISO 9000

ISO 9001:2000 - Certificado

Certificado ISO 9001:2000 entregue ao Club Atletico Boca Juniors

(Argentina)

Escopo da certificação: Eventos Esportivos

2.3.1 A Série ISO 9000

(12)

• Estabelece uma estrutura comum para os processos de ciclo de vida de software,

com terminologia bem definida, que pode ser referenciada pela indústria de

software.

• Aplica-se à aquisição de sistemas, produtos e serviços de software, para o

fornecimento, o desenvolvimento, a operação e a manutenção de produtos de

software, quer sejam executados interna ou externamente a uma organização.

• Contém um conjunto de processos, atividades e tarefas projetado para ser

adaptado de acordo com cada projeto de software.

• A estrutura cobre o ciclo de vida do software desde a concepção de ideias até a

descontinuação do software.

2.3.2 ISO /IEC 12207 - Tecnologia de Informação - Processos de Ciclo de Vida de Software

A ISO/IEC 12207 descreve a arquitetura dos processos de ciclo de vida de software, mas:

• Não especifica os detalhes de como implementar ou executar as atividades e tarefas

incluídas nos processos.

• Não pretende prescrever o nome, formato ou conteúdo explícito da documentação

a ser produzida.

• Não prescreve um modelo específico de ciclo de vida ou métodos de

desenvolvimento de software. Fornece a arquitetura dos processos do ciclo de vida (processos, atividades e tarefas) Responsáveis por:

- Selecionar um modelo de ciclo de vida para o projeto.

- Mapear os processos, atividades e tarefas.

- Selecionar e aplicar métodos. - Executar atividades e tarefas do

projeto.

ISO 12207 Partes envolvidas

(13)

ISO /IEC 12207 – Histórico

• Em 1989 o JTC1 iniciou o desenvolvimento da ISO 12207, com o objetivo de identificar os Processos do Ciclo de Vida de Software.

• Foi desenvolvida com a participação de vários países, dentre eles o Brasil. • Publicada em 1995 (versão NBR em 1998).

• Sofreu duas emendas (em 2002 e 2004) para incluir processos e definição de propósitos e resultados esperados para cada processo, e para compatibilização com a ISO/IEC15504. • Em 2006 houve uma nova revisão para alinhamento com a ISO/IEC 15288 (Engenharia

de Sistemas – Processos de Ciclo de Vida de Sistemas).

• Em 2008 uma nova versão foi publicada (padrão ISO/IEC e IEEE) unindo as alterações das emendas anteriores.

ISO /IEC 12207 – Estrutura

•

24 processos: 23 agrupados em 3 tipos + um processo de adaptação.

•

Os Processos Fundamentais constituem um conjunto de cinco processos que

atendem aos adquirentes, fornecedores, desenvolvedores, operadores e

mantenedores do software, durante o seu ciclo de vida.

•

Os Processos de Apoio são processos empregados sou executados por outros

processos, quando necessário.

•

Os Processos Organizacionais são processos empregados por uma organização para

melhorar continuamente a sua estrutura e os seus processos. Eles são

tipicamente empregados fora do domínio de projetos e contratos específicos.

Até a versão de 2008

(14)

ISO 12207 – Processos

Processos Fundamentais Processos de Apoio

Pr o ce sso d e A d ap ta çã o Aquisição Documentação

Fornecimento Gerência de Configuração

Desenvolvimento Operação Garantia da Qualidade Verificação Validação Revisão Conjunta Manutenção Auditoria Usabilidade

Gerência de Resolução de Problemas

Gerência de Solicitação de Mudanças Avaliação do Produto

Processos Organizacionais

Gerência Engenharia de Domínio

Melhoria

Gerência de Ativos Infraestrutura

Gestão de Programa de Reúso Recursos Humanos

Até a versão de 2008:

ISO /IEC 12207: 2008 – Estrutura

•

43 processos + um processo de adaptação.

•

7 categorias:

- Processos relacionados a Acordos (Contratos)

- Processos relacionados à Habilitação Organizacional para Projetos

- Processos de Projeto

- Processos Técnicos

- Processos de Implementação do Software

- Processos de Apoio ao Software

- Processos de Reúso de Software

(15)

ISO /IEC 12207 :2008 - Processos Contratos Aquisição Fornecimento Habilitação Organizacional para Projetos Gerência do MCV Gerência de Infraestrutura Gerência de Portfólio Gerência de RH Gerência da Qualidade Projetos Planejamento de Projetos Acompanhamento e Controle de Projetos Gerência de Decisão Gerência de Riscos Gerência da Configuração Gerência da Informação Medição Técnicos Definição dos Requisitos dos Stakeholders Análise de Requisitos do Sistema Arquitetura do Sistema Implementação Teste de Qualificação do Sistema Instalação do Software Apoio à Aceitação do Software Integração Operação do Software Manutenção do Software Descontinuação do Software Implementação do Software Implementação do Software Análise de Requisitos do Software Projeto da Arquitetura do Software Projeto Detalhado do Software Construção do Software Integração do Software Teste de Qualificação do Software Apoio Gerência de Documentação do Software Gerência de Configuração do Software Garantia da Qualidade do Software Verificação do Software Validação do Software Revisão do Software Auditoria do Software Resolução de Problemas do Software Reúso de Software Engenharia de Domínio Gerência dos Ativos de

Reúso

Gerência do Programa de Reúso Processos Específicos de Software Processos para o Contexto de Sistemas

ISO /IEC 12207 – Estrutura

Processos possuem propósito e resultado(s). Todos os processos possuem pelo menos uma atividade. Os processos, junto com suas declarações de propósito e resultados, constituem um Modelo de Referência de Processo.

Notas são usadas quando uma informação explanatória é necessária para melhor descrever a intenção ou os mecanismos de um processo. Notas proveem uma orientação considerando potenciais implementações ou áreas de aplicabilidade, tais como listas, exemplos and outras considerações. Atividades são unidades de construção usadas para agrupar tarefas relacionadas. A partir da Emenda 1, se uma atividade é coesiva o suficiente, ela é convertida em um subprocesso por meio da definição de propósito e resultados.

Uma tarefa é uma cláusula detalhada para a implementação de um processo. Pode ser um requisito (deve - “shall”), uma recomendação (deveria - “should”) ou uma permissão (pode- “may”).

Nome, Propósito, Resultado(s) Atividade Nome Tarefa Nota 1 1 0..1 0..* 1 1..* 1..* 0..* Processo

(16)

• Propósito do Processo:

É o principal objetivo da execução do processo.

Convém que a implementação do processo forneça benefícios tangíveis aos envolvidos.

• Resultado do Processo:

Um resultado observável da realização com sucesso do propósito do processo. Um resultado pode ser:

i. um artefato produzido;

ii. uma mudança significativa de estado; e

iii. o atendimento das especificações, como por exemplo: requisitos, metas etc.

• O propósito e uma lista com os principais resultados do processo faz parte da descrição de cada processo no Modelo de Referência de Processo (alinhamento com a ISO 15504). • O propósito e os resultados são uma declaração das metas da execução de cada processo.

2.3.3 CMMI

(Capability Maturity Model Integration)

•

Definido pelo Software Engineering Institute (SEI) - Carnegie Mellon University, com o

intuito de quantificar a capacidade de uma organização produzir produtos de

software de alta qualidade, de forma previsível e consistente.

•

Descreve princípios e práticas dos quais depende a maturidade do processo de

software.

•

Define 5 níveis de maturidade para o processo de desenvolvimento.

•

Tem como objetivo auxiliar as organizações a aumentarem a maturidade de seus

processos por um caminho evolutivo.

•

Pode ser usado por empresas contratantes para identificar as características do

processo utilizado por seus fornecedores.

Informações Gerais

(17)

2.3.3 CMMI

(Capability Maturity Model Integration)

• Década de 80: o Departamento de Defesa Americano (DoD) patrocinou o SEI na elaboração de um modelo para avaliar a capacidade dos fornecedores de software do DoD. • 1986: início dos trabalhos.

• Agosto de 1991: publicada a versão 1.0 do SW-CMM (Capability Maturity Model). • Fevereiro de 1993: publicada a versão 1.1.

• Por ser específico para a área de software, o SW-CMM não contemplava outras áreas importantes das organizações, tais como Recursos Humanos e Engenharia de Sistemas. • Com o sucesso do SW-CMM, outros modelos semelhantes foram criados para outras áreas,

tais como Gestão de Recursos Humanos (People-CMM), Aquisição de Software (SA-CMM) e Engenharia de Sistemas (SE-CMM).

• Entretanto, os diversos modelos apresentavam estruturas, formatos e termos diferentes, dificultando sua aplicação conjunta.

Histórico

2.3.3 CMMI

(Capability Maturity Model Integration)

Histórico – Os ‘vários CMMs’

Software CMM Systems Security Engineering CMM Systems Engineering CMM People CMM SECM (EIA 731) Integrated Product Development CMM Software Acquisition CMM • Diferentes estruturas, formatos, termos, maneiras de medir maturidade. • Confusão, especialmente quando mais de um modelo é utilizado. • Difícil de integrar em um único programa de melhoria.

(18)

2.3.3 CMMI

(Capability Maturity Model Integration)

• O CMMI (Capability Maturity Model Integration) foi criado com a finalidade de

integrar os diversos modelos CMM.

• 1999: publicado o esboço (draft), versão 0.2: CMMISE/SW (Capability Maturity Model

-Integrated – System / Software Engineering).

• Agosto de 2000: publicada a versão 1.0 do CMMI.

• Março de 2002: publicada a versão 1.1 do CMMI.

• A versão 1.2 foi publicada em:

• Agosto de 2006 (CMMI for Development) • Novembro de 2007 (CMMI for Acquisition) • Fevereiro de 2009 (CMMI for Services)

• Novembro de 2010: publicada a versão 1.3 (atual) – Foco das alterações: alta maturidade.

Avaliações baseadas no CMMI 1.2 poderão ser realizadas até 30/11/2011.

2.3.3 CMMI

(Capability Maturity Model Integration)

• O CMMI é um modelo que descreve orientações para a definição e implantação de processos.

• O modelo não descreve processo algum, são orientações definidas através das práticas especificadas.

• Método de avaliação utilizado: SCAMPI (Standard CMMI Assessment Method for Process Improvement).

• O SCAMPI reúne as melhores práticas do CBA-PI e SCE (métodos amplamente utilizados pelo SW-CMM e outros modelos de melhoria de processos).

• Permite avaliação por nível de maturidade ou por capacidade de processo = por estágios ou contínua (similar à ISO/IEC 15504)

• Validade de uma avaliação: 3 anos.

(19)

1

Processo imprevisível, fracamente controlado e reativo

2

Processo caracterizado para projetos e muitas vezes, ainda, reativo

3

Processo caracterizado para a organização e pró-ativo

4

Desempenho do processo controlado estatisticamente

5

Foco na melhoria contínua do processo

Inicial Gerenciado Definido Gerenciado Quantitativamente Em Otimização

2.3.3 CMMI

(Capability Maturity Model Integration)

Níveis do CMMI

1

Processo imprevisível, fracamente controlado e reativo 2

Processo caracterizado para projetos e muitas vezes

reativo 3 Processo caracterizado para a organização e pró-ativo 4 Desempenho do processo controlado estatisticamente 5 Foco na melhoria contínua do processo Inicial

(REQM) Gerência de Requisitos (PP) Planejamento de Projeto (PMC) Monitoração e Controle de Projeto

(PPQA) Garantia da Qualidade do Processo e do Produto (SAM) Gerência de Acordo com Fornecedores

(CM) Gerência de Configuração (MA) Medição e Análise

Gerenciado

(IPM) Gerência Integrada de Projetos (OPD) Definição do Processo Organizacional

(OPF) Foco no Processo Organizacional (OT) Treinamento Organizacional (RD) Desenvolvimento de Requisitos (TS) Solução Técnica,

((PI) Integração do Produto (VER) Verificação (VAL) Validação (RSKM) Gerência de Riscos (DAR) Análise de Decisão e Resolução

Definido

(QPM) Gerência Quantitativa do Projeto (OPP) Desempenho do Processo Organizacional

Gerenciado Quantitativamente

(CAR) Análise de Causas e Resolução (OPM) Gerência do Desempenho Organizacional

Em Otimização

Qualidade de Software Monalessa Perini Barcellos

2.3.3 CMMI

(Capability Maturity Model Integration)

(20)

Process Area 1 Área de Processo 1 Process Area n Área de Processo n

Objetivos Específicos

Práticas Específicas

2.3.3 CMMI

(Capability Maturity Model Integration)

Estrutura Básica

Área de Processo 2

Objetivos Genéricos

Práticas Genéricas

SG - Se aplicam a uma área de processo e tratam de características que descrevem o

que deve ser implementado para satisfazer essa área. São utilizadas nas avaliações para auxiliar a determinar se a área de processo está sendo

satisfeita. Ex.: Gerenciar Requisitos: requisitos são gerenciados e inconsistências com planos de projeto e produtos de trabalho

são identificadas.

PA - Conjunto de práticas relacionadas em uma área que, quando implementadas de forma coletiva, satisfazem a um conjunto de objetivos considerados importantes para

realizar melhoria na referida área. Ex.: Gerência de Requisitos (RM)

SP - Atividades que são consideradas importantes para satisfazer o objetivo específico

associado. Ex.: : Manter rastreabilidade bidirecional entre requisitos: manter rastreabilidade bidirecional entre os requisitos, planos de projeto e produtos de

trabalho.

GP - Atividades que são consideradas importantes para

satisfazer o objetivo genérico associado e contribuem para a

institucionalização dos processos. Ex.: Prover os recursos adequados para implementar o

processo, desenvolver os produtos de trabalho e prover

os serviços do processo. GG – Aparecem em diversas área de processo. Ex.: GG do Nível 2 – O processo é institucionalizado como um processo gerenciado. Objetivos Específicos Práticas Específicas Objetivos Genéricos Práticas Genéricas Área de Processo 2 Produtos de Trabalho Típicos Subpráticas

Exemplos de saídas de uma prática específica ou genérica. Ex.: Para a SP Manter rastreabilidade bidirecional entre requisitos: Matriz de rastreabilidade; Sistema de Acompanhamento de Requisitos.

Descrições detalhadas que fornecem um direcionamento para a interpretação de práticas específicas ou genéricas. Ex.: Para a SP Manter rastreabilidade bidirecional entre requisitos: Elaborar uma matriz de rastreabilidade de requisitos.

(21)

2.3.3 CMMI

(Capability Maturity Model Integration)

Para uma avaliação

Objetivos Específicos Práticas Específicas Objetivos Genéricos Práticas Genéricas Área de Processo 2 Produtos de Trabalho Típicos Subpráticas Requerido _Requerido Esperado Esperado Informativo Informativo Cuidado… Na prática pode ser um pouco diferente…

2.3.3 CMMI

(Capability Maturity Model Integration)

Empresas CMMI no Brasil (2008 a 2010)

• Nível 5 = 4 (EDS SP (2008), Instituto Atlântico CE (2009), Accenture SP (2009), Spread Systems – MSA-Infor MG (2010), CPM Braxis BA (2010)). • Nível 4 = 0

• Nível 3 = 7 (4 em 2008, 3 em 2010)

• Nível 2 = 12 (3 em 2009, 9 em 2010)

(22)

2.3.3 CMMI

(Capability Maturity Model Integration)

Publicação dos Resultados das Avaliações CMMI

Os resultados das avaliações são publicados em

http://sas.sei.cmu.edu/pars/

2.3.3 CMMI

(Capability Maturity Model Integration)

Publicação dos Resultados das Avaliações CMMI

Os resultados das avaliações podem ser filtrados por ano, nível e modelo. Não facilita a obtenção de informações como, por exemplo: número de empresas em um determinado nível e número de empresas avaliadas em um determinado país.

(23)

2.3.3 CMMI

(Capability Maturity Model Integration)

De um nível para outro…

(tempo médio – em meses)

Inicial Gerenciado Definido Gerenciado Quantitativamente Em Otimização

Nota: é possível encontrar valores bem diferentes…

CONTÍNUA

• Níveis de capacidade

• Agrupamento de áreas de processo por categoria • Avaliação da capacidade nas áreas de processo

2.3.3 CMMI

(Capability Maturity Model Integration)

Representações

POR ESTÁGIOS

• Níveis de maturidade

• Agrupamento de áreas de processo por nível • Avaliação da Organização / Unidade Organizacional

como um todo

Nota: As PAs do CMMI são as mesmas para ambas as representações em sua versão atual (1.3). Até a versão 1.1 haviam diferenças.

(24)

2.3.3 CMMI

(Capability Maturity Model Integration)

Nível 1 – INICIAL

• O processo de software é caracterizado como sendo imprevisível e ocasionalmente caótico. Poucos processos são definidos e o sucesso depende de esforços individuais e, muitas vezes, heróicos.

• O processo de software é uma caixa preta, de forma que somente as entradas e os produtos finais podem ser vistos com clareza.

• Organizações no nível 1 apresentam deficiências de planejamento e enfrentam dificuldades ao realizarem previsões.

 Cronogramas e planos são irrealistas.

 Como não há credibilidade no planejamento, mesmo aquilo que foi planejado não é seguido.

• Não há controle de requisitos e o cliente só os avalia na entrega do produto.  É comum passar diretamente dos requisitos à codificação.

 A documentação é encarada como algo inútil.

• São comuns reações intransigentes à coleta de dados e ao uso de padrões, documentação e ferramentas.

2.3.3 CMMI

(Capability Maturity Model Integration)

Nível 2 – GERENCIADO

• Processos básicos de gerência de projetos são estabelecidos para controle de custos, prazos e escopo.

• É possível repetir sucessos de projetos anteriores em aplicações similares.

• Ao invés de o processo ser uma única caixa preta, ele passa a ser uma sequência de caixas pretas que asseguram a visibilidade em determinados pontos, os marcos do projeto.

• Neste nível, organizações têm maior probabilidade de cumprir compromissos de requisitos, prazos e custos, mas desde que sejam semelhantes a outros realizados anteriormente. • A organização é disciplinada, mas não está bem preparada para mudanças.

• Há preocupação com a gerência do projeto. Os gerentes acompanham custos, cronogramas e funcionalidades de cada um dos projetos. Porém, a gerência ainda não é pró-ativa, tomando ações normalmente quando se está diante de uma crise.

(25)

2.3.3 CMMI

(Capability Maturity Model Integration)

Nível 2 – GERENCIADO

• Os projetos podem ter processos diferentes. No entanto, existe uma política para guiar os projetos no estabelecimento desses processos.

• Controla-se a evolução dos requisitos, permitindo avaliações ao final de cada marco do projeto, e controla-se, também, a evolução das configurações do software.

• Medições são realizadas para começar a conhecer o comportamento dos processos. • Exemplo de PA do nível 2:

Garantia da Qualidade do Processo e do Produto: fornecer à equipe e à gerência

um entendimento objetivo dos processos e seus produtos de trabalho associados. Envolve:

 Avaliar objetivamente os processos, produtos de trabalho e serviços executados contra as descrições de processo, padrões e procedimentos aplicáveis.

 Identificar e documentar questões de não conformidades.

 Fornecer feedback para a equipe do projeto e gerentes sobre os resultados das atividades de garantia da qualidade.

 Assegurar que as questões de não conformidades sejam tratadas.

2.3.3 CMMI

(Capability Maturity Model Integration)

Nível 3 – DEFINIDO

• Um processo de software, composto por atividades de gerência, engenharia e apoio, é

documentado, padronizado e integrado em um processo de software padrão da organização.  Processos de engenharia de software são considerados ao lado dos processos gerenciais.

 Há treinamento técnico e gerencial.

• Processos utilizados são estabelecidos e padronizados em toda a organização.

 Todos os projetos utilizam uma versão aprovada e adaptada do processo organizacional para desenvolvimento e manutenção de software.

 A organização interna das tarefas está definida e visível  Os processos pertencem à organização e não aos projetos.

 O Grupo de Processos (Software Engineering Process Group - SEPG) é responsável pelos processos da organização.

 Apesar da padronização, é possível adaptar os processos para as necessidades particulares de um projeto.

• A organização consegue usar os processos mesmo em períodos de crise.

Como o processo é bem definido, caso um desenvolvedor abandone o projeto antes de seu término, o impacto é relativamente menor que nos níveis anteriores.

• Passagem do nível 2 para o 3: a padronização realizada é a oportunidade de escolher as melhores

práticas existentes na organização.

(26)

2.3.3 CMMI

(Capability Maturity Model Integration)

Nível 4 – GERENCIADO QUANTITATIVAMENTE

• Tanto o processo (processos críticos) como o produto de software são quantitativamente compreendidos e controlados.

• A organização estabelece para cada projeto objetivos quantitativos de qualidade e desempenho para as atividades do processo e para os produtos produzidos.

• Medidas de qualidade e desempenho são coletadas em todos os projetos como parte de um processo organizacional de medição e estabelecem uma base quantitativa para que os gerentes possam avaliar o progresso do desenvolvimento, o alcance aos objetivos e a ocorrência de problemas.

• A análise do comportamento dos processos críticos é realizada por meio do controle estatístico de processos.

• Os projetos melhoram o seu controle sobre os produtos e processos e a variância das medidas é diminuída.

2.3.3 CMMI

(Capability Maturity Model Integration)

Nível 5 – EM OTIMIZAÇÃO

• A melhoria contínua do processo é estabelecida por meio de sua avaliação quantitativa e da implantação planejada e controlada de tecnologias e ideias inovadoras.

• A organização está engajada na melhoria contínua de seus processos, possuindo meios para identificar fraquezas e fortalecer o processo de forma pró-ativa, prevenindo defeitos. • O entendimento do processo ultrapassa os processos praticados, possibilitando

compreender os efeitos de alterações potenciais no processo.

• Melhorias em processos e tecnologias são planejadas e executadas como parte das atividades de rotina.

• Mudanças mais significativas de processos ou de tecnologias são feitas a partir de análises de custo/benefício com base em dados quantitativos cuja coleta iniciou-se no nível 4.

(27)

2.3.3 CMMI

(Capability Maturity Model Integration)

Comparando as representações

Vantagens da Representação Contínua

• Fornece maior flexibilidade, focando em áreas de processo específicas de acordo com metas e objetivos de negócio das organizações.

• Permite a comparação de áreas de processo entre diferentes organizações.

• Estrutura familiar para aqueles que estão migrando da comunidade de engenharia de sistemas.

• Foco bem definido nos riscos específicos de cada área de processo. • Estrutura similar à ISO/IEC 15504.

Vantagens da Representação por Estágios

• Fornece um caminho de implementação por meio de grupos de área de processo e implementação em sequência.

• Cada nível funciona como a fundação para o próximo. • Estrutura familiar para aqueles que migram do SW-CMM. • Habilidade de gerenciar processos ao longo da organização.

• Em uma avaliação, atribui um nível de maturidade em que a organização se encontra, permitindo, assim, comparar organizações de forma direta.

2.3.3 CMMI

(Capability Maturity Model Integration)

Comparando as representações

Níveis de Capacidade x Níveis de Maturidade

• Contínua: há objetivos/práticas genéricos para os níveis 1, 2 e 3.

• Por estágios: há objetivos/práticas genéricos para os níveis 2 e 3.

Nota: na representação contínua, depois que uma organização atinge o nível 3, ela deve

implementar as áreas de processo da alta maturidade (OPP, QPM, CAR, OPM) para as áreas de processo implementadas.

(28)

2.3.3 CMMI

(Capability Maturity Model Integration)

As Áreas de Processo

São agrupadas em 4 categorias:

2.3.3 CMMI

(Capability Maturity Model Integration)

CMMI-DEV 1.3 x CMMI-DEV v1.2

Principais alterações

• A área de processo Gerência de Requisitos passou da categoria de Engenharia e para a de Gerência de Projetos.

• A área de processo Inovação e Desenvolvimento Organizacional (OID) foi substituída por Gerência do Desempenho Organizacional (OPM)

• Inclusão de novos objetivos e práticas específicas nas áreas de processo da alta maturidade. • Eliminação dos objetivos e práticas genéricas dos níves de maturidade 4 e 5.

• Eliminação dos níveis de capacidade 4 e 5.

• Atualização do material informativo considerando melhores práticas da indústria e incluindo orientações para organizações que usam métodos ágeis.

• Atualização e melhoria do glossário.

(29)

2.3.3 CMMI

(Capability Maturity Model Integration)

Links Úteis

Site oficial do CMMI:

http://www.sei.cmu.edu/cmmi/

Resultados das avaliações CMMI:

http://sas.sei.cmu.edu/pars/

Informações sobre a versão atual do CMMI (1.3):

http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/index.cfm

2.3.4 MR MPS.BR

• Dados da Secretaria de Política de Informática do MCT apontavam que apenas 30 empresas no Brasil possuíam avaliação CMM e 214 possuíam certificação ISO 9001.

Claramente, as empresas locais favoreciam a ISO 9000.

• Dados de uma pesquisa do MIT*, apontavam que até 2003, na Índia 32 empresas atingiram o nível 5 do CMM, enquanto a China tinha apenas uma e o Brasil nenhuma.

• Em relação ao CMM, a maioria das empresas chinesas e brasileiras não estava em um nível suficientemente alto de maturidade do processo para competir com as empresas indianas.

Empresas avaliadas CMM e ISO 9000 no Brasil até 2003

* Slicing the Knowledge-based Economy in Brazil, China and India: a tale of 3 software industries [MIT, 2003]

Motivação: o cenário da qualidade de processo de software em 2003

1997 1999 2001 2003 Certificação ISO 9000 102 206 167 214 Avaliação CMM (total) 1 2 6 30 Nível 5 - - - - Nível 4 - - - 1 Nível 3 1 1 4 5 Nível 2 - 1 2 24

(30)

2.3.4 MR MPS.BR

• Desejam um reconhecimento

internacional da qualidade do seu processo.

• O fator custo não é crítico.

• O processo como um todo pode

levar muitos anos (às vezes, até 10 anos!) e custar centenas de milhares de dólares.

• A melhoria de processo se dá de

maneira personalizada para cada empresa (Modelo de Negócio Específico).

Perfil das organizações no Brasil

• Necessitam melhorar seus processos

de software em conformidade com normas internacionais (como ISO/IEC 12207 e 15504) e em compatibilidade com outros modelos (como CMMI níveis 2 e 3).

Empresas exportadoras de software e outras grandes empresas

Micro, pequenas e médias empresas que desenvolvem

software no/para o Brasil

• A melhoria de processo se dá por

meio de pacotes de serviços para grupos de empresas (Modelo de Negócio Cooperado).

• O fator custo é crítico.

• O processo pode levar de

2 a 4 anos e custar dezenas de milhares de dólares.

Objetivo

Melhoria de processos de software nas micro, pequenas e médias empresas (PMEs), a um custo acessível, em diversos locais do país.

2.3.4 MR MPS.BR

Em dezembro de 2003 teve início o programa mobilizador para a Melhoria do Processo de Software Brasileiro, coordenado pela Softex (Associação para Promoção da

Excelência do Software Brasileiro), com apoio do Ministério da Ciência e Tecnologia (MCT) e do Banco Interamericano de Desenvolvimento (BID).

Surgimento do MR MPS.BR

 Desenvolvimento e aprimoramento do MR MPS.BR.

 Implementação e avaliação do MR MPS.BR em empresas, com foco em grupos de empresas.

Como?

(31)

2.3.4 MR MPS.BR

MR MPS.BR Modelo de Referência para Melhoria de Processo de Software Brasileiro Realidade das Empresas Brasileiras SOFTEX Governo Universidades Base Técnica ISO/IEC 12207 Definição de Processos, Propósitos e Resultados CMMI Complementação de Processos ISO/IEC 15504 Definição da Capacidade de Processos, Requisitos de Avaliação Histórico • Abril de 2005: Versão 1.0 • Maio de 2006: Versão 1.1 • Junho de 2007: Versão 1.2 • Junho de 2009: Versão 2009 • Junho de 2011: Versão 2011

2.3.4 MR MPS.BR

Estrutura do MR MPS.BR

Programa MPS.BR Modelo de Negócio (MN-MPS) Método de Avaliação (MA-MPS) Guia de Aquisição Guia Geral Modelo de Referência (MR-MPS)

Guia de Avaliação Documento do Programa ISO/IEC 12207

Guias de Implementação

ISO/IEC 15504 CMMI-DEV

(32)

2.3.4 MR MPS.BR

Estrutura do MR MPS.BR

Programa

MPS.BR

(SOFTEX)

Instituições Implementadoras (IIs) Instituições Avaliadoras (IAs)

MNE - Modelo de Negócio Específico para cada Empresa (personalizado) MNC - Modelo de Negócio Cooperado em Grupo de Empresas (pacote) Contrato Contrato Convênio Convênio, se pertinente

MN-MPS: Modelo de Negócio

2.3.4 MR MPS.BR

(33)

Capacitação MPS.BR

16h

24h

16h 24h

Workshop: WAMPS: Workshop Anual do MPS.BR

C1 - Curso Introdução ao MPS.BR P1 - Prova Introdução ao MPS.BR C2 - Curso Implementadores MR-MPS P2 - Prova Implementadores MR-MPS C3 - Curso Avaliadores MA-MPS P3 - Prova Avaliadores MA-MPS C4 - Curso Guia de Aquisição MPS.BR P4 - Prova Guia de Aquisição MPS.BR

Implementador MR-MPS Avaliador Adjunto MA-MPS Consultor de Aquisição, após projeto assistido

2.3.4 MR MPS.BR

Estrutura do MR MPS.BR

(34)

2.3.4 MR MPS.BR

• Descreve o Modelo de Referência para Melhoria do Processo de Software (MR-MPS) e fornece uma visão geral sobre os demais guias que apoiam os processos de avaliação e de aquisição.

• Público alvo: IIs, IAs e organizações que desejam aplicar o MR-MPS.

• Contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o MR-MPS.

• Não define atividades e tarefas necessárias para atender aos requisitos.

• Está em conformidade com os requisitos de Modelos de Referência de Processo da norma ISO/IEC 15504-2.

Guia Geral

Níveis de Maturidade Capacidade Processo Resultados Resultados Propósito Atributos

2.3.4 MR MPS.BR

Estrutura do MR-MPS

São uma combinação entre

processos e sua capacidade. Vão do G ao A. Equivalente ao conceito de área de

processo no CMMI. No MR MPS um processo é descrito por seu

propósito e resultados. Ex.: Gerência de Projetos (GPR)

Descreve o objetivo geral a ser atingido com a execução do

processo. Ex.: GPR: 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.

Estabelecem os resultados a serem obtidos com a efetiva implementação do

processo.

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

Expressa o grau de refinamento e institucionalização com que o

processo é executado na organização / unidade

organizacional.

Características que devem ser satisfeitas para uma determinada capacidade. Ex.: AP 1.1 – O processo é executado Estabelecem os resultados esperados quando se satisfaz o atributo de processo associado. Ex.: RAP 1. O processo atinge seus resultados

definidos.

(35)

2.3.4 MR MPS.BR

• São uma combinação entre processos e sua capacidade.

• O progresso e o alcance de um determinado nível de maturidade do MR-MPS se obtém quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele nível.

Os Níveis de Maturidade

• A existência de mais níveis é mais adequada a pequenas e médias empresas

 Maior visibilidade dos programas de melhoria.  Redução dos custos de

obtenção de cada nível.

2.3.4 MR MPS.BR

(36)

2.3.4 MR MPS.BR

• Expressa o grau de refinamento e institucionalização com que o processo é executado na organização / unidade organizacional.

• Está relacionada com o atendimento aos atributos de processo associados aos processos de cada nível de maturidade.

• À medida que a organização / unidade organizacional evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido pela organização. • Atributos de Processo (AP):

AP 1.1 – O processo é executado. AP 2.1 – O processo é gerenciado.

AP 2.2 – Os produtos de trabalho do processo são gerenciados. AP 3.1 – O processo é definido.

AP 3.2 – O processo está implementado. AP 4.1 – O processo é medido. AP 4.2 – O processo é controlado.

AP 5.1 – O processo é objeto de melhorias e inovações. AP 5.2 – O processo é otimizado continuamente.

Capacidade do Processo

2.3.4 MR MPS.BR

Gerência de Projetos - GPR

GPR - Propósito: 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 (nos níveis E e B).

A descrição dos níveis

Exemplo: Nível G – Parcialmente Gerenciado

Nível Processos Capacidade

G Gerência de Projetos (GPR) Resultados: GPR 1 a GPR 17 GPR 4 (até o Nível F) AP 1.1 e AP 2.1 Resultados: RAP 1 a RAP 10 Sendo: RAP 4 e 10 (G); RAP 5, 6, 7 e 9 (até o Nível F) Gerência de Requisitos

Resultados: GRE 1 a GRE 5

(37)

2.3.4 MR MPS.BR

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

2.3.4 MR MPS.BR

GPR 11. 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.

GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido. GPR 13. O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que afetam o projeto e os resultados são documentados.

GPR 14. O envolvimento das partes interessadas no projeto é gerenciado.

GPR 15. Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento. GPR 16. 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 17. 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.

GPR – Resultados Esperados (cont.)

(38)

2.3.4 MR MPS.BR

Propósito: 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.

Resultados Esperados:

GRE 1. Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos.

GRE 2. O comprometimento da equipe técnica com os requisitos aprovados é obtido. GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida.

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

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

Gerência de Requisitos - GRE

2.3.4 MR MPS.BR

AP 1.1 – O processo é executado.

Este atributo é uma medida do quanto o processo atinge seu propósito. RAP 1. O processo atinge seus resultados definidos.

AP 2.1 – O processo é gerenciado.

Este atributo é uma medida do quanto a execução do processo é gerenciada. 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. RAP 5. (Até o nível F) 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. (Até o nível F) As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência.

RAP 8. A comunicação entre as partes interessadas no processo é gerenciada 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.

Atributos de Processo do Nível G

(39)

2.3.4 MR MPS.BR

Os atributos de processo AP 4.1, AP 4.2, AP 5.1 e AP 5.2 somente devem ser implementados para os

processos críticos da organização/unidade organizacional,

selecionados para análise de desempenho. Os demais atributos de processo

devem ser implementados para todos os processos.

Atributos de Processo e Resultados Esperados por Nível

2.3.4 MR MPS.BR

Estrutura do MR MPS.BR

(40)

2.3.4 MR MPS.BR

• Fornecem orientações para implementar nas organizações os níveis de maturidade descritos no MR-MPS, detalhando os processos contemplados nos respectivos níveis de maturidade e os resultados esperados com a implementação dos processos.

• Público alvo: IIs, IAs e organizações que desejam aplicar o MR-MPS. • Composto por dez documentos:

• Fundamentação para implementação do MR-MPS:2011

Parte 1: do Nível G Parte 2: do Nível F Parte 3: do Nível E Parte 4: do Nível D Parte 5: do Nível C Parte 6: do Nível B Parte 7: do Nível A • Implementação do MR-MPS:2011 em organizações

Parte 8: que adquirem software Parte 9: do tipo Fábrica de Software Parte 10: do tipo Fábrica de Teste

Guias de Implementação

2.3.4 MR MPS.BR

• Evoluindo do Nível Y para o Nível X (a partir de F)

• Começando a Implementação do MPS.BR pelo Nível X (somente até o E) • Cada processo

 Propósito

 Fundamentação Teórica  Resultados Esperados

• Os Atributos de Processo no Nível X