O fator ônibus *

O post de hoje é simples e curto mas apresenta um conceito que é muito importante no dia-a-dia das empresas e dos projetos (principalmente de software, mas não necessariamente se limita a software).

Já participou de algum projeto onde uma ou talvez duas pessoas possuiam todo o conhecimento sobre o projeto? Acho que não é muito difícil isso acontecer, eu mesmo já participei de alguns. Alguns onde outra pessoa tinha todo o conhecimento acerca de um projeto, e outros onde eu mesmo tinha o conhecimento “concentrado” em mim (não porque eu queria, mas por conta das circunstâncias).

O fator ônibus * (do inglês bus factor), significa a quantidade de pessoas, que se forem atropeladas por um ônibus, farão o projeto desandar, ou até mesmo inviabilizar a continuidade do projeto. É óbvio que quanto maior essa medida melhor, pois dificilmente 10 pessoas são atropeladas por um ônibus no mesmo momento.

Moral da história: Se o seu projeto tem o fator ônibus igual a 1 ou 2, você corre sérios perigos! Então corra atrás, compartilhe o conhecimento, treine as pessoas, sugue o que puder sugar dos que tem mais conhecimentos, pergunte, leia, converse e se informe para o bem do seu projeto e da sua equipe!

* Observação: Vale a pena lembrar que o fator ônibus não significa ser literalmente atropelado por um ônibus. Ser atropelado por um ônibus pode significar: Algum membro da equipe conseguir um outro emprego, alguém sair de licença maternidade, alguém decide mudar o estilo de vida, alguém pedir demissão, alguém simplesmente sair de férias por 1 mês (parece absurdo né?), ou realmente alguém for atropelado mesmo por um ônibus 😛

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.

#Vagas – Stefanini – Analista de Testes

 É com prazer que o BdB  continua  a parceria com a área  de Talent Acquisition (que é a área responsável por recrutamento e seleção) da Stefanini. Lembrando sempre que as vagas e oportunidades que forem surgindo vão ser divulgadas aqui no BdB para que você possa aproveitar e se candidatar (caso interesse).

Interessados enviar currículo para talentosrs@stefanini.com especificando no campo “assunto” com o código da vaga.

Analista De Testes JR/PL/SR(Cod. 130606)
Requisitos: Experiência em teste de software funcional e análise de requisitos e de especificações técnicas. Desejável experiência em teste automatizado. Conhecimento em Banco de Dados, preferencialmente SQL Server, e linguagem SQL. Inglês em nível mínimo intermediário.
Remuneração: de acordo com o perfil profissional
Vagas: 11
Local de trabalho: Porto Alegre/RS

Analista de Teste de Performance(cod. 130641)
Requisitos: Experiência em análise e teste de software, de preferência performance. Experiência/conhecimento em linguagens de programação Java ou C++ ou .Net, aplicações web, XML, web services e bancos de dados. Inglês avançado.
Atividades: Elaboração de cenários e execução de testes de software, análise de desempenho.
Remuneração: de acordo com o perfil profissional
Vagas: 4
Local de trabalho: Porto Alegre/RS

Trainee Teste de Software (cod. 130628)
Requisitos: Identificação com o segmento de testes, desejável experiência anterior na área de TI. Inglês mínimo intermediário.
Atividades: Execução de testes de software e elaboração de cenários de testes em projetos internacionais (times globais).
Remuneração: de acordo com o perfil profissional
Vagas: 3
Local de trabalho: Porto Alegre/RS

#TGIF – Google Fiber e suas consequências

Nosso TGIF hoje vai falar sobre o novo produto do google e lancar uma pergunta no ar.
Semana passada o google lançou mais um produto para o mercado, ou melhor vai lançar no dia 9 de setembro,  o Google Fiber.

Google Fiber é nada menos que uma proposta da google de oferecer um serviço de internet cabeada com 1Gb de upload e download. Se você tem em casa uma internet de  10, 15 ou ate 100Mb e acha que está bombando. Aguarde que é por muito pouco tempo 🙂

