2ac2bdcf72fa4c6c81de73d8e46fa808

Prévia do material em texto

Alex Fabiano Garcia 
 
 
 
 
 
 
 
 
Precificação para aplicação hospedada em nuvem: uma abordagem 
ajustada ao consumo do usuário 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
São José do Rio Preto 
2018 
 
 
 
 
 
Alex Fabiano Garcia 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Precificação para aplicação hospedada em nuvem: uma abordagem 
ajustada ao consumo do usuário 
 
 
 
 
Trabalho de Conclusão de Curso (TCC) 
apresentado como parte dos requisitos para 
obtenção do título de Bacharel em Ciências de 
Computação, junto ao Departamento de Ciências 
de Computação e Estatística, do Instituto de 
Biociências, Letras e Ciências Exatas da 
Universidade Estadual Paulista “Júlio de 
Mesquita Filho”, Câmpus de São José do Rio 
Preto. 
 
Orientador: Prof.ª Dr.ª Adriana Barbosa Santos 
 
 
 
 
 
 
 
 
 
 
 
São José do Rio Preto 
2018 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Alex Fabiano Garcia 
 
 
 
 
 
 
 
 
 
 
Precificação para aplicação hospedada em nuvem: uma abordagem 
ajustada ao consumo do usuário 
 
 
Trabalho de Conclusão de Curso (TCC) 
apresentado como parte dos requisitos para 
obtenção do título de Bacharel em Ciências de 
Computação, junto ao Departamento de Ciências 
de Computação e Estatística, do Instituto de 
Biociências, Letras e Ciências Exatas da 
Universidade Estadual Paulista “Júlio de 
Mesquita Filho”, Câmpus de São José do Rio 
Preto. 
 
 
 
 
 
 
 
Comissão Examinadora 
 
Prof.ª Dr.ª Adriana Barbosa Santos 
Unesp - São José do Rio Preto 
Orientador 
 
Prof. Dr. Adriano Mauro Cansian 
Unesp - São José do Rio Preto 
 
Prof. Dr. Carlos Roberto Valêncio 
Unesp - São José do Rio Preto 
 
 
 
São José do Rio Preto 
30 de novembro de 2018 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Àqueles que apesar de todas as adversidades sempre 
acreditaram que eu seria capaz de atingir meus objetivos. 
 
 
 
 
 
 
AGRADECIMENTOS 
 
Agradeço primeiramente aos meus pais, Célio e Dirce, pelo amor incondicional, 
pela educação e por serem exemplos de caráter e conduta, sob qualquer 
circunstância. Por terem criado meus irmãos e a mim com muita simplicidade, mas 
nunca com a falta, além do maior luxo que nos foi oferecido: aprender o lado bom da 
palavra “não”. 
Agradeço à Amanda, minha companheira, pelo apoio, amor e carinho 
proporcionados durante toda a nossa jornada, principalmente nos vários momentos 
adversos que superamos juntos. Ela, mais do que ninguém, compreende as 
dificuldades que superamos para atingir nossos objetivos. 
Aos meus irmãos, Marcelo e Gustavo, por proverem uma amizade que supera 
os nossos laços de sangue. A alegria que partilhamos sempre que nos reunimos é um 
dos combustíveis que me fazem seguir em frente e nunca desistir. 
Gostaria, é claro, de agradecer a todos os excelentes professores da Unesp 
pelo incomensurável conhecimento obtido, especialmente à minha orientadora Prof.ª 
Dr.ª Adriana Barbosa Santos pelo apoio, críticas e orientação sempre que foi 
necessário, mesmo com meus horários conturbados devido ao trabalho. Novamente, 
muito obrigado. 
Por fim, não posso deixar de agradecer aos meus amigos de trabalho, local que 
frequentei desde o início da vida acadêmica e obtive, além do suporte financeiro, 
experiências e conhecimento complementares à faculdade durante este sinuoso 
caminho que trilhei. Cheyla e Adriano, obrigado por acreditarem e confiarem no meu 
trabalho logo no início da minha carreira. Fred, agradeço por todo o suporte, 
orientação e compreensão oferecidos nos últimos anos. Oriol, aprendi contigo que a 
liderança e amizade podem ser muito bem conciliadas. Flávio, obrigado pela 
constante doação de parceria e confiança. Nícolas, obrigado pelos ótimos momentos 
na moradia e trabalho que compartilhamos por muitos anos. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
“Você, eu, ninguém vai bater tão duro quanto a vida. Mas não se 
trata de bater duro, se trata de quanto você aguenta apanhar e 
seguir em frente. O quanto você é capaz de aguentar e continuar 
tentando. É assim que se consegue vencer!” 
(Rocky Balboa, 2006) 
 
 
 
 
 
 
RESUMO 
 
A popularização das aplicações SaaS (Software as a Service) possibilitou às 
empresas desenvolvedoras de software atrair novos clientes e oportunidades de 
negócio, contudo, acentuou as complexidades de controle de faturamento e de 
cobrança pelo serviço disponibilizado. Neste cenário desafiador, a definição de um 
modelo de precificação torna-se ponto chave para o sucesso da solução, sendo o 
consumo realizado pelo usuário um dos fatores determinantes para o cálculo dos 
custos envolvidos. Este trabalho aborda a precificação do software hospedado em 
provedores cloud, descreve ferramentas correlatas, como Stripe e Zuora, softwares 
de gerenciamento de assinatura que oferecem a estas aplicações diversos serviços, 
dentre os quais destaca-se a contabilização de gastos do usuário de forma mais 
customizada. Com base em um levantamento de requisitos, foi desenvolvida a 
Price4SaaS, uma ferramenta alternativa que obtém informações de consumo do 
usuário dinamicamente por meio do consumo das APIs (Application Programing 
Interface) de faturamento das plataformas de nuvem. O código-fonte do artefato 
construído está disponível no repositório do GitHub: 
https://github.com/alexfabgarcia/price4saas. 
 
Palavras-chave: Precificação, Cloud Computing, SaaS, Consumo do Usuário. 
 
 
 
 
 
 
ABSTRACT 
 
The popularization of SaaS (Software as a Service) applications has allowed software 
developer companies to attract new clients and business opportunities, however, it has 
increased the complexities of billing control and charging for provided services. In this 
challenge context, the pricing model definition became a key point for solution success, 
being the user consumption one of the crucial factors for accounting the involved costs. 
This work addresses the pricing of software hosted in cloud providers, it describes 
related tools such as Stripe and Zuora, which are subscription management software 
that offers several services for these cloud-hosted applications, like charging and 
accounting of user expenses. Based on identified requirements, Price4SaaS has been 
developed in order to be an alternative tool that dynamically obtains usage data 
through cloud providers billing APIs (Application Programing Interface). The source 
code for the built-in artifact is available in the following GitHub repository: 
https://github.com/alexfabgarcia/price4saas. 
 
Keywords: pricing, Cloud Computing, SaaS, client usage. 
 
 
 
 
 
 
LISTA DE ILUSTRAÇÕES 
 
Figura 1 - Sequência metodológica do trabalho. ....................................................... 24 
Figura 2 - Itens gerenciados pelo cliente (azul) e pelo provedor de serviços em nuvem 
(cinza). .................................................................................................................... 26 
Figura 3 - Grid® Scoring para softwares de gerenciamento de pagamentos, cobrança 
e faturamento.......................................................................................................... 32 
Figura 4 - Diagrama Entidade-Relacionamento que representa a assinatura de um 
plano de preço de um produto. ............................................................................... 33 
Figura 5 - Comunicação via HTTPS com a aplicação Stripe para reportar consumo 
realizado referente a determinada assinatura. ....................................................... 33 
Figura 6 – Configuração de plano de assinatura baseado em consumo do usuário na 
ferramenta Stripe. ................................................................................................... 34 
Figura 7 - Funcionamento do Rent XP, hospedado na GCP. ....................................36 
Figura 8 – Contexto de funcionamento da Price4SaaS. (1) Contabilização de gastos 
da aplicação SaaS pela plataforma cloud; (2) A ferramenta integra-se com o 
provedor para consumo dos dados. ....................................................................... 38 
Figura 9 - Diagrama contextual de arquitetura da ferramenta Price4SaaS. .............. 42 
Figura 10 - Representação da arquitetura de três camadas. .................................... 43 
Figura 11 - Arquitetura de camadas da ferramenta Price4SaaS. .............................. 45 
Figura 12 - Diagrama de controle de acesso do usuário na Price4Saas. .................. 47 
Figura 13 - Página de autenticação da ferramenta Price4SaaS. ............................... 48 
Figura 14 - Página inicial da ferramenta Price4SaaS. ............................................... 49 
Figura 15 - Página de cadastro de um projeto SaaS na plataforma Price4SaaS. ..... 50 
Figura 16 - Listagem de projetos e ações disponíveis sobre ele na Price4SaaS. ..... 50 
Figura 17 - Configuração da GCP para um projeto na Price4SaaS. ......................... 51 
Figura 18 - Diagrama de sequência da geração de token de acesso à GCP. ........... 52 
Figura 19 - Configuração de estratégias de cobrança dos serviços de nuvem. ........ 54 
Figura 20 - Página de consulta de gastos do projeto em um intervalo de datas. ...... 55 
Figura 21 - Tela de gastos por usuário referentes ao serviço Storage da GCP. ....... 56 
Figura 22 – Gráfico que apresenta os gastos por usuário referentes ao serviço Storage 
da GCP. .................................................................................................................. 56 
Figura 23 - Extratos de gastos consolidados por usuários no período selecionado. . 57 
 
 
Figura 24 - Buckets que contêm as imagens dos imóveis dos usuários da Rent XP. 
Em vermelho são destacados os marcadores com o identificador de cada usuário.
 ............................................................................................................................... 59 
Figura 25 - Gastos da Rent XP sobre serviços da GCP. .......................................... 61 
Figura 26 - Gastos da Rent XP sobre serviços da AWS. .......................................... 61 
Figura 27 - Painel da AWS com fatura da Rent XP no mês de outubro de 2018. .... 62 
Figura 28 - Criação de projeto na GCP. ................................................................... 70 
Figura 29 - Identificador da conta de faturamneto da GCP. ..................................... 71 
Figura 30 - Consulta de Biblioteca de APIs da GCP. ............................................... 72 
Figura 31 - Ativação da API Cloud Billing da GCP. .................................................. 72 
Figura 32 - Criação de conjunto de dados no serviço BigQuery da GCP. ................ 73 
Figura 33 - Informações do conjunto de dados da GCP. .......................................... 74 
Figura 34 - Acesso ao serviço Amazon S3 da AWS. ................................................ 76 
Figura 35 - Criação de bucket no serviço S3 da AWS. ............................................. 77 
Figura 36 - Acesso ao painel de faturamento da AWS. ............................................ 78 
Figura 37 - Exportação de informações de faturamento para o S3. ......................... 78 
Figura 38 - Acesso às credenciais de segurança da AWS. ...................................... 79 
Figura 39 – Listagem de chaves de acesso na AWS. .............................................. 80 
Figura 40 - Chave de acesso criada na AWS. .......................................................... 80 
 
Gráfico 1 - Predominância de provedores de infraestrutura no mercado SaaS em 2017 
(esquerda) e previsão até 2020 (direita). ............................................................... 27 
 
 
 
 
LISTA DE TABELAS 
 
Tabela 1 - Preços de instâncias T2 executando Linux/Unix mostrados para a região 
US East (N. Virginia) AWS. .................................................................................... 28 
Tabela 2 - Máquinas virtuais "standard" na região US East (N. Virginia) GCP. ........ 28 
Tabela 3 - Três camadas principais de um software. ................................................ 43 
Tabela 4 - Tipos de instâncias utilizadas pela Rent XP na GCP e AWS. .................. 59 
Tabela 5 - Tamanho do armazenamento utilizado por cada usuário. ........................ 60 
Tabela 6 - Gastos por usuário da Rent XP para as GCP e AWS no mês de outubro de 
2018 a partir de dados extraídos da Price4SaaS. .................................................. 63 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
CAPÍTULO 1 – INTRODUÇÃO ................................................................................. 22 
1.1 Objetivo Geral ............................................................................................... 23 
1.2 Metodologia ................................................................................................... 23 
CAPÍTULO 2 – FUNDAMENTAÇÃO TEÓRICA ....................................................... 25 
2.1 Modelos de Serviço e provedores em Cloud Computing .......................... 25 
2.2 Custos da Computação em Nuvem ............................................................. 27 
2.3 Modelos de Precificação em SaaS .............................................................. 28 
2.3.1 Precificação SaaS baseada em custos ........................................................... 28 
2.3.2 Precificação SaaS baseado em valor ............................................................. 29 
2.4 Ferramentas de Precificação SaaS por consumo ...................................... 30 
2.4.1 Análise do mercado: Grid® Scoring ................................................................ 31 
2.4.2 Avaliação de ferramentas disponíveis no mercado ........................................ 32 
2.5 Considerações finais .................................................................................... 34 
CAPÍTULO 3 – A FERRAMENTA PRICE4SAAS .................................................... 35 
3.1 Considerações iniciais sobre a ferramenta Price4SaaS ........................... 35 
3.2 Requisitos de sistema .................................................................................. 36 
3.2.1 Pré-requisitos para suporte à plataforma cloud .............................................. 37 
3.2.2 Requisitos funcionais identificados ................................................................. 39 
3.2.3 Requisitos não funcionais desejados .............................................................. 40 
3.3 Desenho de arquitetura de software ........................................................... 41 
3.3.1 Desenho técnico de arquitetura de software ................................................... 44 
3.4 Implementação da ferramenta Price4SaaS ................................................. 46 
3.4.1 Controle de acesso ......................................................................................... 46 
3.4.2 Página inicial ................................................................................................... 48 
3.4.3 Gerenciamento de projetos ............................................................................. 49 
3.4.4 Configuração do provedor de nuvem do projeto ............................................. 50 
3.4.5 Configuração de serviços do projeto............................................................... 53 
3.4.6 Extratos de gastos por período ....................................................................... 54 
3.4.7 Considerações finais ....................................................................................... 57 
CAPÍTULO 4 – TESTES E VALIDAÇÃO DA FERRAMENTA ................................. 58 
4.1 Serviços utilizados pelo Rent XP ................................................................58 
4.2 Informações armazenadas e tráfego de arquivos ...................................... 59 
 
 
4.3 Resultados obtidos ...................................................................................... 60 
4.4 Considerações finais ................................................................................... 63 
CAPÍTULO 5 – CONCLUSÃO ................................................................................. 64 
5.1 Problemas encontrados .............................................................................. 65 
5.2 Trabalhos futuros ......................................................................................... 65 
REFERÊNCIAS ........................................................................................................ 66 
APÊNDICE A – CONFIGURAÇÃO DE PROJETO NA GCP ................................... 70 
APÊNDICE B – CONFIGURAÇÃO DO PROJETO NA AWS .................................. 76 
22 
 
CAPÍTULO 1 – INTRODUÇÃO 
 
Segundo Sommerville (SOMMERVILLE, 2016), o estabelecimento do preço de 
um software se daria, inicialmente, a partir do custo de desenvolvimento somado com 
o lucro desejado. Entretanto, fatores organizacionais, políticos e econômicos, riscos 
associados ao projeto, expectativas do cliente, são fatores comumente considerados 
na elaboração desta tarefa nada trivial. No contexto de aplicações hospedadas em 
plataformas cloud computing1, onde a abrangência do negócio torna-se ainda maior 
(HUANG, et al., 2015), esta missão torna-se ainda mais complicada. 
A crescente adoção da computação em nuvem (GUPTA, et al., 2013; HSU, et 
al., 2014) tornou propícia a disponibilização de aplicações por meio de contratos de 
serviço, popularizando a terminologia Software as a Service (SaaS). De acordo com 
Ojala (2016), este modelo de entrega de software proporciona diversas possibilidades 
de receita, contudo, envolve desafios que dificultam o seu controle e a 
sustentabilidade do negócio, sendo a implantação da precificação um dos principais. 
Com o intuito de suprir essa necessidade de mercado, surgem diversas 
ferramentas especializadas que se integram com as aplicações SaaS para oferecer, 
dentre outras funcionalidades, a criação de planos e cobrança de seus usuários 
baseada em assinatura de serviço, como proposto por Stripe (2018) e Zuora (2018). 
Todavia, no caso de um modelo de precificação baseado no consumo do usuário, há 
necessidade que o software hospedado na nuvem, que se comunica com essas 
ferramentas, tenha implementada toda a lógica de obtenção das métricas de uso. 
Wu, Zhang e Wanchun (2012), baseando-se no modelo de custos adotado 
pelos provedores de computação em nuvem, propuseram uma interessante estratégia 
de precificação personalizada chamada Pricing as a Service (PraaS), fundamentada 
em recursos consumidos pela aplicação, como armazenamento e máquinas virtuais 
em execução. Porém, o estudo pode estar incompleto no que tange a dificuldade de 
obtenção e atualização destes custos. 
 
1 Cloud Computing ou Computação em Nuvem é, de acordo com relatório emitido pelo Instituto Nacional 
de Padrões e Tecnologia (NIST) do Departamento de Comércio dos Estados Unidos (MELL e 
GRANCE, 2011), um modelo que habilita o acesso sob demanda a recursos computacionais (e.g. 
servidores, armazenamento, aplicações e serviços) que podem ser provisionais com baixíssima 
interação do provedor de serviços. 
23 
 
Atualmente, provedores de serviços líderes como Amazon (2018) e Google 
(2018), por exemplo, provêm APIs (Application Programing Interface) que possibilitam 
a consulta de informações sobre os gastos provenientes de um projeto. 
No conjunto de respostas à pergunta “Qual é a sua principal métrica para 
precificação?” da pesquisa realizada pela KBCM (2017), o critério “consumo” 
corresponde a 29%, perdendo apenas para a quantidade de usuários do sistema, com 
36%. Nesta conjuntura, há demanda por ferramentas que auxiliem a precificação de 
aplicações SaaS baseando-se nos gastos dos seus usuários. 
Neste cenário, torna-se oportuno examinar a lacuna existente em relação à 
proposta de uma maneira automatizada de precificação ao usuário final dos SaaS, 
que seja baseada num modelo de cobrança análogo ao que as plataformas de cloud 
computing, de modo que utilize o consumo em sua base de cálculo. 
 
1.1 Objetivo Geral 
 
O objetivo geral deste trabalho é desenvolver uma ferramenta que auxilie a 
formulação da precificação de uma aplicação SaaS, ajustada ao consumo do usuário. 
Mais especificamente, pretende-se: 
• Utilizar métricas fornecidas pela API de cobrança da plataforma em nuvem na 
qual a mesma está hospedada para direcionar a formulação do modelo de 
precificação; 
• Garantir o funcionamento da ferramenta em diferentes plataformas, sendo as 
escolhidas Google Cloud Platform (GCP) e Amazon Web Services (AWS). 
 
1.2 Metodologia 
 
Para detalhar os aspectos metodológicos do trabalho foram definidas as 
seguintes atividades, conforme ilustrado na Figura 1: 
1. Estudo e descrição do estado da arte – destinada a dar mais familiarização 
com o tema, com base em textos clássicos sobre Engenharia de Software, artigos 
contemporâneos e correlatos com Cloud Computing e precificação de SaaS, além da 
identificação e caracterização de ferramentas correlatas disponíveis no mercado. 
2. Estudo de trabalhos relacionados – ferramentas alternativas disponíveis no 
mercado que realizam tarefa similar. 
24 
 
3. Elicitação de requisitos para desenvolvimento da prova de conceito da 
objetivada ferramenta de precificação – são levantados os requisitos necessários para 
o desenvolvimento e teste da ferramenta proposta, incluindo a análise das APIs de 
cobrança disponibilizadas pelas plataformas de nuvem cogitadas. 
4. Implementação da ferramenta – baseia-se nos requisitos previamente 
definidos e de melhorias e correções fomentadas pelos testes realizados, de modo a 
garantir o funcionamento em diferentes plataformas cloud. 
5. Testes e revisões – Com o artefato produzido, um case que se beneficiaria 
da solução proposta foi elaborado para a execução de testes, validação de requisitos 
funcionais identificados e revisões da ferramenta. 
6. Descrição dos resultados – São apresentados os resultados relativos à 
viabilidade da utilização da ferramenta desenvolvida como uma alternativa à 
precificação baseada em consumo do usuário no modelo de serviço SaaS. 
 
Figura 1 - Sequência metodológica do trabalho. 
 
1. Estudo e 
descrição do
Estado da Arte
3. Elicitação de 
Requisitos para o 
desenvolvimento
da Ferramenta
2. Estudo de
Trabalhos 
Relacionados
4. Implementação 
da Ferramenta
5. Testes e
Revisões
6. Descrição dos 
Resultados
 
Fonte: Elaborado pelo autor. 
 
25 
 
CAPÍTULO 2 – FUNDAMENTAÇÃO TEÓRICA 
 
A crescente adoção da computação em nuvem revolucionou a maneira como 
infraestrutura e software são oferecidos na área de tecnologia da informação (GUPTA, 
et al., 2013; HSU, et al., 2014). O que antes era adquirido fisicamente, no caso de 
hardware, ou licenciado, quando se trata de programas de computador, agora é 
disponibilizado mediante contratos de serviço por meio da Internet. Especificamente 
no contexto das empresas desenvolvedoras de software, a computação em nuvem 
propicia o surgimento de oportunidades de negócios, uma vez que novos clientes, 
outrora intangíveis, podem ser alcançados (OJALA, 2016). Entretanto, além de 
aumentar a força competitiva do mercado, estas precisam se preocupar com os seus 
modelos de receita e de cobrança para a disponibilização adequada de seus sistemas. 
Por conseguinte, o correto entendimento e implantação dos modelos de precificação 
de aplicações no âmbito de SaaS torna-se um dos pontos mais críticos para o sucesso 
do negócio. 
Para embasar a discussão do tema, neste capítulo são apresentados os 
modelos de serviço e provedoresde computação em nuvem, como as plataformas 
que implementam este paradigma realizam a cobrança pela infraestrutura 
provisionada, as estratégias de precificação adotadas por aplicações disponibilizadas 
nesses ambientes e, por fim, as ferramentas que auxiliam a precificação das 
aplicações SaaS baseada no consumo do usuário. 
 
2.1 Modelos de Serviço e provedores em Cloud Computing 
 
Segundo relatório do NIST (MELL e GRANCE, 2011), para um provedor de 
computação em nuvem ser caracterizado como tal, além de oferecer características 
essenciais como elasticidade, serviços sob demanda, capacidade de acesso em rede 
e de medição de recursos utilizados, deve ser composto de três modelos de serviço: 
• Infraestrutura as a Service (IaaS): modelo em que os provedores de nuvem 
provisionam hardware físico ou virtualizado a fim da realização de 
processamento, armazenagem, rede de computadores e demais recursos 
computacionais que possibilitem ao usuário a execução de sistemas – 
operacionais ou aplicações –sobre os mesmos; 
26 
 
• Platform as a Service (PaaS): neste modelo, o controle sobre a infraestrutura 
de nuvem não é delegado ao usuário, e sim a capacidade de configuração do 
ambiente de execução para implantação de aplicações ou bibliotecas 
desenvolvidas com linguagens de programação suportadas pelo provedor; 
• Software as a Service (SaaS): objeto deste estudo, este modelo possibilita ao 
usuário final o consumo de aplicações hospedadas em infraestrutura cloud via 
diversos tipos de dispositivos, por uso de aplicações clientes como 
navegadores web ou APIs (Application Programming Interface). 
Na Figura 2 são ilustrados itens cujo gerenciamento fica sob responsabilidade 
do provedor de serviços em nuvem e outros que são gerenciados pelo cliente, 
dependendo do modelo. A pilha apresentada à esquerda representa o conjunto de 
serviços que o usuário deve gerenciar quando possui toda a responsabilidade sobre 
sua infraestrutura, costumeiramente chamado de modelo legado ou On Premise. 
 
Figura 2 - Itens gerenciados pelo cliente (azul) e pelo provedor de serviços em nuvem (cinza). 
Aplicação
Segurança
Banco de Dados
Sistema Operacional
Virtualização
Servidores
Armazenamento
Rede
Data Center
G
e
re
n
c
ia
d
o
 p
e
lo
 C
li
e
n
te
Aplicação
Segurança
Banco de Dados
Sistema Operacional
Virtualização
Servidores
Armazenamento
Rede
Data Center
G
e
re
n
c
ia
d
o
 p
e
lo
 C
li
e
n
te
G
e
re
n
c
ia
d
o
 p
e
lo
 P
ro
v
e
d
o
r
Aplicação
Segurança
Banco de Dados
Sistema Operacional
Virtualização
Servidores
Armazenamento
Rede
Data Center
G
e
re
n
c
ia
d
o
 p
e
lo
 C
li
e
n
te
G
e
re
n
c
ia
d
o
 p
e
lo
 P
ro
v
e
d
o
r
Aplicação
Segurança
Banco de Dados
Sistema Operacional
Virtualização
Servidores
Armazenamento
Rede
Data Center
G
e
re
n
c
ia
d
o
 p
e
lo
 P
ro
v
e
d
o
r
On Premise IaaS PaaS SaaS
 
Fonte: Elaborado pelo autor. 
 
Segundo pesquisa realizada por KBCM Technology Group (2017), apenas 24% 
dos participantes ainda gerenciam sua própria infraestrutura para hospedagem de 
aplicações SaaS. No Gráfico 1, nota-se também a predominância da Amazon Web 
Services (AWS) perante os demais provedores de computação em nuvem para este 
mercado, além da previsão de expansão para os próximos anos. 
 
27 
 
Gráfico 1 - Predominância de provedores de infraestrutura no mercado SaaS em 2017 (esquerda) e 
previsão até 2020 (direita). 
 
Fonte: Adaptado de KBCM (2017). 
 
2.2 Custos da Computação em Nuvem 
 
Os recursos disponibilizados pelos provedores de computação em nuvem são 
cobrados sob demanda, ou seja, o usuário paga apenas pelo que utilizar. O leque de 
opções de produtos oferecidos atende todos os tipos de necessidades, como 
máquinas virtuais com perfil de processamento específico, armazenamento em disco, 
bancos de dados, ferramentas de análise, dentre muitos outros. No caso das 
máquinas virtuais, os preços cobrados variam de acordo com a configuração da 
mesma e sistema operacional escolhidos, além de ser diferenciado pela região onde 
estará hospedada (AMAZON, 2018; GOOGLE, 2018). 
Na Tabela 1 são apresentados os valores de instâncias de menor custo da 
plataforma AWS, chamadas T2, destinadas ao uso geral e que oferecem um nível 
básico de desempenho da CPU (Central Processing Unit) (AMAZON, 2018). Com 
preços de instâncias sob demanda a partir de 0,0058 USD por hora, as instâncias T2 
são ideais para uma variedade de aplicativos de uso geral, como serviços micro, 
aplicações interativas de baixa latência, banco de dados de pequeno e médio porte, 
desktops virtuais, ambientes de desenvolvimento, repositórios de código e protótipos 
de produtos. Na Tabela 2 são mostrados os valores de máquinas virtuais 
padronizadas do provedor Google Cloud Platform (GCP) em uma região similar. 
 
28 
 
Tabela 1 - Preços de instâncias T2 executando Linux/Unix mostrados para a região US East (N. 
Virginia) AWS. 
Nome Virtual CPUs RAM (GB) Preço/hora Preço/mês 
t2.nano 1 0,5 0,0058 USD 4,23 USD 
t2.micro 1 1,0 0,0116 USD 8,47 USD 
t2.small 1 2,0 0,0232 USD 16,04 USD 
t2.medium 2 4,0 0,0464 USD 33,87 USD 
t2.large 2 8 0,0928 USD 67,74 USD 
t2.xlarge 4 16,0 0,1856 USD 135,49 USD 
t2.2xlarge 8 32,0 0,3712 USD 270,98 USD 
Fonte: Adaptado de Amazon Web Services (2018). 
 
Tabela 2 - Máquinas virtuais "standard" na região US East (N. Virginia) GCP. 
Nome Virtual CPUs RAM (GB) Preço/hora Preço/mês 
n1-standard-1 1 3,75 0,0535 USD 27,34 USD 
n1-standard-2 2 7,5 0,1070 USD 54,68 USD 
n1-standard-4 4 15 0,2140 USD 109,35 USD 
n1-standard-8 8 30 0,4280 USD 218,71 USD 
n1-standard-16 16 60 0,8560 USD 437,42 USD 
n1-standard-32 32 120 1,7120 USD 874,83 USD 
n1-standard-64 64 240 3,4240 USD 1749,66 USD 
Fonte: Adaptado de referência de preços Google Compute Engine (2018). 
 
2.3 Modelos de Precificação em SaaS 
 
Quando o software é disponibilizado por meio de SaaS, variados modelos e 
combinações de precificação podem ser adotados para a representação de seu valor 
para o usuário final. Estas estratégias podem focar na cobertura de custos envolvidos 
no desenvolvimento e manutenção da aplicação ou, de modo mais subjetivo, levar em 
consideração a percepção do usuário sobre o valor de negócio provido por ela 
(HARMON, et al., 2009). 
 
2.3.1 Precificação SaaS baseada em custos 
 
Tradicionalmente, o preço estabelecido para um software considera os custos 
associados à criação e manutenção do mesmo (HARMON, et al., 2009). No contexto 
da computação em nuvem, a precificação de aplicações SaaS segue abordagem 
similar ao se embasar na cobrança realizada pela plataforma cloud (KAUR, et al., 
29 
 
2014). As estratégias mais comuns para definição do preço baseado no custo da 
aplicação SaaS são: 
• Flat, na qual usuários pagam por uso ilimitado do serviço, mensalmente, sem 
taxas adicionais. Apresentadas estas características, nota-se que a 
precificação flat possui muita similaridade com o modelo utilizado antes da 
popularização da computação em nuvem; 
• Tiered-pricing: pacotes com diferentes serviços e preços são criados, a fim de 
se adequar a aplicação a distintos perfis de clientes; 
• User-based: a cobrança é realizada de acordo com a quantidade de usuários 
que utilizam o serviço oferecido por determinado tempo. Esta estratégia é 
também chamada Seat-based. 
• Usage-based: também conhecido como modelo Pay as you go, esta estratégia 
está intimamente relacionada ao consumo realizado pelo usuário da aplicação 
SaaS, medido por tempo ou qualquer outro critério definido. A ferramenta 
elaborada provê suporte a esta técnica, conforme apresentação nos capítulos 
posteriores. 
 
