Desenvolvimento de Sistemas Web - Luiz Leaoluizleao.com/Docencia/FAP/PDS/PDS_UND_04.pdf · fornecedores de software • Baseou-se nos estudos dos principais autores sobre ... por

Luiz Leão – [email protected]

http://www.luizleao.com

Unidade IV – Introdução aos Padrões de PDS

Processo de Desenvolvimento de Software

mailto:[email protected]

http://www.luizleao.com/


Unidade IV – Introdução a Padrões de PDS

Conteúdo da Unidade

1. CMM / CMMI

2. SPICE

3. ISO 12207

4. MPS/BR

CMM - Capability Maturity

Model



CMM

• Capability Maturity Model – Modelo de Maturidade em

capacitação

• Criado pelo SEI (Software Engineering Institute) no final

da década de 80 como SW-CMM (Capability Maturity

Model for Software)

• Obteve grande sucesso ao gerar novos padrões para a

engenharia de sistemas



CMM (Cont.)

• Surgiu devido o patrocínio do Departamento de Defesa

dos EUA, para a avaliação da capacidade dos seus

fornecedores de software

• Baseou-se nos estudos dos principais autores sobre

qualidade industrial

• Alguns dos princípios desse modelo encontramos no

livro de Phillip Crosby – Quality is free [1992], tais

como os 5 estágios de maturidade do modelo



CMM (Cont.)

• Por ser específico da área de software, não participam

do escopo do SW-CMM outras áreas importantes como

Recursos Humanos e Finanças. Assim sua aplicação

não garante a viabilidade de uma organização, embora

possa ser um fator importante de melhoria da eficácia e

da competitividade. [KOSCIANSKI, 2007]



CMM (Cont.)

• Foco: Processo – Fator com maior potencial de melhoria

a curto prazo



Níveis de Maturidade

• O objetivo principal do CMM é que as organizações

conheçam e melhorem seus processos de

desenvolvimento de software com a implementação de

práticas definidas

• A melhoria de um processo é baseada em vários

pequenos passos evolucionários em 5 níveis, que

definem uma escalada para avaliar a maturidade do

processo dentro da empresa







• Nível 1 – Inicial

• Nível 2 – Repetitivo

• Nível 3 – Definido

• Nível 4 – Gerenciado

• Nível 5 – Otimizado



Nível 1 – Inicial

• Poucos processos definidos

• Sucesso depende muitas vezes ações individuais

• Organizações nesse nível, muitas vezes, são bem

sucedidas, mas isso em geral se restringe ao

desenvolvimento de produtos com os quais já estiveram

envolvidas anteriormente [Weinberg, 1994]




• Cronogramas e planos são irrealistas e acabam sendo

alterados inúmeras vezes

• Costuma ocorrer saltos nas transição das etapas do

PDS

• Mudanças culturais devem ser implantadas pela

gestão, com a finalidade de se habituar a equipe a

implantação de processos de software



Nível 2 – Repetitivo

• Maior probabilidade de cumprir com cronograma e orçamento, mas desde que seja projetos semelhantes aos já desenvolvidos

• Há preocupação com a gerência do projeto; por exemplo, as práticas de fazer reuniões semanais e de acompanhar o cronograma constantemente são definidas pelos gerentes e seguidas pela equipe.

• Os gerentes, então, conseguem identificar problemas – como dificuldade em atingir prazos – antes que estes apareçam ou se tornem críticos




• Organizações nesse nível, são disciplinadas ao executar

projetos, mas não está bem preparada para mudanças

• É incapaz de prever o resultado da adoção de novas

ferramentas e métodos, ou do desenvolvimento de

novos produtos




• Áreas-chave:

1. Gestão dos Requisitos: Permite a definição e o controle dos requisitos, evitando descontrole nas mudanças, e um acordo entre stackholders e desenvolvedores sobre as funcionalidades requeridas no software

2. Planejamento de Projeto: Estabelece planos do projeto, possibilitando a previsão de prazos e custos

3. Supervisão e Acompanhamento de Projetos: Verifica o atendimento dos compromissos, comparando o que foi atingido com o que havia sido planejado e acionando providências corretivas sempre que haja desvios significativos




• Áreas-chave (Cont.):

4. Gestão de Subcontratação: Gerencia as organizações subcontratadas para desenvolver partes do software segundo padrões de qualidade estabelecidos

5. Grupo de Garantia de Qualidade: Verifica o cumprimento dos compromissos de forma independente em relação aos projetos e verificando a qualidade do processo e dos produtos

6. Gestão de configurações: Garante a consistência permanente dos resultados dos projetos em relação aos requisitos, mesmo quando ocorrem alterações nos compromissos



Nível 3 – Definido

• As organizações já adquiriram conhecimento, baseado

no sucesso de projetos anteriores, estabelecendo assim

uma infraestrutura de processos que permite adaptação

a mudanças para novos projetos

• Conseguem manter-se dentro do processo, mesmo em

momentos de crise



Nível 3 – Definido (Cont.)

• Há ganhos significativos de Qualidade e Produtividade

• Porém, o conhecimento sobre o processo ainda é

basicamente qualitativo

• Ainda estão sendo elaborada a base de conhecimento a

fim de definir metas quantitativas de desempenho de

processo e de qualidade de produto




• Áreas-chave:

1. Grupo de Engenharia de processos de software é

estabelecido, sendo responsável pelas atividades de

desenvolvimento, melhoria e manutenção dos processos

2. Processo-padrão de software no âmbito da organização é

estabelecido, a partir do qual devem ser derivados os

processos definidos para os projetos




• Áreas-chave: (Cont.)

3. Programas de treinamento são estabelecidos para que

membros das equipes desenvolvam suas habilidades técnicas

e seus conhecimentos, e possam realizar seu trabalho de

forma eficiente

4. Gestão integrada de projetos: Baseada nos processos

definidos para os projetos , com o uso de procedimentos

documentados para gestão de tamanho, esforço, prazos e

riscos.




• Áreas-chave: (Cont.)

5. Padronização no âmbito da organização dos métodos de

engenharia de software, abrangendo requisitos, projetos

codificação, testes e documentação.

6. Coordenação entre grupos que participam de projetos de

sistemas, no âmbito da organização

7. Coordenação de revisões no âmbito da organização, com

os objetivos de remover e evitar defeitos



Nível 4 – Gerenciado

• A administração de processos e produtos evolui para um

tratamento quantitativo.

• A organização é proficiente em coleta de métricas de

software e na gestão da base de dados de processo

• A Produtividade e a Qualidade são medidas em todos os

projetos como parte de um programa organizacional

Ex: Aplicativos do Google possuem semelhanças na forma

de interagir, o que é refletido em soluções de qualidade, que

possuem uma identidade



Nível 4 – Gerenciado (Cont.)

• São estabelecidas métricas quantitativas para avaliar os

processos e os produtos

• Os riscos envolvidos no aprendizado para

desenvolvimento em um novo domínio da aplicação

são cuidadosamente gerenciados

• Como resultado desse maior controle, coleta de dados e

gerenciamento de riscos, os produtos de software

tendem a apresentar maior qualidade



Nível 4 – Gerenciado (Cont.)

• Áreas-chave:

1. Gestão Quantitativa dos Processos: Controla o desempenho

dos processos usados pelos projetos. O foco é identificar

causas especiais de variações e, de forma apropriada, corrigi-

las.

2. Gestão de Qualidade de Software: Promove o entendimento

quantitativo da qualidade dos produtos de software, aplicando

métricas nesses produtos.



Nível 5 – Otimizado

• Os processos estão em melhoria contínua, sendo

otimizados para as necessidades de cada projeto

• Os gerentes identificam pontos fracos de cada processo

e agem de forma pró-ativa para que estes sejam

melhorados.



Nível 5 – Otimizado (Cont.)

• A eficiência medida é usada para a análise de custo-

benefício de novas tecnologias

• Os defeitos são identificados e resolvidos, e suas

causas são estudadas para não serem repetidas: as

lições aprendidas com erros e acertos são usadas nos

projetos seguintes




• Áreas-chave:

1. Prevenção dos Defeitos por meio da identificação e remoção

