Edição atual tal como às 18h53min de 24 de novembro de 2025

Garantia de Entrega de Software (Software Delivery Assurance)

Responsável: João Gabriel

Última Atualização: 24/11/2025

Status: Em desenvolvimento

1. Visão Geral

A área de Garantia de Entrega é responsável por projetar, implementar e manter os processos automatizados que levam o software do desenvolvimento até a produção. O objetivo é assegurar que o código produzido seja integrado, testado, empacotado e implantado de forma confiável, repetível e rastreável.

A responsabilidade é atuar como a ponte entre o Desenvolvimento (Engenharia de Requisitos e Projeto de Software) e a Operação (Infraestrutura), garantindo que os portões de qualidade (Q&A) sejam respeitados.

2. Fundamentos Teóricos

A prática de entrega nesta organização é fundamentada nas seguintes Áreas de Conhecimento (KAs) propostas pelo SWEBOK v4:

Software Requirements (Cap. 1): Identificação de requisitos funcionais e não-funcionais (como desempenho e segurança) para estabelecer Critérios de Aceite que validam se o software está pronto para entrega.

Software Engineering Operations (Cap. 6): Foco na automação de deploy, integração contínua (CI) e entrega contínua (CD).

Software Configuration Management (Cap. 8): Controle de versões, baselines de código e gestão de releases.

Software Quality (Cap. 12) & Testing (Cap. 5): Implementação de Quality Gates (portões de qualidade) automatizados no pipeline.

3. Principais Responsabilidades

Arquivo:Tabela ESOF gdeds.jpeg

A atuação é dividida conforme as fases do ciclo de vida do projeto:

3.1. Na Fase de Teste

Nesta etapa, a Garantia de Entrega atua em conjunto com a equipe de Q&A e Segurança. O objetivo não é apenas encontrar bugs, mas validar se o processo de build e empacotamento está estável.

Ação: Automatizar a execução dos testes criados pelo Q&A e garantir que o ambiente de testes (Homologação) seja um espelho fiel da produção.

3.2. Na Fase de Implantação

Esta é a responsabilidade core da função. Envolve mover o artefato aprovado para produção.

Ação: Executar o pipeline de deploy, gerenciar janelas de manutenção e monitorar a saúde da aplicação imediatamente após a publicação.

4. Integração com o Time

Abaixo detalha-se como a Garantia de Entrega interage com as outras áreas da Software House:

4.1. Com Engenharia de Requisitos (Leonardo)

Entrada: Critérios de Aceite funcionais e não-funcionais.

Ação: Configuração do pipeline para validar se o build atende aos requisitos técnicos (ex: tempo de resposta, segurança básica).

Rastreabilidade: Garantia de que cada Release possa ser ligada a um conjunto de Requisitos entregues.

4.2. Com Projeto de Software (Luis Henrique)

Entrada: Definição da Arquitetura e Tecnologias.

Ação: Criação de scripts de build compatíveis com a tecnologia escolhida (ex: Java, Node, Python) e empacotamento conforme a arquitetura (ex: Microsserviços vs Monolito).

4.3. Com Q&A / Testes (Giovana)

Entrada: Planos de teste e scripts de teste automatizados.

Ação: Execução automática desses testes a cada alteração de código (Commit). Se o teste falhar, a entrega é bloqueada (Quality Gate).

4.4. Com Operações (Samuel)

Entrada: Requisitos de infraestrutura e credenciais de acesso.

Saída: Pacote de software (artefato) pronto para execução.

Ação: Colaboração nos scripts de Infrastructure as Code (IaC) para garantir que o ambiente de teste seja igual ao de produção.

Referências e Leitura Recomendada

SWEBOK v4: Capítulos 6 (Operations), 8 (Configuration Mgmt) e 12 (Quality).

Documentação Interna:

Engenharia de Requisitos - Leonardo
Projeto de Software - Luis Henrique
Operação - Samuel
Q&A - Giovana

@@ Linha 21: / Linha 21: @@
 <br>
-===2. Fundamentos Teóricos===
+==2. Fundamentos Teóricos==
 A prática de entrega nesta organização é fundamentada nas seguintes Áreas de Conhecimento (KAs) propostas pelo SWEBOK v4:
 *'''Software Requirements (Cap. 1):''' Identificação de requisitos funcionais e não-funcionais (como desempenho e segurança) para estabelecer Critérios de Aceite que validam se o software está pronto para entrega.
+<br>
 *'''Software Engineering Operations (Cap. 6):''' Foco na automação de deploy, integração contínua (CI) e entrega contínua (CD).
+<br>
 *'''Software Configuration Management (Cap. 8):''' Controle de versões, baselines de código e gestão de releases.
+<br>
 *'''Software Quality (Cap. 12) & Testing (Cap. 5):''' Implementação de Quality Gates (portões de qualidade) automatizados no pipeline.
