João Gabriel (discussão | contribs)
Criou página com '=Garantia de Entrega de Software (Software Delivery Assurance)= <br> ==='''Responsável:''' João Gabriel === ==='''Última Atualização:''' 24/11/2025 === ==='''Status:''' Em desenvolvimento === <br> ==1. Visão Geral== <br> 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, e...'
 
João Gabriel (discussão | contribs)
 
(21 revisões intermediárias pelo mesmo usuário não estão sendo mostradas)
Linha 3: Linha 3:
<br>
<br>


==='''Responsável:''' João Gabriel ===
===='''Responsável:''' João Gabriel ====
==='''Última Atualização:''' 24/11/2025 ===
 
==='''Status:''' Em desenvolvimento ===
===='''Última Atualização:''' 24/11/2025 ====
 
===='''Status:''' Em desenvolvimento ====


<br>
<br>
Linha 19: Linha 21:
<br>
<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:
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 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).
*'''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.
*'''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.
*'''Software Quality (Cap. 12) & Testing (Cap. 5):''' Implementação de Quality Gates (portões de qualidade) automatizados no pipeline.
Linha 33: Linha 41:
<br>
<br>


===3. Principais Responsabilidades===
==3. Principais Responsabilidades==


O papel de Garantia de Entrega cobre as seguintes atividades:
[[Arquivo: Tabela_ESOF_gdeds.jpeg]]


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


Definição da estratégia de branching (ex: GitFlow, Trunk Based).
*'''3.1. Na Fase de Teste'''


Garantia da integridade do repositório de código.
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.


Automação de Build (CI):
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.


Criação de scripts que compilam o código e geram artefatos.
*'''3.2. Na Fase de Implantação'''


Gerenciamento de dependências do projeto.
Esta é a responsabilidade core da função. Envolve mover o artefato aprovado para produção.


Automação de Testes e Qualidade:
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.


Configuração da execução automática de testes unitários e de integração.
==4. Integração com o Time==


Configuração de ferramentas de análise estática de código (SonarQube, linters).
Abaixo detalha-se como a Garantia de Entrega interage com as outras áreas da Software House:


Gerenciamento de Release e Deploy (CD):
'''4.1. Com Engenharia de Requisitos (Leonardo)'''


Empacotamento da aplicação (ex: Imagens Docker, Executáveis).
*Entrada: Critérios de Aceite funcionais e não-funcionais.


Automatização da implantação nos ambientes (Dev, Homologação, Produção).
*Ação: Configuração do pipeline para validar se o build atende aos requisitos técnicos (ex: tempo de resposta, segurança básica).


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


Se bem-sucedido, retorna um objeto JSON com as seguintes informações:
'''4.2. Com Projeto de Software (Luis Henrique)'''


*'''tenureDateCheck:''' verdadeiro quando a assinatura móvel identificada possui um período válido desde a tenureDate, falso caso contrário.
*Entrada: Definição da Arquitetura e Tecnologias.


*'''contractType:''' tipo de contrato (ex.: PAYG - prepaid (pay-as-you-go) account, PAYM - contract account e Business), quando disponível.
*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).


<br>
<br>


*Exemplo de '''Response 200 OK''':
*'''Documentação Interna:'''
<syntaxhighlight lang="json">
 
{
  "tenureDateCheck": true,
  "contractType": "PAYM"
}
</syntaxhighlight>
<br>
<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

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:


  1. Engenharia de Requisitos - Leonardo
  2. Projeto de Software - Luis Henrique
  3. Operação - Samuel
  4. Q&A - Giovana