de suas causas.

2. Gestão da Evolução Tecnológica com procedimentos

sistemáticos de identificação, análise e introdução de

tecnologias apropriadas de forma eficiente nos projetos, como

novas ferramentas, linguagens e técnicas de desenvolvimento




• Áreas-chave (Cont.):

3. Gestão das Mudanças de Processos, com base nos dados

coletados do processo, colocando-os em melhoria contínua.

CMMI - Capability Maturity

Model Integration



CMMI – Introdução

• Com o sucesso do SW-CMM,

novos modelos semelhantes

forma desenvolvidos:

– P-CMM: Gestão de Recursos

Humanos

– SA-CMM: Aquisição de Software

– SE-CMM: Engenharia de Sistemas

– Etc.




• Porém, como possuem estruturas diferentes entre si,

dificultando o uso mais de um modelo no mesmo

projeto, surgiu o CMMI, cuja finalidade é evoluir o

modelo anterior (SW-CMM), integrando os diversos

modelos criados



CMMI – Evolução




• Versões do CMMI:

– Versão 1.0: Agosto de 2000

– Versão 1.1: Março de 2002

– Versão 1.2: Agosto de 2006 (CMMI for Development)

– Versão 1.3: Novembro de 2010




• A versão atual do CMMI (1.3), apresenta 3 modelos:

– CMMI for Development (CMMI-DEV), voltado ao processo de

desenvolvimento de produtos e serviços.

– CMMI for Acquisition (CMMI-ACQ), voltado aos processos de

aquisição e terceirização de bens e serviços.

– CMMI for Services (CMMI-SVC), voltado aos processos de

empresas prestadoras de serviços.






CMMI – Objetivos

• Aumento do foco nas atividades;

• Integração dos processos existentes;

• Eliminar inconsistências;

• Reduzir duplicações;

• Fornecer terminologia comum;

• Assegurar consistência com a norma ISO 15504

(SPICE);

• Flexibilidade e Extensão para outras disciplinas.



CMMI – Resumindo...

• Prover um guia para a melhoria de processos

organizacionais e habilidades de gestão do

desenvolvimento, aquisição e manutenção de produtos

e serviços.



CMMI – Atenção!!

• O CMMI não é um conjunto de processos definidos a

serem utilizados na organização

• O CMMI não é uma metodologia



CMMI

• O CMMI possui 2 representações:

– Representação Contínua

– Representação por Estágios

Representações:



CMMI

• Possibilita à organização utilizar a ordem de melhoria

que melhor atende os objetivos de negócio da empresa.

• É caracterizado por Níveis de Capacitação (Capability

Levels):

Representação Contínua



CMMI

• Níveis de Capacitação

• Agrupamento das Áreas de Processo por Categoria

• Avaliação da capacidade das Áreas de Processo

Representação Contínua – Resumo



CMMI

• Oferece máxima flexibilidade na utilização do modelo

para a melhoria de processos

– A organização pode escolher a ordem de melhoria que melhor

se encaixa a seus objetivos

• Permite comparação com outras organizações processo

a processo

• Fácil comparação com a ISO 15504

Representação Contínua – Vantagens



CMMI

• Os processos da organização que precisam ser

melhorados devem ser conhecidos previamente

– Nem sempre isso é possível

• Flexibilidade de escolha não é de 100%

– Existem dependências entre as áreas de processo – isto pode

limitar as escolhas da organização

• Maior retorno sobre o investimento de empresas com

abordagem contínua ainda não foi comprovado

Representação Contínua – Desvantagens



CMMI

• Nível 0: Incompleto

• Nível 1: Executado

• Nível 2: Gerenciado

• Nível 3: Definido

• Nível 4: Gerenciado Quantitativamente

• Nível 5: Otimizado

Representação Contínua – Níveis de Capacitação



CMMI

Representação Contínua – Níveis de Capacitação



CMMI

• O nível incompleto corresponde, no caso mais simples,

à não-realização de um processo.

• Se o processo é implantado pela organização, o nível 0

é atribuído quando um ou mais objetivos específicos da

área de processo não são satisfeitos.

Nível 0 – Incompleto



CMMI

• Para estar no nível 1, cada processo deve cumprir todos

os objetivos específicos de sua área.

• Um processo utiliza entradas determinadas e leva à

obtenção de produtos específicos, identificados como

saídas.

Nível 1 – Realizado



CMMI

• Os processos são monitorados, controlados, e

revisados, assim como os produtos resultantes

• Todo processo é institucionalizado, sendo ancorado nos

objetivos da organização e devendo cumprir com metas

como custo, prazo e qualidade.

• É planejado e seu desempenho é gerenciado de acordo

com tal plano de ação.




CMMI

• O processo está adaptado a um conjunto de processos

padronizados da organização, seguindo suas diretivas.

• Processos padronizados são estabelecidos e

melhorados continuamente.

• A descrição de um processo definido inclui, entre outros

tópicos, suas entradas, atividades, medidas,

verificações e saídas




CMMI

• São estabelecidas métricas quantitativas para avaliar os

processos e os produtos.

• Os riscos envolvidos no aprendizado para

desenvolvimento em um novo domínio da aplicação

são cuidadosamente gerenciados.

• Como resultado desse maior controle, coleta de dados e

gerenciamento de riscos, os produtos de software

tendem a apresentar maior qualidade.

Nível 4 – Gerenciado Quantitativamente



CMMI

• O processo gerido quantitativamente é alterado e

adaptado para atender às necessidades

negociais/estratégicas da empresa.

• Um processo otimizado possui como foco a melhoria

contínua de desempenho.

• Esse objetivo é buscado por melhorias tecnológicas

incrementais e de inovação.

Nível 5 – Otimizado



CMMI

• Disponibiliza uma sequência pré-determinada para

melhoria baseada em estágios que não deve ser

desconsiderada, pois cada estágio serve de base para o

próximo.

• É caracterizado por Níveis de Maturidade (Maturity

Levels):

Representação Por Estágios



CMMI

• Níveis de Maturidade

• Agrupamento de Áreas de Processo por Nível

• Avaliação da Organização como um todo

Representação Por Estágios – Resumo



CMMI

• Provê uma sequência bem definida de melhoria de

processos

• Permite comparações entre organizações por meio do

uso de níveis de maturidade

• Provê uma única classificação que resume os

resultados das avaliações e permite a comparação

simples entre organizações

Representação Por Estágios – Vantagens



CMMI

• Rigidez na escolha das áreas de processos a serem

melhoradas

– Mesmo se não for de interesse da empresa é necessário

melhorá-lo

• O custo pode ser maior, caso a empresa não tenha

interesse em algumas áreas de processo, mas tenha

que implementá-la mesmo assim

Representação Por Estágios – Desvantagens



CMMI

• Nível 1: Inicial

• Nível 2: Gerenciado

• Nível 3: Definido

• Nível 4: Gerenciado Quantitativamente

• Nível 5: Otimizado

Representação Por Estágios – Níveis de Maturidade



CMMI

Representação Por Estágios – Níveis de Maturidade



CMMI


• Processos são ad hoc e caóticos

• A organização não fornece um ambiente estável para

apoiar os processos

• O sucesso depende do heroísmo e da competência de

pessoas individualmente

• Organizações neste nível se comprometem além de sua

capacidade, abandonam o processo em momentos de

crise e são incapazes de repetir os próprios sucessos



CMMI


• Os processos são planejados e executados de acordo

com uma política

• Recursos adequados e pessoas experientes são

envolvidos para produzir saídas controladas

• Inclui medição, controle e revisão dos processos

• É alcançado pelas metas específicas das áreas de

processo de nível 2 e a meta genérica 2



CMMI


• Processos são bem caracterizados e entendidos, e são

descritos em padrões, procedimentos, ferramentas e

métodos

• No nível 2, cada projeto tinha seus padrões,

procedimentos, etc... No nível 3 há um padrão da

organização

• Os projetos estabelecem seus processos adaptando

este padrão


processos de nível 2 e 3 e metas genéricas 2 e 3



CMMI

Nível 4 – Gerenciado Quantitativamente

• Objetivos quantitativos são estabelecidos para a

qualidade e desempenho dos processos

• Medições são feitas por meio de técnicas estatísticas e

quantitativas, apenas para os subprocessos mais

relevantes


processo de nível 2, 3 e 4 e metas genéricas 2 e 3



CMMI

Nível 5 – Em Otimização

• Os processos são melhorados continuamente com

base no entendimento quantitativo das

• causas comuns de variações inerentes aos processos

• As melhorias são escolhidas e comparadas ao seu

custo e impacto na organização


processo de nível 2, 3, 4 e 5 e metas genéricas 2 e 3



CMMI

Contínua X Por Estágios

• A principal diferença é a forma como cada

representação é aplicada

• Os níveis de capacitação (Contínua) são aplicados na

melhoria de processos de uma organização para cada

área

• Os níveis de maturidade (Por Estágios) indicam

melhorias na organização como um todo.



CMMI




CMMI




CMMI


ISO/IEC 15504 – SPICE




• Software Process Improvement and Capability

dEtermination – Melhoria de Processos de Software e

Determinação de Capacidade

• É um modelo baseado em níveis de capacidade mais

geral e abrangente que os modelos anteriores e mais

específico para software que a ISO 9001

• Apresenta uma estrutura para Avaliação (e Melhoria)

de Processo




• Influenciada por um conjunto de padrões que na base

do projeto SPICE.

• Incluindo, a sua principal fonte de inspiração é a norma

ISO 12207 – um standard internacional da ISO para os

processos do ciclo de vida do software.







• Melhoria Contínua: Avaliação identifica oportunidades

de melhoria. Feita por organizações que buscam

melhorias internas

• Determinação da Capacidade: Avaliação identifica

riscos com o fornecedor. Feita por terceiros ao

realizarem contratos de prestação de serviços ou

fornecimento de produtos.

Contextos de Utilização:







• 1991: Estudo sobre a necessidade de uma norma para

avaliação de processos de software.

• 1993: Início do Projeto SPICE (Software Process

• Improvement and Capability dEtermination).

• 1998: Versão Inicial da “norma SPICE” (publicada como

Relatório Técnico - TR).

• 2003: Encerramento do Projeto SPICE e publicação da

parte 2.

• 2004: Publicação das partes 1, 3 e 4.

Histórico:



A “Norma SPICE”

• Focada exclusivamente em software.

• É um modelo para avaliação de processos de software.

• Possui um modelo de referência que é a base da

Avaliação dos Processos.

• Dá suporte a todo o ciclo de vida do software.

• Dividida em 9 partes.

• Apenas um Relatório Técnico e não uma norma

internacional.



A “Antiga Norma SPICE”



A “Norma SPICE”: Processos (Parte 7)




• É uma norma internacional.

• É genérica, não sendo mais dedicada exclusivamente a

software.

• Introduz o conceito de Modelo de Referência de

Processo, que é externo à norma (antiga parte 2).

• Para ser aplicada à software, deve ser complementada

pela ISO/IEC 12207, considerando suas emendas 1 e 2.




• Dividida em 5 partes:

– 1: Conceitos e vocabulário (antigas partes 1 e 9)

– 2: Estrutura (framework) do processo de avaliação (antiga parte

3).

– 3: Recomendações para a realização de uma avaliação (antigas

partes 4 e 6)

– 4: Recomendações para melhoria de processos e determinação

de capacidade (antigas partes 7 e 8).

– 5: Um exemplo de aplicação com base na ISO 12207.



ISO/IEC 15504: Estrutura



ISO/IEC 15504

• Parte 1 - Conceitos e vocabulário (informativa): Provê uma

introdução geral aos conceitos de avaliação de processos e um

glossário de termos relacionados à avaliação.

• Parte 2 - Realização de uma avaliação (normativa): Define os

requisitos normativos para a realização de uma avaliação de

processo e para modelos de processo em uma avaliação, e define

uma infra-estrutura de medição para avaliar a capacidade de

processo. Essa infraestrutura de medição define nove atributos de

processo, agrupados em seis níveis de capacidade de processo.



ISO/IEC 15504

• Parte 3 - Guia para a realização de avaliações (informativa): Provê

