Qualidade e Teste de Software

4-Normas de Qualidade de Software

Qualidade e teste

D
‍ e software

Me. Roque Maitino Neto

Iniciar

introdução

Introdução

Chegamos à última unidade do nosso curso e, no decorrer de todo conteúdo, tivemos diversas
oportunidades para reafirmar o caráter contínuo e regular do processo de busca pela
qualidade. Ao invés de ficarem concentrados em um só momento, os processos de qualidade
devem se estender por todo ciclo de vida de um produto, o que tende a tornar sua aplicação
mais efetiva e a aumentar a confiabilidade do software. Este raciocínio, amplamente aceito
entre profissionais de qualidade, nos autoriza a entender que o nível de qualidade obtido na
aplicação de um procedimento é diretamente proporcional ao nível do produto por ele
gerado. Por isso, esta unidade se dedica a apresentar normas que definem e sistematizam
processos de desenvolvimento de produtos de software, ofertando à equipe de
desenvolvimento boa referência e meios de avaliação eficientes.

Continue conosco e bom estudo!

Modelo de Maturidade CMMI

Quando atribuímos a alguém a característica da maturidade, é normal que a relacionemos com

tempo de vida e com as experiências vividas. Numa relação direta, assume-se que, quanto
mais idosa, mais maturidade tenha a pessoa.

Embora esta premissa não possa ser totalmente rechaçada em nosso contexto, a
caracterização de um procedimento de software como maduro requer algumas adaptações. A
maturidade, observada neste contexto, refere-se ao grau de evolução atingido pelo
procedimento de software aplicado na organização. Imaginar, no entanto, que apenas o tempo
de aplicação é capaz de conferir a um processo maturidade definitiva é um equívoco. Para
colocarmos as ideias como se deve, começaremos este tópico conceituando o procedimento
de software e abordando um dos mais consagrados modelos de maturidade do mundo.
O modelo de nosso interesse é chamado CMMI, que vem da expressão da língua inglesa
Capability Maturity Model Integration, ou Integração do Modelo da Maturidade em
Capacitação. Embora a tradução literal não revele com clareza seu objetivo, o modelo visa
determinar o estágio atual de maturidade dos processos de uma organização e oferecer meios
para aprimorá-lo. Mantido pelo CMMI Institute, o modelo foi adotado no lugar do CMM,
criado na década de 1980 pela SEI (Software Engineering Institute).

Como nossa abordagem terá como foco processos, vale a pena o resgate desta temática antes
de iniciarmos o CMMI. A criação de um produto, a prestação de um serviço ou o
gerenciamento de um projeto são atividades que, por motivos relacionados a previsibilidade e
a boa utilização dos recursos disponíveis, são conduzidas por meio de processos. Ensina
Wazlawick (2013, p. 11) que processos usualmente são definidos como conjuntos estruturados
de atividades, para as quais são determinados artefatos de entrada e saída, papéis de
responsáveis e participantes, além dos recursos necessários.

Observe que parece haver falta da palavra software nesta definição, mas esteja certo que não
foi o mero acaso que a determinou. Os modelos do CMMI, que logo serão tratados, podem
ser usados para o aprimoramento e avaliação dos processos de uma organização,
independentemente de serem processos de software ou não. Por isso, logo estaremos diante
de definições e práticas de aplicações genéricas que, embora tenham sido na indústria do
software, logo foram adaptadas para outras áreas da atividade humana.

Neste sentido, é de se esperar que um modelo tão abrangente seja particionado em visões
aplicáveis a múltiplos contextos de negócios. A flexibilidade, contudo, vai além e a organização
pode criar uma visão do modelo que atenda às suas necessidades específicas de melhoria de
desempenho. Em março de 2018 o modelo foi atualizado da versão 1.3 para a 2.0 e suas
divisões principais foram assim determinadas (INTRODUCING CMMI V2.0).

CMMI Desenvolvimento: trata-se de um conjunto integrado de práticas testadas e consagradas

que melhora a capacidade de uma organização de desenvolver produtos e serviços de
qualidade, que atendam às necessidades de clientes e usuários finais. Os principais benefícios
obtidos pela sua aplicação incluem:

Garantia de que os produtos e serviços serão entregues com rapidez e eficiência, com pouco
ou nenhum retrabalho.

Aumento da qualidade do produto por meio do reforço na consistência do desenvolvimento

