1. Whitepaper:
Insights sobre Custos Associados à
Manutenção Corretiva, Perfectiva e
Evolutiva de Software
Marcio Marchini - https://br.linkedin.com/in/marciomarchini
Setembro de 2016
1) Contexto: 44% dos Custos em Adaptações ............................................................................... 1
2) Esforço além de LOC (Lines of Code) ........................................................................................... 3
3) Defeitos e o Custo da Qualidade ..................................................................................................... 5
4) Infraestrutura para Evolução com Qualidade ....................................................................... 10
5) Customização = Complexidade = Custo Extra ....................................................................... 11
6) Inovação: Pesquisa, Insucessos e Pivotagem ........................................................................ 15
7) Escalabilidade: A Inovação Inevitável ...................................................................................... 16
8) Conclusão .............................................................................................................................................. 23
1) Contexto: 44% dos Custos em Adaptações
Quando se pensa em fazer um software imagina-se sempre o contexto de um novo
produto sendo codificado e que será entregue ao cliente e pronto. Mas o fato é que a
grande maioria dos softwares é escrita mas precisa evoluir constantemente ao longo
do tempo, após a entrega inicial. Em alguns casos isso ocorre por necessidade de
adaptá-lo a novos processos ou formas de operação do cliente; em outros casos por
mudança de legislação ou evolução tecnológica e obsolescência de hardware,
sistemas operacionais e bibliotecas de terceiros.
O fato é que o custo relativo de manter um software e gerenciar sua evolução em
alguns casos já atinge mais de 90% de seu custo total, conforme pode ser visto na
tabela abaixo (originalmente de
https://wiki.uef.fi/download/attachments/38669960/SMCOSTS.pdf?version=2&m
odificationDate=1430404596000&api=v2):

2. A tendência é clara com o passar dos anos1:
Segundo o estudo do Departamento de Defesa americano (DoD/USA) em
http://www.stsc.hill.af.mil/resources/tech_docs/gsam3/appenf.pdf2 , 67% dos
custos de desenvolvimento de software podem ser classificados como manutenção:
1 http://www.slideshare.net/meijerandre/whitepaper-omnext
2 Também disponível em http://structure101.com/static-
content/pages/resources/documents/mitre-architecture-report.pdf

3. Se fizermos um drill-down dessa fatia de manutenção, 67% podem ser enquadrados
em melhorias para novas necessidades (evolução do produto):
Isso equivale a cerca de 44.89% de esforço total (67% de 67%) focados em
adaptação do sistema original frente a novas necessidades. E isso é sem nem levar
em conta o esforço em arrumar defeitos ao longo do caminho – 21% do gráfico
acima (ou seja, outros 14% do esforço total; 21% de 67%) e os testes (15% do total,
demonstrado no primeiro gráfico).
2) Esforço além de LOC (Lines of Code)
Embora a primeira imagem que se tenha da atividade de software é do programador
codificando as features e algoritmos necessários, o fato é que quanto maior o
sistema, maior é o esforço necessário em atividades complementares como teste e
arquitetura. Segundo dados compilados por Steve McConnel em seu livro de
Software Estimation3, dependendo do tamanho do sistema os esforços com testes
3 https://www.amazon.com/Software-Estimation-Demystifying-Developer-
Practices-ebook/dp/B00JDMPOVQ/

4. chegam a ocupar 37% do esforço total, e outros 19% com Arquitetura, conforme a
tabela 21-1 a seguir.
O fenômeno acima se deve ao que é conhecido como “diseconomy of scale” – o
aumento do gasto de forma superior a linear com o aumento do output. Na área de
software, os estudos Cocomo II demonstram essa “diseconomy of scale” em termos
de esforço total versus o tamanho do sistema:
Vale salientar que a manutenção evolutiva (44% de esforço, visto anteriormente)
demanda um constante trabalho de re-arquitetura, o que significa que esses custos

5. não somem ao longo do tempo. Similarmente, novas perturbações na base de código
necessitam atenção dobrada quanto à qualidade e testes, e por isso o alto
investimento necessário nesses testes. Vale salientar também que os dados acima
terminam em um sistema com 500 mil linhas de código (500 KLOC). No caso de
sistemas modernos com milhões de linhas de código a tendência é aumentar mais
ainda o esforço com arquitetura e testes, seguindo a tendência da tabela.
3) Defeitos e o Custo da Qualidade
Mas e qual é o custo esperado para detectar e remover os defeitos? Já vimos que
cerca de 14% do esforço se dá corrigindo esses defeitos. Vimos também que cerca
de 37% de esforço é o previsto com testes no caso de sistemas com 500KLOC. Isso
ocorre devido à densidade de defeitos esperada, conforme médias da nossa
indústria na tabela a seguir:
Segundo o estudo acima, em novos sistemas com 500KLOC a taxa de defeitos a ser
encontrada após a codificação pode variar de 4 a 100 defeitos a cada mil linhas de
código (ou seja, podemos chegar a 50.000 defeitos em um sistema com 500KLOC!!!).
No caso de novas funcionalidades, medidas por ponto de função, a taxa de defeitos
da indústria4 é:
4 Segundo estudo de Capers Jones, compilado no livro Software Estimation de Steve
McConnel.

6. Ou seja: em uma entrega de 200 pontos de função, esperam-se 1.000 defeitos!
Um erro comum é assumir que essa taxa seja constante (numDefeitos = 5*numPF),
independentemente do tamanho do sistema. Capers Jones recomenda5 usar um
expoente de 1.25 para que a fórmula reflita a não-linearidade da complexidade com
o tamanho dos sistemas, o que gera a fórmula: numDefeitos = numPF ˆ 1.25. Isso
significa que o fator 5:1 da tabela 21-10 na verdade sobe muito, conforme exemplos
abaixo:
Total de Pontos de Função Número de Defeitos Esperados
(PFˆ1.25)
Fator (defeitos:PF)
1.000 5.623 5.6 : 1
5.000 42.044 8.4 : 1
15.000 16.6002 11 : 1
50.000 747.674 14.95 : 1
Em outras palavras: a taxa de defeitos por PF cresce exponencialmente (e não
linearmente), atingindo taxas 3X maiores em sistemas grandes quando comparado a
sistemas menores (14.95 é aproximadamente 3 X 5). O que pode ser feito para
combater essa diminuição exponencial da qualidade com o tamanho do projeto
greenfield6?
Obviamente há técnicas variadas de redução e detecção de defeitos, e a adoção das
mesmas envolve custos. Dentre as principais técnicas e efetividade correspondente,
destacam-se:
5 http://rbcs-us.com/site/assets/files/1337/measuring-defect-potentials-and-
defect-removal-efficiency.pdf
6 Greenfield pois se aplica a um novo projeto sendo feito do zero. Para projetos de
manutenção sobre uma base de código já existente sabe-se que o problema aumenta
mais ainda, embora não tenhamos localizado na bibliografia uma quantificação
precisa.

7. Esses esforços confirmam o custo da qualidade. O tempo extra investido com testes
unitários, code reviews, code inspections, testes de integração etc é necessário a cada
Sprint, a cada Release; é um custo recorrente. Por exemplo, para remover 84% dos
defeitos7, tal investimento se desdobraria tipicamente da seguinte forma:
7 Para ilustrar: em 2008 a média de remoção de defeitos da indústria dos EUA era de
85% segundo Capers Jones em http://rbcs-
us.com/site/assets/files/1337/measuring-defect-potentials-and-defect-removal-
efficiency.pdf

8. Note que, ainda assim, teríamos 792 defeitos nesse conjunto de 1.000 pontos de
função. Para aumentar ainda mais a qualidade e remover 95% dos defeitos,
teríamos a necessidade de investir mais esforço ainda e distribuir o nosso
investimento da seguinte forma:
Note que, ainda assim, teríamos 226 defeitos nesses 1.000 pontos de função, mesmo
com todo o esforço extra investido. Na nossa indústria almeja-se o “defeito zero”,

9. mas o fato é que ainda estamos longe desse sonho, mesmo com bastante esforço
investido.
Mas como quantificar a quantidade de testes necessários? Segundo Capers Jones8, o
número de test cases recomendado é exponencialmente proporcional ao número de
pontos de função de um sistema, seguindo a fórmula: numTestCases = numPF ^1.2.
Exemplo:
Total de Pontos de Função Número de Test Cases (PFˆ1.2) Fator (test cases:PF)
1.000 3.981 3.9 : 1
5.000 27.464 5.49 : 1
15.000 102.638 6.84 : 1
50.000 435.275 8.7 : 1
Em outras palavras: a quantidade de test cases recomendada por PF cresce
exponencialmente (e não linearmente) com o tamanho do sistema, atingindo taxas
2X maiores em sistemas grandes quando comparado a sistemas menores (8.7 é
aproximadamente 2 X 3.9).
Para aumentar a taxa de detecção de erros de 95% para 99%, segundo Capers
Jones9 seria necessário inspecionar manualmente 100% dos itens e aumentar os test
cases em mais 20%.
É preciso frisar também que à medida que sistemas são disponibilizados a um maior
número de usuários – principalmente com a democratização do acesso a Internet e a
migração dos sistemas para tecnologias Web e Cloud em geral – esses ficam sob um
maior escrutínio de usuários. Aumenta a quantidade de problemas constatados, mas
não por um aumento de defeitos, e sim por uma maior probabilidade de executar
combinações de dados ou use cases nunca antes exercitados. A necessidade de
escalabilidade também traz a necessidade de mais tecnologias – mais complexidade
– para lidar com performance, tais como servidores de cache (Redis, memcache),
réplicas de bases de dados, sincronizações de bases federadas, servidores
redundantes e diversas práticas necessárias para alta disponibilidade e
escalabilidade, que abordaremos mais adiante. É inevitável: com a popularidade
vem a complexidade e aumento de custos. Um caso extremo sendo o Facebook, que
atualmente conta não apenas com diversas máquinas em Cloud, mas na verdade
com diversos datacenters espalhados pelo mundo10.
8 http://rbcs-us.com/site/assets/files/1337/measuring-defect-potentials-and-
defect-removal-efficiency.pdf
9 http://rbcs-us.com/site/assets/files/1337/measuring-defect-potentials-and-
defect-removal-efficiency.pdf
10 http://www.datacenterknowledge.com/the-facebook-data-center-faq/

10. Ou seja, além do investimento com pessoas realizando atividades que reduzem os
defeitos do produto, o fato é que há toda uma infraestrutura de hardware e software
por trás, necessária para dar suporte às atividades de redução de defeitos elencadas
acima. Essa infraestrutura, claro, é administrada por pessoas (SysAdmins, DevOps,
DBAs, etc) que disponibilizam toda uma plataforma 24/7 para manter isso em
operação.
4) Infraestrutura para Evolução com Qualidade
Se olharmos a estrutura de times defendida por uma framework Ágil de Larga
Escala como o SAFe, podemos verificar a presença do System Team:
http://www.scaledagileframework.com/system-team/ . É um reconhecimento de
que manter a cadência de entregas de Releases particionadas em Sprints e
mantendo os defeitos sob controle requer todo um investimento em time e
infraestrutura. Tal time é responsável não somente pelas atividades de testes - já
abordada anteriormente - mas também um conjunto de atividades conhecida como
Release Engineering11 (por vezes abreviada como RelEng). Podemos elencar as
seguintes necessidades de investimento:
• Máquinas virtuais disponíveis numa estrutura de cloud interna, permitindo
que desenvolvedores possam instanciar ambientes Sandbox de DEV ou
STAGING para rodar seus testes unitários e de aceitação antes de efetuar
commit.
• DevOps para administrar essa plataforma - como por exemplo OpenShift
e/ou OpenStack – dando suporte aos desenvolvedores operarem no modo
self-serve, provisionando novas instâncias de bancos de dados, servlet
containers, servidores de build contínuo como Jenkins e similares, etc.
• Hardware robusto – por exemplo, Blades – capazes de sustentar toda essa
operação com CPU, I/O e Storage adequados e o respectivo suporte de NO-
BREAKs industriais.
• Sysadmins responsáveis pela configuração e manutenção das Blades,
roteadores CISCO, Storage, back-ups, VPNs e demais infraestrutura que dá
suporte aos DevOps se preocuparem exclusivamente em atender às
necessidades dos desenvolvedores.
• Licenciamento de sistemas operacionais e bancos de dados consomem uma
boa fatia de investimento. Por exemplo, um sistema federado com 5
máquinas Windows diferentes e 3 bancos de dados para rodar uma bateria
de testes de integração de um changeset – essencial para detecção de
problemas conforme vimos anteriormente – requer múltiplas licenças
válidas para os vários sistemas operacionais e os bancos de dados a serem
levantados. Multiplique isso pelo número de desenvolvedores codificando e
testando concorrentemente, cada qual com um sandbox, e o investimento em
11 https://en.wikipedia.org/wiki/Release_engineering

11. licenciamento e hardware torna-se bastante elevado. No caso de testes de
regressão de performance necessita-se instanciar máquinas com um número
de processadores e RAM similar aos de produção, o que encarece o
licenciamento e a plataforma de hardware necessária (mais lâminas na
Blade, mais storage, mais RAM, mais processadores, etc).
• Ferramentas de controle de qualidade de software. Por exemplo, SciTools
Understand12 para controle de métricas, Structure 10113 para controle de
arquitetura. Essas ferramentas possuem licenciamento por máquina e
requerem updates anuais e contratos de manutenção. No caso de
disponibilização das mesmas não só no servidor de build quanto nas
máquinas dos arquitetos, isso requer investimento extra substancial. Mas é o
uso das mesmas que permite controlar a entropia do software, impedindo a
descaracterização da arquitetura original a qual elevaria a taxa de defeitos.
• Treinamentos dos profissionais envolvidos requer um investimento
recorrente. Cursos e certificações nas diversas ferramentas, sistemas
operacionais, bancos de dados, hardware etc são fundamentais para fornecer
uma infraestrutura de alta disponibilidade e eficiência.
Vale lembrar que em muitos casos uma cloud terceirizada como Microsoft Azure ou
Amazon AWS não é viável por conta de legislação e/ou privacidade dos dados. Mas
mesmo quando são viáveis, diversos dos custos acima ainda assim se aplicam.
5) Customização = Complexidade = Custo Extra
Os fatores já apresentados aqui se aplicam tanto a softwares “de prateleira” (shrink-
wrap) como Word, Excel, Waze etc quanto a softwares customizados para clientes
específicos (CRMs customizados, ERPs customizados, etc). Porém, há de se
mencionar que o impacto (e consequentemente custo) dessas customizações para
clientes diferentes é incrivelmente alto. Mas por que isso ocorre?
Embora uma visão superficial possa sugerir que a grande maioria do software
customizado é a mesma, com “apenas alguns ifs em lugares estratégicos, com rotinas
específicas para as features customizadas”, o fato é que software não é linear como
uma parede onde se coloca apenas mais um tijolo, sem efeito colateral na parede
existente. Cada if extra inserido para comportar um caso especial para o cliente A ou
B abre no mínimo duas possibilidades distintas de execução (entrando no if ou não
entrando no if). Um programa com 1 if tem duas rotas possíveis de execução. Um
programa com 2 ifs possui 4 rotas de execução, e assim por diante. Isso significa que
12 https://scitools.com
13 http://structure101.com

12. um programa com apenas 32 ifs teria mais de 4 bilhões14 de rotas diferentes de
execução, necessitando 4 bilhões de testes para exercitar todas as possíveis
combinações desses fluxos de execução15. Hoje sabemos da forte correlação entre
essa quantidade de ifs e a taxa de bugs e custos de manutenção e testes:
Complexidade Ciclomática ou McCabe16. Essa medida tem sido usada em nossa
indústria como principal indicador de dificuldade de manutenção de software17.
Sabe-se que essas “condições especiais” (customizações) contribuem em muito à
diminuição de produtividade por consequência do aumento de ifs em sistemas com
alto grau de customização para clientes diferentes, conforme a tabela abaixo:
14 2ˆ32 = 4.294.967.296
15 Isso sem considerar variações nos dados de entrada, o que aumentaria em muito
esses números de testes necessários.
16 McCabe,Tom, 1976. “A Complexity Measure,” IEEE Transactions on Software
Engineering, Volume SE-2, Number 12 (December 1976), pp. 308–320.
17 Ward,WilliamT., 1989b. “Software Defect Prevention Using McCabe’s Complexity
Metric,” Hewlett Packard Journal, April 1989, pp. 64–68.

13. Podemos ver que, por exemplo, para “Internet Systems (public)”, a produtividade de
1.500LOC/mês/pessoa em um sistema de 10KLOC (sistema pequeno) cai para
200LOC/mês/pessoa em um sistema de 250KLOC – e a tendência é piorar ainda
mais em sistemas com milhões de linhas de código.
No caso de aplicações de missão crítica, pode-se notar um custo maior ainda. Na
tabela 5-2 acima, contraste “Command and Control” (missão crítica) com “Internet
Systems (public)”18: constata-se uma produtividade de cerca de 3 vezes menos! Esse
18 Mais recentemente, devido a alta escalabilidade, até mesmo sistemas de internet
têm-se considerado de missão crítica: uma pausa de 15mins no Groupon significa

14. é o reflexo de todo o overhead necessário para se especificar, codificar, inspecionar e
testar com muito maior rigidez conforme demandam tais aplicações de missão
crítica. Veja que no caso extremo de “Avionics”, chega-se a um custo de 5...7 vezes
maior que “Internet Systems (public)”, com uma produtividade de apenas
40LOC/mês/pessoa em sistemas de 250KLOC. Nos sistemas Avionics modernos com
milhões de linhas de código, a tendência é só diminuir essa produtividade.
Conforme disse Ray Ozzie, ex Microsoft Chief Architect, “Complexity Kills”:
Complexity kills. Complexity sucks the life out of users, developers and IT. Complexity
makes products difficult to plan, build, test and use. Complexity introduces security
challenges. Complexity causes administrator frustration.
And as time goes on and as software products mature – even with the best of intent –
complexity is inescapable.19
A mensagem é clara: menos customizações permitem maior simplicidade (menos
ifs) e maior foco. Nota-se que esta é a abordagem da Apple com seu OS/X, o qual
precisa rodar corretamente apenas nos hardwares fabricados pela própria empresa.
Em contrapartida temos o problema do Windows com sua necessidade de suportar
milhares de configurações de hardware distintas, aumentando em muito a
probabilidade de inserção de defeitos e a necessidade de investimento muito alto
para controle de qualidade – ou deixar passar mais bugs, resultando nas infames
telas azuis (“Blue Screen of Death”) nos casos de crash, que tanto denegriram a
imagem de qualidade da Microsoft.
Com softwares customizados o problema é exacerbado pois não se tratam de
customizações periféricas com drivers externos ao sistema principal; tratam-se de
customizações no cerne dos sistemas em si. Como se o Windows não apenas
precisasse rodar em equipamentos HP e IBM, mas que o Internet Explorer se
comportasse de forma substancialmente diferente na NASA ou no MIT ou na GE, por
customizações feitas para essas corporações. Na prática teríamos, compilados
monoliticamente em apenas 1 Internet Explorer, 3 IEs diferentes: 1 para a NASA, 1
para o MIT e 1 para a GE – com o agravante da complexidade extra e dos efeitos
colaterais deles entre si, coexistindo numa mesma base de código fonte e em
runtime.
Vale então ressaltar que a economia pela comunalidade de código é aparente – cada
variação do software customizado vai requerer mais profissionais, muito mais code
uma perda de faturamento de US$175.000,00 segundo
https://engineering.groupon.com/2016/misc/processing-payments-at-scale/
19 http://www.zdnet.com/article/complexity-kills-can-microsoft-and-all-of-it-
simplify/

15. reviews, mais infraestrutura de build20 e mais testes pois aumenta
exponencialmente o risco, conforme vimos anteriormente (McCabe).
6) Inovação: Pesquisa, Insucessos e Pivotagem
Com a maior disseminação de práticas Lean e seu processo de PDCA aplicado no
nicho de start-ups, tem-se hoje uma maior consciência da necessidade de investir em
pesquisa, experimentos e pivotar no caso de experimentos falhos devido a hipóteses
que não se concretizam21. Esse tipo de prática se aplica também a empresas maiores
– as chamadas Lean Enterprises22. Tais experimentos falhos agregam custos na
operação das empresas de software. Exemplo: seria melhor continuar usando Oracle
ou trocar para MongoDB para uma maior escalabilidade? Somente experimentos
com carga elevada e nas use cases reais poderão ajudar a elucidar indagações como
esta, e esses experimentos têm alto custo de realização. Alguns deles chegam a
necessitar toda uma implementação (codificação) para serem realizados, que pode
ou não virar parte do produto. Em grande parte dos casos tais inovações podem
inclusive resultar em ZERO pontos de função sob uma ótica de features observáveis
pelos clientes. Certamente esse tipo de investimento precisa ser diluído no custo da
solução em si. Toda empresa passa por isso mais cedo ou mais tarde. Facebook, por
exemplo, chegou a produzir o próprio compilador PHP para aumentar a
performance de sua plataforma web23. No caso da Intuit, por exemplo, os
investimentos em inovação se desdobram da seguinte forma24:
20 Exemplo: o cliente A roda em Oracle e o cliente B roda em SQL SERVER. Isso
requer refazer scripts de migração, repensar índices, rodar todos os testes contra os
2 bancos, etc. Todo o código existente – comum ou não – precisa ser avaliado do
zero, como se faz em um novo sistema individual não customizado.
21 http://theleanstartup.com/book
22 https://www.amazon.com/Lean-Enterprise-Performance-Organizations-
Innovate/dp/1449368425
23 https://www.facebook.com/notes/facebook-engineering/the-hiphop-virtual-
machine/10150415177928920/
24 Fonte: livro Lean Enterprise

16. A mensagem é clara: investir em inovação é inevitável para empresas que se
mantêm relevantes e competitivas no mercado. Em alguns casos, investimentos da
ordem de 40% precisam ser efetuados.
7) Escalabilidade: A Inovação Inevitável
Dentre as inovações que as empresas de software precisam incorporar mais cedo ou
mais tarde é o suporte à escalabilidade. Com a digitalização da sociedade
aumentando, o número de usuários que acessam os sistemas chega a crescer várias
ordens de grandeza. Um exemplo extremo já citado aqui é o Facebook, em 2016 com
1.71 bilhões de usuários ativos por mês25. Conforme já mencionamos, essa
escalabilidade vem com um custo – até mesmo datacenters próprios. Mas e que
outros custos (além de hardware) são de se esperar com a escalabilidade?
Destacamos os principais:
• Arquiteto de escalabilidade. Esse tipo de profissional é indispensável em
times com sistemas escaláveis26, sempre antevendo os impactos de
performance no sistema. Performance com escalabilidade é tipicamente um
requisito não funcional, que não conta como ponto de função, mas cuja
ausência pode significar o colapso da solução de software. Conforme
Abbott27, esse profissional deve lançar mão de técnicas de “Fault Isolative
Architecture Structures” dentre tantas outras (capítulo 21).
• Desenvolvedores Sênior em maior densidade, uma vez que algoritmos e
queries precisam ser muito bem projetados para que novas features na
manutenção adaptativa não impactem negativamente a performance do
sistema rodando28. Em outros casos, soluções precisam ser re-arquitetadas
diversas vezes para acompanhar as demandas de escalabilidade, conforme
casos do Twitter, Facebook, Instagram, Pinterest e outros.
• Infra Extra e Profissionais Extra de Teste de Escalabilidade. Conforme já
mencionamos, a infraestrutura para testes em STAGING tem que ser capaz de
25 https://www.statista.com/statistics/264810/number-of-monthly-active-
facebook-users-worldwide/
26 https://www.amazon.com/Scalability-Rules-Principles-Scaling-
Sites/dp/0321753887/
27 https://www.amazon.com/Art-Scalability-Architecture-Organizations-
Enterprise/dp/0134032802
28 Caso real: algo tão simples como adicionar um campo DATE no Oracle pode
praticamente parar um sistema devido à baixa performance de buscas no caso do
campo permitir NULL. Esse campo jamais será indexado no Oracle, necessitando
Sequential Table Scans. Um professional junior ou pleno raramente possui esse tipo
de conhecimento.

17. emular o setup escalável de PRODUCTION. Isso significa o mesmo número de
máquinas, bases de dados, memória etc em testes de carga. Há necessidade
de profissionais capazes de levantar todo esse setup e exercitar os testes de
aceitação e regressão. Mais usuários significa maior probabilidade de achar
bugs, e consequentemente maior necessidade de testes e testadores. Achar
84% dos erros é menos custoso do que de achar 95% dos erros, e assim por
diante (99% dos erros necessitando um esforço muito além, conforme visto
aqui). Tais profissionais precisam ter fluência com ferramentas de teste de
escalabilidade como JMeter29, tsung30, locust31 dentre outros, com
conhecimento de probabilidade e estatística para saberem montar
experimentos representativos e interpretar os resultados.
• DBAs de Escalabilidade. Com o aumento da carga nos sistemas surge a
necessidade de termos estratégias de maior performance com bancos de
dados. Uma delas é a eliminação de locks nas consultas através da utilização
de réplicas read-only (ou followers na nomenclatura Heroku32). Outra técnica
importante é o uso de sharding de bancos, muito bem explicada pelos
engenheiros da Pinterest33 - os quais chegaram a usar 88 bancos de dados
MySQL em 201334. Esse tipo de know-how não é fácil de encontrar nos DBAs
regulares no mercado.
• Engenheiros de Monitoramento de Escalabilidade. Através do uso de
APMs35 tais como New Relic, esse perfil de profissional precisa estar
familiarizado com termos como apdex36 dentre outros, observando a
performance dos sistemas não só na média mas também nos percentis 95% e
99%. Por exemplo, um profissional menos capacitado pode considerar o
gráfico de APM abaixo como perfeitamente tranquilo:
29 http://jmeter.apache.org
30 http://tsung.erlang-projects.org
31 http://locust.io
32 https://devcenter.heroku.com/articles/heroku-postgres-follower-databases
33 https://engineering.pinterest.com/blog/sharding-pinterest-how-we-scaled-our-
mysql-fleet
34 http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-
billions-of-page-views-a.html
35 https://en.wikipedia.org/wiki/Application_performance_management
36 https://docs.newrelic.com/docs/apm/new-relic-apm/apdex/apdex-measuring-
user-satisfaction

18. Porém, um profissional diferenciado (mais caro) saberá que precisa observar
não apenas a média (115ms), mas estará atento às inconsistências de
performance segundo os percentis, como no gráfico abaixo:
O gráfico acima mostra que embora a média de resposta desse servidor
esteja em 115ms, há muita variação de performance, chegando a 1000ms em
alguns casos, o que afeta a satisfação dos usuários. Isso se reflete na oscilação
apdex, abaixo:
Apenas profissionais diferenciados serão capazes de perceber esse tipo de
anomalia e articular com o time de Desenvolvimento e os Product Owners
para incorporar mudanças de arquitetura para um melhor apdex e

19. consequentemente maior escalabilidade - sabendo-se que não há como
converter esse esforço em pontos de função; são requisitos não funcionais.
Em alguns casos extremos, frameworks e utilitários precisam ser codificados
e implantados para capturar todo esse trace. O Twitter, por exemplo,
precisou investir esforço em zipkin37 para rastrear os gargalos de
performance38. Outras empresas precisam investir em soluções SaaS para
logs e crashes, como Splunk39, Sentry40 , Logentries41 e outros.
• Gestão e Processos para Escalabilidade. Conforme Abbott42, escalabilidade
requer uma mudança de cultura e gestão nas empresas (o que demanda
custos com a mudança dessa cultura), de acordo com a matriz RASCI43
abaixo:
A própria maturidade e complexidade dos processos sobe para lidar com a
qualidade frente à escalabilidade, conforme Abbott no diagrama a seguir44:
37 https://github.com/openzipkin/zipkin
38 http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-
with-150m-active-users.html
39 https://www.splunk.com
40 https://sentry.io
41 https://logentries.com
42 https://www.amazon.com/Art-Scalability-Architecture-Organizations-
Enterprise/dp/0134032802
43 Responsible, Accountable, Supportive, Consulted, Informed.
44 Capítulo 7, “Why Processes are Critical to Scale”.

20. Com esse aumento de complexidade, sobem os custos recorrentes.
A essência do problema é simples: com uma maior operação, maior suporte à
escalabilidade é necessário, de forma evolutiva. O desafio para empresas
competitivas é escalar a operação de forma não linear com o crescimento de
usuários, ou os custos seriam proibitivos. Conforme Raymond Blum, da Google:
“[you can’t] scale effort with capacity”45. Ou seja, embora os custos adicionais
com um maior número de usuários precise ser repassado ao cliente, o fato é que
um aumento em 100X no número de usuários não pode acarretar em aumento
de custo operacional de 100X, ou a operação não será economicamente viável. É
preciso atingir uma operação onde o custo da escalabilidade seja, por exemplo,
log(N) em relação ao número de usuários ou transações, com modelos de
cobrança que sejam intuitivos para os clientes e de melhor aceitação. Alguns
exemplos da indústria:
• Unidades de armazenamento: Sentry, dentre outros, utiliza o número de
eventos por dia como unidade de escalabilidade relativa ao número de
usuários e o plano correspondente, com limite também na duração da
retenção46:
• Unidades de processamento: Empresas como Oracle cobram por cores
usados no servidor47, conforme a fórmula: (number of cores)*(multi-core
factor). Os fatores são diferentes conforme a capacidade da máquina, de tal
forma a tornar o pagamento proporcional ao maior uso e consequentemente
45 http://highscalability.com/blog/2014/6/4/the-secret-of-scaling-you-cant-
linearly-scale-effort-with-ca.html
46 https://sentry.io/pricing/
47 http://www.orafaq.com/wiki/Oracle_licensing

21. à maior demanda sobre a operação de inovação e qualidade da Oracle para
atender àquele perfil de cliente (maior exigência). É um rateio dos custos
recorrentes sobre a estrutura da Oracle para se ter software de alta
escalabilidade com qualidade.
• Mix: Empresas como New Relic utilizam o conceito de Compute Unit48,
combinando CPU e RAM: (CPU cores + GB of RAM) x number of hours used =
CU. O preço é calculado pelo valor do final em CU, conforme o screenshot a
seguir:
• Usuários e/ou Conexões: Empresas como a Microsoft possuem planos que
cobram por número de conexões aos seus sistemas, as chamadas CAL49
(Client Access License) – não só para servidores Windows mas também para
seu banco SQL Server50. É uma alternativa aos planos por CPU.
É preciso salientar que em diversos sistemas existe uma “deseconomia de escala”: o
ponto em que o aumento de escalabilidade aumenta em muito os custos, e os
sistemas passam a não ser mais lucrativos na forma atual51:
48 https://newrelic.com/application-monitoring/pricing
49 https://www.microsoft.com/en-us/licensing/product-licensing/client-access-
license.aspx , https://blogs.technet.microsoft.com/volume-
licensing/2014/03/10/licensing-how-to-when-do-i-need-a-client-access-license-
cal/
50 http://serverfault.com/questions/120276/how-are-sql-server-cals-counted ,
http://download.microsoft.com/download/6/F/8/6F84A9FE-1E5C-44CC-87BB-
C236BFCBA4DF/SQLServer2008_LicensingGuide.pdf
51 http://www.investopedia.com/terms/d/diseconomiesofscale.asp

22. Nesse ponto uma re-arquitetura precisa ser feita para tornar a plataforma
novamente escalável economicamente para o próximo patamar de uso previsto.
Essa é a estória recorrente de empresas como Twitter, Facebook, Pinterest
conforme já relatado aqui. Mas quais são os principais fatores que influenciam essa
curva?
No estudo “Which Factors Affect Software Projects Maintenance Cost More?”52,
alguns fatores estão atrelados à escalabilidade e disponibilidade53:
Row Indexes Related to the Information of Cost Factors
1 Product Characteristics
2 Required Software Reliability
3 Database Size
4 Complexity Product
5 Computer Characteristics
6 Execution Time Constraint
Os principais fatores são justamente a robustez e performance frente ao número de
usuários54, balizados pela complexidade do produto:
Indexes Related to the
Information of Cost Factors
Very Little Little Normal Much Very Much
Product Characteristics
Required Software Reliability 7.5 7.5 57.5 27.5 0
Database Size 40 30 20 10 0
Product Complexity 0 2.5 10 40 47.5
Computer Characteristics
Execution Time Constraint 0 0 2.5 30 67.5
52 http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3610582/ ,
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3610582/pdf/AIM-21-1-15.pdf
53 A tabela completa se encontra em
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3610582/table/table001/
54 A tabela complete pode ser encontrada em
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3610582/table/table002/

23. Por conta disso, segundo Cocomo II, devem-se utilizar os seguintes “scaling factors”
em relação aos custos:
Note os coeficientes para “Product Complexity”, “Time Constraint” e “Required
Software Availability” – todos atrelados à disponibilidade e escalabilidade da
solução.
Em suma: Estabeleça se sua plataforma é CPU-bound, IO-bound, storage-bound ou
uma combinação, definindo planos de cobrança condizentes com a expectativa de
disponibilidade e escalabilidade frente aos seus custos recorrentes para uma
manutenção corretiva, perfectiva e adaptativa com a qualidade esperada pelos seus
clientes.
8) Conclusão
Sistemas de software precisam evoluir e se adaptar e essas constantes mudanças
abalam a integridade da arquitetura original. Para conter essa tendência natural à
decadência, todo um investimento em boas práticas, ferramentas e profissionais
capacitados precisa ser feito, de forma recorrente, com inovação constante. No caso
de softwares customizados, a tendência é o aumento exponencial do risco. Com a
escalabilidade, aumentam ainda mais os custos operacionais e aumenta a exposição
ao risco de mais defeitos serem detectados por uma maior base de usuários. Mas a

24. escalabilidade é apenas um dentre tantos requisitos não funcionais55, não
computáveis com pontos de função56, mas cuja existência e esforço fica evidente nas
bibliotecas Open Source criadas por empresas enquanto implementavam os seus
requisitos funcionais57. Toda essa base de código para requisitos não funcionais
aumenta o custo por pontos de função observáveis em softwares de larga escala.
Cobrimos aqui alguns números da indústria e onde investimentos precisam ser
feitos, e sua ordem de grandeza. O fato é que não há nada de “soft” em “software” –
principalmente de larga escala - e qualquer aumento de qualidade requer
investimento substancial e não linear (geralmente exponencial, conforme vimos
aqui) com o aumento dessa base de código e de usuários. Mas o aumento da
complexidade nas soluções de software é inevitável - afinal, “Software is eating the
World”58.
55 http://www-di.inf.puc-rio.br/~julio/nfr-chung-leite.pdf ,
http://v3.scaledagileframework.com/nonfunctional-requirements/
56 Alternativas incluem SNAP Points (http://fattocs.com/pt/cursos/nossos-
cursos/snap.html), Use Case Points
(https://www.researchgate.net/publication/4200526_Effort_estimation_of_use_cas
es_for_incremental_large-scale_software_development) e outros.
57 http://uber.github.io, https://netflix.github.io ,
https://code.facebook.com/projects/ por exemplo.
58
http://www.wsj.com/articles/SB100014240531119034809045765122509156294
60