orientações para interpretar os requisitos para a realização de uma

avaliação.

• Parte 4 - Guia para uso na melhoria de processo e na determinação da

capacidade de processo (informativa): Provê orientações para a

utilização de avaliação de processo para propósitos de melhoria de

processo e de determinação da capacidade.

• Parte 5 - Um Exemplo de modelo de avaliação de processo baseado

na ISO/IEC 12207 e suas Emendas 1 e 2 (informativa): Contém um

exemplo de modelo de avaliação de processo que é baseado no modelo de

processo de referência definido na ISO/IEC 12207 e suas emendas 1 e 2.



ISO/IEC 15504: Estrutura

• [1] Visão geral e vocabulário

• [2] Estrutura para medição de capacidade de processo, composta por seis

níveis de capacidade(0 a 5)

• [2] Requisitos para um processo de avaliação de processo

• [2] Requisitos para modelos de referência de processo

• [2] Requisitos para modelos de avaliação de processo

• [2] Requisitos para verificação de conformidade de uma avaliação

• [3] Guia para avaliação de processo

• [3] Orientações para qualificação de avaliadores competentes

• [3] Exemplo de atividades de um processo de avaliação

• [4] Guia para utilização dos resultados de uma avaliação de processo, para

melhoria ou determinação de capacidade

• [5] Exemplo de um modelo de avaliação de processo de software

Normativo



ISO/IEC 15504: Dimensões

• Dimensão de Processo: Corresponde à definição de

um conjunto de processos considerados universais e

fundamentais para a boa prática da engenharia de

software; Atualmente, um modelo de referência de

processo no domínio de software é a ISO 12207;

• Dimensão de Capacidade: Permite uma avaliação

detalhada dos processos executados por uma

organização. Trabalha com: – Níveis de capacidade

– Atributos de processo



ISO/IEC 15504: Dimensões



ISO/IEC 15504: Atributos de Processo

• 1.1 Execução: O processo atinge os objetivos

esperados.

• 2.1 Administração do Processo: Objetivos do

processo são identificados e sua execução é planejada.

Responsabilidades são atribuídas, a infra-estrutura é

fornecida e a comunicação entre os envolvidos é

gerenciada.

• 2.2 Administração do Produto: Produtos do processo

são identificados e documentados, requisitos para eles

são definidos e revisões e ajustes são efetuados

conforme necessário.




• 3.1 Definição: Um processo padrão é definido para a

organização.

• 3.2 Implementação: Os elementos identificados em 3.1

são postos em prática.

• 4.1 Medição: Estabelecem-se objetivos quantitativos,

bem como as medições a serem realizadas e a

frequência de sua aplicação. Os resultados são

coletados, analisados e publicados na organização.

• 4.2 Controle: Estabelecem-se limites de variação para

as medidas e ações corretivas para tratar as causas de

desvios em relação a esses limites.




• 5.1 Inovação: Objetivos de melhoria são estabelecidos.

Oportunidades de melhoria são identificadas.

• 5.2 Otimização: O desempenho do processo é medido

e o impacto das melhorias propostas é comparado com

os objetivos esperados. A implementação de mudanças

é gerenciada.



ISO/IEC 15504: Avaliação de Atributos

Grau de Satisfação

N

Não atingido

0 a 15% Existe pouca ou nenhuma evidência de

que o atributo de processo seja

alcançado.

P

Parcialmente

atingido

16 a 50% Existe evidência de uma abordagem

significativa para atingir o atributo,

mas alguns aspectos (tais como

resultados) são ainda imprevisíveis.

L

Largamente

atingido

51 a 85% O desempenho do processo pode

variar em algumas áreas.

T

Totalmente

Atingido

86 a 100% Não há nenhuma falta ou falha

significativa.



ISO/IEC 15504: Níveis Exigidos de Capacidade

de Processo

Nível de Capacidade

1 2 3 4 5

1.1 L ou T T T T T

2.1 L ou T T T T

2.2 L ou T T T T

3.1 L ou T T T

3.2 L ou T T T

4.1 L ou T T

4.2 L ou T T

5.1 L ou T