deste produto, com o objetivo de reduzir defeitos.

Redução de custos através de processos aprimorados de planejamento, programação e

orçamento.

Atendimento às expectativas do cliente durante todo o ciclo de vida do produto.

CMMI Serviços: aqui o conjunto integrado de práticas é direcionado à melhoria do
desempenho e das principais capacidades das organizações que fornecem serviços, incluindo
B2B, B2C e serviços independentes. A correta aplicação deste modelo pode aumentar a
lealdade do cliente em relação a organização, entrega do serviço em tempo menor, melhoria
da qualidade e redução de custos.

CMMI Gerenciamento de fornecedores: se é verdade que ninguém vence sozinho, então esta
divisão do CMMI já tem sua importância garantida no contexto. Há uma interdependência
crescente entre consumidor e fornecedor e a redução de riscos e mitigação das expectativas
mal compreendidas são providências garantidas pelo gerenciamento de fornecedores guiado
pelo CMMI. Esta visão é, portanto, é um conjunto integrado de práticas que melhora a
capacidade de uma organização de identificar e gerenciar fornecedores de uma maneira que
maximiza a eficiência da cadeia de suprimentos e reduz os riscos.

A capacidade e maturidade de um processo remetem à noção do grau de qualidade com o

qual um processo atinge um resultado esperado. Segundo a descrição do modelo, a qualidade
é influenciada pelo processo e seu foco é melhorar o processo de uma organização.

O CMMI oferece duas formas possíveis de aplicação do modelo. A aplicação em estágios

caracteriza, por níveis de maturidade, o estado geral dos processos da organização, entendida
em sua totalidade. O diagnóstico gerado por este meio permite, por exemplo, comparações
do nível de maturidade entre organizações diferentes. Já a aplicação contínua utiliza níveis de
capacidade para caracterizar o estado dos processos da organização em relação a uma área de
processo individual. Assim, a aplicação contínua é projetada para permitir à empresa focar em
processos específicos que deseja melhorar em função de suas prioridades (WAZLAWICK,
2013).

Se as formas de aplicação remetem a situações específicas e genéricas, é de se imaginar que o

modelo preveja também distinção entre objetivos específicos e genéricos para os processos
em que atuará. Objetivos específicos são características determinadas e únicas que devem ser
alcançadas para que determinada área do processo seja satisfeita. Tais objetivos são atingidos
pela aplicação de práticas específicas. Os objetivos genéricos, por sua vez, são buscados em
várias áreas do processo e são atingidos por práticas genéricas.

Qualquer que seja sua versão, visão ou foco de aplicação, o CMMI é um modelo que aponta o
caminho para melhorias graduais no processo, percorrido em 5 níveis de maturidade e 4 níveis
de capacidade, e criado para que organizações possam sair de um processo de software
caótico para um processo maduro e disciplinado. A tabela 4.1 mostra estes níveis.
Vale ainda o registro de que, embora a aplicabilidade do CMMI não esteja necessariamente
relacionada a um processo específico, é no contexto de aquisição, desenvolvimento e
prestação de serviços de software que reside nosso interesse imediato, daí a menção a
“processo de software”.

Nível Capacidade Maturidade

0 Incompleto -

1 Realizado Inicial

2 Gerenciado Gerenciado

3 Definido Definido

4 - Quantitativamente gerenciado

5 - Em otimização

Tabela 4.1 - Níveis gerais de capacidade e maturidade.

Fonte: WAZLAWICK (2013, p. 267).

Apesar das tantas especificidades que o caracterizam, a essência do CMMI é baseada na

classificação em níveis da capacidade e da maturidade. Há que se registrar, contudo, que o
CMMI não prevê um nível de maturidade 0, usado apenas num dos modelos que abordaremos
ainda nesta unidade. Os detalhes dos níveis de capacidade e maturidade são dados na
sequência:

Níveis de Capacidade do Processo: um nível de capacidade do processo é alcançado quando

todos os objetivos genéricos para aquele nível são satisfeitos. Quanto maior o nível atingido
pelo processo, mais bem estruturado ele será considerado. Vejamos:

Nível 0 – Incompleto:

Um processo é considerado incompleto quando não está sendo colocado em prática ou está
sendo desempenhado apenas parcialmente. Um ou mais objetivos específicos da área de
processo não estão sendo satisfeitos e não existem metas genéricas para serem alcançadas.
Assim, processos considerados incompletos não devem ser oficializados.