A google promete revolucionar a internet e vai iniciar esse serviço pioneiro no mercado com precos realmente agressivos:

Conexão de 1Gb + TV por U$ 120 sem taxa de instalação.
Conexão de 1Gb por U$ 70 sem taxa de instalação.
Conexão de 5 Mb apenas pagando a taxa de instalação (U$300) ou 12 meses de U$ 25 e garantia de 7 anos sem pagar.

A pergunta que fica é: Se você estiver com esse serviço google fiber e fora isso ainda usar os produtos do google com o Google Drive , Google Talk, etc… e acontecer algo parecido com o que aconteceu no dia do lançamento do produto para a maioria dos usuários do Google Talk que passou parte da manhã sem conseguir usá-lo (Veja imagem abaixo)

Clique para ampliar

Seria o caos nas nossas vidas ? O problema da semana passada  eu acho que não foi muito grave pois tivemos várias outras formas de nos comunicar pela web: skypefacebookmsn ate mesmo pelo whatsapp.

Agora imaginem uma dependência física como o Google Fiber, onde possivelmente vai sair na frente e ter muita gente usando por ai.
Se der um tango down ? e ai ? Será que vai ter muita gente pulando pela janela ?

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Existe profissional de TI fazendo corpo mole na sua empresa?

Em qualquer profissão existem pessoas que fazem o conhecido “corpo mole”, alguns , inclusive,  se esforçam tanto na enrolação, que fica até difícil de percebermos, e acabam compensando sua pouca produtividade com grande esforço no “marketing pessoal” ou no “relacionamento” com os colegas.

As conseqüências das ações desse tipo de profissional nem sempre são imediatas ou graves, porém não há dúvida do custo e do prejuízo que essas atitudes podem ter no projeto e até mesmo na empresa.

Apesar desse tipo de profissional existir em todas as áreas e funções, no post de hoje, vamos focar em como reconhecer um testador desse tipo. Vamos apresentar algumas dicas para perceber quando um tester não está trabalhando como deveria, mas não se espante se você visualizar as mesmas características em outros profissionais.

Esse tipo de problema ainda ocorre, porque é fácil se safar sem realizar algum trabalho efetivo, e geralmente os líderes de equipe e gerentes de projeto não possuem as ferramentas e conhecimentos necessários para avaliar o progresso do trabalho de um testador. (Link – Artigo)

É extremamente fácil dizer que algo foi testado.

– Conhecimento superficial: Os profissionais que fazem corpo mole, em geral possuem conhecimento extremamente limitado sobre o sistema, afinal eles não teriam o trabalho de se aprofundar e conhecer os detalhes de cada requisito ou estória de usuário. Isso gera diversas consequências que facilitam a identificação desses profissionais:

1 – Encontram apenas Bugs superficiais e de pouco valor

2 – Não conseguem participar efetivamente das reuniões de planejamento

3 – Se limitam a fazer apenas o que lhes é pedido

Algumas mudanças na maneira de acompanhar o progresso do trabalho podem ajudar na tarefa de identificar esses profissionais:

– Evitar acompanhar a execução dos testes apenas através de relatórios gerados pelas ferramentas. Em seu lugar, questionar os envolvidos na execução, compreender o que foi testado, reportado e os próximos passos.

Outra ação, que talvez, apresente um resultado interessante é assegurar que diversas técnicas de execução são utilizadas: Automação, testes exploratórios, estáticos… Dessa forma, o profissional “corpo mole” precisará demonstrar seu conhecimento de uma maneira que permitirá uma melhor medição do seu trabalho.

Para finalizarmos o post, um vídeo divertido, onde George Constanza, da série Seinfeld, explica sua técnica para demonstrar que está cheio de atividades no trabalho.

E vocês? Que outras características observam nos Profissionais “George Constanza”?

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.

O facebook está piorando nossas vidas

CONTEXTO

