Como adotar uma metodologia ágil para o desenvolvimento de firmware / software de sistemas embarcados?

17

Sempre me perguntei como aplicar métodos ágeis realmente existem em softwares de sistemas embarcados complexos e grandes (mais de 100 engenheiros). O desenvolvimento do firmware tem algumas características únicas que dificultam a agilidade (por exemplo, o hardware não está disponível até o final do ciclo de desenvolvimento; depois que o produto é lançado, não é possível atualizar facilmente o firmware; etc ...)

A norma nesse tipo de desenvolvimento é a documentação espessa e as exaustivas revisões por pares. Você não pode obter uma correção de código simples, como renomear uma variável sem 2-3 assinaturas. (Eu exagerei um pouco, mas isso é típico. Além disso, muitas pessoas usam atalhos e os gerentes de projeto até os aprovam, especialmente diante dos prazos rígidos do mercado.)

Gostaria de ouvir algumas dicas ou diretrizes sobre como adotar a metodologia ágil para projetos de desenvolvimento de firmware.

hopia
fonte
Entendo que o hardware finalizado não está disponível até o final do ciclo de desenvolvimento, mas você não possui hardware de protótipo ou depuração, uma placa de desenvolvimento ou pelo menos um simulador de fornecedor para testar? Ou estamos começando do zero aqui?
Kevin Vermeer
3
Eu estava conversando com um desenvolvedor ágil sobre meu trabalho incorporado. "Um lançamento a cada 6-8 semanas!?!?" ele disse. "Isso é realmente muito tempo". "Não, você entendeu mal me", eu disse, "é de 6 a 8 meses "
AShelly
2
Estou curioso para saber que tipo de produto possui mais de 100 engenheiros embarcados?
pemdas
@reemrevnivek - geralmente há uma placa de avaliação de projetos anteriores que poderia ser usada. Às vezes, eles são semelhantes o suficiente para o novo produto. Mesmo assim, mesmo que todos os seus testes estejam passando na placa de avaliação quando você executa o firmware no dispositivo final, na maioria das vezes, os testes serão interrompidos porque houve algumas coisas novas que os caras do hardware decidiram adicionar no último minuto ou talvez não mencionou a nós no início ....
hopia

Respostas:

10

Eu acho que duas técnicas são fundamentais:

  • Desenvolva um simulador completo ou ambiente de teste para o hardware, para que você possa desenvolver o software como se tivesse hardware real. Não economize ou use atalhos aqui: o desenvolvimento de um bom simulador será recompensado.

  • Escreva vários testes de unidade no simulador.

Depois que você fizer essas coisas e as pessoas tiverem certeza de que o simulador e os testes de unidade fornecerão uma idéia precisa de como as coisas funcionarão com o hardware, será mais fácil adotar outras técnicas ágeis (iterações curtas, refatoração implacável etc.) .

Kristopher Johnson
fonte
Além disso, faça com que os fabricantes de chips forneçam a parte relevante do código do simulador.
Rwong 9/04
no momento em que você tem essas coisas que um concorrente já enviou
Bill
Se você tiver mais de 100 engenheiros, certamente poderá criar um simulador utilizável em menos tempo do que seus concorrentes enviarão. Isso é especialmente verdade se seus concorrentes não tiverem como testar seus softwares até receberem o hardware.
9119 Kristopher Johnson
Sim, concordo que os simuladores são fundamentais. Assim, está projetando todo o sistema desde o início, com base na eficiência com que você pode dividir o sistema em componentes testáveis. Agora, como para convencer todas as pessoas para ir ágil é outra questão ........
hopia
@ bill Isso é muito provável. No entanto, isso provavelmente significa que eles enviaram um produto inferior não testado e o produto do OP os expulsará da água. Bem, pelo menos é assim que deve ser.
Julio
2

O impacto do Agile em um processo de desenvolvimento envolvendo vários fornecedores pode ser comparado ao que acontece quando uma empresa faz JIT.

Para entregar o JIT, cada um dos fornecedores da empresa deve entregá-lo.

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

Da mesma forma, se você deseja que um produto complexo seja desenvolvido de acordo com as metodologias Agile, todos os subgrupos da cadeia devem funcionar dessa maneira.

Em termos de desenvolvimento 'incremental' (também conhecido como Tracer Bullets de 15 anos atrás), isso implicaria que o 'núcleo' seja lançado muito em breve para o motorista, e que o driver básico esteja disponível para o integrador e que a GUI ser desenvolvido, com um único botão e uma caixa de edição, ao mesmo tempo.

A parte difícil é convencer os projetistas de hardware, provenientes de uma sólida disciplina de engenharia inovadora, a ingressar na nossa sociedade de consertadores.

A segunda parte mais difícil é encontrar uma maneira de permitir o desenvolvimento incremental em um mundo onde uma impressão de hardware deve ser solicitada com três semanas de antecedência. Estou pensando emuladores, FPGA está aqui. Eu não sou um cara de hardware, no entanto.

Se você deseja optar pelo desenvolvimento incremental de hardware, pode, assim como nos limites de uma cadeia JIT, prever um mecanismo de buffer que permita que as equipes Agile avancem.

Não sejamos cegos: o Agile também precisa lidar com processos pesados! Não peça à equipe do Agile para 'refatorar' agora sua base de código Java para Python no próximo sprint. É apenas porque algumas das partes são realmente estáveis ​​que podemos dançar nossos movimentos ágeis em cima delas.

xtofl
fonte
+1 para agile apenas sendo possível porque o material subjacente foi totalmente projetado / executado.
Bill
1

Manifesto Ágil: http://agilemanifesto.org/

"Indivíduos e interações sobre processos e ferramentas"

  • Conheça mais. Empurre menos papel.

"Software que trabalha sobre uma documentação completa"

  • Protótipo e construção de picos de tecnologia cedo e frequentemente.

  • Resolva o problema real do usuário em vez de continuar a criar aderência exigente a uma especificação. Isso significa soluções evolutivas . A idéia de que precisamos construí-la da maneira correta, porque nunca mais podemos construí-la de novo, está errada. Planeje a iteração. Faça parte da estratégia de marketing e implementação.

"Colaboração do cliente sobre negociação de contrato"

  • Os processos hiper-complexos de controle de alterações são apenas maneiras de dizer "não" ao cliente.

  • O bloqueio antecipado de todos os requisitos e a imposição do controle de alterações é outra maneira de dizer "não".

  • Se você já planeja mais de uma versão, poderá adiar mais facilmente os requisitos para uma versão posterior. Depois que o cliente tiver o dispositivo com o software incorporado, a próxima versão mudará em suas prioridades.

"Respondendo à mudança seguindo um plano"

  • Embora a integração complexa exija um plano complexo, o "programa" geral (ou sequência de projetos) não pode ser concretizado cedo demais.

Uma metodologia totalmente ágil (ou seja, scrum) pode não fazer sentido para um sistema incorporado.

O manifesto Agile, no entanto, fornece maneiras de permitir que as mudanças sejam possíveis sem permitir o caos simples.

S.Lott
fonte
0

Meu problema com o scrum em sistemas embarcados é que há muitas tarefas a serem executadas, especialmente nos estágios iniciais, que não são demonstráveis. Começamos com uma placa de desenvolvimento, sem sistema operacional, sem tela, sem comunicação serial, etc. Não tivemos nossa tela por 6 sprints.

Os 4 primeiros sprints foram: Instalando o RTOS Criando tarefas Criando drivers de rede e serial Criando rotinas de interrupção para botões, comunicações, etc. Criando classes e métodos principais de banco de dados Criando um menu de depuração serial

A maioria dessas tarefas não é adequada para histórias de usuários. De fato, a única interface em todo o sistema era o menu de depuração serial, construído no sprint 3, portanto não havia nada para demonstrar no final dos sprints. Até o menu serial era para uso interno e não para o usuário final.

Obviamente, cada classe que escrevemos tem testes de unidade associados e usamos uma estrutura de teste de unidade para automatizar a execução de todos os testes.

Acabamos escrevendo frases de "histórias de usuários" como "Como desenvolvedor ...", com as quais não estou feliz, mas ao usar o Target Process (www.targetprocess.com), não existe o conceito de um item de backlog que é uma tarefa ou tarefa.

Eu adoraria ouvir como os outros lidaram com essas situações.

Bruce
fonte