Nível 1 – Realizado:

Neste nível, o processo é viável e está sendo seguido, é capaz de gerar produtos ou serviços e
pode até ser considerado como um dos motivos para que a organização tenha experimentado
melhorias. No entanto, tais conquistas podem ser perdidas ao longo do tempo, já que, um
processo realizado ainda não foi institucionalizado, ou seja, não segue regras claras e definidas
como maneira de garantir a repetição.

Nível 2 – Gerenciado:
Neste nível, um processo já é planejado e executado de acordo com a política definida, utiliza
recurso humano qualificado, produz saídas previsíveis, é capaz de envolver os stakeholders, é
monitorado, controlado e avaliado. Em períodos de estresse, as práticas planejadas são
mantidas pelo gerenciamento empreendido no processo.

Nível 3 – Definido:

Um processo definido é feito sob medida a partir das diretrizes da organização. Este nível
também se caracteriza por manter registros gerais do processo. No nível anterior
(Gerenciado), as descrições de processos, os procedimentos e as normas que os padronizam
podem ser bastante diferentes em cada aplicação particular do processo. No nível de
capacidade 3, as normas, descrições de processos e procedimentos para um projeto são feitos
sob medida a partir do conjunto de processos padrão da organização, o que lhes dá, via de
regra, mais consistência. Ao compararmos os níveis 2 e 3, concluiremos que a descrição dos
processos no nível 3 é mais rigorosa do que no anterior. Em um processo definido suas
finalidades, insumos, atividades, recursos, métricas, entradas e saídas são itens descritos com
clareza e precisão, o que facilita seu gerenciamento.

A descrição dos níveis de capacidade de um processo serviu para preparar nosso caminho até
o conhecimento dos níveis de maturidade da organização e de seus procedimentos. Sua
apresentação é feita resumidamente na sequência.

Níveis de Maturidade: para suportar a aplicação (ou representação) por estágios, o CMMI
contempla níveis de maturidade em sua concepção. Um nível de maturidade é composto por
práticas especificas e genéricas aplicáveis em um conjunto predefinido de áreas de processos
que tornam melhor o desempenho geral da organização. O nível de maturidade fornece, pois,
uma maneira de caracterizar o seu desempenho da organização. Quanto maior o nível de
maturidade, mais organizada em seus processos pode ser considerada a organização. Em
consequência, a tendência de gerar produtos de qualidade avançada é maior (MAITINO NETO,
2016)

Tratados de forma genérica (os processos podem ser para desenvolvimento de software ou
não), a descrição dos níveis de maturidade é assim feita:

Nível 1 – Inicial:

Neste nível, a organização coloca em prática processos caóticos e sem definições claras, o que
acaba atrelando o sucesso da empresa a iniciativas individuais e esporádicas. A organização
não provê um ambiente estável para o desenvolvimento do produto ou serviço. Estimativas
são baseadas em percepções subjetivas, o que favorece que cronogramas e orçamentos sejam
abandonados com frequência.
Nível 2 – Gerenciado:

Este nível permite que, por causa do gerenciamento aplicado, os interessados no projeto
possam acompanhar suas entregas intermediárias. Há critérios para nortear o planejamento e
execução dos projetos e a previsibilidade dos resultados é apontada como característica neste
contexto, mesmo diante de imprevistos e adversidades.

Nível 3 – Definido:

Mesmo tendo sido originados em diferentes áreas e tendo objetivos completamente distintos,
os projetos se tornam efetivos a partir de padrões globais da organização. Um projeto da área
de software seguirá os mesmos padrões que um projeto da área de manufatura, por exemplo.
Com isso, a definição dos projetos é feita de forma bem rigorosa neste nível. Note que os
níveis 2 e 3 de maturidade guardam semelhanças com os mesmos níveis de capacidade do
processo.

Nível 4 – Quantitativamente gerenciado:

Neste nível, a organização estabelece metas de qualidade e as utiliza na gestão de seus

projetos. A qualidade de processo e de produto é controlada de forma que seja previsível em
alguma medida.

Nível 5 – Em otimização:

Trata-se do nível mais elevado na escala e objetivo a ser atingido por qualquer organização.
Aqui, a organização já alcançou a excelência em cada nível anterior e passa a buscar melhoria
contínua em seus processos, com base nas medições quantitativas já obtidas.

saiba mais

Saiba mais

A versão 2.0 do CMMI foi lançada no ano de 2018 e ainda está em processo de
reconhecimento pelo mercado. No entanto, as melhorias em relação à versão anterior são
significativas e valem a pena serem conhecidas. Acesse:

ACESSAR

Vale ressaltar que o CMMI usa estas descrições de níveis para classificar os estágios dos
processos sob avaliação. Há, contudo, além destas descrições, uma indicação de caminho a
ser seguido para que um determinado nível de maturidade seja atingido. Tomemos como
exemplo a versão anterior do CMMI, a 1.3. Uma de suas divisões, a CMMI-DEV (DEV vem de
development, ou desenvolvimento), prevê a existência de 22 áreas específicas de processo de
desenvolvimento de um produto de software. Cada área está associada a um nível de
maturidade e sua descrição contém o propósito de sua existência. A tabela 4.2 apresenta 6
destas 22 áreas.

Pelos dados contidos na tabela concluímos que os níveis de maturidade situados entre 2 e 5
são atingidos na medida em que a organização implementa as providências descritas em cada
nível. Para atingimento do nível gerenciado (nível 2), por exemplo, é necessário que as áreas
de gerenciamento de requisitos, gerenciamento de configuração e garantia da qualidade de
produto e de processo, entre outras, atinjam o nível de capacidade 2. Para atingimento do
nível de maturidade 3, é necessário que todas as áreas de processo do nível 2, mais a área de
desenvolvimento de requisitos (também entre outros) alcancem o nível de capacidade 3.

Área do Processo Categoria Nível Propósito

Gerenciamento de requisitos Gerenciamento de Projetos 2 Gerenciar os requisitos

dos produtos e componentes de produto do projeto e garantir um alinhamento entre esses
requisitos e os planos de projeto e produtos de trabalho.

Gerenciamento de configuração Suporte 2 Estabelecer e manter a

integridade dos produtos de trabalho usando identificação de configuração, controle de
configuração, relatório de status de configuração e auditorias de configuração.

Garantia da Qualidade de Processo e Produto Suporte 2 Fornecer à equipe e

aos gerentes um entendimento objetivo sobre os processos e produto de trabalho associados.

Desenvolvimento de Requisitos Engenharia 3 Elicitar, analisar e estabelecer

os requisitos do cliente, do produto e dos componentes do produto.

Gerenciamento quantitativo do projeto Gerenciamento do Projeto 4

Gerenciar quantitativamente o projeto para alcançar os objetivos estabelecidos de
desempenho e de qualidade do projeto.

Gerenciamento de desempenho organizacional Gerenciamento de Projeto 5

Gerenciar proativamente o desempenho da organização de forma a atingir seus
objetivos de negócio.

Tabela 4.2. Exemplos de áreas do processo de desenvolvimento de um produto.

Fonte: adaptado de WAZLAWICK (2013, p. 269)

Parece-nos, pois, que a característica evolucionária do modelo ficou mais bem destacada.
Trataremos na sequência de uma norma criada especificamente para processos de software.

atividade

Atividade

A aplicação do CMMI em uma organização pode ser feita de duas maneiras: a aplicação
____________ caracteriza o estado dos processos de acordo com níveis de capacidade. Já a
aplicação ________ caracteriza o estado geral dos processos por meio de níveis de
maturidade. Quando se encontra no nível __________, uma organização já consegue conduzir
processos avaliados e controlados.

Fonte: Elaborado pelo autor.

No contexto do CMMI, assinale a alternativa que contém expressões que completam

corretamente as lacunas da sentença.

a) Contínua, certificada, aprimorado.

b) Em estágios, contínua, complementar.

c) Em estágios, controlada, aprimorado.

d) Contínua, em estágios, gerenciado.

e) Contínua, paulatina, gerenciado.

Feedback: A alternativa correta é a letra D.

Alternativa a – incorreta. Não existe a nomenclatura “aprimorado” para nível de capacidade.

Alternativa b – incorreta. Não existe a nomenclatura “complementar” para aplicação do

CMMI.

Alternativa c – incorreta. Não existe a nomenclatura “controlada” para aplicação do CMMI.

Alternativa d – correta. De fato, todos os termos completam de forma correta a sentença

dada.

Alternativa e – incorreta. Não existe a nomenclatura “paulatina” para aplicação do CMMI.

Verificar Resposta

A norma ISO/IEC 12207

Você e alguns de seus amigos resolvem abrir uma empresa de desenvolvimento de software e,
logo depois de formalmente criada e estruturada, ela finalmente recebe a primeira demanda.
Como o cliente tinha pressa, foram combinados prazos apertados e, por isso, não há tempo a
perder. Basta então que sentem e codifiquem logo o programa, não é mesmo?
O desconhecimento da existência de uma norma específica que descreve e disciplina o ciclo de
vida de um software pode levar alguém a responder “sim” a esta pergunta e, por
consequência, ter grande chance de enfrentar o insucesso logo em sua primeira empreitada.

Neste sentido, o item atual da nossa unidade descreve a norma ISO/IEC 12207. Ela estabelece
uma estrutura comum para processos de ciclo de vida de software, com terminologia bem
definida, que pode e deve ser referenciada por organizações desenvolvedoras de software. Ele
contém processos, atividades e tarefas que são aplicáveis durante a aquisição, fornecimento,
desenvolvimento, operação, manutenção ou descarte de sistemas, produtos e serviços de
software. Esses processos do ciclo de vida são realizados por meio do envolvimento de partes
interessadas (ou stakeholders), com o objetivo final de alcançar a satisfação do cliente.

Por fim, o documento que descreve a norma também fornece processos que podem ser
empregados para definir, controlar e aprimorar processos de ciclo de vida de software dentro
de uma organização ou projeto.

A norma ISO/IEC 12207 é composta por um conjunto abrangente de diretrizes a partir do qual
uma organização pode construir modelos de ciclo de vida de software apropriados a seus
produtos e serviços, da concepção até ao encerramento.

A norma pode ser usada em um ou mais dos seguintes modos (SYSTEMS, s.d):

Por uma organização: para ajudar a estabelecer um ambiente de processos desejados. Esses
processos podem ser suportados por uma infraestrutura de métodos, procedimentos,
técnicas, ferramentas e pessoal treinado. A organização pode então empregar esse ambiente
para executar e gerenciar seus projetos e estabelecer o desenvolvimento de sistemas de
software através de seus estágios de ciclo de vida.

Por um projeto: neste contexto, serve para ajudar a selecionar, estruturar e empregar os
elementos de um ambiente estabelecido para fornecer produtos e serviços. Neste modo, a
norma 12207 é utilizada na avaliação da conformidade do projeto com o ambiente declarado e
estabelecido.

Por um adquirente e um fornecedor: aqui a norma serve para ajudar a desenvolver um

acordo sobre processos e atividades. Por meio do acordo, os processos e atividades deste
documento são selecionados, negociados, acordados e executados. Neste modo, a norma é
usada para orientação no desenvolvimento do contrato.

Por avaliadores de processos: para servir como um modelo de referência de processo para
uso no desempenho de avaliações de processos que podem ser usados para apoiar a melhoria
do processo.

atividade
Atividade

O desconhecimento da existência de uma norma específica que descreve o ciclo de vida de um

software pode levar projetos ao fracasso, justamente pela falta de disciplina e de método na
condução dos processos que levam a criação de um produto de qualidade.

Fonte: Elaborado pelo autor.

Em relação a norma ISO/IEC 12207, analise as afirmações que seguem.

I) Um dos propósitos da norma é fornecer conjunto definido de processos para facilitar a

comunicação entre partes que mantêm interesse em uma ou mais etapas do ciclo de vida de
um sistema de software.

II) Embora contenha a descrição de processos relacionados ao desenvolvimento de um

software, a norma foca os processos de aquisição e de descarte do produto, justamente por
serem estes processos não serem contemplados no CMMI.

III) Os avaliadores de processos podem basear-se na ISO/IEC 12207 para criar modelo para
avaliação. No entanto, a norma não serve para balizar a condução de projetos de software,
por tratar apenas de seu ciclo de vida.

É correto o que se afirma em:

a) I apenas.

b) I e II apenas.

c) I, II e III.

d) I e III apenas.

e) II e III apenas.

Feedback: A alternativa correta é a letra A.

Afirmação I: correta. De fato, a afirmação condiz com o propósito da norma.