Você também acha isso? ou não? Talvez você até ache que o facebook é muito legal pelo simples motivo que você pode encontrar as pessoas que você não tinha mais contato e parentes distantes não é mesmo?

Pois eu vou lhe dizer que você provavelmente está errado!! Ainda não é o momento de ficar com raiva de mim, eu nem entrei em detalhes nem justifiquei o porquê estou dizendo isso. Mas aqui vão os detalhes, e se você está mesmo interessado nisso é porquê você ama o facebook ou porquê você odeia (ou nenhum dois dois, você está somente curioso :P)! O texto ficou um pouco extenso, mas seria maravilhoso que você pudesse ler tudo e deixar sua opinião.

 CASO GERAL

Você está no facebook e reencontra e encontra muita gente que você conheceu no passado, gente que você gostava e também gente que você não gostava. Todos esses estarão lá marcando mais um número na sua lista de amigos. Além desses existem outros que você precisa fazer um esforço mental muito grande para lembrar quem são, e ainda existe, PASMEM, aqueles que a gente adiciona sem nem conhecer (não me pergunte o motivo).

Você tem então 100, ou 500 ou 1000 ou ainda 5000. O mais triste de tudo é que na vida real você tem uma roda de amigos de uns cinco ou dez amigos que você gosta, se importa e mantém contato regular. E dentre esses você tem um ou dois que você sabe que pode contar a qualquer momento e que são amigos pra toda hora. Você não acha isso interessante? ou será que a palavra melhor aqui seria triste?

CASO MUITO COMUM 1

Você adicionou algumas pessoas que estudaram com você a 15 (ou mesmo dois) anos atrás. Foi legal rever essa pessoa né? Mas e aí?? O que acontece agora??

Até onde me consta (e olhe que eu sou um usuário ativo do facebook, pelo menos até agora…) o que vai acontecer é o seguinte: Você vai começar a “curtir” algumas fotos e comentar algumas atualizações da pessoa, e vice-versa, a pessoa também vai muito provavelmente fazer isso com você. E PONTO FINAL. O relacionamento é limitado a isso, e esse é o assunto do próximo caso.

Você vai se encontrar, sair com essa pessoa, convidá-la pra sua casa, ou fazer uma ligação e conversar com ela? MUITO PROVAVELMENTE não!

CASO MUITO COMUM 2

Sabe aquela sensação que você tinha antigamente quando recebia uma carta? Era muito legal, você sabia que alguém (que provavelmente se importava o suficiente com você para isso) tinha gastado o tempo dela para escrever algo para você.

Tudo bem que o email veio aí e substituiu praticamente por completo essa situação que acabei de descrever. Mas ainda hoje, a sensação de receber um email (destinado a você somente) é algo muito precioso (pelo menos para mim) e ainda me dá uma sensação de alegria muito grande. No meio de tantas propagandas e correntes enviadas por email, receber um email destinado somente a você é coisa muito boa. Nesse caso alguém também gastou o tempo dela escrevendo algo para você, ou enviando fotos, ou algo do tipo (muito provavelmente pelo simples motivo que ela se importa com você e provavelmente isso é recíproco).

Não estou aqui para dizer que as pessoas pararam de se importar umas com as outras, o problema de hoje em dia é que existe uma ferramenta que nos encaminha cada vez mais na direção de pararmos de nos importar uns com os outros (como pessoas físicas que somos, e não virtuais). Essa ferramenta se chama CURTIR.

Quando você mora distante dos amigos e família (que é o meu caso), você começa a perceber que a quantidade de pessoas que curtem uma foto sua no facebook é muito grande. Até aí tudo bem, mas se você for comparar a quantidade de pessoas que curtem com a quantidade de pessoas que fazem uma ligação para você, ou mesmo que enviam um email para você procurando saber como você está, você vai ver que existe algo errado. Afinal, você tem 100 amigos que curtiram uma foto ou 2 que realmente se importam e procuram se comunicar com você?

E não vale dizer que: “Ah, acho que não ligam nem falam com as pessoas porque já vêem que elas estão bem pelo facebook!”. Isso para mim não cola de jeito nenhum.

