Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Se você está curioso por algumas estatisticas sobre o ano de 2013, aqui está, basta clicar na figura abaixo e seguir o link 😉

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Pedacinho de texto das estatisticas:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.

Click here to see the complete report.

Anúncios

Elicitação de Requisitos de sistemas Safety-critical

Sistemas safety-critical são aqueles que, em caso de falha, podem causar danos severos ou morte de indivíduos e/ou danos significativos ao meio ambiente. Esses sistemas estão presentes em diversos equipamentos que fazem parte do nosso cotidiano, como, por exemplo, carros (e.g. sistema de controle de frenagem, controle de piloto automático, ajuste de tração), aviões (e.g. sistema de controle de porta, sistema de ajuste de rota, navegação), e equipamentos médicos (e.g. sistema de ajuste de radiação em maquinas de ressonância magnética, sistemas de gatilho de marca-passo).

 IEEE_logoVocê já se perguntou como os requisitos desses sistemas são elicitados e documentados? As regras para tratar requisitos de safety são um tanto quanto diferentes das praticas “tradicionais” de elicitição de requisitos. Para que os produtos sejam homologados, e então liberados para o mercado, os equipamentos tem que ser desenvolvido seguindo praticas descritas em padrões ISO/IEEE (e.g. ISO 26262, ISO 14971). Esses padrões cobrem práticas que vão da especificaçao até à implantação do sistema. Nesse post vamos tratar apenas dos itens que são comuns à fase de requisitos de sistemas safety-critical.

Processos de elicitação de requisitos de safety, em geral, seguem 5 passos:

1 – Identificação do ítem: Considerando o domínio automotivo, o item não é o carro em si; mas um sistema que, ao final, irá compor o automóvel, como, por exemplo, o sistema de controle de tração, o sistema de piloto automático, etc.

2 – Análise de riscos e ameaças (hazard and risk analysis): Nessa fase são analisados e documentados todos os riscos inerentes àquele sistema. Um exemplo de hazard é “Piloto automático não desativar quando requisitado pelo motorista”. A cada um desses eventos é associado um Safety Integrity Level ou SIL (isso é assunto para outro post), que corresponde a uma indicação do quão catastrófico esse evento pode ser cruise-control-traktor-headercaso aconteça.

3 – Estabelecer Safety Goal: Cada evento ameaçador é associado a um safety goal ou, traduzindo literalmente, meta de segurança. Por exemplo, o safety goal associado ao hazard “Piloto automático não desativar quando requisitado pelo motorista” pode ser “Piloto automático precisa ser desativado quando requisitado pelo motorista”.

4 – Requisitos funcionais de safety: Para cada safety goal, uma série de requisitos funcionais de safety são derivados. Exemplo: “Ao pisar pedal de freio, piloto automático deve ser desativado”.

5 – Requisitos técnicos de safety: Cada requisito funcional de safety deve ter detalhes técnicos de como ele será implementado. Essa especificação deve conter detalhes dos blocos funcionais que vão implementar a função (hardware e/ou software).

normas-iso

No processo de certificação do produto, todos os artefatos e documentos associados são analisados e avaliados quanto a consistência, detalhamento, de modo a julgar a eficácia e eficiência do produto. Uma vez homologado, o produto é liberado para o mercado.

Processos de engenharia de safety são muito complexos e rígidos. Muitas outras técnicas são usadas para assegurar que esses sistemas não falharão. E, caso falhem, que o efeito seja o menos trágico possível.

No próximo post irei escrever sobre o que vem sendo feito no Brasil na área de sistemas safety-critical; mais especificamente no que diz respeito a software embarcado em equipamentos médico-hospitalares.

Como reduzir o tempo gasto em testes?

Teste é sempre um gargalo! Não dá pra estimar quanto tempo é gasto em testes (e certificação),  mas algumas fontes mostram que cerca de 50% do esforço para desenvolver um produto é gasto em testes. Com esse dado, e o senso comum de quem trabalha com desenvolvimento de software, teste de software se torna um excelente alvo para ser estudado com o objetivo de se reduzir o tempo gasto.

Obviamente, muitos estudos já foram feitos nessa direção, e nesse post vamos falar um pouco sobre um artigo que realizou um mapeamento sistemático com o objetivo de identificar todos os trabalhos existentes (acadêmicos) que tratam sobre redução de tempo e esforço de testes. O artigo, publicado em 2012, tem como título “Reducing test effort: A systematic mapping study on existing approaches” e pode ser encontrado aqui.

Primeiramente, é claro que poderíamos reduzir o esforço de testes simplesmente tendo menos testes, mas é claro que reduzir a qualidade do produto final é inadmissível, principalmente quando tratamos de sistemas críticos e safety-relevant.

Diante disso, o artigo identificou 5 categorias que se propõem a diminuir o esforço gasto com testes (consequentemente diminuindo o tempo também na maioria das vezes). As cinco categorias são:

  • Test Automation – 50% dos estudos identificados nesse mapeameanto sistemático abordam essa categoria. Isso não é surpreendente pois automatizando testes muito tempo consegue ser economizado.
  • Prediction – 28% dos estudos abordam predição, no sentido de dar suporte a decisões sobre quanto esforço de teste precisa ser gasto para um dado sistema e como distribuir esse esforço entre as diversas atividades.
  • Test input reduction – 15% dos estudos abordam essa categoria, com o intuíto de ajudar da seleção e priorização  de test cases (essa categoria também é conhecida como redução de suítes de teste)
  • Quality assurance (QA) before testing – Essa categoria (encontrada em 5% dos estudos) lida com atividades executadas antes dos testes propriamente ditos e que ajudam a reduzir os testes. Essas atividades são: análises estáticas, inspeçoes e revisões.
  • Test Strategies – Essa categoria (encontrada em 2% dos estudos) aborda pontos  como a seleção de diferentes técnicas de teste e também seleção de diferentes níveis de teste para economizar tempo e esforço.

É claro que esses pontos são focados em estudos acadêmicos, e que nos projetos reais da vida real podem existir outras abordagens para reduzir esforço dos testes. Você usa/conhece alguma abordagem? Compartilhe conosco 🙂

In-Car Connectivity – Carros Conectados à Internet

Screen shot 2012-12-20 at 11.47.10No Salão do Automóvel de Frankfurt de 2011, a Ford anunciou o Evos Concept Car. Dentre as inúmeras inovações propostas, uma que se destaca é a interação do carro com serviços disponíveis na nuvem, que pretende transformar a maneira que guiamos. A idéia geral é apresentada por Paul Mascarenas – Ford Chief Technical Officer and Vice President Research and Innovation -, e pode ser assistida no vídeo disponível nesse link. Muito marketing vem sendo feito sobre o Evos; em especial, o 2012 Sydney Motor Show deu grande destaque ao conceito de automotive cloud connectivity. No entanto, pouco se vê se concretizando. Mais informações sobre o Evos pode ser encontrada aqui.

ericsson_logo

Quem parece que vai concretizar essa história de In-Car Connectivity é a Volvo e a Ericsson. No último dia 17/12/2012, a Ericsson anunciou uma parceria com a Volvo que promete conectar carros com serviços disponíveis na nuvem. O anúncio pode ser lido na íntegra aqui. Desde então, o assunto tem sido muito comentado; por exemplo, Volvo and Ericsson Partner for In-Car Connectivity, e Ericsson e Volvo Lançam Carro Conectado na Nuvem

O que vi e ouvi na 64th Feira de Veículos Comerciais em Hannover

Entre os dias 20 e 27 de Setembro, o Hannover Messe sediou a 64th feira de veículos comerciais, IAA 2012(Internationale Automobil-Ausstellung). Esse evento reúne os principais produtores de veículos de grande porte como caminhões, carretas, utilitários de menor porte como vans e combos, assim como produtores de peças e tecnologias para veiculos dessa categoria.Tive boas conversas com gente da Mercedes, Volvo, Bosch, BorgWarner, Donaldson, e alguns outros nomes desse mercado. Foi bom ver as novidades, e, claro, a evolução do software nesses produtos. Os hot-topics foram: comunicação carro-a-carro, personalização, integração com smart phones, e ampla integração com redes sociais. Em especial, a Bosch estava mostrando um sistema que permite personalizações em um caminhão, com base na sincronização entre o iPhone do motorista e o sistema central do veículo. Mais especificamente, antes de entrar no caminhão,  o motorista iniciava um app, e algumas configurações como regulagem de bancos e espelhos, e o esquema de cores do painel eram ajustados.

No que diz respeito a redes sociais, as preferências de restaurantes e localização de amigos, por exemplo, também fazem parte desses sistemas. Se em determinado momento o motorista iniciar uma busca de restaurantes próximos se sua localidade, o sistema dará destaques especiais a restaurantes que tenham similaridades com as preferências dele definidas em redes sociais, e mostrará como esses locais tem sido avaliados pelos demais clientes.

No que tange desenvolvimento desses sistemas, todos destacaram que o fato do software ter assumido papel chave nesse contexto foi importante, tendo em vista todo beneficio gerado. No entanto, os efeitos colaterais tem sido grandes. O principal problema destacado foi: Atraso na entrega do produto. Os cronogramas de projetos desses sistemas nunca estiveram tão atrasados. E todos culpam os times de desenvolvimento de software. Aquela velha historia que ouve-se frequentemente “a culpa é do pessoal da informática” se tornou comum nesse meio.

Muitos destacaram a necessidade de contratação imediata de profissionais qualificados para atuar no desenvolvimento de sistemas dessa natureza. As demanda são diversas: gerenciamento de requisitos, modelagem arquitetural, teste, controle de evolução,  gerência de configuração, e gerenciamento de projetos foram enfaticamente citados.

O mercado está aquecido. Apesar da crise na europa, as empresas tem contratado engenheiros de software aos montes. Aos interessados, se dediquem a aprender inglês. Sem ele todo conhecimento adquirido com métodos e técnicas computacionais não terão valia alguma por aqui.

Carros Inteligentes

O avanço das técnicas computacionais vem motivando a indústria automotiva a praticamente reinventar os seus produtos, fazendo com que os carros de hoje em dia sejam, de fato, um aglomerado de sistemas de computação se comunicando e tomando decisões que, em certos casos, chegam a ser superiores às intenções dos motoristas.

Para se ter noção da quantidade de computação presente em um carro nos dias de hoje, considere os seguintes dados: Um jato F-35 contém aproximadamente 6 milhões de linhas de código; um 787 Dreamliner, 7 milhões. Já um Mercedes-Benz classe S, aproximadamente 20 milhões de linhas de código. Em 2009, a Frost & Sullivan estimou que em um futuro não muito distante, os carros chegarão a 300 milhões de linhas de código.

Quais as implicações de tanta computação em um automóvel? Uma das principais, obviamente, é o custo de produçao. O Dr. Manfred Broy, professor de Ciência da Computação da TU Munique, e mentor para assuntos computacionais de uma renomada marca automotiva alemã, estima que o custo com software e eletrônicos em um carro chega a ser responsável por ate 40% do custo de um automóvel. Nos proximos sete anos, essa porcentagem deve chegar a até 80%. Levando em conta que a hora de profissionais de software nao é nem um pouco barata nos dias atuais (Good for us! :-)), espera-se que a contínua necessidade desses profissionais no desenvolvimento de carros eleve ainda mais os preços destes num futuro próximo. No contexto brasileiro, isso implica em carros ainda mais caros. Dai vê-se a necessidade de um ajuste na política de preços no setor automotivo brasileiro.

Diante desse cenário, os grandes nomes da computação têm voltado a atenção para o mercado automotivo: Microsoft firmando acordo com Toyota, a Google e seu Google Car, IBM, e até a Apple sonha sonhou em se aventurar no mercado automotivo com o utópico iCar.

Gostaria de compartilhar algumas experiências pessoais sobre os desafios no dia-a-dia no ambiente de desenvolvimento em algumas indústrias automotivas. Mas isso é assunto para outro post.

Aos interessados, recomendo a leitura do artigo This Car Runs on Code de  Rober N. Charette, fonte primária das informações desse post.

Modelos Arquiteturais em Sistemas Aviônicos

   Antes de me aventurar no domínio de sistemas embarcados, trabalhei com desenvolvimento de sistemas financeiros e de administração público-privada. Diversas vezes, ao perguntar por modelos arquiteturais do sistema, era informado que ele era inexistente estava desatualizado. Depois de algum tempo nesse contexto, me juntei ao grupo de profissionais que acreditam que um bom código fonte e algumas linhas de comentário são suficientes enquanto documentação.

A realidade no domínio de embarcados é bem diferente. Entidades que regulamentam sistemas que, em caso de falha, causarão danos à pessoas ou ao meio-ambiente (mais conhecidos como sistemas safety-critical), exigem que as empresas que constroem esses sistemas sigam rigidamente as etapas dos processos de desenvolvimento, e gerem artefatos de documentação extremamente detalhados.

No caso de sistemas aviônicos, o DO-178B – Software Considerations in Airborne Systems and Equipment Certification, por exemplo, define processos rígidos para (i) Planejamento, (ii) Desenvolvimento, (iii) Requisitos, (iv) Design, (v) Codificação e Integração, (vi) Teste e Verificação, (vii) Gerencia de configuração, e (viii) Gerenciamento de qualidade. Para se ter uma ideia geral das etapas e artefatos, recomendo uma olhada na seguinte apresentação: Introduction to Avionic Systems Development.

Um dos artefatos exigidos pelo DO-178B é a documentação arquitetural dos vários sistemas que compõe um sistemas aviônico: diagramas de componentes, diagramas comportamentais de tempo-continuo e de estados, dentre outros.

Alem de servir para documentação, esses modelos são usados como base para geração de código funcional. Essa historia de geração automática de código soava um tanto quanto utópica para mim também, até que, certa vez, o chefe da engenharia de uma grande empresa de aviação me disse que não confiava em códigos escritos por desenvolvedores, mas sim em códigos gerados a partir de especificações arquiteturais. Tentando entender o que se passava na cabeça desse cidadão, comecei a me inteirar mais sobre o assunto, e me convenci do quão poderosos mecanismos de geração de código podem ser quando utilizados apropriadamente. Para uma visão prática sobre o assunto, recomendo conhecerem um pouco sobre ferramentas como OpenArchitectureware e Acceleo.

Esses modelos são também peças-chave nos processos de garantia de qualidade, que vão desde testes baseados em modelos à técnicas formais de Model-Checking (sim, estou falando de assuntos relacionados a métodos formais. Eles são amplamente utilizados na industria aviônica). Toda essa amarração exigida pelas normas regulatórias implica em lentidão no desenvolvimento, e, quando não gerido adequadamente, pode gerar atrasos consideráveis na entrega do produto (ver caso do Boeing 787 Dreamliner). No entanto, empresas que desenvolvem esses produtos muitas vezes optam por atrasos aceitáveis no time-to-markt, mas assegurar que os produtos são feitos como manda a norma; caso contrário, o prejuízo financeiro será ainda maior, e a reputação da empresa desaparece.

Aí vai um recado para turma do “anti-modelos-e-apenas-código-escrito-é-o-que-conta”: Sistemas dessa natureza não podem falhar! Não existe possibilidade de reiniciar o sistema de navegação ou de propulsão de uma aeronave enquanto ela voa a 900Km/h a uma altitude de 30000 pés. O custo de voltar a versão de um software depois que ele já foi inserido em uma família de jatos tem um custo que pode comprometer o projeto como um todo. Não estamos tratando de sistemas web; também não quero dizer que estes sejam menos complexos ou de menor importância; digo apenas que as restrições de domínio são mais rígidas, levando em conta as catástrofes causadas se um sistema desse falhar.