Aula 03/02/2026
Análise resumida dos Tutoriais GQS de 01 a 05
Apresentação (21 a 24)
Alinhamento com as duas próximas equipes (07 e 08)
Introdução
- Mapa do Conhecimento, Padrões Técnicos e Novos Escopos
O SWEBOK (Software Engineering Body of Knowledge) é a principal referência internacional para organizar, padronizar e legitimar o conhecimento da Engenharia de Software. Para uma turma de Gestão da Qualidade de Software, ele deve ser entendido menos como um “conteúdo a decorar” e mais como um mapa de governança do conhecimento: define o que a área reconhece como práticas maduras, quais competências são esperadas de profissionais e como avaliar se um processo, produto ou organização está alinhado ao estado da arte da engenharia.
O Mapa do Conhecimento do SWEBOK estrutura a Engenharia de Software em áreas de conhecimento (Knowledge Areas – KAs), como Requisitos, Projeto, Construção, Testes, Manutenção, Gerência, Qualidade e Processos. Do ponto de vista da qualidade, esse mapa é essencial porque deixa claro que qualidade não é uma fase, mas um atributo transversal: ela emerge da coerência entre requisitos bem definidos, decisões de projeto rastreáveis, código verificável, testes sistemáticos e processos controlados. Em gestão da qualidade, o mapa funciona como instrumento de diagnóstico: ele permite identificar lacunas técnicas, riscos organizacionais e pontos onde a ausência de disciplina compromete o resultado final.
Os Padrões Técnicos associados ao SWEBOK reforçam seu papel como ponte entre teoria e prática. O guia se ancora em normas amplamente reconhecidas, como ISO/IEC (qualidade de produto e processo), IEEE (documentação, verificação e validação) e modelos de melhoria de processo. Para a gestão da qualidade, isso significa que o SWEBOK não propõe “boas ideias”, mas referencia critérios auditáveis, comparáveis e aceitos internacionalmente. Ele oferece uma base comum para avaliação de conformidade, definição de métricas, construção de processos e alinhamento entre equipes técnicas, gestão e stakeholders externos.
A versão 4 do SWEBOK amplia significativamente seu valor para a área de qualidade ao incorporar novos escopos e uma visão mais moderna da engenharia de software. Ela reforça temas como engenharia orientada a dados, integração entre desenvolvimento e operação, sistemas intensivos em software e maior atenção ao contexto organizacional e humano. O principal benefício para a Gestão da Qualidade de Software é a mudança de foco: qualidade deixa de ser vista apenas como controle e passa a ser entendida como capacidade organizacional de entregar software confiável, sustentável e evolutivo em ambientes complexos. Em outras palavras, o SWEBOK v4 não ensina apenas “como fazer software certo”, mas como estruturar a organização para fazê-lo consistentemente bem.
Qualidade e Requisitos
- QA x QC, Requisito Flutuante e Falhas
A distinção entre QA (Quality Assurance) e QC (Quality Control) é fundamental para a Gestão da Qualidade de Software. QA refere-se a um conjunto de atividades preventivas, focadas em processos: definir padrões, métodos, práticas e políticas que reduzam a probabilidade de defeitos. Já QC é reativo, concentrado no produto: testar, inspecionar e verificar se o software atende aos requisitos estabelecidos. Em termos simples, QA pergunta “estamos desenvolvendo da maneira correta?” enquanto QC pergunta “o que foi desenvolvido está correto?”. Projetos que confundem ou negligenciam essa distinção tendem a investir tarde demais na qualidade, quando o custo de correção já é alto.
O SWEBOK trata qualidade como uma área de conhecimento própria, mas deixa claro que ela é transversal a todo o ciclo de vida do software. Qualidade não se resume a testes finais; ela envolve requisitos bem definidos, decisões de projeto justificadas, código compreensível, verificável e processos monitoráveis. Para a gestão, isso implica sair da lógica de “caçar erros” e adotar uma abordagem sistêmica: estabelecer critérios de qualidade desde o início, definir métricas, garantir rastreabilidade e promover revisões contínuas. A qualidade, sob a ótica do SWEBOK, é resultado de disciplina técnica e organizacional, não de esforço heroico pontual.
Um dos maiores inimigos dessa disciplina é o chamado requisito flutuante: requisitos que mudam constantemente, são ambíguos ou não possuem critérios claros de aceitação. O SWEBOK enfatiza que requisitos mal gerenciados comprometem diretamente a qualidade, pois tornam impossível saber o que significa “software correto”. Para a Gestão da Qualidade de Software, o problema não é a mudança em si, mas a mudança sem controle. Requisitos flutuantes sem rastreabilidade, impacto analisado e validação formal geram retrabalho, inconsistência e fragilidade técnica, corroendo qualquer esforço de QA ou QC.
O SWEBOK reforça um ponto recorrente em estudos da área: falhas são a causa número 1 de fracassos em projetos de software, e essas falhas raramente são apenas técnicas. Elas decorrem, em grande parte, de processos deficientes, requisitos mal definidos, ausência de prevenção e gestão reativa da qualidade. Para uma turma de Gestão da Qualidade de Software, a mensagem central é clara: qualidade não é um custo adicional nem uma etapa final, mas um fator crítico de sobrevivência do projeto. Investir em QA, controlar requisitos e tratar falhas como sinais de problemas sistêmicos — e não como exceções isoladas — é o que diferencia projetos que fracassam daqueles que conseguem entregar software confiável de forma consistente.
Projeto e Construção de Software
- Requisitos para Construção, MVVM, TDD , DDD
A transição de Requisitos para Construção é um dos pontos mais sensíveis para a qualidade de software. É nesse momento que decisões mal resolvidas em requisitos — ambiguidade, falta de critérios de aceitação, ausência de rastreabilidade — se transformam em defeitos estruturais no código. Para a Gestão da Qualidade, essa transição não deve ser vista como “passagem de bastão”, mas como um processo controlado: requisitos precisam ser suficientemente claros, verificáveis e validados para que a construção não seja baseada em interpretações individuais, o que invariavelmente gera inconsistência e retrabalho.
Arquiteturas como MVVM (Model–View–ViewModel) contribuem diretamente para a qualidade ao impor uma separação clara de responsabilidades entre interface, lógica de apresentação e domínio. Sob a ótica da gestão da qualidade, o valor do MVVM não está na tecnologia em si, mas na redução de acoplamento, no aumento da testabilidade e na previsibilidade do comportamento do sistema. Quando bem aplicado, esse padrão facilita a verificação, a manutenção e a evolução do software, pois mudanças na interface tendem a não comprometer regras de negócio, e vice-versa — um princípio central defendido pelo SWEBOK.
O TDD (Test-Driven Development) se alinha fortemente à visão do SWEBOK ao deslocar a qualidade para o início do processo de construção. Em vez de tratar testes como atividade corretiva (QC), o TDD funciona como mecanismo de garantia de qualidade (QA): ele força a explicitação do comportamento esperado antes da implementação, reduz ambiguidades e cria uma base de testes automatizados que atua como rede de segurança contínua. Para a gestão da qualidade, o ponto-chave não é “escrever testes antes”, mas usar o TDD como disciplina que melhora a clareza dos requisitos técnicos e reduz o custo das falhas ao longo do ciclo de vida.
Já o DDD (Domain-Driven Design) contribui para a qualidade ao atacar uma das principais causas de defeitos apontadas pelo SWEBOK: o desalinhamento entre o modelo de software e o domínio do problema. Ao estruturar o sistema a partir de um modelo de domínio explícito, linguagem ubíqua e limites bem definidos, o DDD reduz ruído de comunicação e decisões técnicas arbitrárias. Para a Gestão da Qualidade de Software, DDD, TDD e padrões arquiteturais como MVVM não devem ser vistos como modismos, mas como instrumentos complementares que fortalecem a transição entre requisitos e construção, aumentam a previsibilidade do sistema e tornam a qualidade um atributo construído desde a base, e não inspecionado tardiamente.
Testes e Manutenção
- Black-White Box, Testes de Regressão e Tipos de manutenção
A disciplina nos testes é um dos pilares centrais da Gestão da Qualidade de Software. Testar não é uma atividade eventual nem uma etapa final do projeto, mas um processo sistemático, planejado e repetível. O SWEBOK enfatiza que a qualidade só é sustentável quando os testes seguem critérios claros, têm objetivos definidos e estão integrados ao ciclo de vida do software. A ausência de disciplina transforma testes em ações improvisadas, incapazes de fornecer evidências confiáveis sobre o estado real do produto.
O SWEBOK organiza os testes, entre outros critérios, pela perspectiva Black Box e White Box. Testes de caixa preta avaliam o sistema a partir de seus requisitos e comportamento externo, sem considerar a implementação interna, sendo essenciais para validar se o software atende ao que foi especificado. Já os testes de caixa branca analisam a estrutura interna do código, cobrindo fluxos, decisões e caminhos lógicos, contribuindo para a detecção de defeitos estruturais. Para a gestão da qualidade, o ponto-chave é entender que essas abordagens são complementares: focar apenas em uma delas cria uma falsa sensação de cobertura e deixa riscos ocultos.
Os testes de regressão ocupam um papel estratégico na garantia da qualidade ao longo da evolução do sistema. Sempre que o software é modificado — seja para corrigir defeitos, adicionar funcionalidades ou adaptar-se a mudanças externas — existe o risco de reintroduzir falhas já resolvidas. O SWEBOK destaca que testes de regressão são o principal mecanismo para proteger o investimento feito em qualidade ao longo do tempo. Para a gestão, eles funcionam como um indicador de maturidade: sistemas que não possuem regressão estruturada tendem a se tornar instáveis à medida que evoluem.
Tipos de manutenção se conecta diretamente com testes e qualidade no longo prazo. O SWEBOK classifica a manutenção em corretiva, adaptativa, perfectiva e preventiva, e todas dependem fortemente de uma base sólida de testes. Manutenção corretiva sem testes gera ciclos intermináveis de falhas; manutenção adaptativa sem regressão aumenta o risco a cada mudança; manutenção perfectiva sem cobertura adequada degrada a arquitetura; e manutenção preventiva só é viável quando há visibilidade sobre o comportamento do sistema. Para uma turma de Gestão da Qualidade de Software, a mensagem central é clara: testes disciplinados não servem apenas para encontrar erros, mas para viabilizar a evolução controlada e sustentável do software.
Gerências
- Changes no ITIL, Baseline, Métricas
A Gerência de Engenharia de Software (ESOF) tem como foco central garantir controle, previsibilidade e qualidade ao longo do ciclo de vida do software. A integração com práticas de Changes do ITIL, mantido pela AXELOS, reforça essa visão ao tratar mudanças como eventos formais, avaliados quanto a impacto, risco e benefício. Para a Gestão da Qualidade de Software, isso significa que alterações em requisitos, código ou infraestrutura não devem ser vistas como exceções inevitáveis, mas como atividades gerenciáveis, cujo mau controle é uma das principais fontes de falhas e retrabalho.
A definição e manutenção de uma baseline dos artefatos é outro elemento essencial destacado pelo SWEBOK. Baseline representa o conjunto de versões aprovadas de requisitos, modelos, código e testes que servem como referência estável para evolução do sistema. Do ponto de vista da qualidade, sem baseline não há controle real: não é possível saber o que mudou, por que mudou ou se a mudança degradou o produto. Em ambientes educacionais e profissionais, a ausência de baseline costuma levar à perda de rastreabilidade, dificuldades de auditoria e à falsa impressão de progresso, quando na verdade há apenas variação descontrolada.
As métricas na Gerência de ESOF são o instrumento que transforma percepção em evidência. O SWEBOK enfatiza que qualidade não pode ser gerenciada apenas por opinião; ela exige indicadores objetivos relacionados a esforço, defeitos, cobertura de testes, retrabalho e estabilidade ao longo do tempo. Métricas bem escolhidas permitem avaliar a eficácia do processo, identificar tendências negativas precocemente e sustentar decisões gerenciais. Para a Gestão da Qualidade de Software, o valor das métricas não está em medir tudo, mas em medir aquilo que realmente reflete risco, qualidade e capacidade de entrega.
O foco da Gerência de ESOF é integrar testes, manutenção e controle de mudanças em uma visão única de qualidade contínua. Disciplina nos testes — incluindo abordagens de Black Box e White Box, testes de regressão e suporte aos diferentes tipos de manutenção (corretiva, adaptativa, perfectiva e preventiva) — é o que garante que o software possa evoluir sem perder confiabilidade. Para uma turma de Gestão da Qualidade de Software, a mensagem-chave do SWEBOK é clara: qualidade não é resultado de inspeção pontual, mas de gestão sistemática, apoiada em controle de mudanças, baselines bem definidas, métricas relevantes e testes disciplinados ao longo de toda a vida útil do sistema.
Temas de hoje
https://www.overleaf.com/read/gvtznjcjmtns#ee9114
21. Modelos de Processos de Software - Samuel Vieira Fonseca
22. Squad - Joabe Guimaraes Rodrigues
23. UML - Tainá Souza Peixoto
24. MDE - Bruna Teodoro Ribeiro