Bon, je pensais principalement au bus, tout en sachant aussi qu'on réutilisait des COTS, mais effectivement, il devait y avoir un peu de software dans la charge utile (mais pas tant que ça) et dans certains composants. Mais à part le GPS qui nous fournissait des résultats «intelligents» (et d'une certaine façon c'était aussi un COTS, vu le temps qui leur fallait pour répondre à des questions simples, ils ne devaient plus être des masse à bosser dessus...), la plupart des développements en dehors de notre équipe (j'ai dit 20, c'est peut-être 30 en tout sur la durée, mais jamais plus de 20 simultanément) étaient très bas niveau. Les autres équipements, c'est principalement matériel (des capteurs qui renvoient des voltages/pulse/..., des actionneurs qui prennent des pulses/voltages en entrée, le tout qui doit être converti par le logiciel du bus)
La charge utile, par exemple, c'était principalement géré par notre logiciel (avec assez peu d'intelligence), on recevait la TC, et on transformait ça commandes sur le bus 1553. Les commandes à interpréter par le logiciel de la payload se résumaient en gros à «mute, unmute, on, off, changement de gain, changement de position de switch.» Pas vraiment de quoi occuper des centaines de développeurs a priori. (je ne compte que le logiciel, pas ceux qui développent le matériel)
Après ça dépend comment et qui on compte, je suppose. Est-ce qu'il faut intégrer les gens qui mettent au point les lois de contrôle (mais qui n'écrivent pas de code, mais une spec), est-ce qu'il faut intégrer les gens qui font le logiciel des bancs de tests, des simulateurs, ... ? Faut-il compter ceux qui ont développé il y a des années des parties réutilisées ?
Mais on n'arrive pas à des milliers, ça c'est sûr.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par 2PetitsVerres (Mastodon) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 2.
Bon, je pensais principalement au bus, tout en sachant aussi qu'on réutilisait des COTS, mais effectivement, il devait y avoir un peu de software dans la charge utile (mais pas tant que ça) et dans certains composants. Mais à part le GPS qui nous fournissait des résultats «intelligents» (et d'une certaine façon c'était aussi un COTS, vu le temps qui leur fallait pour répondre à des questions simples, ils ne devaient plus être des masse à bosser dessus...), la plupart des développements en dehors de notre équipe (j'ai dit 20, c'est peut-être 30 en tout sur la durée, mais jamais plus de 20 simultanément) étaient très bas niveau. Les autres équipements, c'est principalement matériel (des capteurs qui renvoient des voltages/pulse/..., des actionneurs qui prennent des pulses/voltages en entrée, le tout qui doit être converti par le logiciel du bus)
La charge utile, par exemple, c'était principalement géré par notre logiciel (avec assez peu d'intelligence), on recevait la TC, et on transformait ça commandes sur le bus 1553. Les commandes à interpréter par le logiciel de la payload se résumaient en gros à «mute, unmute, on, off, changement de gain, changement de position de switch.» Pas vraiment de quoi occuper des centaines de développeurs a priori. (je ne compte que le logiciel, pas ceux qui développent le matériel)
Après ça dépend comment et qui on compte, je suppose. Est-ce qu'il faut intégrer les gens qui mettent au point les lois de contrôle (mais qui n'écrivent pas de code, mais une spec), est-ce qu'il faut intégrer les gens qui font le logiciel des bancs de tests, des simulateurs, ... ? Faut-il compter ceux qui ont développé il y a des années des parties réutilisées ?
Mais on n'arrive pas à des milliers, ça c'est sûr.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.