Afirmação II: incorreta. A afirmação estabelece vínculo indevido entre a 12207 e o CMMI.
Além disso, não se pode afirmar que o foco da norma esteja centrado na aquisição e descarte
de um produto.
Afirmação III: incorreta. A primeira parte da afirmação é correta. No entanto, a norma também
alcança procedimentos relacionados a projeto de software, o que invalida a afirmação.

Verificar Resposta

A norma ISO/IEC 15504 (SPICE)

Parecem ser traços comuns das normas abordadas nesta unidade a busca pela determinação e
aumento do nível de maturidade/capacidade de um processo, bem como a melhoria dos
processos de uma organização.

A norma ISO/IEC 15504 não foge à regra e, através de seu “apelido”, deixa claro seu objetivo:
SPICE é acrônimo de Software Process Improvement and Capability dEtermination, ou
Melhoria do Processo de Software e Determinação da Capacidade. Estamos diante, então, de
uma norma específica para processos de software, em oposição à vocação generalista do
CMMI.

Ensina Wazlawick (2013) que ela foi criada como uma complementação para a ISO/IEC 12207 e
tem como objetivo orientar a avaliação e autoavaliação da capacidade das organizações em
processos, possibilitando assim a melhoria destes processos. Ela também serviu para suprir
lacuna da ISO 90003 que, embora tenha servido como referência para a indústria de software,
não tratava dos níveis de maturidade e de melhoria contínua.

São duas as dimensões da norma:

Dimensão de processos: as 5 categorias de processos aqui definidas guardam bastante

similaridade com os processos da norma ISO/IEC 12207. Alguns destes processos incluem
relação cliente/fornecedor, procedimentos de engenharia de software e de qualidade de
software.

Dimensão de capacidade: em cada processo são previstos seis níveis de capacidade, que não
se distanciam dos que já abordamos. São eles: incompleto, realizado, gerenciado,
estabelecido, previsível e otimizado. A avaliação destes processos é feita em função de
determinados atributos destes processos.

A avaliação dos processos da organização é prevista pela própria norma e segue procedimento
definido, que se inicia com a seleção do avaliador, segue para o planejamento da avaliação,
passa pela coleta e validação de dados e acaba com a atribuição do nível de capacidade de
cada processo avaliado.

atividade
Atividade

A avaliação dos níveis de capacidade é demonstrada em função de um conjunto de atributos

de processos. Cada nível tem seus próprios atributos e os atributos são avaliados de acordo
com a uma escala de obtenção.

WAZLAWICK, Raul Sidnei. Engenharia de Software: Conceitos e Práticas. 1. ed. Rio de Janeiro:
Elsevier, 2013. p. 260.

Assinale a alternativa em que se encontra a melhor caracterização para a norma ISO/IEC

15504:

a) Criada para substituir a ISO/IEC 12207.

b) Criada para determinação do processo de teste de software.

c) Sua dimensão de capacidade prevê 5 níveis em cada processo.

d) Serve como complemento para o CMMI.

e) Objetiva a melhoria do processo de software.

Feedback: A alternativa correta é a letra E.

Alternativa a: incorreta. A norma foi criada para complementar, não para substituir a ISO/IEC
12207

Alternativa b: incorreta. Foi criada para melhoria do processo de software e para determinação
do nível de capacidade dos processos envolvidos.

Alternativa c: incorreta. Sua dimensão de capacidade prevê 6 níveis ao invés de 5.

Alternativa d: incorreta. Não há menção na literatura de que tenha sido criada para
complementar o CMMI.

Alternativa e: correta. De fato, a norma foi criada para melhoria do processo de software e
para determinação do nível de capacidade dos processos envolvidos, daí a sigla SPICE
(Software Process Improvement and Capability dEtermination)

Verificar Resposta

O MPS.BR
Embora consagradas e largamente utilizadas pelas organizações mundo afora, as normas e
modelos criados no exterior não gozam de exclusividade em nosso país. O MPS.BR, também
conhecido como MR-MPS (Modelo de Referência para Melhoria do Processo de Software) é
um modelo de avaliação de software feito sob medida para empresas nacionais. Ele foi
concebido em 2003 pela SOFTEX, organização cuja missão é ampliar a inovação e a
competitividade do setor brasileiro de software e serviços de tecnologia da informação,
promovendo o desenvolvimento do país (SOFTEX, s.d.).

A estrutura do modelo empresta itens basilares de normas e modelos internacionalmente