2.3.2 Precificação SaaS baseado em valor 
 
A chave do sucesso da precificação de aplicação baseada em seu valor é o 
reconhecimento de que o preço do produto está baseado na visão do cliente sobre o 
valor de negócio provido pelo software ao invés de recursosde TI (tecnologia da 
informação) consumidos. Nesta linha, o sentimento de satisfação e de custo-benefício 
do consumidor com o serviço provido determinam o valor do produto, bem como a 
ideia de que a melhor opção dentre a concorrência ganhará o mercado (HARMON, et 
al., 2009). 
Para se definir um preço, é necessário identificar valores que guiam o mercado 
alvo e a importância de cada um deles na tomada de decisão, de forma a criar um link 
emocional entre o consumidor e o produto a fim de diferenciá-lo dos demais 
(HARMON e LAIRD, 1997). As principais categorias de valores são: 
• Econômico: baseado na ideia de que o cliente entende o custo envolvido para 
que o serviço seja disponibilizado a ele; 
30 
 
• Performance: percepção do consumidor de que produto consumido apresenta 
um retorno adequado pelo que se está pagando; 
• Fornecedor: a confiança e credibilidade passadas pelo fornecedor alicerçam o 
relacionamento com seus clientes. O estabelecimento deste valor inibe o 
surgimento de concorrentes (HARMON, et al., 2009); 
• Motivação do cliente: baseia-se em desejos e metas pessoais dos 
consumidores; 
 
2.4 Ferramentas de Precificação SaaS por consumo 
 
Com respeito aos trabalhos relacionados à precificação de software, Wu, Zhang 
e Wanchun (2012) propuseram uma abordagem personalizada para cobrança 
ajustada ao consumo do usuário para IaaS, PaaS e SaaS. O estudo estabelece uma 
estratégia de precificação baseada em métricas de consumo dos recursos da 
plataforma cloud na qual a aplicação está hospedada, dentre os quais podem ser 
destacados o espaço de armazenamento em disco e o tempo de processamento para 
determinada configuração de CPU. A avaliação realizada pelos autores conclui que o 
modelo de precificação por uso de recursos computacionais sob demanda favorece o 
aumento da receita para os provedores de IaaS. Entretanto, no contexto de aplicações 
SaaS, o estudo limita-se à teoria e aplica os custos de infraestrutura de maneira 
estática. Atualmente, os principais provedores de serviços cloud, como AWS (2018) e 
GCP (2018), possuem APIs que possibilitam a obtenção dessa informação 
dinamicamente. 
Durante a procura pelo tema na literatura, percebe-se uma carência de 
ferramentas que auxiliem na precificação de aplicações SaaS, principalmente ao se 
adotar o modelo baseado em consumo do usuário. Todavia, no mercado diversas 
alternativas são apresentadas para integração com estas aplicações por meio de 
planos de assinatura, as quais destinam-se a suprir essa necessidade. 
 
 
 
 
31 
 
2.4.1 Análise do mercado: Grid® Scoring 
 
Um bom ponto de partida para a análise das opções disponíveis no mercado e 
de suas características é a pontuação estabelecida por meio da metodologia Grid® 
Scoring (2018). 
Na Figura 3 são apresentados os melhores softwares na categoria de 
gerenciamento de assinaturas, segundo o Grid® Scoring. Para serem ponderadas, as 
aplicações devem: 
• Armazenar informações de pagamentos de clientes; 
• Possuir integração ou fazer papel de gateway de pagamento; 
• Automatizar contratos e faturamento; 
• Processar pagamentos automáticos de variados meios de pagamento. 
 
A pontuação considera fatores como a satisfação dos clientes, por meio de 
suas opiniões sobre o produto, além da quantidade de usuários, presença e influência 
no mercado e ROI (Return On Investment). Por fim, são classificados em quatro 
categorias: 
• Leader – produz produtos neste quadrante são altamente recomendados pelos 
usuários e possuem substancial presença no mercado. Stripe destaca-se 
nestes quesitos; 
• High Performer – os clientes também classificam muito bem o software, porém, 
este ainda não possui alta influência corporativa. Chargebee e Chargefy foram 
enquadrados nesta categoria; 
• Contender – ao contrário das aplicações high performers, contenders possuem 
elevada presença no mercado, entretanto, nota baixa de satisfação de seus 
clientes. Zuora está incluído nesta classificação; 
• Niche – além de influência inferior no mundo corporativo, estas aplicações 
ainda possuem satisfação inferior por parte de seus clientes. Recurly é citado 
aqui. 
As ferramentas destacadas no Grid® Scoring possuem funcionalidades 
similares, principalmente no âmbito de mensuração do consumo do usuário. Por esta 
razão, os conceitos aplicados serão demonstrados em sequência de maneira 
genérica. 
32 
 
 
Figura 3 - Grid® Scoring para softwares de gerenciamento de pagamentos, cobrança e 
faturamento. 
 
Fonte: Captura de tela do site G2 Crowd (G2 Crowd - Grid® Scoring Methodology, 2018). 
 
 
2.4.2 Avaliação de ferramentas disponíveis no mercado 
 
Os softwares de gerenciamento de assinatura realizam integrações com 
aplicações SaaS com o objetivo de oferecer a elas serviços de precificação, 
faturamento, contabilidade, dentre muitos outros. Para tal, controlam as inscrições de 
seus clientes nos planos de assinatura configurados, conforme ilustrado pelo 
diagrama da Figura 4. 
 
 
 
33 
 
 
Figura 4 - Diagrama Entidade-Relacionamento que representa a assinatura de um plano de preço de 
um produto. 
 
ClienteAssinatura
Plano de preço
do produto
N 1
 
 
Fonte: Elaborado pelo autor. 
 
No caso de planos de assinatura baseados no consumo do usuário, estas 
ferramentas permitem definir como isto será mensurado. Na Figura 6 é ilustrada a 
configuração de um plano de assinatura de determinado produto que será cobrado de 
acordo com o armazenamento realizado pelo cliente. Neste exemplo, que combina os 
modelos de precificação por consumo e por camada (tiered), a cada mês o usuário 
pagaria $0,01 (um centavo de dólar) a cada GB armazenado para os 100 primeiros 
GB e $0,50 por GB para os demais. 
Para que seja possível a contabilização dos gastos do cliente e posterior 
cobrança referente aos mesmos, a aplicação SaaS fica encarregada por implementar 
a lógica de negócio que mensura o consumo do usuário em determinado momento e 
por fornecer esta informação para o software gerenciador da assinatura por meio de 
integração, usualmente realizada por REST (Representational State Transfer) via 
HTTPS (Hypertext Transfer Protocol Secure) (Figura 5). 
 
Figura 5 - Comunicação via HTTPS com a aplicação Stripe para reportar consumo realizado referente 
a determinada assinatura. 
 
Fonte: Imagem extraída da referência da API Stripe (2018). 
 
 
34 
 
Figura 6 – Configuração de plano de assinatura baseado em consumo do usuário na ferramenta 
Stripe. 
 
 
Fonte: Captura de tela da ferramenta Stripe. 
 
2.5 Considerações finais 
 
Os softwares de gerenciamento de assinatura de serviços disponíveis no 
mercado auxiliam as aplicações SaaS a realizar a sua arrecadação, baseando-se nos 
gastos de seus clientes. Contudo, estas, por sua vez, devem implementar toda a lógica 
de negócio necessária para que a contabilização do consumo seja realizada. Outro 
ponto é que este cálculo nem sempre é trivial dada a diversidade de recursos 
disponibilizadas pelos provedores de serviços cloud. 
Neste sentido, aliando a proposta de Pricing as a Service de Wu et al. (2012) à 
possiblidade de obtenção de gastos da aplicação de maneira dinâmica, considerando 
o consumo das APIs das plataformas em nuvem, uma ferramenta alternativa viria a 
mitigar este problema. 
35 
 
CAPÍTULO 3 – A FERRAMENTA PRICE4SAAS 
 
Este capítulo tem como objetivo fornecer uma visão geral da ferramenta de 
suporte à precificação de aplicações SaaS, denominada Price4SaaS. Na seção 3.1 
será apresentado um cenário com o propósito de se exemplificar como o utilitário 
proposto pode auxiliar na tarefa de cobrança de um usuário de acordo com seu gasto 
sobre um software hospedado na nuvem. No tópico seguinte, são expostos os 
requisitos funcionais e não funcionais que orientaram a implementação da Price4SaaS 
de tal maneira a suportar múltiplas plataformas cloud. O design de arquitetura de 
software adotadoé, então, detalhado na seção 3.4. A implementação da ferramenta 
é exibida em sequência, sucedida das considerações finais. 
 
3.1 Considerações iniciais sobre a ferramenta Price4SaaS 
 
Antes de se apresentar os requisitos para a elaboração da Price4SaaS, um 
case é exposto nesta seção com a finalidade de se exemplificar como a ferramenta 
Price4SaaS pode auxiliar na precificação de uma aplicação SaaS. Partindo, portanto, 
desta ideia, surge o Rent XP, um site hospedado em uma plataforma de serviços em 
nuvem que oferece aos seus clientes a opção de publicação de seus imóveis a fim de 
acomodar viajantes por determinado período. Neste cenário, o cliente em questão 
pode ser desde o proprietário de um único imóvel até imobiliárias de médio e grande 
portes que disponibilizam os seus imóveis vagos com o intuito de manter a sua receita 
em períodos de baixa temporada. Os viajantes, por sua vez, reservam suas 
acomodações após escolherem o local e período de sua estadia. 
O diagrama apresentado na Figura 7 ilustra o funcionamento básico do Rent 
XP, além dos principais recursos que são consumidos da plataforma cloud na qual a 
aplicação está hospedada, Google Cloud Platform. Os seguintes processos resumem 
o funcionamento do site: 
1. Os clientes alvo do Rent XP, imobiliárias e locadores particulares, publicam 
seus imóveis para locação temporária no site; 
2. Viajantes acessam o site e alugam um imóvel de sua escolha pelo período 
que desejam; 
3. O Rent XP cobra de seus clientes um percentual sobre os imóveis alugados. 
 
36 
 
Figura 7 - Funcionamento do Rent XP, hospedado na GCP. 
 
Fonte: Elaborado pelo autor. 
 
Os desenvolvedores do Rent XP desejam, no entanto, definir um modelo de 
precificação que consideram justo e transparente, no qual podem arrecadar 
mensalmente dos clientes que publicam os imóveis no site de tal forma que a cobrança 
seja proporcional à quantidade de recursos que consumiram. Em outras palavras, o 
proprietário de um imóvel que o disponibiliza no Rent XP para locação publicando 
algumas fotos deve pagar um valor mensal muito inferior quando comparado com uma 
grande imobiliária que publica muitos imóveis na plataforma. 
Ao considerar este cenário onde há a dificuldade de se calcular a fatia que um 
usuário da aplicação SaaS efetivamente consumiu sobre o que é cobrado pela 
plataforma cloud por todos os recursos computacionais utilizados, a Price4SaaS 
fornece uma abordagem que visa solucionar a realização deste cálculo, apresentada 
em detalhes nas próximas seções. Este case será retomado no próximo capítulo 
durante a validação da ferramenta proposta. 
 
3.2 Requisitos de sistema 
 
Sommerville (2016) define que os requisitos para um sistema são as descrições 
dos serviços que deve fornecer e as restrições sobre o seu funcionamento, 
distinguindo-os, desta maneira, entre requisitos funcionais e requisitos não funcionais. 
Enquanto aqueles representam as funcionalidades que o software deve oferecer, 
como reagir a determinadas entradas e como se comportar em determinadas 
37 
 
situações, estes definem as restrições impostas ao sistema como um todo, como 
limitações de tempo e padrões de desenvolvimento. Pressman e Maxim (2014) 
oferecem, por sua vez, uma visão de requisitos não-funcionais que extrapola a 
imposição de restrições, mas, sim, os definem como atributos de qualidade, 
performance ou segurança de um sistema. 
Os requisitos de software da Price4SaaS são apresentados nas próximas 
seções. Entretanto, são precedidos de pré-requisitos que determinam se uma 
plataforma de serviços em nuvem é ou não suportada pela ferramenta. 
 
3.2.1 Pré-requisitos para suporte à plataforma cloud 
 
O provedor que hospeda uma aplicação SaaS realiza sua cobrança por meio 
de uma complexa contabilização sobre as políticas de preço que são, usualmente, 
distintas de acordo com o tipo de serviço consumido, além de serem potencialmente 
diferentes dependendo da região geográfica escolhida. Produtos de armazenamento 
de arquivos da AWS e da GCP, por exemplo, possuem definições de preço que variam 
de acordo com o volume de dados armazenados, quantidade de solicitações, 
frequência de acesso, replicação de informações, dentre outras (GOOGLE, 2018; 
AMAZON, 2018). Esses valores estão, ainda, suscetíveis a alterações por diversos 
fatores, como a introdução de novas funcionalidades com valor de negócio ou até pelo 
barateamento da infraestrutura (KASH e KEY, 2016). 
Na Figura 8 é apresentado um diagrama para ilustrar o contexto da Price4SaaS 
com o objetivo de esclarecer os pré-requisitos que viabilizam o seu funcionamento. O 
item 1 representa a supracitada contabilização de gastos de um software realizada 
pela plataforma cloud por meio de suas políticas de preço. Por sua vez, o item 2 retrata 
a integração da ferramenta com este provedor de nuvem a fim de obter estas 
informações de consumo da aplicação sobre os mais diversos serviços utilizados. De 
posse dos dados, estratégias de segregação são empregadas para se dividir o 
consumo dos seus usuários. 
 
38 
 
Figura 8 – Contexto de funcionamento da Price4SaaS. (1) Contabilização de gastos da aplicação 
SaaS pela plataforma cloud; (2) A ferramenta integra-se com o provedor para consumo dos dados. 
 
Fonte: Elaborado pelo autor. 
 
Sob esta conjuntura, três pré-requisitos podem ser estabelecidos para que uma 
plataforma cloud seja suportada pela Price4SaaS: 
1. O provedor de nuvem deve oferecer uma interface de integração que 
possibilite acesso às informações de faturamento dos serviços utilizados 
pela aplicação SaaS; 
2. Os dados disponibilizados devem conter obrigatoriamente a identificação do 
serviço da plataforma e o seu período de consumo; 
3. Deve existir um mecanismo que viabilize o agrupamento de dados por 
usuário. 
Uma estratégia que pode ser aplicada para atingir a última condição é a 
rotulagem de recursos da plataforma via mecanismos de tags ou marcadores, os quais 
proporcionam a flexibilidade de identificá-los ou agrupá-los de diversas maneiras, 
como, a título de exemplo, a qual ambiente da aplicação (desenvolvimento, teste ou 
produção) ou proprietário que pertencem (GOOGLE, 2018; AMAZON, 2018). Os 
rótulos aplicados aos recursos que geram métricas de uso são encaminhados para o 
sistema de faturamento e, desta maneira, podem ser utilizados para identificador 
unicamente um usuário da aplicação. 
A rotulagem não pode ser aplicada para a contabilização de todos os serviços 
do provedor cloud, no entanto. Recursos computacionais como máquinas virtuais são 
39 
 
usualmente consumidos por uma aplicação SaaS para atender requisições de 
múltiplos usuários e, portanto, tal custo não pode ser atribuído a apenas um cliente. 
Desta forma, esta estratégia pode ser adotada na granularidade de serviços 
suportados com o intuito de diminuir a complexidade do cálculo, enquanto os demais 
gastos podem seguir um tratamento diferente, como praticar a divisão por todos os 
usuários. 
 
3.2.2 Requisitos funcionais identificados 
 
Conhecidas as características que permitem o desenvolvimento da 
Price4SaaS, puderam ser identificados denominadores comuns entre os provedores 
de nuvem para a elicitação dos seus requisitos funcionais (RF), de forma a nortear a 
elaboração da ferramenta com suporte a múltiplas plataformas. Os requisitos são 
listados em sequência: 
 
RF.1 – Controle de acesso 
O acesso à ferramenta deve ser concedido após autenticação do usuário via 
credenciais válidas. Níveis de permissão controlados por meio de perfis e 
recursos devem existir com o propósito de controlar as funcionalidades que o 
usuário autenticado pode acessar. 
 
RF.2 – Gerenciamento de usuários 
Deve ser possível incluir, editar e excluir um usuário de forma a possibilitar 
novos acessos à ferramenta. A este, deve ser atribuído um perfil que indica as 
permissões de acesso às funcionalidades do sistema.RF.3 – Listagem de provedores cloud e serviços suportados 
A ferramenta deve exibir os provedores de nuvem suportados e quais dos seus 
respectivos serviços são passíveis de configuração para precificação. 
 
RF.4 – Gerenciamento de projetos 
A ferramenta deve permitir a inclusão, edição e exclusão de projetos (nome, 
descrição e provedor de nuvem), os quais representam as aplicações SaaS 
hospedadas nas plataformas cloud. 
40 
 
RF.5 – Configuração do provedor de nuvem do projeto 
A ferramenta deve permitir a inclusão e edição das configurações necessárias 
para viabilizar a integração da Price4SaaS com o provedor de nuvem de um 
projeto cadastrado. A quantidade de informações de configuração é variável 
dadas as particularidades de cada plataforma, de tal forma que o software deve 
absorver esta condição. 
 
RF.6 – Estratégia de faturamento para serviços cloud utilizados 
A ferramenta deve listar os serviços da plataforma cloud que o projeto consome 
e permitir que o usuário configure uma estratégia de faturamento para o seu 
cômputo na Price4SaaS. Quando o serviço for suportado (RF.3), a opção 
“Cobrança por uso” estará disponível para escolha, enquanto serviços não 
suportados serão, por padrão, relacionados à estratégia “Dividir gastos”. Neste 
último caso, o valor contabilizado para o serviço será dividido igualitariamente 
entre todos os usuários. 
 
RF.7 – Extrato de gastos por período 
A ferramenta deve possibilitar a consulta de gastos do projeto em determinado 
intervalo de datas para oferecer suporte à precificação da aplicação. A 
apresentação destas informações deve ser de três maneiras: 
1. Discriminados os gastos por serviços, conforme estratégia de precificação 
previamente definida (RF.6); 
2. Oferecer a possibilidade de detalhamento de gastos que são totalizados por 
usuário; 
3. Apresentar os gastos de um serviço específico por usuário da aplicação 
SaaS. 
 
3.2.3 Requisitos não funcionais desejados 
 
Dentre os mais diversos requisitos funcionais desejáveis para um software, três 
foram elencados para aplicação na ferramenta Price4SaaS dadas as suas 
características. 
 
 
41 
 
RNF.1 – Portabilidade 
O sistema deve ser desenvolvido de tal forma que seja possível migrá-lo para 
diferentes ambientes com facilidade, uma vez que a aplicação deve ser 
preferencialmente hospedada na mesma plataforma cloud escolhida pela 
aplicação SaaS, tanto pela diminuição da latência ao obter as informações 
quanto pela contabilização do tráfego para egresso na Internet por parte do 
provedor. 
 
RNF.2 – Extensibilidade 
Novas plataformas de nuvem podem ser agregadas à aplicação, desde que 
atendam os pré-requisitos estabelecidos pela ferramenta. 
 
RNF.3 – Segurança 
Todos os recursos privados do sistema podem ser acessados somente após a 
realização do processo de autenticação do usuário. 
 
3.3 Desenho de arquitetura de software 
 
Pressman (2014) indica que o desenho de arquitetura de um software é iniciado 
através da definição do seu contexto. Ainda segundo o autor, uma maneira adequada 
para se iniciar esta tarefa é através da composição de um diagrama contextual de 
arquitetura, o qual apresenta o sistema e as entidades (pessoas, sistemas, 
dispositivos, etc.) com as quais ele, bem como a natureza desta interação. Na Figura 
9 este diagrama para a Price4SaaS é ilustrado. 
 
42 
 
Figura 9 - Diagrama contextual de arquitetura da ferramenta Price4SaaS. 
Price4SaaSAdministrador Usa
API
da Plataforma 
Cloud
Banco de Dados
Depende de Depende de
 
Fonte: Elaborado pelo autor. 
 
A entidade “Administrador” representa o usuário que utiliza a Price4SaaS para 
auxiliá-lo na precificação de um software hospedado na nuvem. A ferramenta, por sua 
vez, depende de duas entidades essenciais para o seu funcionamento: “API da 
Plataforma Cloud” e “Banco de Dados”. A primeira simboliza a interface para 
integração com o provedor de serviços em nuvem para obtenção de informações de 
gastos da aplicação SaaS, enquanto a segunda corresponde ao repositório escolhido 
para armazenar as configurações dos projetos gerenciados. 
Compreendido o contexto em que a aplicação se enquadra, a sua organização 
interna pode ser explorada. De acordo com Fowler (2002, p. 17-18), uma das 
estratégias mais comuns para mitigar a complexidade de um software é dividi-lo em 
camadas. Um ótimo exemplo de emprego desta técnica é a organização dos 
protocolos de rede em camadas (KUROSE e ROSS, 2014, p. 35-39). Esta escolha 
traz importantes vantagens para o desenvolvimento e manutenibilidade do sistema, 
como a capacidade de se modificar a realização de um serviço ou mesmo substitui-lo 
sem afetar outros componentes. Não menos importante é o benefício de se evoluir um 
software sem a necessidade de conhece-lo como um todo. 
 
 
 
43 
 
Tabela 3 - Três camadas principais de um software. 
Camada Responsabilidades 
Apresentação 
Fornecimento de serviços, exibição de 
informações (p. ex., em Windows ou HTML, 
tratamento de solicitações do usuário) 
Negócio Lógica que é o real propósito do sistema. 
Fontes de dados 
Comunicação com os bancos de dados, 
sistemas de mensagens, gerenciamento de 
transações, outros pacotes. 
Fonte: Tabela extraída de Patterns of Enterprise Application Architecture (FOWLER, 2002). 
 
Em harmonia com as ideias expostas por Fowler, o conceito de três principais 
camadas foi implementado na ferramenta: apresentação, negócio – ou domínio – e 
fonte de dados (FOWLER, 2002, p. 19-22). A lógica de apresentação trata da 
interação entre o usuário e o software, a qual pode ser desde um terminal com linhas 
de comando até uma interface de usuário enriquecida. A camada de fonte de dados, 
por sua vez, lida com processos de comunicação com outros sistemas em nome da 
aplicação para obtenção e persistência de informações. Por fim, a camada de negócio 
é responsável por identificar a solicitação de um usuário via camada de apresentação, 
decidir qual ou quais fontes de dados devem ser utilizadas na lógica de negócio 
associada e realizar o processamento adequado. Um sumário destas 
responsabilidades é apresentado na Tabela 3. 
 
Figura 10 - Representação da arquitetura de três camadas. 
Apresentação
Negócio ou Domínio
Fonte de Dados
Consome
Consome
 
Fonte: Elaborado pelo autor. 
44 
 
No diagrama das três camadas apresentado na Figura 10, nota-se que há uma 
dependência bem-definida entre cada faixa da arquitetura. A camada de apresentação 
consume os serviços da camada de negócio e desconhece a existência da camada 
de fonte de dados. A camada de negócio, por sua vez, faz uso dos serviços de fonte 
de dados com a preocupação de aplicar a sua lógica, entretanto, não conhece a 
camada de apresentação. Para finalizar o fluxo, a camada de fonte de dados expõe 
informações de sistemas terceiros sem saber exatamente quem irá consumi-las. Na 
seção de desenho técnico apresentada a seguir, os componentes associados a cada 
camada serão detalhados. 
 
3.3.1 Desenho técnico de arquitetura de software 
 
As tecnologias adotadas para a implementação da Price4SaaS garantem a 
exequibilidade do projeto em um ambiente de nuvem e suportam o cumprimento dos 
requisitos de sistema, além de serem open source. Fundamentado na linguagem de 
programação Java 8, o framework Spring foi utilizado para simplificar a criação e a 
sua execução (SPRING, 2018). Um servlet container é embarcado durante o processo 
de empacotamento de tal maneira que a solução se torna autocontida. Assim, a 
aplicação Java web pode ser inicializada através do usual comando “java -jar” 
(SPRING, 2018). Na Figura 11 são apresentadas as tecnologias mais importantes 
associadas à arquitetura empregada. 
As requisições enviadas ao software via protocolo HTTP (Hypertext Transfer 
Protocol) são tratadas na camada de apresentação pelo Spring MVC, o qual interage 
– quando necessário – com os serviços da camada de negócioe delega ao 
mecanismo de templates chamado Thymeleaf a tarefa de geração das páginas web. 
Estes documentos são construídos com HTML (Hyper Text Markup Language) versão 
5, CSS (Cascading Style Sheets) versão 3, a linguagem interpretada JavaScript e a 
biblioteca JQuery, sendo posteriormente encaminhados como resposta à solicitação 
para interpretação no navegador do usuário. 
 
45 
 
Figura 11 - Arquitetura de camadas da ferramenta Price4SaaS. 
 
Fonte: Elaborado pelo autor. 
 
Redundâncias à parte, a camada de negócio é composta de classes Java sem 
estado, especializadas na lógica de negócio da ferramenta. Elas possuem como 
dependência as fontes de dados, das quais obtêm as informações necessárias para 
realizar o seu ofício. Os elementos retornados pelos seus métodos compõem a 
resposta ao usuário. 
As APIs das plataformas cloud e uma base de dados para armazenar as 
configurações dos projetos são as fontes de origens utilizadas pela ferramenta. O 
banco de dados orientado a documentos MongoDB foi escolhido principalmente para 
suportar os requisitos funcionais da aplicação, sabido que há informações de 
configuração dos provedores de serviços em nuvem que não seguem um esquema 
pré-estabelecido, característica esta que favorece o uso de bases de dados não 
relacionais, também conhecidas como NoSQL (Not only Structured Query Language) 
(STÖRL, et al., 2015). 
46 
 
Spring Transaction Manager (2018) e Spring Security (2018), em amarelo na 
Figura 11, são dois elementos transversais às camadas da aplicação e que auxiliam 
nas tarefas de controle transacional e segurança da aplicação, respectivamente. O 
primeiro, garante a consistência das informações persistidas na base de dados por 
meio do simples emprego de anotações nos métodos das classes de negócio 
(ORACLE, 2018), enquanto o segundo facilita as tarefas de autenticação e 
autorização dos usuários através do mapeamento das rotas protegidas. 
 
3.4 Implementação da ferramenta Price4SaaS 
 
Os requisitos funcionais implementados para a composição da Price4SaaS 
foram priorizados de forma a expor o real valor da ferramenta. Desta forma, a 
elaboração do gerenciamento de usuários foi postergada para trabalhos 
suplementares por não inviabilizar o seu funcionamento. A seguir, o controle de 
acesso geral da aplicação é detalhado, seguido das demais funcionalidades 
implantadas. 
 
3.4.1 Controle de acesso 
 
O controle de acesso da Price4SaaS é baseado na proteção de URLs (Uniform 
Resource Locator) da aplicação web qualificadas como privadas. Páginas definidas 
como públicas podem ser acessadas sem qualquer interferência na requisição cliente. 
Na Figura 12 é apresentado um diagrama que ilustra o cenário de autenticação. 
 
47 
 
Figura 12 - Diagrama de controle de acesso do usuário na Price4Saas. 
Recurso
Solicitado
Login
Valida credenciais
Credenciais Válidas
Credenciais
Inválidas
Usuário Não
Autenticado
Usuário
Usuário
Autenticado
Solicita
 Recurso
 Privado
Logout
 
Fonte: Elaborado pelo autor. 
 
Quando um usuário não autenticado tenta acessar um recurso privado, ocorre 
um redirecionamento para a página de autenticação (Figura 13), na qual deverá 
fornecer seu usuário e senha para validação. Se as credenciais fornecidas forem 
válidas, o usuário é redirecionado para o recurso inicialmente solicitado. Caso 
contrário, a mensagem de erro “Usuário ou senha inválidos” é exibida na própria 
página de autenticação, que permanece visível. 
Uma vez que o usuário esteja autenticado, todas as páginas exibem o seu 
nome e a opção “Log out” para que o seu acesso seja invalidado. Realizada esta 
última ação, o usuário é novamente redirecionado para a tela de autenticação, sendo 
a mensagem “Log out realizado” exibida. 
 
48 
 
Figura 13 - Página de autenticação da ferramenta Price4SaaS. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
3.4.2 Página inicial 
 
A página inicial da Price4SaaS, ilustrada na Figura 14, possui visibilidade 
pública e funciona como um painel de boas-vindas ao usuário. Esta tela contém links 
de acesso às funcionalidades iniciais da aplicação. Através dela, é possível acessar: 
• A funcionalidade de autenticação do usuário por meio do link “Log in”; 
• A tela de gerenciamento de projetos; 
• Os provedores de nuvem e seus serviços que são suportados pela aplicação; 
• Uma página que introduz o usuário aos conceitos da ferramenta. 
 
49 
 
Figura 14 - Página inicial da ferramenta Price4SaaS. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
3.4.3 Gerenciamento de projetos 
 
