GERAÇÃO DE REGISTROS DE DECISÃO DE

ARQUITETURA UTILIZANDO GPT 3.5

KEVIN BELTRÃO DE MELO

ORIENTADOR: VINICIUS GARCIA
 Kevin Beltrão
8⁰ PERÍODO DE SISTEMAS DE INFORMAÇÃO

Sobre mim

Engenheiro de Software desde 2018

Atualmente trabalhando para a Varsity Tutors
Interesse em Deep Learning
Talvez o primeiro aluno da pandemia de SI a
se formar (2020.1)
1. Arquitetura

2. Registro de Decisão de Arquitetura

Conceitos
3. Processamento de linguagem natural
 Arquitetura
NA ENGENHARIA DE SOFTWARE

Organização Complexidade Objetivos

Como diferentes Domar a complexidade Diferentes projetos vão ter
elementos de um de um sistema necessidades diferentes e
sistema se relacionam consequentemente diferentes
tipos de arquitetura serão
mais adequadas
Registro de Decisão de
Arquitetura
Architecture Decision Record (ADR)

Documentação Comunicação Não arquitetos

Documenta as decisões Permite que diferentes Auxilia outros
de arquitetura, stakeholders tenham desenvolvedores a
considerando fatores acesso à decisão tomarem
como contexto, responsabilidade pela
consequências e arquitetura
alternativas.
 Processamento de
Linguagem Natural
Para gerar textos

Linguagem Gerar textos Aplicação

humana Além de interpretar, É usado para diferentes
Interpreta linguagens também pode ser finalidades, como para
humanas, como inglês, utilizado para gerar gerar código/testes
espanhol, ou português, textos para um projeto e
ao invés de operações Chatbot
matemáticas
 Introdução
Sistemas Demandas Documentar Tempo Inteligência
complexos variadas arquitetura artificial
 Objetivo Geral
Desenvolver e avaliar um protótipo que, com o auxílio da API do OpenAI, gere
Architecture Decision Records editáveis a partir de descrições fornecidas pelo
usuário, servindo como um ponto de partida para a documentação final.
 Objetivos Específicos
1. Investigar os fundamentos e formatos padrão dos ADRs.
2. Integrar a API do OpenAI ao protótipo para aproveitar suas capacidades de processamento de
linguagem natural.
3. Definir critérios de avaliação para os ADRs gerados, considerando tanto a qualidade inicial
quanto a facilidade de edição.
4. Coletar feedback de profissionais da área para avaliar a eficácia, precisão e utilidade do
protótipo no cenário real de desenvolvimento.
 Metodologia

Protótipo Experimento Entrevista

Frontend + Backend + Usuários utilizam o Usuários são
API do openAI protótipo simulando os entrevistados de acordo
seus trabalhos com as perguntas
definidas
Protótipo e Repositório

desenvolvimento
Monorepo utilizando Lerna hospedado no GitHub. Contém a
aplicação de Backend e de Frontend, ambas baseadas em
TypeScript.

Frontend
Client baseado em ReactJS utilizando Vite com SWC. Módulo
React Markdown do NPM para exibir a saída do markdown
escrito. Faz requisições ao backend utilizando Axios.

Backend
API Restful feita em Express.js. Recebe a requisição do
frontend com a descrição da mudança de arquitetura,
adiciona o prompt pré-definido e utiliza o módulo do NPM
openai para fazer a requisição. O modelo selecionado é o
gpt-3.5-turbo.
Client
 Prompt
You are a staff engineer responsible for
creating Architecture Decision Records.

You will be provided a description of an

architecture decision and you will need to
create an ADR.

As a staff engineer, it's also expected you will

provide new insights that are not mentioned
on the input, such as consequences,
alternatives, and rationale.

Description:\n\n
Coleta de dados Experimento com os usuários
Os profissionais utilizavam a aplicação e ao terem o ADR
gerado, era pedido que editassem o resultado até estarem
satisfeitos. Nisso era avaliado o quanto estavam editando e
por quais motivos.
Foram entrevistados na pesquisa 12 profissionais, de
graduando a doutor e de 2 a 14 anos de experiência.

Entrevista
Após cada experimento, foram feitas perguntas ao
profissional da vez para avaliar a solução. O objetivo principal
era avaliar se a solução apresentada era preferível às
alternativas existentes.
 Formulário de Pesquisa
1. Nota de 0 a 10 do quão relevante foi o ADR gerado
2. Nota de 0 a 10 sobre o quão intuitiva é a ferramenta
3. Você acredita que a ferramenta economizou seu tempo em relação à
criação manual de um ADR?
4. Você usaria essa ferramenta em seus projetos futuros? Por quê?
5. Quais foram os principais pontos fortes e fracos que você identificou no
ADR gerado?
6. Gostaria que alguma funcionalidade fosse adicionada à ferramenta?
7. Como você compara essa ferramenta com outros métodos que você já
usou para criar ADRs?
Resultados
Avaliação Geral da Relevância dos ADRs gerados

Média 9.1
Menor nota 7.5
Usuário sentiu falta de uma análise mais profunda e insights mais completos do impacto
da mudança de arquitetura na empresa
 Avaliação Geral da Intuição da Interface de Uso

Média 9.4
Menor nota 8
Reclamações mais comuns: poderia ter uma descrição melhor do que era esperado no
input e faltam labels
Economia de tempo em relação a produção manual de
um ADR

Foi unânime que a ferramenta economizou tempo dos usuários em relação a produção
manual de um ADR

Foi recorremente destacado que além do conteúdo textual gerado, a formatação gerada
também foi um fator impactante.
 Uso da ferramenta em seus projetos futuros

De forma unânime, os usuários responderam que utilizariam esta ferramenta em projetos

futuros, mais uma vez destacando a formatação em Markdown do output.
 Principais pontos fortes e fracos

Principais pontos fortes:

Novos insights
Economia de tempo
Formatação do texto

Principais pontos fracos:

Falta de profundidade em alguns tópicos
Partes do output redundantes ou prolíxas
Texto muito similar ao input do usuário
 Sugestão de funcionalidade

Uma das sugestões mais repetidas foi a capacidade de manter uma conversa com a AI para
direcioná-la para melhores outputs.

Outras interassantes foram integração com o GitHub e geração de imagens no ADR.

 Comparação com outras ferramentas

Os usuários compararam com o uso do GPT diretamente e com templates. Demonstraram

preferência pelo protótipo.
 Conclusão

Eficiência e Tempo Intuitividade

qualidade
Obrigado

E-mail
kbm@cin.ufpe.br