reconhecidos, além das imprescindíveis boas práticas da Engenharia de Software e a realidade
de negócio dos desenvolvedores do nosso país, raramente contemplada em modelos
internacionais.

O guia de implementação do modelo prevê 7 níveis de maturidade, ao invés dos 5 tradicionais

do CMMI. Esta característica torna mais sutil a diferença entre os níveis e, em tese, mais
gradual o atingimento de níveis superiores de maturidade.

Embora possa ser considerado independente, o MPS é compatível com a ISO 12207, com a
norma 15504 e também com o CMMI (WAZLAWICK, 2013).

Este modelo de qualidade, além de refletir características próprias das organizações

domésticas, apresenta outro diferencial que torna sua adoção bastante atraente: o custo mais
acessível quando comparado às normas internacionais.

Conforme a figura 4.1, esses são os níveis definidos pelo MPS.BR:

Figura 4.1. Componentes do modelo de maturidade do MPS-BR

Fonte: Softex.

reflita

Reflita

A implantação de um padrão de qualidade em uma empresa pequena é necessária? Alguns

argumentos talvez ajudem na resolução dessa questão: conquista de novos mercados, criação
de condições para o surgimento de clima de incentivo, motivação e participação,
direcionamento da empresa para o cliente e até redução de custos.

Fonte: MAITINO NETO (2016, p. 138).

Não à toa, o MPS é líder em avaliações no Brasil, numa comparação direta com o CMMI. Ele
permanece o número 1 no ranking de melhoria da capacidade de desenvolvimento de
software e serviços de TI nas empresas brasileiras (SOFTEX, s.d.).

saiba mais

Saiba mais

A SOFTEX disponibiliza gratuitamente o Guia Geral do MPS.BR das várias visões do modelo. O
guia específico para software pode ser encontrado em:

ACESSAR

Com ordenação e nomenclatura ligeiramente diferentes das vistas em outros modelos, o MPS
é apresentado na sequência. Cada atributo de processo no MPS.BR é detalhado por um
conjunto de resultados esperados (SOFTEX, 2016).

Nível G: Parcialmente Gerenciado. O nível G de maturidade – o mais baixo na escala – visa o

atingimento de certos objetivos relacionados aos processos de Gerência de Projetos e de
Gerência de Requisitos. Em relação ao gerenciamento de um projeto, os resultados esperados
incluem a definição do escopo do trabalho para o projeto e a definição do modelo e das fases
do ciclo de vida do projeto. Já no que que se refere ao gerenciamento de requisitos, é
esperado que os requisitos sejam avaliados com base em critérios objetivos e que o
comprometimento da equipe técnica com estes requisitos seja efetivo.

Nível F: Gerenciado. O nível de maturidade F é composto pelos processos do nível de

maturidade G, mais os processos de Medição e Aquisição de software, Garantia da Qualidade,
Gerência de Configuração e Gerência de Portfolio de Projetos.

Nível E: Parcialmente Definido. Este nível é formado pelos processos dos níveis G e F,
acrescidos dos processos de Avaliação e Melhoria do Processo Organizacional, Definição do
Processo Organizacional, Gerência de Recursos Humanos e Gerência de Reutilização. Aqui, o
processo Gerência de Projetos evolui e a gerência do projeto passa a ser praticada com base
no processo definido e com base nos planos integrados.

Nível D: Largamente Definido. O nível D é composto pelos processos dos níveis de maturidade
G ao E, mais os processos de Desenvolvimento de Requisitos, Integração do Produto, Projeto e
Construção do Produto, Validação e Verificação.
Nível C: Definido. O nível de maturidade C é composto pelos processos dos níveis de
maturidade anteriores (G ao D), acrescidos dos processos Desenvolvimento para Reutilização,
Gerência de Decisões e Gerência de Riscos.

Nível B: Gerenciado Quantitativamente. Este nível de maturidade é composto pelos processos

dos níveis de maturidade anteriores (G ao C). Neste nível, o processo de Gerência da Operação
do Serviço sofre evolução, por meio do acréscimo de novos resultados para atender aos
objetivos de gerenciamento quantitativo.

Nível A: Em Otimização. Por fim, este nível de maturidade é composto pelos processos dos
níveis de maturidade anteriores (G ao B).

O nível A, portanto, é o ideal de maturidade a ser atingido segundo este modelo. O