A funcionalidade de gerenciamento de projetos é o coração da Price4SaaS. 
Uma vez que o projeto SaaS esteja cadastrado, é possível realizar as configurações 
do seu provedor de serviços de nuvem e, posteriormente, consultar as informações 
de gastos da aplicação. 
Após a adição do projeto na ferramenta, sua referência é apresentada em uma 
listagem com ícones que permitem a realização das ações “Editar”, “Configurar 
provedor de nuvem” e “Excluir” sobre ele, como pode ser visto na Figura 16. A ação 
de edição do projeto, acessível por meio da interação com o ícone “lápis”, possibilita 
a alteração do seu nome e da sua descrição, porém, a escolha de outro provedor de 
nuvem não é permitida. Caso se deseje modificar esta opção, outro projeto deve ser 
criado e o anterior, removido via ação “Excluir” (ícone “lixeira”). Por fim, a configuração 
da plataforma cloud é acionada pelo por meio do ícone “engrenagens”, funcionalidade 
apresentada na próxima seção. 
 
50 
 
Figura 15 - Página de cadastro de um projeto SaaS na plataforma Price4SaaS. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
Figura 16 - Listagem de projetos e ações disponíveis sobre ele na Price4SaaS. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
3.4.4 Configuração do provedor de nuvem do projeto 
 
Como cada plataforma cloud possui configurações singulares para que os 
dados de faturamento de uma aplicação SaaS sejam consumidos pela Price4SaaS, a 
página de configuração é gerada de acordo com o provedor de nuvem do projeto. Para 
melhorar a experiência do usuário na ferramenta, nesta tela foi implementado um 
51 
 
componente do tipo “passo a passo”, conforme ilustrado na Figura 17 para um projeto 
hospedado na GCP. O mesmo se aplica para a configuração da AWS. A seguir, são 
apresentadas as abordagens para suporte a estas plataformas. 
 
Figura 17 - Configuração da GCP para um projeto na Price4SaaS. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
3.4.4.1 Suporte à Google Cloud Platform 
 
 A obtenção de informações de faturamento na GCP ocorre via consumo de 
diversas APIs da plataforma. O Apêndice A contém o detalhamento de uma série de 
configurações que devem sem aplicadas no provedor de nuvem e armazenadas na 
Price4SaaS para que a integração seja possível. Resumidamente, é necessário: 
1. Criar um projeto; 
2. Criar conta de faturamento e vinculá-la com o projeto; 
3. Habilitar as APIs necessárias; 
4. Ativar a exportação de dados de faturamento; 
5. Criar credenciais para integração. 
 
 
52 
 
Os códigos do projeto (primeiro passo) e da conta de faturamento (segundo 
passo), além das informações de credenciais (quinto passo) são armazenados no 
banco de dados da Price4SaaS. 
Os dois últimos passos da configuração merecem destaque. A GCP exporta 
dados de consumo para arquivos nos formatos CSV e JSON e também para leitura 
por meio de um de seus serviços, o BigQuery. Esta última opção foi adotada pois 
captura um conjunto maior de dados e seu uso é mais conveniente uma vez que a 
linguagem SQL (Structured Query Language) pode empregada nas consultas 
(GOOGLE, 2018). No que se refere à integração com esta plataforma cloud, as 
informações de credenciais configuradas no último passo são utilizadas para consumo 
das APIs da Google, que utilizam o protocolo OAuth 2.0 para autenticaçãoe 
autorização (GOOGLE, 2018). 
 
Figura 18 - Diagrama de sequência da geração de token de acesso à GCP. 
 
Fonte: Adaptado de Google (2018). 
 
O diagrama de sequência que é apresentado na Figura 18 visa ilustrar o 
processo de integração com a Google utilizando o protocolo OAuth 2.0. A sequência 
de autorização começa quando o Price4SaaS redireciona um navegador para um URL 
do Google. A URL inclui parâmetros de consulta que indicam o tipo de acesso 
53 
 
solicitado. O Google lida com a autenticação do usuário, a seleção de sessões e o 
consentimento do usuário. O resultado é um código de autorização, que a ferramenta 
pode trocar por um token de acesso e um token de atualização. A Price4SaaS 
armazena o token de atualização para uso futuro e usa o token de acesso para 
acessar uma API do Google. Quando o token de acesso expirar, o token de 
atualização pode ser utilizado para obter um novo. 
 
3.4.4.2 Suporte à Amazon Web Services 
 
De maneira similar à integração com a plataforma GCP, para que a Price4SaaS 
consuma as informações de faturamento de uma aplicação SaaS hospedada na AWS 
é exigido que uma sequência de configurações seja aplicada, conforme exposto no 
Apêndice B. Em síntese, para realizar a integração é preciso: 
1. Criar usuário para agrupar recursos do projeto; 
2. Criar fonte para armazenamento; 
3. Habilitar o relatório de faturamento; 
4. Configurar o serviço Amazon Redshift; 
5. Configurar credenciais. 
 
Uma vez seguidos estes passos, a AWS exporta diariamente (ou de hora em 
hora, conforme configuração) as informações de gastos para arquivos CSV em uma 
fonte de armazenamento, mais especificamente por meio do serviço S3 (Simple 
Storage Service). A Price4SaaS poderia realizar a leitura direta destes arquivos 
brutos, no entanto, com a possibilidade de se habilitar o suporte do serviço Amazon 
Redshift desta plataforma cloud, o consumo dos dados é torna-se simplificado, de 
maneira semelhante ao consumo do serviço BigQuery da GCP. 
 
3.4.5 Configuração de serviços do projeto 
 
Posto que a configuração do provedor de nuvem do projeto foi realizada, torna-
se possível a configurar como os serviços utilizados serão contabilizados na 
Price4SaaS. Quando o recurso de um serviço pertencer a um usuário específico da 
aplicação, a estratégia de faturamento “Cobrar por Uso” estará disponível, caso 
contrário, a opção “Dividir Gastos” é adotada por padrão. Na Figura 19 são exibidos 
54 
 
os serviços utilizados por um projeto hospedado na GCP. A estratégia de cobrança 
por uso está disponível para o serviço “Storage” pois um espaço de armazenamento 
de arquivos pode ser rotulado com o intuito de demarcar que ele pertence a um 
usuário. 
 
Figura 19 - Configuração de estratégias de cobrança dos serviços de nuvem. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
3.4.6 Extratos de gastos por período 
 
A página de extratos de gastos por período é o resultado da consolidação de 
toda as configurações realizadas na plataforma cloud e na ferramenta Price4SaaS. 
Escolhido um intervalo de datas, é possível consultas os gastos de consumo dos 
serviços provedor cloud neste período de acordo com a estratégia de cobrança 
previamente configurada. Na Figura 20 é possível visualizar que o projeto nomeado 
“Minha aplicação SaaS” utilizou os serviços BigQuery, Compute Engine e Storage da 
plataforma GCP no mês de setembro de 2018. 
 
55 
 
Figura 20 - Página de consulta de gastos do projeto em um intervalo de datas. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
A partir do botão “Detalhar” é possível explorar os gastos de cada usuário 
referentes a serviços associados à estratégia de cobrança “Cobrar por Uso”. As 
informações são exibidas em um tabela (Figura 21) e também em forma de gráfico 
(Figura 22). Em ambos os casos, o identificador único do usuário é exibido para 
representar o seu gasto referente a este serviço. A aplicação SaaS é responsável 
apenas por definir um rótulo (marcador ou tag) no recurso de armazenamento do 
provedor de nuvem, sendo “p4s-userid” a chave e o código do usuário o valor. 
Por fim, a última opção implementada para visualização de gastos por período 
é o extrato geral por usuário, acionada por meio do botão “Gastos por usuário”. Nesta 
tela, ilustrada na Figura 23, o identificador do usuário é associado ao seu gasto total 
no período, ou seja, referente ao somatório de todos os serviços de seu uso exclusivo 
– estratégia de cobrança por uso – e de sua parcela na divisão de gastos dos demais 
serviços da aplicação SaaS – estratégia padrão “Dividir gastos”. 
 
56 
 
Figura 21 - Tela de gastos por usuário referentes ao serviço Storage da GCP. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
Figura 22 – Gráfico que apresenta os gastos por usuário referentes ao serviço Storage da GCP. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
57 
 
Figura 23 - Extratos de gastos consolidados por usuários no período selecionado. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
3.4.7 Considerações finais 
 
Neste capítulo foram apresentados todos os conceitos utilizados para a 
elaboração da Price4SaaS, desde os requisitos funcionais e não funcionais até a 
exposição das páginas da aplicação web implementada que suporta as plataformas 
GCP e AWS. 
 A seguir, os procedimentos de teste e validação dos requisitos da ferramenta 
são apresentados de forma a certificar a importância do trabalho desenvolvido e 
identificar pontos de melhoria. 
 
58 
 
CAPÍTULO 4 – TESTES E VALIDAÇÃO DA FERRAMENTA 
 
Este capítulo apresenta os procedimentos adotados para a realização de testes 
e validação funcional da ferramenta desenvolvida. Para tal, será retomado o case Rent 
XP, introduzido na seção 3.1, validando-o na GCP e na AWS. Ambas plataformas 
possuem uma camada de uso gratuita, na qual os gastos não são cobrados do cliente. 
Esses valores foram ignorados durante as contabilizações realizadas durante os 
testes. 
 
4.1 Serviços utilizados pelo Rent XP 
 
Normalmente uma aplicação SaaS faz uso de diversos serviços da plataforma 
cloud que a hospeda. No entanto, com o intuito de simplificar a validação do case Rent 
XP sem que a sua execução fosse comprometida foram empregados três recursos 
principais: 
1. Máquina virtual: na qual o servidor de aplicação é instalado para atender as 
requisições dos seus usuários; 
2. Armazenamento de arquivos: local onde são armazenadas as fotos dos imóveis 
registrados; 
3. Banco de dados: empregado na persistência das demais informações dos 
imóveis disponibilizados na aplicação. 
 
A ferramenta Price4SaaS utiliza-se do mecanismo de rotulação de recursos do 
provedor de nuvem para possibilitar a precificação baseada em consumo do usuário. 
No cenário do Rent XP, esta estratégia pode ser aplicada apenas nos serviços de 
armazenamento de arquivos, uma vez que os demais são compartilhados por todos 
os usuários. Na Figura 24 é ilustrado o empregado dos marcadores nos espaços de 
armazenamentos dos usuários da aplicação Rent XP na GCP. Na AWS o mesmo 
procedimento é realizado, sendo que a única diferença é o termo “tag”, utilizado pela 
plataforma. 
 
 
59 
 