5.2 L ou T

ISO/IEC 12207



NBR ISO/IEC 12207

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



NBR ISO/IEC 12207

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

• O processo de adaptação consiste na supressão de

processos, atividades e tarefas não aplicáveis.



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



NBR ISO/IEC 12207

• As partes envolvidas são responsáveis pela seleção de

um modelo de ciclo de vida para o projeto e pelo

mapeamento dos processos, atividades e tarefas dentro

desse modelo.

• As partes envolvidas são também responsáveis pela

seleção e aplicação dos métodos e pela execução das

atividades e tarefas adequadas ao projeto.



NBR ISO/IEC 12207

• Processos Fundamentais;

• Processo de Apoio;

• Processos Organizacionais;

• Processos de Adaptação

Estrutura



NBR ISO/IEC 12207

Estrutura



NBR ISO/IEC 12207

Estrutura

MPS.BR



Problema da Excelência: como atingir níveis de

maturidade CMMI no Brasil?



Problema da Excelência: como atingir níveis de

maturidade CMMI no Brasil?

• Na base da pirâmide encontra-se a grande massa de micro,

pequenas e médias empresas (PMEs) que desenvolvem software

no Brasil e que necessitam melhorar radicalmente os 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). Porém, o fator

custo é crítico.

• Esse processo pode levar de 2 a 4 anos e custar dezenas de

milhares de dólares.

• Aqui, a melhoria de processo está baseada na oferta de pacotes de

serviços para grupos de empresas (Modelo de Negócio

Cooperado)



MPS.BR

• Melhoria de Processos do Software Brasileiro

• É uma iniciativa para melhorar a capacidade de desenvolvimento

de software nas empresas brasileiras, sob coordenação da Softex –

Associação para Promoção da Excelência do Software Brasileiro

com apoio do MCTI – Ministério da Ciência, Tecnologia e Inovação,

desde dezembro de 2003.

• Seu principal objetivo é desenvolver e disseminar modelos de

melhoria de processos que atendam às necessidades da Indústria

Brasileira de Software e Serviços de TI.



MPS.BR

• Como objetivos secundários, e não menos importantes,

estes modelos visam apoiar tanto as MPME - micro,

pequenas e médias empresas (foco principal) quanto as

grandes organizações públicas e privadas (foco

secundário) a estabelecer um caminho economicamente

viável para que alcancem os benefícios da melhoria de

processos e da utilização de boas práticas da

engenharia de software e da prestação de serviços de

TI em um intervalo de tempo razoável, a um valor justo.



MPS.BR

Estrutura



MPS.BR

Desenvolvimento e Aprimoramento



MPS.BR

Base Técnica do MPS.BR



MPS.BR

• A - Em Otimização;

• B - Gerenciado quantitativamente;

• C - Definido;

• D - Largamente Definido;

• E - Parcialmente Definido;

• F - Gerenciado;

• G - Parcialmente Gerenciado.




MPS.BR




Avaliação MPS.BR • Objetivo: verificar a maturidade da unidade organizacional (UO) na

execução de seus processos de software.

• Para que uma avaliação MPS seja conduzida com sucesso, é necessário:

– Comprometimento do patrocinador: Representante da alta gerência da UO a

ser avaliada ou da organização que solicita a avaliação da UO.

– Motivação: O responsável pela UO deve motivar os participantes de forma

aberta e construtiva.

– Fornecimento de Feedback:

– Confidencialidade: das fontes de informação e documentação recolhidas

durante a avaliação e dos participantes (tanto da equipe de avaliação quanto

dos entrevistados).

– Percepção dos Benefícios: Os membros da UO devem perceber que a

avaliação resultará em benefícios que os ajudarão direta ou indiretamente a

realizar o seu trabalho.

– Credibilidade: o patrocinador, o gerente e os colaboradores da UO devem

acreditar que a avaliação chegará a um resultado representativo da

organização.



Avaliação MPS.BR

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

processo é executado na organização.

• Está relacionada com o atendimento aos atributos de processo

associados aos processos de cada nível de maturidade.

• À medida que a organização evolui nos níveis de maturidade, um

