flowchart BT
N1[Nivel 1 — Inicial<br/>imprevisivel, reativo] --> N2[Nivel 2 — Gerenciado<br/>projetos planejados e controlados]
N2 --> N3[Nivel 3 — Definido<br/>processo padrao da organizacao]
N3 --> N4[Nivel 4 — Gerenciado Quantitativamente<br/>processo medido por dados]
N4 --> N5[Nivel 5 — Em Otimizacao<br/>melhoria continua]
style N1 fill:#f8d7da,stroke:#842029
style N2 fill:#fff3cd,stroke:#664d03
style N3 fill:#cfe2ff,stroke:#084298
style N4 fill:#d1e7dd,stroke:#0f5132
style N5 fill:#e2d9f3,stroke:#59359a
Módulo 15 — Modelos de Qualidade: ISO, CMMI, MPS.BR
Onde estamos. Chegamos ao fim da nossa jornada. Ao longo do semestre você aprendeu a especificar, projetar, implementar, testar e manter software. Agora vamos olhar tudo isso de cima: como uma organização inteira mede, controla e amadurece sua maneira de fazer software. Este último módulo é, ao mesmo tempo, um tema novo e um fecho de tudo o que já vimos. Quero que você saia daqui entendendo por que a qualidade do processo é o fio que costura a disciplina inteira.
Deixe-me abrir com uma pergunta que parece ingênua, mas não é. Se dois programadores igualmente competentes escrevem o mesmo sistema, por que uma empresa entrega no prazo, com poucos defeitos, enquanto a outra atrasa, retrabalha e apaga incêndios? A diferença raramente está no talento individual. Está na forma como o trabalho é organizado, repetido, medido e melhorado. É disso que os modelos de qualidade tratam: não descrevem uma linguagem melhor nem um algoritmo mais esperto, e sim uma maneira mais madura de trabalhar — e essa maturidade dá sentido a cada tema que estudamos.
Qualidade de produto e qualidade de processo
Precisamos separar dois sentidos de “qualidade” que o senso comum mistura. A qualidade de produto é uma propriedade do software pronto: o quanto ele é confiável, seguro, eficiente, usável e manutenível. É o que você avalia quando o sistema já está na sua frente. A qualidade de processo é uma propriedade de como o software foi feito: o quanto o caminho até o produto é organizado, previsível e passível de melhoria. Uma olha para o resultado; a outra, para o percurso.
O pressuposto que sustenta tudo neste módulo é uma aposta razoável, embora não uma garantia mecânica: um bom processo tende a gerar um bom produto. Se a equipe levanta requisitos com método, revisa projeto, escreve testes automatizados e registra decisões, a probabilidade de o produto sair confiável e manutenível é muito maior do que se cada um improvisa. Sommerville é cuidadoso ao formular isso: processo não é destino. Um processo excelente aplicado por gente desmotivada ainda pode falhar. Mas, na média e em escala, investir no processo é o caminho mais confiável para elevar o produto — porque um bom processo captura os erros cedo, quando ainda são baratos de corrigir.
ImportanteA tese que atravessa este módulo
Você não controla diretamente a qualidade do produto: ela emerge de milhares de decisões pequenas ao longo do desenvolvimento. O que você controla é o processo. Por isso os grandes modelos de qualidade organizacional — CMMI e MPS.BR — avaliam o processo, não o produto final. A aposta é que melhorar o como eleva o quê.
Essa é exatamente a lógica que Pressman coloca na base das suas camadas da engenharia de software: sobre o compromisso com a qualidade repousa o processo, e sobre ele os métodos e as ferramentas. Este módulo é um retorno a essa base, agora com instrumentos concretos para medi-la.
A família de normas ISO no contexto de software
Quando o assunto é padronizar qualidade, o primeiro nome que aparece é a ISO, a organização internacional de normalização. Ela publica normas para praticamente tudo, e há duas frentes que nos interessam, correspondendo às duas qualidades que distingui.
Do lado da qualidade de produto, a referência é a família ISO/IEC 25010, que define um modelo de qualidade para produtos de software organizado em características e subcaracterísticas: adequação funcional, confiabilidade, desempenho, segurança, usabilidade, manutenibilidade e portabilidade. Se isso soa familiar, é porque é exatamente o vocabulário de atributos que apresentei no módulo inicial e que aprofundamos ao falar de qualidade e testes. A 25010 dá nome, estrutura e uma linguagem comum a esses atributos, de modo que uma equipe possa dizer com precisão o que quer dizer por “software de qualidade” e medir cada dimensão separadamente.
Do lado da qualidade de processo e de gestão, a referência é a ISO 9001, que não é específica de software: é uma norma genérica de sistemas de gestão da qualidade, aplicável a qualquer organização. Ela não diz como construir software; exige que a organização defina seus processos, os documente, os siga, registre evidências e os melhore continuamente. A ideia é que a qualidade não seja um acaso de um herói talentoso, mas uma consequência previsível de um sistema de gestão bem definido. Quando uma empresa é certificada ISO 9001, atesta-se que ela tem processos definidos e os cumpre — não que o produto seja excelente, mas que o caminho é controlado.
NotaDuas normas, duas perguntas diferentes
A ISO/IEC 25010 responde: “o produto que saiu é bom, e em quais dimensões?” A ISO 9001 responde: “a organização tem um sistema de gestão da qualidade que realmente segue?” Uma avalia o artefato; a outra, o sistema que o produz. As duas se complementam, e nenhuma substitui a outra.
Não vou cravar números de edição ou ano dessas normas, porque são periodicamente atualizadas; o que importa é o papel de cada uma.
CMMI: um modelo de maturidade do processo
Agora entramos no coração deste módulo. O CMMI — a sigla vem de Capability Maturity Model Integration, Modelo Integrado de Maturidade e Capacidade — nasceu de um esforço, originalmente ligado ao Software Engineering Institute nos Estados Unidos, para responder a uma pergunta prática: como saber se uma organização é capaz de entregar software de forma confiável e repetível? Ele descreve uma escada de maturidade com cinco níveis, e a posição nessa escada diz o quanto o processo é previsível e controlado.
A lógica dos níveis é cumulativa: cada degrau pressupõe o anterior consolidado. Deixe-me percorrê-los qualitativamente, como estágios de amadurecimento e não como uma pontuação.
No nível 1, inicial, o processo é imprevisível e reativo. As coisas até são entregues, mas à custa de esforço heroico, horas extras e sorte. O sucesso de um projeto não se transfere para o próximo, porque depende das pessoas, não do método.
No nível 2, gerenciado, os projetos passam a ter gestão básica: requisitos são controlados, o trabalho é planejado e acompanhado, e há disciplina para cumprir o que foi combinado dentro de cada projeto. O ganho é a repetibilidade em nível de projeto.
No nível 3, definido, a organização dá um salto: o processo deixa de ser algo que cada equipe reinventa e passa a ser um padrão organizacional, documentado e adaptado por cada projeto a partir de um conjunto comum. O conhecimento pertence à organização, não às pessoas. Aqui a empresa tem, de fato, “um jeito de fazer software”.
No nível 4, gerenciado quantitativamente, entram os números. O processo passa a ser medido estatisticamente: a organização coleta métricas, entende sua variação normal e usa dados para prever desempenho e qualidade. Não se decide mais por intuição, e sim por evidência quantitativa.
No nível 5, em otimização, o foco é a melhoria contínua. A organização usa os dados que coleta para identificar causas de defeitos e ineficiências e para melhorar o próprio processo de forma sistemática. O processo aprende sobre si mesmo.
Uma peça central do CMMI é a ideia de áreas de processo. Em vez de exigir vagamente que a organização “seja madura”, o modelo organiza o trabalho em conjuntos coerentes de práticas ligadas a um objetivo — gestão de requisitos, planejamento de projeto, garantia da qualidade, gestão de configuração. Cada área reúne metas e práticas esperadas, e o nível de maturidade corresponde a ter satisfeito, de forma institucionalizada, as áreas exigidas para aquele degrau. É esse detalhamento que transforma um ideal abstrato de maturidade em algo verificável por uma avaliação.
MPS.BR: o modelo brasileiro
O CMMI é poderoso, mas tem um problema prático no nosso contexto: uma avaliação formal costuma ser cara e demorada, o que a coloca fora do alcance da maioria das pequenas e médias empresas, justamente as que predominam no Brasil. Foi para atacar essa lacuna que surgiu o MPS.BR, o programa de Melhoria de Processo do Software Brasileiro, coordenado pela SOFTEX. Ele não foi concebido para competir com o CMMI em prestígio internacional, mas para ser um caminho mais gradual, mais barato e mais acessível à realidade nacional, sem abrir mão do rigor conceitual e mantendo compatibilidade com as referências internacionais de qualidade de processo.
A grande sacada do MPS.BR está no seu maior número de degraus. Em vez de cinco níveis, ele define sete, nomeados por letras de G até A, do menos maduro ao mais maduro — ordem contraintuitiva à primeira vista, pois começa em G e sobe até A. Em ordem crescente, os níveis são: G — Parcialmente Gerenciado, F — Gerenciado, E — Parcialmente Definido, D — Largamente Definido, C — Definido, B — Gerenciado Quantitativamente e A — Em Otimização.
Por que sete degraus em vez de cinco? Porque degraus menores são mais fáceis de subir. Uma empresa pequena que hoje trabalha no caos consegue enxergar o nível G como uma meta próxima, conquistá-lo, colher um reconhecimento formal e ganhar fôlego para o próximo passo. Essa gradação fina torna a jornada de melhoria viável para quem tem pouco caixa e pouca folga. É política pública aplicada à qualidade de software: o objetivo é fazer muitas empresas darem o primeiro passo, não apenas as grandes chegarem ao topo.
flowchart BT
G[Nivel G — Parcialmente Gerenciado] --> F[Nivel F — Gerenciado]
F --> E[Nivel E — Parcialmente Definido]
E --> D[Nivel D — Largamente Definido]
D --> C[Nivel C — Definido]
C --> B[Nivel B — Gerenciado Quantitativamente]
B --> A[Nivel A — Em Otimizacao]
style G fill:#f8d7da,stroke:#842029
style F fill:#ffe5d0,stroke:#8a4b00
style E fill:#fff3cd,stroke:#664d03
style D fill:#e7f1d5,stroke:#4d6b0f
style C fill:#cfe2ff,stroke:#084298
style B fill:#d1e7dd,stroke:#0f5132
style A fill:#e2d9f3,stroke:#59359a
Comparando CMMI e MPS.BR
As duas escadas descrevem a mesma viagem — do caos improvisado à melhoria contínua guiada por dados —, mas com passos de tamanhos diferentes. Vale colocá-las lado a lado, porque a correspondência esclarece a intenção de cada modelo.
| Estágio de maturidade | CMMI | MPS.BR |
|---|---|---|
| Ponto de partida (sem gestão) | Nível 1 — Inicial | (situação anterior a G) |
| Gestão básica de projetos | Nível 2 — Gerenciado | Níveis G e F |
| Processo padrão da organização | Nível 3 — Definido | Níveis E, D e C |
| Processo medido por dados | Nível 4 — Gerenciado Quantitativamente | Nível B |
| Melhoria contínua | Nível 5 — Em Otimização | Nível A |
Repare no que a tabela revela. O MPS.BR essencialmente fatia os níveis do CMMI em degraus menores: onde o CMMI dá um salto do nível 2 para o 3, o MPS.BR oferece um caminho intermediário. Topo e base são conceitualmente equivalentes; o que muda é a granularidade do meio, pensada para acompanhar a empresa passo a passo.
A tabela a seguir resume as diferenças de propósito e contexto entre os dois, que é o que você deve reter.
| Dimensão | CMMI | MPS.BR |
|---|---|---|
| Origem | Internacional (contexto norte-americano) | Brasileiro, coordenado pela SOFTEX |
| Número de níveis | Cinco | Sete (de G a A) |
| Granularidade da escada | Passos maiores | Passos menores e mais graduais |
| Custo e esforço de avaliação | Tipicamente mais altos | Pensado para ser mais acessível |
| Público-alvo prioritário | Organizações de qualquer porte, com peso no mercado global | Pequenas e médias empresas brasileiras |
| Reconhecimento | Amplo reconhecimento internacional | Forte no mercado nacional |
Não se trata de um modelo ser “melhor” que o outro. O CMMI carrega prestígio internacional e é exigido em muitos contratos globais; o MPS.BR é o caminho pragmático para elevar a maturidade média da indústria brasileira, degrau a degrau. Uma empresa pode começar pelo MPS.BR e depois buscar o CMMI quando amadurecer e precisar do reconhecimento externo.
Uma prática madura vista no código
Você pode se perguntar o que uma escada de maturidade organizacional tem a ver com as linhas que você escreve. A resposta é: tudo, porque a maturidade do processo se manifesta em decisões concretas de engenharia. Quando o processo é apenas inicial, cada um valida entrada do seu jeito, espalhando regras pelo código. Quando amadurece para o nível definido, a organização padroniza e exige verificação sistemática. Veja a diferença numa verificação de dados de um pedido.
Esse código “funciona” nos casos felizes e falha silenciosamente nos demais — sintoma típico de processo sem verificação institucionalizada. Agora observe como uma prática madura, com padronização e verificação explícita de pré-condições, se reflete no mesmo trecho.
/// Padrao da organizacao: toda operacao valida pre-condicoes de forma explicita.
class Pedido {
final double precoUnitario;
final int quantidade;
Pedido({required this.precoUnitario, required this.quantidade}) {
if (precoUnitario < 0) {
throw ArgumentError('precoUnitario nao pode ser negativo: $precoUnitario');
}
if (quantidade <= 0) {
throw ArgumentError('quantidade deve ser positiva: $quantidade');
}
}
double get total => precoUnitario * quantidade;
}A segunda versão não é fruto de um programador mais inteligente. É fruto de um processo que definiu um padrão — “toda entidade valida suas pré-condições e falha de forma clara” — e que verifica seu cumprimento em revisões e testes. Esse é o elo que fecha a distinção do início do módulo: qualidade de processo (padronizar e verificar) produzindo qualidade de produto (código confiável, que falha de forma previsível). A maturidade não mora no herói, e sim no padrão institucionalizado.
DicaComo enxergar maturidade no dia a dia
Da próxima vez que ler um código, pergunte-se: isto reflete um hábito da equipe inteira ou uma escolha isolada deste autor? Testes automatizados, nomes padronizados e tratamento consistente de erros são impressões digitais de um processo maduro. Sua ausência denuncia um processo ainda inicial, por mais talentosos que sejam os programadores.
O fecho da disciplina: qualidade de processo dá sentido a tudo
Olhe para trás e veja o desenho completo. Estudamos requisitos porque um processo maduro especifica com método antes de construir. Estudamos UML e projeto porque ele organiza a estrutura antes de codificar. Estudamos testes e TDD porque ele valida de forma sistemática, não por sorte. Estudamos manutenção e qualidade porque ele cuida da evolução do software no tempo. Cada tema do semestre foi, na verdade, uma das áreas de processo que um modelo de maturidade exige. O que os modelos deste módulo fazem é dar nome, ordem e medida a esse conjunto.
É por isso que deixei este tema para o fim. Nos primeiros módulos, cada assunto podia parecer uma técnica isolada — uma forma de escrever requisitos aqui, um diagrama ali, um jeito de testar acolá. Agora você tem o mapa que os une. A qualidade do processo é a moldura que explica por que investimos em cada uma dessas práticas: juntas e institucionalizadas, elas transformam o software de um ato heroico e imprevisível em uma engenharia confiável e repetível. Voltamos à mesma frase com que abrimos o semestre: na base de tudo está o compromisso com a qualidade. Este módulo mostrou que esse compromisso não é um sentimento, e sim um processo que se pode descrever, avaliar e melhorar.
Síntese
Quero que você retenha três ideias deste último encontro. A primeira é a distinção entre qualidade de produto e qualidade de processo, e a aposta que as liga: um bom processo tende a gerar um bom produto, porque captura erros cedo e torna o resultado previsível. A segunda é o vocabulário dos modelos: a ISO/IEC 25010 nomeia a qualidade do produto e a ISO 9001 a gestão da qualidade, enquanto CMMI (cinco níveis) e MPS.BR (sete níveis, de G a A, mais graduais e acessíveis à indústria brasileira) descrevem a mesma escada de maturidade com granularidades diferentes. A terceira, que encerra a disciplina, é que a maturidade do processo dá sentido a tudo o que estudamos: cada técnica do semestre é peça de um processo que, amadurecido, sustenta a qualidade no tempo.
Para consolidar antes da aula: escolha um dos temas que estudamos — requisitos, projeto, testes, manutenção — e explique, em voz alta, a que nível de maturidade de processo ele pertence e por que uma organização inicial normalmente não o pratica bem. Se conseguir amarrar aquele tema à ideia de maturidade de processo, terá entendido não só este módulo, mas o sentido de toda a disciplina.