Problèmes de qualité, de délais, de coûts, de gestion des corrections et de la maintenance sont des défis auxquels sont confrontés tous les éditeurs. Pour y faire face ils se doivent d’industrialiser les processus de développement des logiciels qu’ils réalisent.

Par essence, le logiciel est fortement dépendant du savoir-faire et il est illusoire de vouloir se rendre indépendant des hommes, mais il est possible moyennant la mise en place de méthodes appropriées de dépendre des bonnes compétences, sans dépendre d’individus particuliers en tant que tels.

• L’industrialisation des développements logiciels et d’un département de R&D recouvre le passage d’un modèle artisanal et reposant fortement sur un savoir-faire de personnes isolées à un modèle industriel reproductible, prévisible et permettant de réduire en partie la dépendance aux individus « nommés ».

Dans quelles conditions cette industrialisation est-elle possible ?

• Cette industrialisation suppose le suivi d’une méthode rigoureuse et systématique qui contient notamment des aspects d’outillage fort (le logiciel peut servir à construire du logiciel) et d’automatisation (tout ce qui est fait au moins trois fois doit être automatisé).

C’est par ces moyens que l’on arrive à un processus prévisible et relativement reproductible, moyennant les aléas de la recherche pour certains types de logiciels ou le degré d’innovation et d’incertitude est élevé, même en ce qui concerne la faisabilité.

L’industrialisation recouvre l’ensemble du cycle de développement.

Il ne s’agit pas seulement d’équiper le développeur d’outils ou de générer du code, il faut supporter l’ensemble du cycle de développement, depuis la conception jusqu’aux retours du client qui utilise le logiciel.

L’industrialisation doit se faire sur toutes ces dimensions faute de quoi le niveau d’industrialisation réel de l’offre sera aligné sur le niveau le plus bas de ces éléments du cycle.

La boucle est constituée de 7 volets :

1. La conception produit,
2. Le développement lui-même,
3. La gestion de versions et configurations,
4. La gestion des ‘builds’,
5. La gestion du déploiement et de l’installation,
6. La gestion des tests,
7. La récupération d’informations d’exploitation

Le niveau d’industrialisation (ou de qualité) du développement d’un logiciel se fait selon 7 axes:

• La conception produit recouvre l’ensemble des éléments qui conduisent à définir le périmètre du produit.
• Ce périmètre comprend les éléments fonctionnels mais ne se réduit pas à ceux-ci.
• Il faut prendre en compte les contraintes techniques ou de plate-forme, les besoins en traduction et la manière dont le feedback des utilisateurs et clients est intégré à l’évolution pour les versions futures.
• L’industrialisation de ce volet doit donc s’évaluer en regard des différents éléments mentionnés ici, en observant les processus réellement en place, et en évitant le piège de la sur-formalisation. Certaines méthodologies « tout-UML » par exemple font croire à une industrialisation mais en fait déresponsabilise les équipes en les abritant derrière des documents formels que les utilisateurs valident sans comprendre; C’est souvent après un long effet tunnel que le problème se révèle et il est alors trop tard.

L’industrialisation au niveau développement comprend différents axes.

• Le génie logiciel est l’un des premiers qui vient à l’esprit puisqu’il s’agit de produire du code automatiquement.
• Mais ce point n’est pas suffisant, car il est tout aussi important d’utiliser au maximum des composants et de coder le moins possible, ce qui limite les risques, le coût de maintenance et permet une évolution plus rapide.
• Le caractère systématique des tests unitaires et de la revue de code par un « lead developer » expérimenté est également un élément très important pour la qualité industrielle d’un logiciel.

La gestion de versions est une discipline importante pour un éditeur de logiciels

• Elle commence par la mise en place d’un contrôle de code source qui permet de travailler en équipe et de savoir qui fait des modifications sur quel fichier source
• Lorsqu’un logiciel est déployé, il convient de créer des branches de code, avec des nécessités de report des modifications lorsqu’un bogue est découvert dans une version mais qu’il concerne plusieurs branches.
• On peut aussi gérer en version les bases de données, les binaires ou autres documents intégrés au logiciel.
• Enfin, la gestion correcte d’une base de données contenant les versions des différents éléments déployés chez les clients est importante pour gérer la maintenance.

Lorsque l’on veut faire un logiciel déployé de manière large, il est crucial de le construire dans un environnement dédié appelé « serveur de build ». Ce serveur automatise l’assemblage des composants et la compilation de l’ensemble.

L’expérience prouve qu’une construction régulière du logiciel, par exemple tous les soirs, permet de diminuer le nombre de bogues et d’observer la convergence d’un cycle de développement produit.

Des statistiques sur les erreurs peuvent permettre aussi de faire évoluer les processus de développement, ou de remonter du feedback aux équipes pour améliorer les normes de développement et la qualité en mode « amélioration continue ».

Le déploiement est un processus trop souvent sous-évalué et sous-positionné chez les éditeurs.

• Il est insuffisamment traité en terme d’investissement, mais aussi en terme de compétences car on place souvent des personnes à faible valeur ajoutée qui ont des compétences sur des outils d’installation, aujourd’hui de moins en moins pertinents compte tenu de l’évolution de la technologie (.NET notamment).
• Ceci étant, le besoin d’industrialiser le déploiement par des installations automatisées, la vérification de pré-requis ou les vérifications de compatibilité de plate-forme demeure, mais nécessite des compétences assez larges et sans cesse renouvelées.
• Il faut donc l’aborder avec le bon niveau de priorité, et également travailler la partie documentaire afin de bien documenter le contexte de fonctionnement de l’application.
• Beaucoup trop d’équipes de développement se contentent encore de dire « cela fonctionne sur mon poste ». L’utilisateur se moque éperdument du poste du développeur !

Les tests sont naturellement et évidemment un fort levier d’industrialisation

• Ils recouvrent des dimensions larges et doivent être le plus possible automatisés, notamment en ce qui concerne la non-régression
• Il ne faut pas non plus négliger les tests de performance et de montée en charge.
• Cette problématique est très différente de la performance, le besoin étant de pouvoir toujours suivre l’augmentation des sollicitations par ajout de puissance, ce qui doit en général être pensé au niveau de la conception et de l’architecture.
• Des tests liés à l’internationalisation et à la localisation : langues, formats de dates, monnaies et autres paramètres régionaux doivent également être prévus, pour éviter la découverte de problèmes au moment de la traduction.

Ce volet comprend les éléments qui peuvent être fait pour reboucler avec le déploiement chez les clients au besoin via le département support de l’éditeur

Des éléments peuvent être introduits directement par conception dans le produit afin de disposer de données sur :

1. Les erreurs en production
2. Les informations d’utilisation
3. Les compteurs de performances

• Les bogues rencontrés doivent être utilisés pour enrichir la base des tests de non-régression
• La recherche et développement peut être impliqué dans le lien avec la communauté des utilisateurs, via des contributions publiques ou des événements de type club utilisateur
• La prise en compte de l’international et les liens qui peuvent être créés avec des clients étrangers ou au travers des filiales sont souvent un élément sous-estimé également par les éditeurs qui se lancent sur ces marchés

Les enjeux de la mise en œuvre d’un scénario d’industrialisation tourne autour de quatre grands points :

• L’humain, avec le difficile compromis à trouver entre l’historique « éprouvé » et l’infusion de nouvelles compétences, l’expérience prouvant qu’un levier externe est souvent indispensable
• La méthodologie, qui nécessite souvent une évolution difficile issue d’un compromis similaire entre ce qui est mature et qu’il faut garder et ce qui doit s’adapter
• Les technologies, qui amènent aussi un besoin de nouvelles compétences sur des outils de plus en plus sophistiqués pour gérer le cycle de développement
• La gestion du changement, qui nécessite à la fois une rupture nette pour lancer une approche différente (au moins en communication) tout en définissant des étapes réalistes par « petits pas »

Les technologies et outils qui supportent l’industrialisation sont de plusieurs type :

• Les outils de la gamme Visual Studio Team System, à commencer par Team Foundation Server
• Les différentes Editions :Team Architect, Team Developer, Team Test
• Les composants visuels tiers : Infragistics, DevExpress, Telerik
• Les outils centraux dans le processus de production de code comme CodeFluent
• Les outils périphériques par exemple pour l’analyse de code comme Ndepend ou Fxcop

Visual Studio Team System fournit Team Foundation Server, une infrastructure destinée à supporter l’ensemble du cycle de développement

Sur chaque élément, peuvent aussi se brancher des outils tiers pour approfondir un axe particulier du cycle.

Sites Microsoft

• Visual Studio Team System
• Interview avec Blaise Vignon, chef de produit Visual Studio
• TFS Developer Center
• Livre blanc de l’industrialisation
• Vers la Software Factory
• Centres de compétences Team System
• FX Cop

Autres sites

• Ndepend
• CodeFluent

L’AFDEL dispose d’une commission R&D qui mériterait d’être connue de tous les CTO d’éditeurs français: