23 de julho de 2026
Sistema Web para Análise Comparativa do Poder de Compra entre Países
Caio de Luccas Rosolen; Mauricio Acconcia Dias
DOI: 10.22167/2675-6528-202600644
Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.
Resumo
Desenvolveu-se um sistema web para análise comparativa do poder de compra entre países, utilizando preços locais de produtos e indicadores salariais como base para o cálculo de métricas de acessibilidade. A pesquisa foi conduzida por meio de um estudo de caso aplicado, com foco na concepção e implementação de uma solução de software composta por módulos de coleta, persistência, processamento, API e interface web. Para tanto, utilizaram-se dados de preços obtidos via Canopy API e indicadores salariais da ILOSTAT, os quais foram armazenados em banco de dados PostgreSQL e processados sob demanda pelo backend. Os resultados demonstraram a viabilidade técnica da arquitetura modular adotada, evidenciando a integração entre os componentes do sistema, a preservação histórica dos dados coletados, a exposição padronizada das informações por meio de API REST e a exibição dos resultados em interface web. Observou-se que a solução implementada atendeu ao escopo do produto mínimo viável, permitindo consultas comparativas por país e por produto. Concluiu-se que o sistema alcançou o objetivo proposto e estabeleceu uma base consistente para futuras expansões, incluindo a ampliação de indicadores, análises históricas e a evolução da camada de apresentação.
Palavras-chave: Acessibilidade de compra; API REST; Arquitetura modular; Integração de dados; Produto mínimo viável.
1. Introdução
A crescente disponibilidade de dados públicos e de interfaces de programação de aplicações (APIs) tem transformado o cenário para o desenvolvimento de sistemas, ampliando as possibilidades de integração, processamento e disponibilização automatizada de informações econômicas. Este contexto, no entanto, impõe desafios significativos do ponto de vista da Engenharia de Software, demandando arquiteturas que sejam não apenas modulares e escaláveis, mas também capazes de garantir a rastreabilidade e a evolução contínua do sistema frente à natureza heterogênea das fontes de dados (Pressman e Maxim, 2016; Sommerville, 2016).
Essa necessidade técnica torna-se ainda mais premente quando o objetivo é realizar comparações econômicas em escala internacional. Tradicionalmente, análises baseadas exclusivamente na conversão cambial nominal frequentemente falham em representar o esforço real de aquisição de bens e serviços. A simples conversão de moedas não reflete as diferenças nos custos de vida e nos salários locais, o que pode levar a interpretações distorcidas sobre o poder de compra efetivo dos indivíduos em diferentes países.
Para superar as limitações da conversão cambial, instituições como o World Bank utilizam o International Comparison Program (ICP) para gerar paridades de poder de compra. Essas paridades ajustam os valores para controlar as variações nos níveis de preços entre economias (World Bank, 2026). Embora o ICP opere em uma escala macroeconômica, sua metodologia ressalta a importância de métricas que considerem a acessibilidade econômica em seus contextos locais distintos para comparações internacionais válidas.
Sob essa ótica, a relação entre o preço de um produto, o salário local e o tempo de trabalho necessário para adquirir esse item emerge como uma abordagem prática e intuitiva para mensurar o poder de compra. Essa perspectiva, conforme demonstrado por Ashenfelter (2001), oferece uma métrica tangível e de fácil compreensão, que reflete de forma mais precisa o custo real de vida e a capacidade aquisitiva em diferentes regiões.
Contudo, a aplicação dessas teorias econômicas em ferramentas digitais dinâmicas e acessíveis ao público ainda apresenta lacunas. Existe uma carência de soluções de software que integrem de forma automatizada e em nível operacional dados de preços locais e indicadores salariais, como os fornecidos pela International Labour Organization (ILO, 2026). A ausência de tais ferramentas dificulta a realização de comparações rápidas e intuitivas do poder de compra para itens específicos em diferentes países.
A priorização de dados da ILO justifica-se pela sua organização em bases comparáveis de salários e jornadas de trabalho, elementos cruciais para o cálculo do “esforço de compra” de forma automatizada. A oportunidade reside, portanto, na criação de soluções computacionais que preencham essa lacuna, permitindo a integração e o processamento desses dados para gerar métricas de acessibilidade.
Um sistema web capaz de coletar preços em diversos países e relacioná-los com indicadores econômicos oferece não apenas uma consulta comparativa simplificada, mas também estabelece uma base robusta para análises temporais sobre a evolução do poder de compra. Tal solução contribui para uma compreensão mais aprofundada das disparidades econômicas globais e para a tomada de decisões informadas, tanto por indivíduos quanto por organizações.
Diante desse cenário, o presente trabalho justifica-se pela necessidade de uma ferramenta que integre e processe dados econômicos heterogêneos de forma eficiente e transparente. O objetivo deste estudo foi desenvolver um sistema web para análise comparativa do poder de compra entre países, utilizando preços locais de produtos e indicadores salariais como base para o cálculo de métricas de acessibilidade.
2. Material e Métodos
A pesquisa foi delineada como um estudo de caso aplicado, com abordagem quali-quantitativa, focada no desenvolvimento de um sistema web para análise comparativa do poder de compra entre países. Este sistema foi concebido para coletar, armazenar, processar e disponibilizar dados econômicos de APIs públicas. A natureza aplicada buscou a construção de uma solução funcional de software, enquanto a abordagem qualitativa orientou a arquitetura e modelagem dos componentes. A dimensão quantitativa manifestou-se na coleta e tratamento de dados numéricos para gerar comparações.
Os dados empregados foram secundários, obtidos de APIs públicas e fontes institucionais externas, assegurando padronização e reprodutibilidade. Para a coleta de preços de produtos, utilizou-se a Canopy API. Os indicadores econômicos e salariais foram obtidos da base ILOSTAT (International Labour Organization Statistics), mantida pela Organização Internacional do Trabalho (ILO, 2026), priorizando remuneração mensal e por hora, salário-mínimo legal e jornada de trabalho, essenciais para o cálculo das métricas de acessibilidade.
Os critérios de seleção das fontes incluíram disponibilidade técnica e viabilidade de integração. Países e produtos incluídos no MVP foram definidos intencionalmente, considerando a disponibilidade das fontes e as limitações operacionais da API de preços, restringindo o universo de coleta a um conjunto viável de itens de diferentes categorias de consumo.
A arquitetura do sistema foi modular, inspirada em princípios de microsserviços, para favorecer manutenção, escalabilidade e evolução. A solução foi implementada com contêineres Docker, isolando cada módulo em seu ambiente de execução, e orquestrada com Docker Compose para comunicação integrada dos serviços. A estrutura da aplicação organizou-se em componentes de coleta automatizada de dados, processamento de informações, persistência em banco de dados relacional, disponibilização de resultados via API REST e camada de apresentação.
O fluxo de dados envolveu a obtenção de informações de APIs externas, agregação e cálculo de métricas, armazenamento histórico no PostgreSQL e acesso padronizado via API para o frontend. Para a implementação, utilizou-se Python no backend, PostgreSQL para persistência e FastAPI para a camada de exposição de dados, permitindo a criação eficiente de endpoints REST e documentação automática. O processamento das informações ocorreu no backend, gerando métricas comparativas sob demanda, o que reduziu a complexidade da persistência e garantiu análises baseadas nos registros mais recentes.
Na camada de apresentação, desenvolveu-se um frontend web com React, utilizando Vite para build e Tailwind CSS para estilização. Essa combinação visou construir uma aplicação leve, modular e adequada ao escopo do MVP, facilitando a exibição simplificada dos dados processados ao usuário final, consumindo os endpoints da API REST.
O levantamento de requisitos focou na definição das funcionalidades essenciais para a validação do sistema, priorizando a integração entre os componentes, a persistência histórica dos dados e a disponibilidade das informações processadas. Requisitos funcionais e não funcionais foram detalhados para guiar o desenvolvimento da solução.
O banco de dados foi modelado relacionalmente, contemplando tabelas de referência, dados históricos e estruturas auxiliares para coleta e processamento. Dados estáticos de configuração, como fontes externas e produtos, foram inseridos por scripts de carga inicial. Dados dinâmicos foram coletados semanalmente (preços) e mensalmente (indicadores salariais), permitindo a construção de séries temporais e análises comparativas baseadas nos registros mais recentes disponíveis.
Aspectos técnicos da implementação incluíram a conversão de tipos de dados, como estruturas NumPy e Pandas, para formatos compatíveis com a serialização JSON, assegurando a integridade das respostas da API. A utilização de contêineres Docker isolou os componentes, padronizou o ambiente de execução e facilitou a portabilidade e reprodutibilidade da arquitetura implementada.
A interface web, desenvolvida com React, Vite e Tailwind CSS, consumiu os endpoints da API REST para apresentar consultas por país e por produto. O frontend priorizou a simplicidade de navegação e a clareza na exibição das métricas, mantendo a lógica de negócio e processamento concentrada no backend, sem transferir regras de negócio para o cliente.
3. Resultados e Discussão
A implementação do sistema web para análise comparativa do poder de compra, no escopo de um produto mínimo viável (MVP), demonstrou a viabilidade técnica da solução proposta. Os resultados abrangeram a execução da coleta automatizada de dados, o armazenamento histórico das informações, o processamento sob demanda das métricas comparativas e a disponibilização dos achados por meio de uma API e interface web. A análise desses elementos permitiu verificar o funcionamento integrado da solução e discutir o desempenho da arquitetura adotada, confirmando sua aderência aos objetivos estabelecidos no trabalho.
Execução do sistema e coleta de dados
A pesquisa evidenciou a capacidade do sistema em realizar a coleta automatizada de dados econômicos a partir de APIs externas configuradas, como a Canopy API para preços e a ILOSTAT para indicadores salariais. Este processo ocorre de forma periódica e independente da interação do usuário, sendo fundamental para a obtenção de dados brutos. Observou-se que a comunicação com as fontes externas e a inserção dos dados no banco de dados foram realizadas com sucesso, conforme os registros de execução do coletor de dados.
Os logs de execução do coletor de dados registraram o início do microsserviço e a conexão bem-sucedida com o banco de dados. A coleta de indicadores salariais da ILOSTAT foi iniciada para diferentes indicadores, como “EAR_4MTH_SEX_CUR_NB_A”, com a migração de dados para a tabela final. Embora alguns indicadores, como “MWG_2MTH_SEX_CUR_NB_A” e “QLS_HW_AVE_NB_A”, não tenham retornado dados em determinadas execuções, o processo de coleta de preços via Canopy API foi consistentemente bem-sucedido.
Para os preços, o sistema registrou a coleta de itens como “COCA_ZERO_12P” em diferentes países, com valores de 46.68 em BR, 8.39 em US e 9.96 em ES. Similarmente, o produto “HAVAIANAS_TOP” foi coletado com preços de 34.50 em BR, 14.33 em US e 24.00 em ES. Esses registros confirmaram a capacidade do sistema de interagir com as APIs externas e de inserir os dados coletados na base de dados, validando a funcionalidade de coleta automatizada.
Persistência e organização dos dados
Os dados coletados pelo sistema são armazenados em um banco de dados PostgreSQL, que preserva o histórico das coletas e impede a sobrescrita de registros anteriores. Essa abordagem é crucial para manter a rastreabilidade das informações e construir uma base sólida para análises comparativas e temporais futuras. A persistência foi organizada para separar dados cadastrais, históricos e estruturas auxiliares de processamento, garantindo a consistência entre os dados das fontes externas e os valores armazenados.
A estrutura relacional do banco de dados incluiu tabelas como `countries` para o cadastro de países, `country_translations` para traduções, `products` e `categories` para organização de produtos, e `product_asins` para mapeamento de códigos de busca por país. Os preços coletados são armazenados na tabela `price_history`, com coletas semanais para capturar variações. Os indicadores salariais são registrados na tabela `labor_indicators_history` com coletas mensais, refletindo a menor frequência de atualização desses dados.
A tabela `salary_history` armazena registros detalhados, incluindo `id_salary`, `id_country`, `id_indicator`, `id_source`, `salary_value`, `currency`, `reference_year` e `collection_date`. Por exemplo, foram registrados valores como 5985.29 LCU para um indicador em 2024 e 525.09 LCU para outro em 2024, com datas de coleta em 2026. A tabela `price_history` contém `sku`, `id_country`, `price`, `currency` e `collection_timestamp`, mostrando registros como “HAVAIANAS_TOP” com preço de 24.00 EUR em um país e “COCA_ZERO_12P” com preço de 46.68 BRL em outro, ambos com timestamps de coleta em 2026.
Essa organização permite a preservação dos dados brutos e oferece suporte ao processamento sob demanda realizado pela API. A manutenção do histórico é um ativo significativo da solução, pois viabiliza não apenas a consulta dos dados atuais, mas também futuras análises sobre a evolução conjunta entre preços, salários e métricas de acessibilidade, conforme a necessidade de estudos mais aprofundados sobre o poder de compra (Ashenfelter, 2001).
Exposição e consumo dos dados via API
A API desenvolvida demonstrou sua capacidade de expor os dados persistidos no banco de dados de forma padronizada, utilizando endpoints REST para consultas por país e por produto. As respostas são retornadas em formato JSON, contendo dados já processados e organizados de acordo com as regras definidas na camada de backend. Este comportamento confirmou a adequação da API como um intermediário eficiente entre a persistência relacional e a camada de apresentação do sistema.
Durante os testes, a API recuperou dados históricos, aplicou as regras de transformação necessárias e disponibilizou respostas estruturadas para o frontend. Isso permitiu que a camada de apresentação operasse sem a necessidade de processamento adicional, concentrando a responsabilidade pelas regras de negócio e cálculos das métricas comparativas no backend. Essa abordagem reforçou a decisão arquitetural de centralizar a lógica de processamento na API, utilizando o frontend apenas para visualização e interação.
Os logs de execução da API e processamento de consultas sob demanda ilustraram o fluxo de trabalho. O sistema registrou a inicialização do “EconomicProcessor” e a conexão com o banco de dados. Requisições como “Análise global para o país ID 1” e “Ranking global para o SKU HAVAIANAS_TOP” foram processadas, com a busca de preços e salários e a finalização da análise com múltiplos registros processados. Isso demonstra a capacidade do sistema de responder a diferentes tipos de consultas de forma eficiente.
As respostas da API para consultas por país, como para o país de ID 1, incluíram dados para “COCA_ZERO_12P” com preço de 46.68 e “HAVAIANAS_TOP” com preço de 34.50, ambos indicando 4.15 e 3.07 horas necessárias em média, respectivamente. Para análises comparativas por produto, como “HAVAIANAS_TOP”, a API retornou dados para diferentes países, mostrando preços locais (34.50 no país 1, 14.33 no país 2, 24.00 no país 3) e as horas médias necessárias para aquisição (3.07, 0.33, 0.31, respectivamente). Esses resultados confirmam a padronização e a eficácia da API na entrega de informações processadas.
Implementação e validação do frontend
A camada de apresentação do sistema foi implementada como uma interface web simples, focada em disponibilizar ao usuário a consulta dos dados processados pelo backend. O frontend foi desenvolvido para consumir a API e apresentar análises por país e por produto, sem transferir regras de negócio ou processamento pesado para o cliente. A interface permitiu a navegação entre a página inicial, as telas de análise e as páginas textuais de contextualização do sistema, confirmando a viabilidade da camada de apresentação como componente final da solução.
A interface inicial do sistema ofereceu opções para “Explorar por país” e “Explorar por produto”, exibindo países como Estados Unidos, Brasil, Espanha, Japão e Índia, e produtos como Coca-Cola, Havaianas Top, LEGO Classic 10698 e AirPods Pro 3. Essa organização visual facilitou a interação do usuário e a seleção dos parâmetros de consulta. A leitura principal do sistema, conforme indicado na interface, não se baseia na conversão cambial nominal, mas no esforço de compra em relação à renda local, alinhando-se à premissa do estudo.
Na análise comparativa por produto, como para “AirPods Pro 3”, a interface exibiu informações detalhadas para os países disponíveis. Para os Estados Unidos, o preço local era de US$ 209,99, com salário médio de US$ 6.272,93 e salário mínimo de US$ 1.257,00, resultando em 3,35% do salário médio e 16,71% do salário mínimo comprometidos, e 4 horas e 51 minutos de trabalho médio necessários. No Japão, o preço local era de JP¥ 251, com um salário médio de JP¥ 0 (indicando dado ausente ou não aplicável para o indicador específico) e salário mínimo de JP¥ 182.726, resultando em 0,14% do salário mínimo comprometido e 10 minutos de trabalho médio necessários.
Esses exemplos demonstram que o frontend foi capaz de consumir corretamente as respostas da API e exibir os dados em um formato adequado para consulta, evidenciando a organização visual das informações e a integração efetiva entre a camada de apresentação e os serviços disponibilizados pela API. A simplicidade de navegação e a clareza na exibição das métricas comparativas foram priorizadas, atendendo ao escopo do MVP.
Integração entre os componentes do sistema
A integração entre os componentes do sistema constituiu um dos principais resultados observados no desenvolvimento. A solução foi estruturada de modo que cada módulo executasse uma responsabilidade específica dentro do fluxo geral da aplicação, permitindo a separação entre coleta de dados, persistência, processamento, disponibilização das informações e apresentação ao usuário final. Essa organização evidenciou a separação de responsabilidades entre os componentes, reduzindo o acoplamento entre persistência, processamento e apresentação, o que é fundamental para a manutenção e evolução de sistemas complexos (Pressman e Maxim, 2016; Sommerville, 2016).
No fluxo implementado, o módulo de coleta realizou a comunicação com as APIs externas para obter dados brutos de preços e indicadores econômicos. Essas informações foram persistidas no banco de dados relacional, preservando o histórico das coletas e assegurando a rastreabilidade dos registros. A API atuou como camada intermediária, recuperando os dados armazenados, aplicando as regras de transformação e cálculo das métricas comparativas, e disponibilizando os resultados em formato estruturado para consumo pela interface web. A camada de frontend, por sua vez, consumiu os endpoints da API e apresentou os resultados ao usuário em páginas de consulta por país e por produto.
A arquitetura implementada, que combinou coleta automatizada, armazenamento histórico, processamento sob demanda e visualização web, demonstrou a viabilidade da proposta do trabalho. A utilização de contêineres Docker e orquestração via Docker Compose favoreceu o isolamento dos componentes, a padronização do ambiente de execução e a reprodutibilidade da arquitetura. Essa abordagem integrada confirmou a capacidade de aplicar diferentes tecnologias em uma aplicação única, mantendo clareza arquitetural e possibilidade de evolução futura.
Análise crítica da solução implementada
A arquitetura modular adotada mostrou-se adequada ao problema proposto, pois permitiu distribuir responsabilidades entre componentes especializados, reduzindo o acoplamento entre coleta, persistência, processamento e apresentação. Essa separação favoreceu a organização do sistema e tornou mais clara a delimitação das responsabilidades técnicas de cada módulo, o que é uma vantagem importante em soluções que dependem da integração contínua com fontes externas de dados. No contexto da Engenharia de Software, esse resultado é relevante por demonstrar que a adoção de uma estrutura modular contribui para a clareza arquitetural, manutenção e evolução incremental da aplicação.
O processamento sob demanda também se mostrou uma decisão adequada para o escopo do MVP. Em vez de armazenar previamente todas as combinações possíveis de resultados processados, a solução concentrou a persistência nos dados brutos e transferiu para a API a responsabilidade de calcular as métricas no momento da consulta. Essa estratégia reduziu a redundância de armazenamento, preservou a integridade dos dados originais e simplificou a atualização das análises com base na coleta mais recente disponível. Consequentemente, a solução conseguiu equilibrar simplicidade estrutural e flexibilidade analítica, o que se mostrou compatível com o objetivo de construir um sistema funcional e evolutivo.
A separação entre backend e frontend também produziu resultados positivos no desenvolvimento da solução. Ao concentrar no backend a lógica de negócio, o processamento dos indicadores e a integração com o banco de dados, o frontend pôde ser mantido como camada de apresentação e interação, com menor complexidade técnica. Essa decisão favoreceu a clareza da arquitetura, reduziu a sobrecarga da interface web e facilitou a validação do fluxo de dados entre os componentes. Em conjunto, os resultados indicam que os principais ganhos da solução estiveram na integração consistente entre os módulos, na preservação histórica dos dados coletados e na capacidade de disponibilizar métricas comparativas por meio de uma interface acessível ao usuário.
Limitações do MVP e possibilidades de evolução
Embora o sistema desenvolvido tenha demonstrado viabilidade técnica para o escopo proposto, algumas limitações devem ser consideradas. A primeira delas está relacionada ao caráter reduzido do produto mínimo viável, que contemplou um número restrito de países, produtos e indicadores, definido de forma intencional para tornar a implementação compatível com os recursos disponíveis durante o desenvolvimento do trabalho. Essa restrição foi imposta, em parte, pelas limitações operacionais e de custo da Canopy API para a obtenção de preços, o que influenciou diretamente a dimensão do conjunto de produtos e países incluídos no MVP.
Outra limitação relevante refere-se à dependência de fontes externas de dados. A disponibilidade dos itens pode variar entre os mercados analisados, o que implica ausência legítima de determinados produtos em algumas consultas, sem que isso represente erro de funcionamento do sistema. Além disso, no estágio atual, a comparação foi baseada prioritariamente em indicadores salariais, como salário médio, salário mínimo e métricas derivadas de horas de trabalho necessárias para aquisição dos produtos. Embora essa escolha seja adequada ao objetivo do MVP, ela não esgota as possibilidades analíticas do sistema.
A principal contribuição do trabalho não reside na criação de um novo índice econômico, mas na construção de uma solução de software capaz de integrar fontes heterogêneas e produzir métricas aplicadas de acessibilidade de compra. A camada de apresentação foi desenvolvida com foco em simplicidade e clareza, priorizando a validação do fluxo de consulta e a integração com a API. Dessa forma, ainda permanecem possibilidades de evolução relacionadas à ampliação da responsividade da interface, inclusão de visualizações gráficas, filtros mais detalhados, ordenações adicionais e mecanismos de comparação histórica.
A preservação dos dados em base histórica constitui, por sua vez, uma das principais oportunidades de evolução da solução. A manutenção contínua dos registros coletados permite que o sistema seja futuramente expandido para análises temporais mais robustas, possibilitando investigar, por exemplo, a evolução conjunta entre preços, salários e esforço de compra ao longo do tempo. Em conjunto, essas limitações não comprometem a validação da proposta do trabalho, mas delimitam o escopo do MVP e indicam caminhos concretos para evolução da solução em versões futuras, como a incorporação de outros indicadores econômicos complementares, como renda disponível, inflação e PIB per capita.
Em síntese, os resultados obtidos demonstram a viabilidade técnica do sistema web desenvolvido, que integra coleta automatizada de dados, persistência histórica e processamento sob demanda para fornecer métricas comparativas de poder de compra. A arquitetura modular e a separação de responsabilidades entre os componentes foram cruciais para o sucesso da implementação, permitindo que a solução atendesse ao objetivo de oferecer uma ferramenta funcional e escalável para análises de acessibilidade de compra entre países, estabelecendo uma base sólida para futuras expansões e aprofundamento das análises.
4. Conclusão
O presente estudo teve como objetivo desenvolver um sistema web para análise comparativa do poder de compra entre países, utilizando preços locais de produtos e indicadores salariais como base para o cálculo de métricas de acessibilidade. Verificou-se a viabilidade técnica da solução proposta, que integrou a coleta automatizada de dados de preços e salários de fontes externas, a persistência histórica dessas informações em um banco de dados relacional e o processamento sob demanda das métricas comparativas. Observou-se que a arquitetura modular adotada, com a separação de responsabilidades entre os componentes de coleta, persistência, processamento e apresentação, favoreceu a organização do sistema e a redução do acoplamento. A exposição padronizada dos dados por meio de uma API REST e a interface web simplificada permitiram a consulta eficaz dos resultados, demonstrando a capacidade da solução em fornecer métricas aplicadas de acessibilidade de compra.
A principal contribuição do trabalho reside na construção de uma ferramenta de software funcional que integra fontes de dados heterogêneas para gerar métricas de acessibilidade de compra, oferecendo uma base robusta para análises do poder de compra em diferentes contextos. Contudo, o escopo do produto mínimo viável foi intencionalmente reduzido, abrangendo um número limitado de países, produtos e indicadores, e a solução demonstrou dependência de fontes externas, cujas limitações operacionais e de custo influenciaram a dimensão dos dados coletados. Para estudos futuros, sugere-se a ampliação do conjunto de indicadores econômicos, a incorporação de análises temporais mais robustas a partir da base histórica de dados preservada, e a evolução da camada de apresentação com visualizações gráficas e filtros detalhados, consolidando o sistema como uma ferramenta analítica mais abrangente.
Referências Bibliográficas
Ashenfelter, O. 2001. Cross-country Comparisons of Wage Rates: The Big Mac Index. Princeton University, Princeton, NJ, USA.
International Labour Organization [ILO]. 2026. Wages and Working Time Statistics (COND database): concepts and definitions. Documentação oficial. Acesso em: 10 fev. 2026.
Pressman, R.S.; Maxim, B.R. 2016. Engenharia de Software: Uma Abordagem Profissional. 8ed. McGraw-Hill Education, Porto Alegre, RS, Brasil.
Sommerville, I. 2016. Engenharia de Software. 10ed. Pearson Education do Brasil, São Paulo, SP, Brasil.
World Bank. 2026. International Comparison Program (ICP) – Methodology. Documentação oficial. Acesso em: 10 fev. 2026.
Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq
Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy

