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.

Anúncios

#TGIF – E o software continua a constranger seus criadores

Um dos assuntos mais falados nessa semana foi o lançamento do “tablet” da microsoft, o surface, principalmente devido ao travamento do produto durante a demonstração.

Não há como não rir, ao assistir o pânico do apresentador durante a demonstração. Lançar produtos (software) ao vivo têm se mostrado uma tarefa de alto risco ao longo dos anos. A mesma Microsoft, é protagonista de outro vídeo famoso no youtube, onde o windows trava durante sua apresentação.

Porém, apesar do expertise da microsoft nesse tipo de constrangimento a própria apple, também, já se viu vítima de problemas durante uma apresentação. Menos mal que o problema não foi causado pelo software e sim pela rede wi-fi, mas o momento inconveniente é constrangedor.

Quer rir mais um pouco? 

– Microsoft Speech Recognition

 

Leia, também, outros artigos já publicados na série:A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

– Facebook = Inovação até na Infraestrutura

– Quer aprender a tocar guitarra?

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

TMM, o que é isso ?

TMM, se você conhece os termo CMM então não terá nenhuma dificuldade de entender o que é TMM, pois o objetivo do TMM é ser usado de uma maneira semelhante ao CMM(Capability Maturity Model), no qual foi baseado, que é o de proporcionar uma estrutura para avaliar a maturidade dos processos de teste em uma organização, e assim definindo alvos na melhoria da maturidade destes processos. O TMM é o acrônimo Test Maturity Model e foi primeiramente desenvolvido pela Dr. Ilene Burnstein do Instituto de Tecnologia de Illinois. O TMM pode ser usado tanto em conjunto com o CMM como também pode ser usado sozinho.

Assim como o CMM, o TMM possui 5 niveis de maturidade do processo.

1 – Inicial, que significa que a organização esta usando métodos ad-hoc para testes, usualmente não existe um profissional qualificado e nem ferramentas especializadas para testes e basicamente o objetivo dos testes é mostrar que o sistema e software funcionam.

2 – Fase de definição, neste segundo nível os testes já são considerados como processo, o mesmo eh definido como uma fase após o desenvolvimento e já é usado algumas técnicas básicas de testes. Nesta fase o objetivo dos testes são verificar que o sistema e software estão de acordo com os requisitos.

3 – Integração, como o nome da sugere o processo de teste é integrado ao ciclo de vida do desenvolvimento do software. Nesta fase já podem ser vistos treinamentos formais de técnicas de testes, controle e monitoramento do processo de teste e o inicio do uso de ferramentas de automação. Um bom exemplo de integração dos processos de testes com o ciclo de vida do desenvolvimento de software é o  conhecido Modelo-V

4 – Gerenciado e mensurado, nesta fase a organização já passa a controlar e gerenciar o processo de teste de maneira ainda mais formal, utilizando quantificações capturadas através de métricas bem definidas. O desenvolvimento do produto passa a ser testado em busca de atributos de qualidade como confiabilidade, usabilidade e manutenibilidade. O casos de teste são armazenados em bancos de dados de ferramentas de gerenciamento de testes, assim como os defeitos que são registrados em uma ferramenta com seu devido grau de severidade e prioridade.

5 – Otimização, nesta fase o teste passa a ser institucionalizado dentro da organização, o processo de teste eh muito bem definido, assim como seus custos e efetividade são monitorados e a automação dos teste são um das partes principais do processo.

