Visage / Engenharia de Software

Grandes sistemas não começam pelo código. Começam pela compreensão correta do problema.

Software Delivery Framework. Um processo estruturado para descobrir, projetar, construir, validar, implantar e evoluir software crítico, da necessidade operacional à operação assistida. Toda fase termina em um gate, e nenhuma fase crítica avança sem critério objetivo de saída.

Versão 1.0 11 fases 5 trilhos transversais Referência: ISO/IEC/IEEE 12207:2026 e NIST SP 800-218

01 · Princípios

Cinco ideias sustentam todo o resto. Elas não são estilo de trabalho, são o que separa um projeto que entra em operação de um que vira coleção de telas.

O código é consequência.

Antes dele existem decisões sobre negócio, processos, pessoas, dados, arquitetura, segurança e experiência de uso. Quanto mais tarde uma decisão estrutural aparece, maior tende a ser o impacto dela sobre prazo, custo e complexidade, porque já existem funcionalidades dependentes daquela decisão.

Nenhuma fase crítica avança sem critério objetivo de saída.

Cada fase termina em um gate. Um gate não é uma reunião, é uma lista de itens que precisam estar definidos e registrados. Enquanto não estiverem, a fase seguinte não começa, e isso protege o cliente tanto quanto protege a Visage Web.

Baseline não é prisão.

Software evolui e mudar de ideia é legítimo. O problema nunca foi mudar, foi mudar sem governança. Toda solicitação é classificada, tem impacto analisado e é aprovada antes de entrar, e é isso que encerra a discussão sobre o que estava ou não incluído.

Percentual de telas prontas não é percentual de sistema pronto.

Um módulo pode parecer noventa por cento concluído na tela e ainda faltar validação, permissão, auditoria, integração, tratamento de erro, teste, segurança, desempenho, documentação e homologação. Por isso medimos estado objetivo por item, não sensação de progresso.

Segurança não é etapa final.

Tratar segurança como conferência de fim de projeto é o caminho mais caro de descobrir um problema. Ela atravessa todas as fases, junto com privacidade, qualidade, documentação e observabilidade.

02 · O ciclo de vida

Onze fases, cada uma terminando em um gate. Clique em uma fase para ver o objetivo e o critério de saída dela. Um gate não é reunião, é lista de itens que precisam estar definidos e registrados para a fase seguinte começar.

Intake e qualificação

Entender o problema de negócio, os envolvidos, as restrições e a viabilidade antes de qualquer promessa técnica.

Gate de saída Project Brief

Discovery

Mapear a operação real, não a operação que está no organograma: como o trabalho acontece hoje, com quais documentos, planilhas e exceções.

Gate de saída Discovery Report

Requisitos

Transformar necessidade em requisito verificável, com critério de aceite escrito. Requisito que não pode ser verificado não é requisito, é expectativa.

Gate de saída Scope Baseline

Arquitetura da solução

Definir modelo de dados, integrações, autenticação, autorização, ambientes, segurança e requisitos não funcionais antes de produzir tela.

Gate de saída Architecture Approval

UX e design de produto

Desenhar fluxo, jornada e interface a partir do requisito aprovado, validando com quem vai usar de verdade.

Gate de saída Design Approval

Planejamento e backlog

Quebrar o escopo em épicos, histórias e releases, com prioridade, dependências e ordem de implantação por área.

Gate de saída Development Baseline

Engenharia

Construir de forma incremental, com integração contínua, revisão de código e publicação em ambiente separado da operação.

Gate de saída Release Candidate

Qualidade e segurança

Testar função, regressão, permissão, segurança, carga e desempenho antes de o cliente ver, não depois.

Gate de saída QA Approval

Homologação

O cliente valida processos reais de negócio, com dado real, em ambiente separado, e assina o aceite.

Gate de saída Acceptance Sign-off

Implantação

Migrar dado, publicar em produção, ligar observabilidade e backup, com plano de retorno escrito antes de subir.

Gate de saída Go-Live

Operação assistida e evolução

Acompanhar de perto os primeiros ciclos reais, medir adoção, corrigir o que aparece no uso e abrir o roteiro de evolução.

Gate de saída Operação contínua

Cinco trilhos atravessam todas as fases

Nenhum deles é etapa. Tratar qualquer um como conferência de fim de projeto é o jeito mais caro de descobrir um problema.

Segurança

Modelagem de ameaça, controle de acesso, tratamento de dado sensível e revisão de dependência, em toda fase, não no fim.

Privacidade

Que dado pessoal existe, por que existe, quem acessa, por quanto tempo fica e como é apagado.

Qualidade

Critério de aceite, teste, revisão de código e regressão como parte do trabalho, não como etapa extra.

Documentação

Decisão registrada, modelo de dado descrito e manual do que muda para quem opera.

Observabilidade

Log, auditoria, métrica de uso e alerta, para que o sistema conte o que está acontecendo antes de o usuário reclamar.

03 · Os gates

O que precisa estar definido e registrado para a fase seguinte começar. Clique para abrir cada um.

O desenvolvimento não estima nem se compromete com prazo antes disto.

Requisitos escritos e numerados, cada um com critério de aceite verificável
Regras de negócio registradas, inclusive as exceções que só existem na prática
O que está fora do escopo, dito explicitamente
Volume esperado de dado, usuários e transações
Dependências de terceiros identificadas, com responsável por cada acesso

Este é o gate mais caro de pular. Decisão estrutural descoberta tarde custa mais porque já existem funcionalidades dependentes dela.

Entidades principais e relacionamentos definidos
Autenticação, autorização e papéis de acesso definidos
Integrações e contratos de dados com sistemas de terceiros
Estratégia de arquivos, anexos e documentos
Auditoria, log e rastreabilidade de quem alterou o quê
Ambientes de desenvolvimento, homologação e produção
Política de backup e plano de retorno
Requisitos não funcionais: desempenho, disponibilidade, retenção e volume

Nada chega ao cliente para homologar sem passar por aqui. Homologação não é o primeiro teste do sistema.

Teste funcional dos critérios de aceite do requisito
Regressão nas áreas que dependem do que foi alterado
Permissão testada entrando com o acesso de um usuário comum, não do administrador
Verificação de segurança da mudança e das dependências
Comportamento em celular quando a rotina acontece em campo
Tratamento de erro e mensagem compreensível para quem opera

O aceite é do cliente e é registrado. É ele que separa entrega de retrabalho.

Processo de negócio executado de ponta a ponta com dado real
Pelo menos um caso fora do padrão testado
Aceite assinado pelo responsável da área e pelo coordenador
Pendências remanescentes classificadas e priorizadas, não esquecidas

Subir para produção é decisão conjunta, com caminho de volta definido antes.

Migração de dado validada por amostra conferida pelo cliente
Plano de retorno escrito e testado
Backup verificado antes da publicação
Monitoramento e alerta ligados
Data definida para desligar o processo antigo
Equipe treinada e canal de suporte comunicado

04 · Quem responde pelo quê

Boa parte do atrito em projeto de software nasce de responsabilidade não combinada. Homologação parada três semanas do lado do cliente não é atraso de desenvolvimento, e isso precisa estar dito antes de acontecer.

Visage Web

Arquitetura e modelagem de dados
UX e interface
Engenharia e revisão de código
Qualidade e testes
Segurança aplicada ao ciclo
Infraestrutura, ambientes e backup
Documentação técnica
Gestão do projeto e dos gates

Cliente

Product Owner nomeado e disponível
Disponibilidade das áreas envolvidas
Validação das regras de negócio
Fornecimento dos dados e documentos
Acesso a sistemas de terceiros
Homologação dentro do prazo combinado
Aprovações dentro do prazo combinado

Compartilhada

Definição e manutenção do escopo
Priorização
Gestão de riscos
Change requests
Decisão de go-live
Roteiro de evolução

05 · Governança de mudanças

Baseline não é prisão. Software evolui e mudar de ideia é legítimo. O problema nunca foi mudar, foi mudar sem governança. Toda solicitação cai em uma destas cinco categorias antes de qualquer coisa.

Solicitação Classificação Análise de impacto Aprovação Priorização Desenvolvimento

Categoria	O que é	Como entra	Custo
Bug	Comportamento diferente do requisito aprovado.	Entra imediatamente quando para a operação	Correção, sem custo
Ajuste	Alteração pequena que não modifica arquitetura nem esforço de forma significativa.	Entra na release corrente	Dentro do contrato
Melhoria	Evolução de funcionalidade existente e já aprovada.	Vai ao backlog e é priorizada	Dentro do contrato, conforme volume
Novo requisito	Capacidade não contemplada no baseline aprovado.	Passa por requisito, arquitetura e prazo próprios	Orçado à parte
Change request	Alteração com impacto mensurável em escopo, custo, prazo ou arquitetura.	Só entra com aprovação formal do patrocinador	Orçado à parte, com análise de impacto

06 · Como medimos progresso

Percentual de telas prontas não é percentual de sistema pronto. Um módulo pode parecer noventa por cento concluído na tela e ainda faltar validação, permissão, auditoria, integração, tratamento de erro, teste, segurança, desempenho, documentação e homologação. Por isso cada item tem um estado objetivo, e não uma porcentagem.

Backlog

Registrado, ainda não analisado.

Ready

Analisado, com critério de aceite e dependências resolvidas.

Em desenvolvimento

Em construção.

Code review

Revisado por outra pessoa antes de seguir.

QA

Em teste funcional, de regressão, permissão e segurança.

Validação do cliente

Em homologação com quem usa.

Aceito

Aceite registrado pelo cliente.

Publicado

Em produção e em uso.

Uma funcionalidade não está pronta porque funciona na máquina de quem programou. Está pronta quando, conforme aplicável:

Código concluído e revisado por outra pessoa
Critérios de aceite do requisito atendidos
Testes executados, incluindo regressão do que depende da mudança
Comportamento validado em desktop e em celular quando aplicável
Permissões verificadas com acesso de usuário comum
Log e auditoria registrando a operação
Tratamento de erro implementado, com mensagem compreensível
Verificação de segurança da mudança concluída
QA aprovado
Documentação e decisões atualizadas
Homologação realizada pelo cliente
Aceite registrado

07 · Fundamentos

Este framework foi estruturado com referência em práticas consolidadas de engenharia de software, adaptadas ao porte e ao contexto de cada projeto.

ISO/IEC/IEEE 12207:2026

Segunda edição, publicada em abril de 2026, que substitui a de 2017. Estabelece o conjunto comum de processos do ciclo de vida de software, da aquisição e do desenvolvimento à operação, manutenção e descarte. A própria norma prevê adaptação ao contexto, e é isso que permite um modelo híbrido como este, com governança por gates e execução iterativa.

NIST SP 800-218 (SSDF)

Recomenda integrar práticas de desenvolvimento seguro ao ciclo inteiro, justamente porque poucos modelos tratam segurança em profundidade, com o objetivo de reduzir vulnerabilidades e atacar as causas que as produzem. É a razão de segurança aparecer aqui como trilho, e não como etapa final.

A Visage Web não declara certificação nessas normas. Elas são a referência técnica sobre a qual o método foi construído.

Vai começar um sistema? Conte o que a sua operação precisa e mostramos em qual fase o seu projeto deve começar.

Falar com a Visage Web