Editorial: Custo do firmware

Ultimamente temos ouvido notícias sobre o que um erro de firmware pode acarretar negativamente para empresas. Prejuízo, perda de confiança, má qualidade dos produtos, etc. são alguns exemplos de consequências, resultado de erros/bugs indesejados ou até mesmo de código inserido com a finalidade de se obter indevida vantagem. Isso nos leva a pensar no custo do firmware, o que qualidades ou defeitos do código influenciam direta ou indiretamente no valor agregado do produto.

 

O objetivo do artigo não é quantificar o custo real, mas sim apontar o que pode ser feito para reduzir o valor gasto dentro de um projeto, dado que cada equipe tem um custo.

 

Vamos utilizar aqui alguns valores apresentados pelo Jack Ganssle em seu livro The Art of Designing Embedded Systems. Além disso, vale a pena conferirmos um trecho da entrevista que ele nos concedeu, onde ele discute como é interpretado o conceito de qualidade pelas as empresas, dada a vasta experiência que ele possui na área.

 

Question: Jack, even on current days, a huge amount of companies doesn’t mind about quality, instead they want their projects done now, what do you think about that?

 

Jack Ganssle: Quality is my pet peeve, we just don’t do the things we should be doing to get the quality needed. Toyota had to pay 1.2 billion dollars because of their bad software, and if you think about it, that code is now the most expensive software anyone has ever written. It is true we all need to rush but it will always cost you more. There is a quote that I really like: shortcut makes for a long detours. In the past we could get away with it because our systems were quite simple, but they are a lot more complicated now, so I don’t think we can continue doing things without quality. And the thing is, we know how to do it right, and we choose not to do so. To me that is more like a mortal sin, it is no longer acceptable. We’ve had 30 years to teach us the right way to build embedded systems, and, sooner or later, people are going to start getting really hurt with driverless cars, avionics and even medical instruments. There was a big recall in US a few years ago of infusion pumps, these machines used to inject drug in the blood, due to firmware errors and other problems.

 

 

Qual é o custo do firmware?

 

Um estudo realizado internamente pela Bell Labs revelou que para se obter de 1 a 2 defeitos a cada 1.000 linhas de código de seus projetos, precisa-se produzir de 150 a 300 linhas de código por mês. Considerando que os salários e gastos pertinentes ao desenvolvimento, gera-se um custo de aproximadamente $25~$50 por linha de código.

 

Devem estar se perguntando por que é tão cara uma linha de código. Pois bem, vejam outro exemplo, o software de controle de uma missão com ônibus espacial da NASA, feito pelos engenheiros da IBM. Pode ser considerado um software com “zero erros”, já que apresenta um custo aproximado de $1.000 por linha de código. É o melhor código já escrito então?

 

Quando chega-se ao final de um projeto, é importante se somar todos os custos envolvidos, desde a fase de iniciação (onde os requisitos são elucidados) até a fase de entrega/implementação. Assim popula-se um histórico de projetos e respectivos custos, e percebe-se que os valores estimados estão bem abaixo do realizado. E por quê?

 

E durante todo esse tempo mudanças acontecem, essa é a única certeza num processo de desenvolvimento de software. Pois bem, já que esse dado é conhecido, por que não é preparado um processo de forma a facilitar a mudança? Vamos apontar algumas técnicas que podem lhe ajudar.

 

Mas antes disso, vamos nos familiarizar com a mudança. Quanto ela custa?

 

 

Quanto custa a mudança?

 

O processo de desenvolvimento de software de uma empresa, seja baseado no modelo Waterfall, tradicional (RUP) ou algum ágil, é composto pelas seguintes grandes fases:

  • Elucidação de requisitos;
  • Modelagem;
  • Codificação;
  • Testes;
  • Implantação.

 

O que é de se esperar com relação a um defeito ser encontrado ou pedido de mudança acontecer nessas diferentes fases? A tendência é imaginar que ele aumenta quando essa mudança acontece mais próximo da fase de entrega do projeto. E é isso mesmo o que acontece! Um estudo realizado por Boehm [1] aponta esse fenômeno. Veja a Figura 1.

 

custo do firmware: custo da mudanÇa
Figura 1 - Custo relativo de uma mudança
Fonte: Pressman, R. S., Software Engineering: A Practitioner's Approach, Fifth edition, 2001

  

Por isso que o custo de um bug encontrado em campo é muito mais caro para a empresa do que o mesmo encontrado na fase de desenvolvimento, ou mesmo durante os testes internos. Um dos grandes problemas com relação a um bug encontrado em campo é o sentimento criado pelo cliente com relação ao produto, o que pode ser muito pior para a empresa que o custo resultante da correção do problema.

 

Qual será a razão para que isso aconteça e como evitar ou melhorar o resultado?

 

A resposta é implementar um processo de desenvolvimento de software focado em qualidade. Seja ele baseado no processo tradicional (RUP), espiral, waterfall, ágil, etc. O importante é fazer com que sejam criadas pequenas entregas ao cliente ao longo do desenvolvimento, não somente para mostrar que algo está sendo feito, mas sim para entender, por parte do cliente, se o que está sendo entregue está correto. Tenham em mente que seguir o caminho que o cliente quer é o fundamental.

 

O controle de qualidade do processo garante que isso aconteça, rastreando cada um dos requisitos do projeto com os artefatos entregues. Mas esse controle não contém só esse passo. Podemos listar algumas técnicas que podem ajudar a desenvolver o produto da forma correta, evitando, assim, bugs:

  • Elucidação dos requisitos do projeto;
  • Adotar ferramenta de gerenciamento de configuração e mudanças;
  • Modelar o sistema usando uma arquitetura que atenda os requisitos não-funcionais do projeto;
  • Adotar padrões de codificação;
  • Implementar versionamento de código;
  • Executar inspeções de código.

 

Perguntamos-nos as vezes se chefes realmente entendem software. “Por que você quer perder tempo pensando em planejar/escrever código melhor ao invés de simplesmente escrever mais código?” É um tipo de pergunta que pode vir deles.

 

Código precisa funcionar, mas não somente isso. Ele precisa transmitir as ideias e criatividade do programador por meio de instruções e comentários inteligíveis de forma que outros desenvolvedores da equipe sejam capazes de darem manutenção no projeto. Esse resultado é obtido quando, por exemplo, a equipe adota padrões de codificação.

 

 

Padrões de codificação

 

Este é um detalhe que, quando discutido por uma equipe de desenvolvimento, pode gerar muito conflito entre os seus componentes. Isso porque a forma de se escrever código, esteticamente falando, é particular de cada um. No entanto, quando é desenvolvido um projeto em equipe - não necessariamente dentro de uma empresa, pode ser num grupo de TCC da faculdade - torna-se interessante e efetivo cada um que for agregar código escrever de uma forma padrão. Dessa forma não são criados códigos personalizados, com arquivos contendo estilos os mais diversos possíveis, já que muitos desenvolvedores ajudaram em sua elaboração.

 

Alguns padrões estão disponíveis publicamente, como o Jack Ganssle Standard, Google C++ Style Guide, GNU Coding Standard, SEI CERT C Coding Standard, Mozilla Coding style,  FreeBSD Kernel Style, etc. Outros pagos são muito bons, como o Netrino C e MISRA C. Basta pegar algum ou alguns deles, customizar de acordo com o que a equipe se adequa com mais naturalidade, e estabelecer como meta. Simples! O importante é não haver predomínio de egos ao interesse da equipe, e haver inspeções periódicas do código armazenado no repositório de código do projeto.

 

Veja um exemplo, abaixo, de código ofuscado, vencedor da competição IOCCC (The International Obfuscated C Code Contest). É um código que funciona, mas...

 

custo do firmware: código ofuscado
Figura 2 - Código ofuscado
Fonte: http://www.ioccc.org/2014/endoh1/prog.c

 

O que adianta ter um código que funciona bem, está de acordo com os padrões mais rigorosos de codificação, mas que ninguém sabe onde está? Ou pior, está com todos, mas cuja última versão é diferente em cada um dos computadores. O que acontece, numa empresa que adota esse processo, se o desenvolvedor que possui a versão correta deixa a empresa e resolve apagar tudo por raiva?

 

 

Controle de versão

 

Esse tipo de comportamento foi verificado na FAA (Federal Aviation Administration) em 1999, quando um dos seus funcionários se apossou do código que desenvolveu, que corrigia um problema no controle de tráfego aéreo. Nesse caso, não seria interessante um controle de versão?

 

Um sistema de controle de versão é responsável por criar um banco de dados de software, onde todas as mudanças são registradas, contendo data/hora, responsável e motivo. Quando versões são entregues pela equipe, nesse sistema são criadas estruturas (tags, branches, etc) que identificam porções de código. Podemos criar, a partir de uma revisão, uma tag/branch da última versão, por exemplo.

 

Exemplos de sistemas de versionamento de código são o SVN (Subversion), git, mercurial, etc.

 

 

Inspeção de código

 

Vamos considerar aqui técnicas de inspeção de código que lhe agreguem qualidade. Uma boa forma de se explicar como se inspecionar código é por meio de exemplos e processo.

 

O início do projeto ocorre, os requisitos ou a maior parte deles é elucidada, a arquitetura do sistema é desenhada, e chega a hora de escrever código. Um programador consciente vai em busca do sistema de versionamento e do padrão de codificação para poder trabalhar em sintonia com a equipe.

 

Foi dada a tarefa de desenvolver um módulo dada uma interface muito bem definida durante a etapa de design/modelagem. O que fazer para ajudar na qualidade do código agora? Que tal utilizar um compilador em conjunto com uma ferramenta de análise estática de código? Dessa forma garantimos um código sem warning e aderente a um padrão de codificação do mercado (ou customizado).

 

Análises dinâmicas também podem ser realizadas, tais como análise do uso de memória RAM, stack e heap.

 

O primeiro passo foi dado, mas antes de versionar o código escrito, é importante executar uma inspeção de caixa-branca, por meio, por exemplo, de peer-review, onde a equipe vai analisar o código escrito e indicar se está correto ou se mudanças podem ser feitas para se ter um módulo melhor.

 

Agora que as ferramentas indicaram que o código está correto e que o time apontou que está sendo seguido o caminho correto, pode-se versionar o código e seguir o desenvolvimento. Esse processo é repetitivo, e pode estar presente dentro de um processo maior, seja ele tradicional ou ágil. No último as iterações são mais frequentes, o que faz com que a equipe tenha conhecimento mais cedo da evolução do código e o cliente tenha acesso às pequenas entregas evolutivas.

 

 

Casos reais

 

Alguns bugs sérios apareceram ultimamente. Vamos listar alguns e discutir quais foram as suas consequências.

 

Heartbleed bug

 

heartbleed

 

Este é o bug da biblioteca OpenSSL, implementação do protocolo TLS, sendo vulnerável tanto um cliente quanto um servidor que faça uso dela.

 

O bug foi inserido em dezembro/2011 no repositório da biblioteca OpenSSL, mas somente em 14/03/2012 foi liberada a versão 1.0.1, contendo a extensão de heartbeat. A divulgação pública do bug ocorreu em 07/04/2014, com 17% dos servidores web afetados.

 

O problema apontado é a imprópria validação de dados de entrada, devido à errada verificação de limites de buffers na implementação do heartbeat da biblioteca. Isso causa uma vulnerabilidade conhecida como buffer over read, onde uma quantidade maior de dados pode ser lida do que é esperado e permitido.

 

Veja um cenário normal e malicioso com relação ao uso da biblioteca.

 

custo do firmware: heartbeat usage
Figura 3 - Simulação do bug de heartbeat
Fonte: http://en.wikipedia.org/wiki/Heartbleed

 

A solução para este bug pode ser conferida em:

 

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902

 

Veja o diff do código: 

 

 

Toyota Camry bug

 

custo do firmware: toyota camry
Figura 4 - Acidente com o Toyota Camry

 

O sintoma do bug detectado foi uma aceleração indesejada do carro, que acarretou em 1 morte em Set/2011. O problema está presente na ECM (Engine Control Module) para controle da “borboleta” do motor.

 

Na placa responsável por este gerenciamento, um RTOS é utilizado e dezenas de milhares de linhas de código compõe o projeto. Resultado de uma consultoria pedida pela EDN ao consultor Michael Barr (CTO e sócio-fundador do Barr Group), alguns problemas foram encontrados no projeto: 

  • Stack overflow (41% → 94% de uso real);
  • Não houve monitoração de uso dinâmico da stack;
  • Unsafe casting;
  • Race conditions entre tarefas;
  • 11.000 variáveis globais (código “spaghetti”);
  • Uso parcial do padrão MISRA-C 1998, adotando somente 11 regras (de 93 possíveis), sendo 5 delas violadas.

 

 

Conclusão

 

O importante para o processo de desenvolvimento evoluir é ter a equipe sintonizada nos objetivos e nas mudanças realizadas no projeto. Sendo assim, um ajudando o outro, com inspeções, dificilmente cria-se donos de códigos, e bugs são mais difíceis de serem criados.

 

Uma vez que testes internos façam uma varredura completa no produto, tentando criar cenários de testes que vão ser reproduzidos em campo, tornam o processo mais robusto e, por consequência o produto.

 

Valores de custos não temos com exatidão, isso vai depender fortemente da equipe de desenvolvimento.

 

 

Agradecimentos

 

Escreveram e revisaram este texto: Fábio Souza e Henrique Rossi.

 

 

Referências

 

[1] Boehm, B., Software Engineering Economics, Prentice-Hall, 1981.

[2] Pressman, R. S., Software Engineering: A Practitioner's Approach, Fifth edition, 2001

[3] Firmware basics for the boss

[4] http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences

NEWSLETTER

Receba os melhores conteúdos sobre sistemas eletrônicos embarcados, dicas, tutoriais e promoções.

Obrigado! Sua inscrição foi um sucesso.

Ops, algo deu errado. Por favor tente novamente.

16
Deixe um comentário

avatar
 
8 Comment threads
8 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
10 Comment authors
MariaCireneu Tanan Tonioni RibeiroRonaldo NunezMarcelo JoAndré Castelan Recent comment authors
  Notificações  
recentes antigos mais votados
Notificar
Maria
Visitante
Maria

Parabéns pelo Texto! excelente!

Cireneu Tanan Tonioni Ribeiro
Membro
Cireneu Tanan Tonioni Ribeiro

Excelente post, gostei muito!
Abraço!
Cireneu

Ronaldo Nunez
Membro
Ronaldo Nunez

Parabéns pelo excelente post! Lembro de meu professor durante as aulas de "teste de software" perguntando se as empresas em que trabalhavamos implementavam algum teste nos softwares desenvolvidos. A resposta, sem surpresa alguma, foi não para a maioria das empresas. E por quê? Pelos motivos apontados ao longo do texto: é o "chefe" que está preocupado com a entrega e não com a qualidade, é o programador que quer se mostrar o 'super-herói' que entrega tudo no prazo, e a falta de respeito com o cliente e por ai vai... Ao meu ver, o problem é que as pessoas querem manter métodos tradicionais de gestão de projetos/negócios em um mundo que muda muito rapidamente. Para alguns mercados, demorar mais que seis meses desenvolvendo um produto pode te deixar defasado a ponto de não se conseguir vender o que está sendo… Leia mais »

Henrique Rossi
Admin
Henrique Rossi

Olá Ronaldo! Muito obrigado pelos comentários e elogios.

Precisamos fomentar esse assunto, pois como disse, a demanda do nosso mercado é outra, precisamos de resultado a curto prazo. Se não entregarmos valor agregado rapidamente, perdemos lugar no mercado realmente.

Vejo a onda de novas SBCs e kits de desenvolvimento, lançados constantemente, numa velocidade incrível, sintoma dessa demanda.

Abarços,
Henrique

André Castelan
Visitante
André Castelan

Bacana o artigo e o livro eh muito bom! O que voces acham que falta para a industria de firmware chegar na produtividade / ferramentas que a industria de software mais alto nivel tem? Sera que sao dois bichos diferentes mesmo? Eu acabei de ler o livro http://www.amazon.com/The-Phoenix-Project-Helping-Business/dp/0988262592 que recomendo para todos. Basicamente no final ele faz um levantamento comparando lucro e valor da empresa com numero de deploys por tempo. As empresas que mais demoram para lancar um produto / uma correcao de bug sao as com menor valor de mercado. Temos empresas como a Amazon que lancam um bugfix / uma feature a mais 9 mil vezes por dia e empresas como as mais tradicionais que demoram 6 meses - 1 ano. Acho isso muito verdade, basta ver os valores de mercado de empresas de embarcados vs empresas… Leia mais »

Marcelo Jo
Membro
Marcelo Jo

Eu acho que ainda os mercados são diferentes principalmente no que se diz a respeito de expectativa da qualidade de um produto. Veja, se um software tem um bug que gera uma exceção e q no pior caso fecha a janela, poucas pessoas devolverão o produto. Agora, imagina um leitor blueray, um micro-ondas ou algum sistema embarcados que funciona e que de tempos em tempos trava. O produto é tido como ruim e muito provavelmente terá uma péssima reputação e logo péssimas vendas. Logo eu vejo que cada release feito num sistema embarcado desse tipo tem q ter um cuidado maior pra evitar tais problemas. Ao mesmo tempo, atualmente vejo que existem muitos sistemas que vc não pode distinguir se é embarcado ou não. Ainda tais sistemas podem ser usados em mercados onde a tolerância ao erro seja maior ou… Leia mais »

André Castelan
Visitante
André Castelan

Com certeza, mas hoje em dia tem muito blue ray conectado na internet ja. Se for um problema de firmware, o que impossibilita uma atualizacao quando botar ele na net? Se voce tiver um sistema onde eh facil fazer deploy da atualizacao, ela pode ser feita varias vezes num soh dia, achou o bug, corrige, testa, manda atualizacao para o cliente. Um erro de software pode ser tao caro e desastroso quanto um de hardware, por exemplo, bancos, qualquer coisa que lide com $$ direta ou indiretamente. Algo que fica claro no livro tambem eh que quanto mais tempo se demora para lancar algo mais bugs vai ter e mais tempo vao demorar para serem corrigidos. Tem que encurtar o loop, lancar a todo momento, colher feedbacks e aprimorar. Muito do que o movimento lean start up pregal Cada vez… Leia mais »

Marcelo Jo
Membro
Marcelo Jo

Tá certo! Aí entra o bom senso que mencionei no final. Acho que como tudo na vida, não tem um método que cubra todas as necessidades. O trabalho de um desenvolvedor é ter essa análise crítica e escolher os melhores métodos e ferramentas pra sua necessidade/mercado.
Hoje tem sistemas embarcados conectados na internet como vc disse, assim como sistema embarcados que estão em marte ou ainda sistemas embarcados dentro do corpo humano.
Todo esse papo me lembrou uma aula durante a graduação onde o professor nos questionou a definição de qualidade, citando o exemplo do relógio rolex com garantia pra vida inteira que parou de funcionar depois de 65 anos contra o relógio xing-ling com garantia de 2 meses que funcionou 6 meses.

Jhonatan Casale
Membro
Jhonatan Casale

Parabéns autores pelo post, conteúdo muito relevante para cair um pouco a ficha de que não basta só entregar código, a qualidade do que entregamos diz muito de nossa postura profissional.

Henrique Rossi
Admin
Henrique Rossi

Perfeitamente Jhonatan! São esses pontos pelos quais seremos lembrados. O importante é sabermos pesar os dois caminhos para seguir no correto dentro de um projeto.

Dimitrius Borges
Membro
Dimitrius Borges

Passei, ao menos, metade de um período de uma matéria na faculdade estudando apenas custos de um software. Mas no sentido básico mesmo: O quanto custa escrever um código bem feito. Foi esclarecedor em dois sentidos: Primeiro mostrou o quão importante é o desenvolvimento organizado/padronizado/planejado de um software, por mais simples que ele seja ou pareça ser (o que é o ponto central do artigo de vocês); O segundo ponto é que a brincadeirinha de chamar programador de "Garoto de Programa" tem mesmo um fundo de verdade: resultado rápido, barato e que parece que foi uma boa, mas na verdade não foi não...

EDIT:

Só acrescentando. Sou Engenheiro de Computação e trabalho tanto com hardware quanto com software. A diferença entre as duas áreas é palpável, é muito comum o software ser negligenciado e subestimado em comparação ao hardware.

Henrique Rossi
Admin
Henrique Rossi

Pois é...É mais fácil deixar o software de lado pois sempre dá para mudar. O HW é mais difícil, acabando com maior prioridade às vezes. Entendo o que disse.

Fabio Rueda
Membro
Fabio Rueda

Aos autores... Parabéns pelo post! 🙂 Apenas como sugestão acho que vale a pena incluir neste tópico a recente "falha" da Volkwagen (mesmo sendo intencional). Abraços do amigo

Henrique Rossi
Admin
Henrique Rossi

Muito obrigado pelo elogio Fábio!

Concorco contigo. Vamos avaliar essa sugestão. Abraços

Fernando Luiz Cola
Membro
Fernando Luiz Cola

Parabéns a equipe, ótimo post!
A realidade do mercado é bem essa! Me assusta as vezes como firmware é desenvolvido.
Abraços!

Henrique Rossi
Admin
Henrique Rossi

Muito obrigado pelos elogios Fernando! Esperamos poder ajudar com esse conteúdo.

Abraços,
Henrique