Ah, lembre-se que você pode ver por ai como TPI (Test Process Improvement), ou TMMi (Test Maturity Model Integration) nao sao a mesma coisa apesar de terem praticamente o mesmo objetivo, existem algumas diferenças entre eles e para saber mais detalhes leiam este documento bem intuitivo e escrito por Emerson Rios e Ricado Cristalli ou então beba a água direto da fonte (TPITMMi

Então após essa breve explicação sobre TMM, você consegue ter uma ideia em qual nível TMM da sua empresa ?

Já conhece o eXtreme Go Horse Programming?

Você conhece o eXtreme Go Horse (XGH) Programming? Não?? Então não perca tempo e veja aqui essa maravilhoso processo 🙂 Será que a vida de desenvolvimento de software fica mais fácil depois das dicas desse processo? 😀

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH.

XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes.

Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script maluco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro.

O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

Fonte: http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/

Esse texto é uma brincadeira, você pode me xingar no twitter: @maribalbe

#TGIF – Quer aprender a tocar guitarra?

Quem não gostaria de aprender a tocar guitarra? Então você precisa dessa guitarra: GTar!  A GTar possui um dock onde o iPhone é acoplado.

A GTar é elétrica e não necessita de cabos para funcionar. Seu corpo é feito em madeira e as cordas são do mesmo material de uma guitarra verdadeira. No entanto a afinação do instrumento não faz diferença na sonoridade do mesmo, uma vez que o som fica a cargo do iPhone e da acústica da guitarra. As primeiras guitarras serão entregues aos compradores a partir de setembro, uma vez que a empresa já atingiu o valor necessário para iniciar a produção. Segundo a startup cada gTar custará na faixa dos US$ 450.

Ferramentas de prototipação

No post passado comentei um pouco sobre wireframes e como abordá-los como processos e não apenas como artefatos. No final do artigo, mencionei que existem algumas ferramentas que normalmente são utilizadas pelos profissionais de UX. Antes de falar um pouco sobre ferramentas, vamos relembrar um pouco sobre o que é prototipação.

A fase de prototipação é aquela em que construímos um ou mais modelos para avaliar (no caso do design centrado no usuário, junto ao usuário) se a solução que desenvolvemos ainda é valida do ponto de vista de tecnologia, negócios e dos próprios usuários. Esses protótipos podem ter várias fidelidades, a depender basicamente do que queremos comunicar com aquele wireframe e o tempo disponível.

Se queremos comunicar apenas a ideia geral por trás da solução, podemos utilizar wireframes de baixa fidelidade. Eles representam um estágio inicial no desenvolvimento do produto e carecem propositalmente de detalhes mais profundos. Por outro lado, quando queremos contemplar mecanismos e informações mais detalhadas normalmente utilizamos wireframes de alta fidelidade.

Uma das principais ferramentas para o desenvolvimento do primeiro tipo citado – os wireframes de baixa fidelidade – é o Balsamiq. Essa ferramenta é bem simples e fácil de ser utilizada e pode gerar wireframes de maneira rápida apenas arrastando os componentes diretamente da barra. Por outro lado, desenvolver interações nesses wireframes é praticamente impossível, visto que o único mecanismo para tal é a troca de páginas. A simplicidade da ferramenta se reflete no seu preço de US$79.

Balsamiq
Balsamiq

Existem muitas ferramentas que seguem a linha do Balsamiq mas que têm um ou outro recurso a mais ou a menos. Algumas também utilizadas e que têm esse diferencial são: Mockingbird (planos a partir de US$9/mês), iPlotz (planos a partir de US$15/mês), MockFlow (US$59/ano) e ForeUI (US$150).

Quando se fala de prototipação em alto nível, temos também várias ferramentas. Entre elas uma merece destaque, o Axure RP. Atualmente ela se apresenta como talvez a mais usada e completa. Podendo gerar mais do que wireframes estáticos, o Axure RP chega a versão 6.5 com a possibilidade de inserir interações complexas com o uso até de variáveis e rotinas em javascript. Tal flexibilidade e poder tem o seu preço. Nesse caso, o preço é de US$549.

Axure
Axure

Independente da ferramenta, prototipação é algo trabalhoso. Em alguns casos, o bom e velho lápis e papel ainda vai ser o jeito mais fácil de comunicar aos stakeholders qual é a melhor solução para eles, em outros, quando não houver escolha e algo formal deve ser entregue, resta escolher a melhor ferramenta.

Os 7 princípios do teste de software

No post – Os bons testes falham – falamos sobre um dos princípios de teste definidos no livro “Fundamentos de testes de software”. Hoje, compartilho com vocês dois vídeos, bem curtos, que resumem os 7 princípios definidos no livro. Os mesmos servem como referência, principalmente para aqueles que estão iniciando na área de testes.

O primeiro vídeo, exibido acima, aborda os 4 primeiros princípios, são eles:

1 – Teste demonstra a presença de defeitos.

Os testes reduzem a probabilidade que erros desconhecidos permaneçam no sistema, mas mesmo que nenhum defeito seja encontrado isso não é prova de conformidade.

2 – Teste exaustivo é impossível.

Mesmo com auxílio da automação, o número de combinações possíveis de cenários de teste numa aplicação é gigantesco, inviabilizando a possibilidade de se afirmar que TUDO foi testado.

3 – Testes devem iniciar o quanto antes e erros encontrados tarde custam mais para corrigir.

Iniciando o mais cedo possível no ciclo de vida do desenvolvimento do software, diminuímos o custo das correções e possibilitamos que erros de design, requisitos e arquitetura sejam encontrados no momento ideal. (Link para vídeo que aborda o assunto)

4 – Agrupamento de defeitos 

80% dos defeitos são causados por 20% do código. Ao identificar essas áreas sensíveis, os testes podem prioriza-las, enquanto ainda procuram por erros nas demais regiões.

O segundo vídeo, exemplifica os princípios anteriores e apresenta os 3 últimos pontos:

5 -Paradoxo do Pesticida

Caso os mesmos testes sejam aplicados repetidamente, em determinado momento eles deixam de ser úteis, ou seja, não conseguem encontrar nenhum novo defeito. Por isso, os testes precisam ser revisitados com frequência.

6 – Teste é dependente do contexto

Diferentes tipos de aplicações exigem a aplicação de técnicas diferentes de teste.
7 – A ilusão da ausência de defeitos

De nada adianta o sistema estar correto funcionalmente, porém não atender a real  necessidade do usuário.

O Cliente

Entre todos os princípios listados, acredito que os números 3 e 7 representam os principais aspectos da nossa atividade. A busca constante por antecipar cada vez mais as possíveis falhas da aplicação e assegurar que o sistema entregue atenda as reais necessidades do cliente, agregando valor ao seu negócio.

E vocês que aspectos consideram mais importantes nos testes de software?

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