sábado, 16 de fevereiro de 2013

Sobre sistemas críticos, regulamentação de profissões etc...


tl;dr: Regulamentação? Sou contra. A comparação com engenharia, medicina etc... é descabida. Software crítico não é desenvolvido no GitHub por entusiastas. Seu software muito provavelmente não é crítico.

Às vezes ainda ouço discussões sobre regulamentação das profissões de informática. E vejo frequentemente, para justificar a regulamentação, a analogia com os engenheiros. Como quase-engenheiro, afirmo que simplesmente não existe como comparar o trabalho de um engenheiro com o da maioria dos desenvolvedores no aspecto da segurança do produto final.

Se uma estrutura ou um equipamento falharem, milhares de pessoas podem morrer, um país pode parar; para a maioria dos softwares, uma falha muitas vezes será um mero incômodo passageiro. (Desconsiderando gente que enlouquece quando o Facebook cai :)

Já vejo que vão falar em software crítico, então vamos ao que interessa: software crítico - aquele que lida com processos físicos de grande complexidade, vidas, grandes somas de dinheiro, etc... - não é desenvolvido por um profissional solitário: ele é desenvolvido por equipes com gente de várias áreas, que trabalham sob protocolos, legislações e normas extremamente rígidas.

Esse tipo de software passa continuamente por verificação formal, peer review e outros sistemas; uma mudança só é realizada após ficar demonstrado que ela não afeta o funcionamento de nenhuma outra parte do sistema. Testes extensivos são realizados, tanto em simulação quanto em hardware físico (muitas vezes com bancadas de teste completamente automatizadas, sem interação humana). Todas as decisões de projeto são documentadas, conforme mandam normas de órgãos reguladores e sociedades profissionais como a IEEE.

O firmware que vai num carro, num avião ou num robô cirúrgico, em aplicações onde o fabricante pode ser responsabilizado por eventuais falhas que venham a acontecer, muito provavelmente não vai ser desenvolvido por entusiastas colaborando no GitHub e coordenando atividades por um canal de IRC, nem por um time constituído apenas de desenvolvedores: vai ser desenvolvido por uma equipe de engenheiros, físicos, matemáticos entre outros. De forma interdisciplinar, cada profissional trabalhando na área do conhecimento que lhe é pertinente.

Vai ser desenvolvido em conjunto com o hardware, mantendo contato com essa equipe e com os órgãos do governo que fazem a certificação dos sistemas e subsistemas. Vai ser projetado com uma arquitetura robusta e redundante em nível de hardware: mesmo que todos os microprocessadores do meu carro parem, eu terei - ou ao menos devo ter - condições de parar ele no acostamento e acender o pisca-alerta.

O mesmo eu posso dizer do sistema pelo qual passam todas as transações de um banco, do supervisório do sistema elétrico de um país ou da plataforma que coordena todos os processos de uma grande indústria: não são desenvolvimentos que estão ao alcance dos desenvolvedores comuns, e não são projetos onde novos recursos são adicionados a todo instante.

Se sair do ar, perco o dinheiro que o AdSense me paga, um erro no banco de dados fez com que as pessoas não pudessem jogar nosso jogo ou um bug fez com que pessoas não consigam se inscrever para uma promoção não tem nada de crítico. Crítico é se sair do ar, milhões de pessoas não poderão receber seus salários amanhã, um bug fez com que um país inteiro fique sem energia, um erro no banco de dados impediu um atendimento de emergência etc....

Normalmente essas aplicações de missão crítica são áreas onde já, pela própria definição e natureza delas, não existe espaço para amadorismo ou para hacks questionáveis. E os desenvolvedores delas são as exceções altamente especializadas, não a regra. Então, não use ela como justificativa: seu software pode ser importante (e provavelmente ele é), mas ele não é crítico.

Empresas que desenvolvem sistemas críticos exigem titulação (muitas vezes mestrado ou doutorado) nas áreas de interesse. Exigem experiência comprovada e conhecimento das normas e legislações respectivas. Assim, qualquer outra regulamentação já se torna irrelevante: os contratadores efetivamente são quem regulamenta o mercado.

Outro motivo pelo qual me posiciono contra: trabalho, entre outras coisas, com desenvolvimento de software embarcado (não em aplicações críticas). Não tenho formação na área de informática: o que eu uso para meu trabalho, aprendi sozinho devido ao questionável estado do curso que faço.

Então, com uma lei dessas, pode ser que eu não possa mais exercer meu trabalho, mesmo eu tendo projetado o hardware e agora estar escrevendo o firmware ou o driver para ele. Muito bom - só que não.

Profissionais de diversas áreas podem ser, e muitas vezes são, excelentes desenvolvedores, desenvolvem várias bibliotecas e softwares amplamente utilizados, e se veriam em uma situação complicada com uma eventual regulamentação. Um médico ou um engenheiro que venha a desenvolver software para uso na sua profissão, e transforme isso em um negócio, precisa ter diploma de informática?

Temos também mais um motivo: informática é uma das poucas áreas que permite que um autodidata chegue ao mesmo nível de um profissional diplomado. Quer mexer com eletrônica? Para sair do básico, prepare-se para comprar instrumentação, montar placas de circuito impresso com componentes menores que a ponta do seu dedo etc... Seu hobby é a música? Vai ser necessário montar um estúdio, comprar instrumentos entre outros. São áreas de interesse que envolvem tempo, dinheiro, espaço, ferramental, entre outros recursos não tão facilmente acessíveis.

Já a informática? Se você está lendo esse blog, você provavelmente já tem todo o equipamento necessário: um computador e um cérebro (embora às vezes, parece que falta o segundo para alguns :). Qualquer pessoa com um mínimo de interesse pode aprender a programar, colaborar com projetos de software livre, etc.... Não me parece nada justo criar uma reserva de mercado apenas para quem tem um diploma que muitas vezes não significa nada. Nenhum dos grandes desenvolvedores atuais chegou até onde está hoje apenas com as aulas, os trabalhos e os diplomas.

E exatamente: um diploma é um pedaço de papel que significa tive aproveitamento nas disciplinas e apresentei um TCC. Mesmo que aproveitamento seja passar em tudo com a nota mínima e o TCC seja um projeto trivial. Nada diz quanto à capacidade do formando.


Mas a regulamentação vai impedir a sobrinhagem. Adivinhe? Não vai! O "sobrinho" vai comprar o diploma numa Universidade Tabajara e continuar sobrinhando. Já vi código péssimo vindo de pessoas supostamente com doutorado em Informática, e já vi código muito bom vindo de entusiastas. Assim como já vi projetos péssimos vindos de pessoas formadas em Engenharia.


Mas a regulamentação vai impedir os maus profissionais. Leia o que eu escrevi no parágrafo acima. E a regulamentação em pouco ou nada defenderá os direitos dos usuários.

Não vejo vantagem nenhuma em regulamentação das profissões relacionadas à informática, especialmente quando ela se dedica simplesmente a fechar o mercado e garantir um mercado enorme para as faculdades pagou-passou, excluindo profissionais que chegaram lá sem precisarem de 4 anos - muitas vezes perdidos, que poderiam ter sido investidos de forma melhor - de sala de aula, mas com muito mais conhecimento do que alguém que simplesmente fazia o que era pedido nos trabalhos.

Existe uma ampla diferença entre regulamentar uma profissão pela responsabilidade que ela exige, pelo risco de vida que ela envolve (que é o caso da Engenharia, Medicina etc...) e regulamentar por regulamentar ou regulamentar a pedido de um grupinho de profissionais ameaçados - que é o caso da Informática.

Nota: existem propostas muito mais razoáveis, como essa da SBC - que vai justamente contra o que certos burocratas querem: derruba por terra eventuais conselhos fiscalizadores e define liberdades no exercício das profissões de informática. 

sexta-feira, 8 de fevereiro de 2013

Exportando dados do LTspice e lendo eles em um programa Python + ajuste de curvas

(Obs.: post técnico, mas nada que um mortal não consiga ler)

Esses dias, precisei ler dados gerados no LTspice em um programa Python. Aliás, essa é uma solução relevante para incluir gráficos do LTspice em trabalhos acadêmicos, papers etc... visto que ele não gera gráficos de boa qualidade visual quando impressos.

A solução é bem simples:

No LTspice desenhe o circuito, simule etc... Selecione o gráfico, mande File/Export para gerar um .txt, selecionem os sinais a serem armazenados no arquivo. Como exemplo usei o circuito abaixo e fiz uma análise CC, variando V1 e medindo a tensão antes dos diodos:



Vou chamar esses resultados de diodo.txt. O LTspice gera um arquivo delimitado por tabulações. Agora, para ler em Python, eu poderia usar a biblioteca csv, mas existe uma forma mais pythônica de ler esses dados e plotá-los: usando a função loadtxt da biblioteca NumPy.

Os parâmetros dessa são:
  • fname: nome do arquivo
  • dtype: tipo de dados esperado
  • delimiter: separador
  • skiprows: quantas linhas pular no começo
  • usecols: uma tupla que permite especificar as colunas que queremos pular
A partir daqui ficou óbvio do que precisamos: da fname e da skiprows (a primeira linha é cabeçalho). Assim, teremos o código a seguir:
(se não abrir: https://gist.github.com/renanbirck/4743036)

Ele pode ser usado com o arquivo diodo.txt que forneço de exemplo (aviso: 4 MB. Clique com o botão direito e mande salvar para o seu browser não sentar)

Obteremos isso:


Podemos mexer na legenda, etc etc... mas cheguei ao que eu queria demonstrar.

E agora, já que temos esses dados, podemos ajustar eles a um modelo. Visualmente, nota-se que eles parecem com uma tangente hiperbólica. Assim, façamos um modelo do tipo

e usaremos o método dos mínimos quadrados para ajustá-lo a uma função desse tipo (poderíamos usar qualquer outro método de otimização). O código então tornar-se-á:
(se não abrir: https://gist.github.com/renanbirck/4743133)

Após executarmos, obtemos o gráfico:


Como queríamos demonstrar, obtivemos um bom ajuste. O modelo é bem adequado; para visualizarmos os parâmetros bastaria um print p no final do código.

E nem doeu: foram exemplos adaptados do que eu encontrei na documentação do SciPy. :)

Quanto ao desempenho, a leitura dos dados leva 2 segundos, e o ajuste cerca de 15 segundos num i7-2670QM, mas isso pode (e vai) variar dependendo do chute inicial; para um trabalho mais avançado seria interessante e necessário fazer um meta-ajuste.