Figura 24 - Buckets que contêm as imagens dos imóveis dos usuários da Rent XP. Em vermelho são 
destacados os marcadores com o identificador de cada usuário. 
 
Fonte: Captura de tela da Google Cloud Platform. 
 
 No caso das máquinas virtuais, instâncias com configurações similares foram 
adotadas nas duas plataformas cloud. A Tabela 4 contém os detalhes dos tipos de 
instância utilizados pela Rent XP em cada uma delas. Por fim, o banco de dados 
utilizado foi o MySQL, sendo este serviço conhecido como Cloud SQL e RDS na GCP 
e AWS, respectivamente. 
 
Tabela 4 - Tipos de instâncias utilizadas pela Rent XP na GCP e AWS. 
Plataforma Cloud Tipo da Instância Virtual CPUs RAM (GB) 
Google Cloud Platform n1-standard-22 7.5 
Amazon Web Services c5.large 2 8 
Fonte: Elaborado pelo autor. 
 
4.2 Informações armazenadas e tráfego de arquivos 
 
 O cenário de validação elaborado foca na quantidade de imagens 
armazenadas nas plataformas cloud, bem como o tráfego realizado para Internet ao 
solicitar estes arquivos. Na Tabela 5 são apresentados os identificadores dos usuários 
que disponibilizam os seus imóveis no Rent XP e o tamanho em MB ocupados para 
armazenar as imagens dos mesmos. Para cálculo do tráfego das imagens, foi 
considerado que cada imóvel de um usuário fosse visualizado por completo duas 
60 
 
vezes no intervalo de datas utilizado, ou seja, suas imagens seria trafegadas para 
Internet duas vezes. 
 
Tabela 5 - Tamanho do armazenamento utilizado por cada usuário. 
Identificador do usuário Tamanho total dos arquivos (MB) 
danilo-moura 93 
frederico-farias 1.790 
imobiliaria-confianca 16.300 
imobiliaria-gloria 27.200 
imobiliaria-pires 19.900 
laura-reis 1.770 
lorenzo-batista 2.370 
ofelia-franco 65 
pedro-castro 1240 
vicente-franco 825 
Fonte: Elaborado pelo autor. 
 
4.3 Resultados obtidos 
 
Após a realização de configuração do Rent XP na ferramenta Price4SaaS, a 
consulta de informações de gastos nas duas plataformas foi realizada para o mês de 
outubro. Na Figura 25 são apresentados os gastos do case com os serviços da GCP, 
enquanto na Figura 26 são exibidos os valores para serviços da AWS. De imediato, é 
possível visualizar que neste cenário a hospedagem na Google Cloud Platform é mais 
atrativa. 
Além disso, a cobrança pelo serviço Amazon Redshift da AWS ocorre 
unicamente pela integração adotada com a Price4SaaS, de forma que o consumo de 
dados de faturamento acaba gerando novos encargos para a aplicação SaaS. No caso 
do serviço BigQuery, nenhuma cobrança foi realizada, uma vez que a quantidade de 
informações armazenadas no seu dataset não gera encargos. Desta maneira, nota-
se que a implementação da integração da ferramenta com a GCP é muito mais 
vantajosa. 
 
 
61 
 
Figura 25 - Gastos da Rent XP sobre serviços da GCP. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
Figura 26 - Gastos da Rent XP sobre serviços da AWS. 
 
Fonte: Captura de tela da ferramenta Price4Saas. 
 
Com o intuito de realizar um comparativo da medição realizada pela ferramenta 
Price4SaaS com a cobrança efetiva da plataforma cloud, na Figura 27 é apresentada 
a fatura do painel da AWS contendo os gastos referentes ao mês de outubro de 2018. 
62 
 
Percebe-se, conforme esperado, que os valores são iguais aos exibidos na Figura 26, 
uma vez que são exportados pelo próprio provedor. No entanto, a medição exibida 
pela Price4SaaS é dependente do período de exportação de informações de gastos 
que é, usualmente, diário. Neste cenário, por exemplo, a ferramenta elaborada não 
possui assertividade sobre os gastos do dia corrente. 
 
Figura 27 - Painel da AWS com fatura da Rent XP no mês de outubro de 2018. 
 
Fonte: Captura de tela do painel de cobrança da AWS. 
 
 Para efetuar uma análise no âmbito de gastos individuais, na Tabela 6 são 
exibidos os gastos por usuário da Rent XP nas plataformas GCP e AWS no mês de 
outubro de 2018, a partir de dados extraídos da Price4SaaS. Neste cenário, um 
usuário com poucos MB de armazenamento possui gastos reduzidos quando 
comparado a um usuário com armazenamento elevado. O usuário identificado por 
“danilo-moura”, tomando a plataforma GCP como exemplo, pagaria R$ 22,66, o que 
representa 4,33% do total de gastos da aplicação SaaS no mês de consumo, enquanto 
o usuário identificado por “imobiliária-gloria” deveria desembolsar R$ 136,38, o que 
representa mais de 26% da fatura mensal. Além disso, nota-se que o percentual de 
economia entre as plataformas avaliadas é maior para um usuário que possui menos 
MB de arquivos armazenados. 
63 
 
Tabela 6 - Gastos por usuário da Rent XP para as GCP e AWS no mês de outubro de 2018 a partir de 
dados extraídos da Price4SaaS. 
Identificador 
do usuário 
Tamanho 
total dos 
arquivos 
(MB) 
Gastos 
GCP 
% de 
gastos 
GCP 
Gastos 
AWS 
% de 
gastos 
AWS 
% de 
economia 
entre 
plataformas 
danilo-moura 93 R$ 22,66 4,33% R$ 36,41 4,67% 37,76% 
frederico-
farias 
1.790 R$ 29,77 5,69% R$ 46,38 5,95% 35,81% 
imobiliaria-
confianca 
16.300 R$ 90,65 17,34% R$ 131,62 16,90% 31,13% 
imobiliaria-
gloria 
27.200 R$ 136,38 26,08% R$ 195,66 25,12% 30,30% 
imobiliaria-
pires 
19.900 R$ 105,76 20,23% R$ 152,77 19,61% 30,77% 
laura-reis 1.770 R$ 29,69 5,68% R$ 46,26 5,94% 35,82% 
lorenzo-
batista 
2.370 R$ 32,21 6,16% R$ 49,79 6,39% 35,31% 
ofelia-franco 65 R$ 22,54 4,31% R$ 36,24 4,65% 37,80% 
pedro-castro 1240 R$ 27,47 5,25% R$ 43,15 5,54% 36,34% 
vicente-franco 825 R$ 25,73 4,92% R$ 40,71 5,23% 36,80% 
Fonte: Elaborado pelo autor. 
 
4.4 Considerações finais 
 
Neste capítulo foi possível validar a integração entre a Price4SaaS e as APIs 
das plataformas cloud às quais a ferramenta oferece suporte. No entanto, a integração 
com o serviço Amazon Redshift da AWS gerou novos encargos para a aplicação 
SaaS, enquanto o consumo do serviço BigQuery da GCP tomou um caminho 
totalmente oposto, uma vez que nenhuma cobrança foi realizada sobre este serviço. 
 
 
64 
 
CAPÍTULO 5 – CONCLUSÃO 
 
Este trabalho apresentou a fundamentação, os requisitos e o desenvolvimento 
da Price4SaaS. No Capítulo 1, o propósito do estudo e o contexto no qual se enquadra 
foram introduzidos para indicar a sua relevância. No capítulo subsequente, a 
importância da precificação para uma aplicação SaaS e a revolução causada pela 
computação em nuvem foram expostas, juntamente com estudos e ferramentas 
correlatas que visam precificar este tipo de software. Já no Capítulo 3, o case Rent 
XP é exposto inicialmente para exemplificar um cenário que se beneficiaria da 
ferramenta proposta. Posteriormente, são apresentados os pré-requisitos para 
suporte a uma plataforma cloud, a elicitação de requisitos e a arquitetura de software. 
Esta seção é, então, finalizada com a exposição da implementação das 
funcionalidades da Price4SaaS. Por fim, na fase de testes e validação da ferramenta, 
apresentado no Capítulo 4, o case supracitado é melhor detalhado e a sua validação 
é realizada nas plataformas GCP e AWS, comparando-se os resultados obtidos. 
Com o desenvolvimento apresentado neste trabalho, considera-se que o seu 
objetivo geral foi atingido, uma vez que a ferramenta implementada auxilia na 
precificação de aplicações SaaS baseando-se no consumo de seus usuários. A 
proposta de Pricing as a Service (WU, et al., 2012), citada na seção 2.4, torna-se 
dinâmica na Price4SaaS, pois a estratégia de leitura de métricas da plataforma em 
nuvem por meio de suas APIs é adotada pela ferramenta. Por fim, desde que o 
provedor cloud atenda aos requisitos de disponibilização de informações de gastos, 
expostos na seção 3.2.1, a Price4SaaS oferece suporte a múltiplas plataformas, 
sendo GCP e AWS as escolhidas para exposição neste texto. 
Conclui-se, portanto, que a adoção da Price4SaaS por parte dos 
desenvolvedores de uma aplicação SaaS é uma opção promissora para viabilizar o 
modelo pay as you go (2.3.1) e que pode trazer como benefício a seus usuários o 
oferecimento de um serviço transparente e igualitário ao se demonstrar a razão da 
cobrança realizada. Contudo, no seu estado atual de desenvolvimento, o valor de 
negócio da ferramenta está condicionado à estratégia de rotulação de recursos 
pertencentes ao usuário da aplicação na plataforma cloud, conforme exposto nas 
seções 3.2.1 e 4.1. Com o intuito de direcionar trabalhos posteriores, a seguir são 
expostas as principais adversidades enfrentadas, bem como um encaminhamento 
para trabalhos futuros. 
65 
 
5.1 Problemas encontrados 
 
Dentre os diversos problemas encontrados durante o desenvolvimento do 
trabalho, merecem destaque: 
• Dificuldade de encontrar estudos