@@ Linha 35: / Linha 41: @@
 <br>
-===3. Principais Responsabilidades===
+==3. Principais Responsabilidades==
+[[Arquivo: Tabela_ESOF_gdeds.jpeg]]
+A atuação é dividida conforme as fases do ciclo de vida do projeto:
-O papel de Garantia de Entrega cobre as seguintes atividades:
+*'''3.1. Na Fase de Teste'''
-Gestão de Configuração:
+Nesta etapa, a Garantia de Entrega atua em conjunto com a equipe de Q&A e Segurança. O objetivo não é apenas encontrar bugs, mas validar se o processo de build e empacotamento está estável.
-Definição da estratégia de branching (ex: GitFlow, Trunk Based).
+Ação: Automatizar a execução dos testes criados pelo Q&A e garantir que o ambiente de testes (Homologação) seja um espelho fiel da produção.
-Garantia da integridade do repositório de código.
+*'''3.2. Na Fase de Implantação'''
-Automação de Build (CI):
+Esta é a responsabilidade core da função. Envolve mover o artefato aprovado para produção.
-Criação de scripts que compilam o código e geram artefatos.
+Ação: Executar o pipeline de deploy, gerenciar janelas de manutenção e monitorar a saúde da aplicação imediatamente após a publicação.
-Gerenciamento de dependências do projeto.
+==4. Integração com o Time==
-Automação de Testes e Qualidade:
+Abaixo detalha-se como a Garantia de Entrega interage com as outras áreas da Software House:
-Configuração da execução automática de testes unitários e de integração.
+'''4.1. Com Engenharia de Requisitos (Leonardo)'''
-Configuração de ferramentas de análise estática de código (SonarQube, linters).
+*Entrada: Critérios de Aceite funcionais e não-funcionais.
-Gerenciamento de Release e Deploy (CD):
+*Ação: Configuração do pipeline para validar se o build atende aos requisitos técnicos (ex: tempo de resposta, segurança básica).
-Empacotamento da aplicação (ex: Imagens Docker, Executáveis).
+*Rastreabilidade: Garantia de que cada Release possa ser ligada a um conjunto de Requisitos entregues.
-Automatização da implantação nos ambientes (Dev, Homologação, Produção).
+'''4.2. Com Projeto de Software (Luis Henrique)'''
-===pog===
+*Entrada: Definição da Arquitetura e Tecnologias.
-Se bem-sucedido, retorna um objeto JSON com as seguintes informações:
+*Ação: Criação de scripts de build compatíveis com a tecnologia escolhida (ex: Java, Node, Python) e empacotamento conforme a arquitetura (ex: Microsserviços vs Monolito).
-*'''tenureDateCheck:''' verdadeiro quando a assinatura móvel identificada possui um período válido desde a tenureDate, falso caso contrário.
+'''4.3. Com Q&A / Testes (Giovana)'''
-*'''contractType:''' tipo de contrato (ex.: PAYG - prepaid (pay-as-you-go) account, PAYM - contract account e Business), quando disponível.
+*Entrada: Planos de teste e scripts de teste automatizados.
+*Ação: Execução automática desses testes a cada alteração de código (Commit). Se o teste falhar, a entrega é bloqueada (Quality Gate).
+'''4.4. Com Operações (Samuel)'''
+*Entrada: Requisitos de infraestrutura e credenciais de acesso.
+*Saída: Pacote de software (artefato) pronto para execução.
+*Ação: Colaboração nos scripts de Infrastructure as Code (IaC) para garantir que o ambiente de teste seja igual ao de produção.
+==Referências e Leitura Recomendada==
+*'''SWEBOK v4:''' Capítulos 6 (Operations), 8 (Configuration Mgmt) e 12 (Quality).
 <br>
-*Exemplo de '''Response 200 OK''':
+*'''Documentação Interna:'''
-<syntaxhighlight lang="json">
-{
-  "tenureDateCheck": true,
-  "contractType": "PAYM"
-}
-</syntaxhighlight>
 <br>
-===Considerações===
+# [[Engenharia de Requisitos]] - Leonardo
+# [[Projeto de Software]] - Luis Henrique
-A API prioriza a privacidade dos usuários, informando apenas se o critério de tempo de vínculo do número foi atendido, sem revelar dados sensíveis. Sua lógica é flexível, permitindo ajustar o tempo mínimo de associação que deve ser considerado adequado — por exemplo, sinalizando números com menos de 30 dias de uso. Além disso, sua padronização facilita a integração entre diferentes operadoras e sistemas ao redor do mundo, tornando a adoção global mais simples. Outra vantagem é a possibilidade de integrações diretas com soluções de KYC, detecção de troca de SIM card ou ferramentas antifraude, ampliando o valor no ecossistema digital.
+# [[Operação]] - Samuel
+# [[Q&A]] - Giovana

Garantia da entrega do software: mudanças entre as edições