CONCLUSÃO

Meu amigo leitor, se você chegou até aqui (sem pular nada do texto) você está de parabéns! 🙂 E eu gostaria de fazer uma recomendação para você. Se você gosta de alguém, e dá realmente valor a alguma pessoa, além de curtir a foto dessa pessoa no facebook, procure também saber como ela está, faça uma ligação, mande uma carta, mande um email, ou até mande uma mensagem privada no facebook mesmo. Mas, por favor, não deixem nossas relações se resumirem a meros clicks em um botão de CURTIR. Curta a vida fora do facebook.

PÓS-CONCLUSÃO

Ainda tenho outros casos muito comuns em mente, que pioram nossa vida. No futuro teremos outro post nessa direção, então se você gostou (ou se odiou) você precisa voltar aqui daqui a algum tempo.

#Vagas – Stefanini – Desenvolvedor de Software, DBA, PL/SQL

 É com prazer que o BdB  continua  a parceria com a área  de Talent Acquisition (que é a área responsável por recrutamento e seleção) da Stefanini. Lembrando sempre que as vagas e oportunidades que forem surgindo vão ser divulgadas aqui no BdB para que você possa aproveitar e se candidatar (caso interesse).

Interessados enviar currículo para dbarcelos@stefanini.com especificando no campo “assunto” com o código da vaga.

Desenvolvedor Java JR/PL/SR (cód. 130602)
Requisitos: Experiência em desenvolvimento Java. Bons conhecimentos em PL / SQL, design e padrões de projetos. Desejável conhecimentos em weblogic, webservices, Soa  e certificação. Inglês minimo intermediário(fala, leitura, escrita).
Atividades: Para trabalhar com manutenção, melhorias (novas aplicações ou migração de tecnologia) e desenvolvimento de sistemas em Java em projetos internacionais, compostos por times distribuídos geralmente no Brasil, Estados Unidos, Índia, Malásia, Japão, Rússia e outros.
Remuneração: de acordo com o perfil profissional
Vagas: 5
Local de trabalho: Porto Alegre/RS

Project Manager Júnior (cód. 1306024)
Requisitos: Experiência com liderança de equipes, distribuição e controle de tarefas, conhecimento da ferramenta MS Project. Inglês Fluente.
Atividades: Atuar em  projetos internacionais (times globais).
Remuneração: de acordo com o perfil profissional
Vagas: 1
Local de trabalho: Porto Alegre/RS

Analista de Testes PL/SR (cód. 130606)
Requisitos: Experiência em teste de software funcional e análise de requisitos e de especificações técnicas. Desejável experiência em teste automatizado. Conhecimento em Banco de Dados, preferencialmente SQL Server, e linguagem SQL. Inglês em nível mínimo intermediário.
Atividades: testes funcionais em projetos internacionais (times globais).
Remuneração: de acordo com o perfil profissional
Vagas: 3
Local de trabalho: Porto Alegre/RS

Desenvolvedor  COBOL  SR (cód. 130608)
Requisitos: Sólida experiência em desenvolvimento Cobol. Conhecimentos em SQL.
Atividades: manutenção e desenvolvimento de sistemas em projetos internacionais (times globais).
Escolaridade: Desejável superior completo ou em andamento em Ciências da Computação, Sistemas da Informação ou afins.
Remuneração: aberta a negociação
Local de trabalho: Porto Alegre/RS.
Vagas: 6

Desenvolvedor BI Pleno (cód. 130674)
Requisitos: Conhecimento/experiência em alguma ferramenta de Reporting (Ex: Business Objects; MicroStrategy, OBIEE, etc).  Inglês avançado ou fluente.
Atividades: Desenvolvimento com forte atuação em PL/SQL (queries) e Reporting.
Escolaridade: Desejável Superior completo ou em andamento em Ciências da Computação, Sistemas de Informação ou afins
Remuneração: aberta a negociação
Local de Trabalho: Porto Alegre/RS
Vagas: 1

Desenvolvedor Peoplesoft SR (130629)
Requisitos: Inglês avançado a fluente; conhecimento em PeopleCode, PeopleSoft, PeopleTools; Oracle, SQL.
Atividades: Desenvolvimento e análise em projetos internacionais (Times Globais).
Escolaridade: Superior completo em Ciências da Computação, Sistemas de Informação ou cursos afins.
Remuneração: aberta a negociação.
Local de Trabalho: Porto Alegre/RS.
Vagas: 1

Consultor DBA Oracle SR (130609)
Requisitos: Comandos básicos de Linux, Arquitetura Oracle 10g. 11gR1 e 11gR2; Oracle RAC e Dataguard; Oracle ASM; Oracle Grid Control. Inglês avançado.
Atividades: Atuação na Migração de Storage, gerenciamento de discos, monitoramento, etc.
Escolaridade: Superior completo ou em andamento e, Sistemas de Informação ou afins.
Remuneração: aberta a negociação
Local de Trabalho: Porto Alegre/RS
Vagas: 1

Desenvolvedor PL/SQL:  JR/PL/SR (130603)
Requisitos: Experiência mínima de dois anos na função, Inglês intermediário.
Atividades: Desenvolvimento em PL/SQL em projetos internacionais (Times Globais).
Escolaridade: Superior completo ou em andamento em Sistemas de Informação ou afins.
Remuneração: aberta a negociação.
Local de Trabalho: Porto Alegre/RS.
Vagas: 5

Embedded Systems no BdB

Estamos iniciando hoje uma coluna que tratará exclusivamente de assuntos relacionados ao desenvolvimento Sistema embarcados (embedded systems). O objetivo deste primeiro post é destacar a relevância do assunto, uma vez que muitos podem estar se perguntando o porque de uma coluna exclusiva para tratar deste tema.

No passado, o termo embedded ou embarcado remetia à projetos impressos em placas de circuito que ofereciam uma ou duas funcionalidades. Hoje o termo tomou uma proporção bem maior, uma vez que grande parte de nossas atividades diárias dependem de equipamentos que são controlados por algum tipo de sistema embarcado. Um automóvel, por exemplo, possui sistemas responsáveis pelo controle de frenagem, cálculo de consumo de combustível, piloto automático, navegação, dentre outros. Em equipamentos médico-hospitalares, como em uma maquina Raio-x, existem sistemas embarcados que garantem que o paciente não receberá dosagens extremas de radiação. Um avião é quase que absolutamente controlado por sistemas complexos que funcionam de maneira altamente integrada, de modo a garantir a devida execução de comandos.

Profissionais que projetam e desenvolvem esses sistemas, além de considerarem os aspectos funcionais, precisam levar em conta restrições do domínios impostas por entidades reguladoras como ISO e IEEE. Essas restrições determinam, por exemplo, o processo de desenvolvimento a ser seguido, mecanismos de testes, e níveis aceitáveis de integração entre as parte que compõe os sistemas. Além disso, esse profissionais precisam considerar desde limitações de processamento e memória, à condições ambientais extremas que o sistema estará sujeito, tais como variações de temperatura, humidade e radiação.

Por uma questão histórica, esses sistemas eram desenvolvidos exclusivamente por Engenheiros eletrônicos. No entanto, como o software tem se tornado aspecto chave nesses sistemas, profissionais com formação em Ciência da Computação tem sido cada vez mais requisitados, devido ao conhecimento em métodos e técnicas computacionais exigidos pelos orgãos certificadores.

Essa coluna irá tratar de tópicos do domínio da computação que tem sido utilizado no desenvolvimento de sistemas embarcados, tais como desenvolvimento de sistemas embarcados usando métodos ágeis, frameworks de desenvolvimento, linguagens de programação mais usadas (acreditem, esse mundo não se limita a C/C++), plataformas de desenvolvimento (principalmente no domínio de sistemas automotivos e aviônicos), gerenciamento de projetos e de requisitos, dentre outros.