atingimento de um nível superior pressupõe o atingimento do(s) nível(is) anterior(es).

atividade

Atividade

O MPS.BR é um programa mobilizador, de longo prazo, criado em dezembro de 2003,

coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX),
com apoio do Ministério da Ciência, Tecnologia e Inovação (MCTI), Financiadora de Estudos e
Projetos (FINEP), SEBRAE e Banco Interamericano de Desenvolvimento (BID/FUMIN) (SOFTEX,
2016, p. 4).

Em relação ao MPS.BR, analise as afirmações que seguem:

I) Os sete níveis de maturidade do MPS.BR dificultam sua aplicação, dai seu baixo índice de
adoção pelas organizações brasileiras.

II) Trata-se da reprodução do CMMI, traduzida e adaptada para o mercado brasileiro.

III) O nível de maturidade G prevê o atingimento de certos objetivos relacionados a gerência de

requisitos e de projetos.

É correto o que se afirma em:

a) II apenas.

b) I e III apenas.
c) I, II e III.

d) III apenas.

e) II e III apenas.

Feedback: A alternativa correta é a letra D.

Afirmação I: incorreta. Por apresentarem diferenças mais sutis entre os níveis, a estruturação
em 7 divisões melhora a aplicabilidade do modelo, ao invés de prejudica-la.

Afirmação II: incorreta. Embora seja baseado no CMMI, o MPS.BR é um modelo independente
e com diretrizes próprias.

Afirmação III: correta. De fato, temos uma definição correta do nível G na alternativa.

Verificar Resposta

indicações

Material Complementar

Livro

Tecnologia da Informação em Questões. CMMI e MPS.BR

Kindle Edition

Editora: EC Edições de Concursos

Comentário: Trata-se da compilação de questões relacionadas a CMMI e MPS.BR que fizeram

parte de provas de concursos para cargos públicos. Vale a leitura para, inclusive, fazer auto
avaliação do seu conhecimento.

Filme

Onze homens e um segredo (EUA)

Ano: 2002

C
‍ omentário: Neste filme, um grupo de homens se organiza para assaltar cassinos em Las
Vegas. O planejamento, a capacitação dos recursos humanos e a execução da empreitada são
conduzidos com extremo rigor para o atingimento do objetivo.
Para conhecer mais sobre o filme, acesse o trailer disponível em:

Trailer

conclusão

Conclusão

Na minha organização, os processos que a mantêm em funcionamento são bem definidos? Se

estão corretamente definidos, posso afirmar que eles são, de fato, aplicados? No caso de
serem definidos e aplicados, serei capaz de afirmar que são bem gerenciados? Sem
parâmetros reais e claros, as respostas a estas perguntas ficariam à mercê da subjetividade e
da percepção que cada gestor tem da sua organização. Como pudemos constatar ao longo
desta unidade, o esforço da comunidade de pesquisadores, com a colaboração preciosa do
mercado, foi capaz de criar estes parâmetros reais em formato de normas, tão imprescindíveis
para quem se importa com qualidade.

Ao chegarmos ao fim da última unidade deste curso, desejamos que a condução da sua vida
acadêmica seja bastante proveitosa e que sua atuação profissional esteja perfeitamente
alinhada com seus objetivos pessoais. Grande abraço e boa sorte!

referências

Referências Bibliográficas

INTRODUCING CMMI V2.0. CMMI Institute. Disponível em https://cmmiinstitute.com/cmmi.

Acesso em 2 de abr. 2019.

International Organization for Standardization. ISO/IEC 12207 International Standard

Information Technology - Software Life Cycle Processes, 2008.

International Organization for Standardization. ISO/IEC 15504 International Standard

Information Technology - Software Process Assessment, 2010.

MAITINO NETO, Roque. Engenharia de Software. Londrina: Editora e Distribuidora Educacional

S.A., 2016. 224 p.

SOFTEX. Missão. Disponível em https://softex.br/a-softex. Acesso em 2 de abr. de 2019.

SYSTEMS and software engineering: Software life cycle processes. ISO/IEC/IEEE
12207:2017(en). Disponível em https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:12207:ed-
1:v1:en. Acesso em 5 de abr. 2019.

WAZLAWICK, Raul Sidnei. Engenharia de Software: conceitos e práticas. Rio de Janeiro:

Elsevier, 2013.

Imprimir

© 2019 - LAUREATE - Todos direitos reservados