Les développeurs d’applications embarquées doivent faire face à des problèmes plus complexes que leurs confrères développeurs d’applications classiques.

Le choix d’une solution solide de Gestion de la Configuration Logicielle peut les aider à relever les défis auxquels ils doivent faire face : gérer des ensembles étendus et complexes de fichiers, fonctionner dans des environnements de développement distribués, et participer à la gestion de la propriété intellectuelle.

Perforce est de plus en plus utilisé dans les secteurs de l’électronique pour aider à accélérer les développements et le prototypage, comme pour améliorer le travail d’équipe autour de la conception des produits.

Parmi les clients de Perforce dans ce secteur on trouve CSR, Harman Becker, National Instruments, Zoran, Nvidia et TomTom.

Les défis du développement d’applications embarquées

Pour répondre aux contraintes de leur secteur, les développeurs d’applications embarquées doivent être d’autant plus exigeants quant au choix de leur solution de Gestion de la Configuration Logicielle. En effet, au-delà du besoin classique d’une application rapide, simple d’emploi et facile à administrer, une application de GCL utilisée dans le développement d’applications embarquées doit en outre être capable de gérer des ensembles étendus et complexes de fichiers, de fonctionner dans des environnements de développement distribués, et de participer à la gestion de la propriété intellectuelle.

Premier défi: gérer des ensembles étendus et complexes de fichiers

Les systèmes embarqués sont composés de nombreux composants, hardware et software. Par exemple, une puce intelligente combine des schémas, du code RTL, des données GDS, des drivers logiciels, du middleware et même un OS et des applications. Chaque système est complexe et peut contenir des variantes d’un même composant. De plus chaque système a lui-même des variantes propres à une région ou à une plateforme de telle sorte qu’un même produit puisse être vendu dans sur des marchés aux besoins différents (par exemple plusieurs versions d’un même téléphone pour les différents marchés mondiaux). Les fichiers auxiliaires, comme les jeux de tests, peuvent changer alors que les composants en cours de test sont eux-mêmes modifiés. Cependant, un build complet requiert la version correcte de chacun des composants. Le défi est de s’assurer de la corrélation entre chaque composant et ses fichiers auxiliaires.

Deuxième défi: fonctionner dans des environnements de développement distribués

Les composants des systèmes embarqués sont souvent développés sur des sites géographiques multiples. Dans certains cas des équipes outsourcées travaillent sur le même composant. Dans ces circonstances, le développement collaboratif suppose que chaque développeur ait accès en temps réel au travail de ses collègues. Le défi est de s’assurer que les différentes équipes de développement restent synchrones.

Troisième défi: participer à la gestion de la propriété intellectuelle

Les systèmes embarqués sont souvent intégrés à des technologies tierces. Dans ce cas les développeurs de tierces-parties doivent être en mesure de mettre à jour leurs contributions. Ces mises à jour doivent être répertoriées et il doit être possible de les suivre de telle sorte que les produits restent composés de versions à jours, compatibles et stables.Le défi est de permettre à chaque éditeur de contrôler et de suivre leurs contributions.

,Les bonnes pratiques à adopter pour bien utiliser la GCL dans le développement d’applications embarquées

Un bon système de Gestion de la Configuration Logicielle doit être rapide et efficace, de telle sorte que les Développeurs ne soient pas tentés de le contourner. Il doit également être suffisamment souple pour gérer les complexités propres au développement d’applications embarquées.

Voici quelques bonnes pratiques à adopter pour qu’une solution efficace et bien déployée de GCL mette de l’ordre dans un environnement complexe.

Pour assurer la gestion d’ensembles étendus et complexes de fichiers, il faut organiser les fichiers de façon cohérente et effectuer de bons builds

Les branches logicielles peuvent être utilisées pour isoler le code expérimental du code de production, ou encore pour isoler une version. Il faut choisir avec soin la source à partir de laquelle la branche est créée, par exemple pour incorporer une technologie tierce sur un composant. Avec une bonne solution de Gestion de la Configuration Logicielle on peut créer des branches et définir les relations entre les branches. Les branchements doivent se faire de telle sorte que la consommation d’espace disque soit réduite, en utilisant la technique du « lazy copying » par exemple. Cette technique permet de ne copier que les différences sans recopier ce qui est équivalent d’une branche à une autre. Ainsi les branches qui contiennent un grand nombre de fichiers peuvent être créées rapidement et sans nuire aux performances ou aux coûts.

• Un système de GCL permet de créer des espaces de travail selon les attributs des fichiers qui les composent : précisions sur la date et l’heure de création, le numéro de version, les étiquettes de contenus ...  Le système permet de s’assurer que seuls les fichiers souhaités figurent dans un espace de travail donné, garantissant ainsi la qualité des builds.

Méthodes à considérer pour faire mieux fonctionner des environnements de développement distribués

•  L’utilisation d’une solution multi-plateformes permet à des équipes d’horizons multiples de travailler ensemble, car il est rare que toutes utilisent la même plateforme. Les utilisateurs doivent pouvoir isoler leur travail en cours sur leur espace de travail personnel, puis ils doivent pouvoir le retourner sur l’espace collectif une fois leur travail achevé. Idéalement, une bonne solution de gestion de la Configuration Logicielle doit fonctionner selon les attentes de chaque type d’utilisateurs. Par exemple, les utilisateurs Java doivent retrouver leur environnement de travail habituel. Le développement collaboratif devient très efficace à partir du moment ou tous les membres d’un projet peuvent utiliser le même outil de GCL, quels que soient leurs rôles, leurs outils, leurs méthodes de travail ou leurs plateformes.

Pour participer à la gestion de la propriété intellectuelle

• L’utilisation d’une « politique de familles de fichiers – ou codeline » permet d’isoler les composants d’un projet de telle sorte que des modifications ne soient pas faites par inadvertance. Cela permet également d’éviter que le code propriétaire ne soit vu par les contributeurs extérieurs à un projet,  et de définir les rôles et les droits de chacun quant à la modification des fichiers de chaque codeline. Dans ce contexte un outil de GCL doit autoriser des mécanismes de protection d’une granularité fine, qui permettent le contrôle total des fichiers qu’il gère.
• L’utilisation des branches autorise le développement agile et le prototypage rapide. Un outil de GCL qui permet des branchements peu coûteux et qui fournit des vues configurables permet de supporter toutes les méthodes de développement, dont les méthodes agiles et le modèle V. Un système de branchements peu coûteux permet aux développeurs de réutiliser des portions de code, de travailler dessus et de les réintégrer au reste du projet sans perturber la production.
• Tous les contenus d’un projet doivent être stockés dans la même base, quel que soit leur format (pas forcément du texte). Les fichiers binaires - schémas de puces ou PDFs - sont aussi importants à contrôler que le code source, tout comme les fichiers compilés des contributeurs externes. Une solution de GCL qui autorise le « lazy copying » permet à toutes les variantes de fichiers de co-exister sans affecter l’espace de stockage.