maior nível de capacidade para desempenhar o processo deve ser

atingido pela organização.

Capacidade de Processo



Avaliação MPS.BR

• 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

Atributos de Processo (AP):



Capacidade AP 1.1 – O processo é executado

Resultado esperado:

O processo atinge seus resultados definidos



Capacidade AP 2.1 – O processo é gerenciado

Resultados esperados: • Existe uma política organizacional estabelecida e

mantida para a gerência do processo;

• Os objetivos para a execução do processo são identificados;

• A execução do processo é planejada e monitorada;

• A execução do processo é ajustada para atender aos planos;



Capacidade AP 2.2 – Os produtos de

trabalho do processo são gerenciados

Resultados esperados:

• Os requisitos para produtos de trabalho do processo são definidos;

• Os requisitos para a documentação e controle dos produtos de trabalho são definidos;

• Os produtos de trabalho são identificados, documentados e controlados apropriadamente;

• Os produtos de trabalho são revisados de acordo com o planejado e ajustados, quando necessário, para atender aos requisitos;



Capacidade AP 3.1 – O processo é definido


• Um processo-padrão, incluindo diretrizes apropriadas

para sua adaptação, é definido para descrever os

elementos fundamentais que devem ser incorporados

num processo definido;

• A sequência e interação do processo-padrão com outros

processos são determinadas;



Capacidade AP 3.2 – O processo está

implementado


• Um processo definido é implementado com base em um

processo-padrão apropriadamente selecionado e/ou

adaptado;

• Os papéis, responsabilidades e autoridades requeridos para

execução do processo definido são atribuídos e

comunicados;



Caracterização do Nível de Resultados em

Projetos

• Caracterizar o grau de implementação de cada

resultado esperado do processo e de cada

resultado de atributo de processo em cada

projeto. – Para cada resultado esperado deve haver pelo menos uma

afirmação

– Todos os projetos devem ter afirmações para os resultados

– Para os projetos concluídos, devem ter afirmações para 50%

dos resultados

– Com base nas evidências, atribuir T, L, P ou N a cada projeto,

em cada resultado esperado.



MPS.BR

Nível Processo Capacidade

Inovação e Implantação na Organização A

(mais

alto)

Análise e Resolução de Causas

AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2

Desempenho do Processo Organizacional B

Gerência Quantitativa do Projeto

AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2

Análise de Decisão e Resolução C

Gerência de Riscos

AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2

Desenvolvimento de Requisitos

Solução Técnica

Integração do Produto

Instalação do Produto

Liberação do Produto

Verificação

D

Validação

AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2

Treinamento

Avaliação e Melhoria do Processo

Organizacional

Definição do Processo Organizacional

E

Adaptação do Processo para Gerência de

Projeto

AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2

Medição

Gerência de Configuração

Aquisição

F

Garantia da Qualidade

AP 1.1, AP 2.1 e AP 2.2

Gerência de Requisitos G

Gerência de Projeto

AP 1.1 e AP 2.1



MPS.BR



MPS.BR



Caracterização do grau de implementação de

cada um dos processos • Um processo está SATISFEITO quando:

– Todos os resultados esperados para o processo foram

caracterizados como T ou L, sendo que aproximadamente 85%

é T (no mínimo 75% T para processos com 4 resultados, e entre

75% e 85% T para processos com entre 5 e 7 resultados

esperados).

– E têm-se os atributos do processo conforme a Tabela de

Caracterização de atributos do processo para satisfazer aos

níveis MPS.



MPS.BR

Diferenciais

• 7 níveis de maturidade, o que possibilita uma

implantação mais gradual e uma maior visibilidade dos

resultados de melhoria de processo, com prazos mais

curtos.

• Compatibilidade com CMMI, conformidade com as

normas ISO/IEC 15504 e 12207.

• Adaptado para a realidade brasileira (foco em micro,

pequenas e médias empresas).

• Custo acessível (em R$)

Documents

Desenvolvimento de Sistemas Web - Luiz Leaoluizleao.com/Docencia/FAP/PDS/PDS_UND_04.pdf · fornecedores de software • Baseou-se nos estudos dos principais autores sobre ... por