Qu’est-ce que le génie logiciel et quelques exemples ?


Le terme "génie logiciel" a été utilisé par de nombreuses personnes pour signifier beaucoup de choses différentes. Le domaine du développement logiciel souffre de ce que j'appelle "l'inflation des titres de poste". En d'autres termes, beaucoup de ceux qui portent le titre d'emploi "ingénieur logiciel" ne sont pas de véritables ingénieurs logiciels, mais plutôt des programmeurs (ou peut-être un peu plus).

Alors, qu'est-ce que le génie logiciel ? C'est faire toutes les choses nécessaires pour produire des logiciels de haute qualité sur lesquels quelqu'un peut compter. Une façon d'expliquer ce que sont toutes ces choses est de voir ce que disent les experts du domaine. En 1998 environ, un groupe d'organisations comprenant les deux principales sociétés techniques en informatique (l'Association for Computing Machinery et la société informatique IEEE), ainsi qu'une douzaine de grandes entreprises qui développent des logiciels de très haute qualité et très complexes, ont entrepris de définir ce qu'un véritable ingénieur logiciel doit savoir. Après plusieurs années de travail intensif, cet effort a abouti à un document intitulé "Guide to the Software Engineering Body of Knowledge" (souvent appelé SWEBOK). Ce guide en est maintenant à sa troisième version après avoir été revu et corrigé par plus de 1000 experts du monde entier. Il est maintenu par l'IEEE Computer Society et peut être acheté auprès d'elle sous forme de livre imprimé ou téléchargé gratuitement en PDF à l'adresse www.swebok.org.


Le SWEBOK définit 15 domaines de connaissances qui sont considérés comme essentiels pour un véritable génie logiciel. Chacun d'entre eux, à son tour, est divisé en une douzaine de sujets plus détaillés. L'un de ces 15 est la construction logicielle (programmation) et les autres sont des choses comme les exigences logicielles, la conception logicielle, la gestion de la configuration logicielle, les tests logiciels, la qualité logicielle, la gestion de projet logiciel, et bien d'autres. Le document SWEBOK comporte également une excellente liste de matériel de référence.


Il y a pas mal de choses impliquées dans le véritable génie logiciel. Un examen du document SWEBOK est un bon point de départ si vous essayez de comprendre tout ce qui est impliqué dans la réalisation d'un véritable génie logiciel. Mais il ne s'agit là que des connaissances de base. Il y a aussi la question de l'expérience, à la fois dans le développement de logiciels et dans la compréhension des applications pour lesquelles on écrit des logiciels.

Notez que le véritable génie logiciel permet à une personne (ou, plus souvent, à une équipe d'ingénieurs logiciels) de développer un logiciel très complexe, comme celui qui est nécessaire pour un système de contrôle du trafic aérien ou une centrale nucléaire ou un avion ou une automobile moderne. Un exemple illustrant un projet de cette envergure serait très vaste. J'ai fourni ci-dessous un exemple simplifié de ce qu'il faudrait faire pour concevoir le logiciel d'une application un peu plus petite. Il est basé sur plusieurs produits sur lesquels j'ai travaillé au cours de ma carrière :

  • un système de navigation pour un navire,
  • un progiciel qui était un précurseur des systèmes modernes de traitement de texte,
  • un système radar pour les hélicoptères commerciaux,
  • un système d'exploitation pour un superordinateur,
  • et plusieurs autres.

Ci-après, j'ai énuméré les activités qu'un ingénieur logiciel effectue lors du développement d'une grande application logicielle vraiment professionnelle et de haute qualité. Notez que, bien que j'aie énuméré les activités du génie logiciel dans un ordre particulier, beaucoup d'entre elles se produisent simultanément les unes avec les autres et, souvent, vous faites certaines d'entre elles à plusieurs reprises.

  1. Comprendre le problème à résoudre. Cela nécessite souvent une connaissance approfondie du domaine d'application. Un logiciel pour la navigation de navires ou d'avions nécessite des connaissances bien différentes de celles d'un logiciel pour la résolution d'applications commerciales, qui à son tour nécessite des connaissances bien différentes de celles d'un logiciel pour un dispositif médical critique pour la sécurité, qui est bien différent d'un logiciel pour une application de téléphone intelligent.
  2. Comprendre les technologies disponibles. Quels dispositifs matériels seront impliqués et ce qu'ils seront capables de faire et ce que le logiciel devra faire. C'est ce qu'on appelle parfois l'ingénierie des systèmes et, dans la mesure où elle est nécessaire, elle requiert des ingénieurs qui connaissent plusieurs technologies. Au début de ma carrière, les personnes qui effectuaient ce travail présentaient leurs résultats à l'équipe logicielle, mais au fur et à mesure que les logiciels devenaient de plus en plus importants dans la conception de systèmes complexes, les ingénieurs logiciels sont devenus de plus en plus responsables et impliqués dans cette activité.
  3. Prendre des décisions sur les outils, les langages et les méthodologies de développement de logiciels qui ont le plus de sens. Il s'agit d'une activité d'analyse et de planification qui nécessite la connaissance de plusieurs langages, outils et méthodologies. Vous ne vous contentez pas de prendre votre langage de programmation préféré et de l'utiliser. Par exemple, vous pouvez utiliser un ordinateur pour lequel votre langage préféré n'a pas de compilateur ou votre langage préféré peut être mal adapté à l'application.
  4. Participer aux décisions concernant les parties du logiciel qui doivent être développées par quelles organisations (dans le cas d'un grand projet, il peut y avoir plusieurs organisations impliquées). Ces organisations peuvent ne pas toutes faire partie de votre entreprise. Si une partie du logiciel doit être acquise auprès d'une autre organisation ou développée par elle, vous devrez peut-être aussi vous impliquer dans l'établissement et la négociation des obligations contractuelles et autres exigences que vous imposerez à ces fournisseurs.
  5. Décider de la manière dont le logiciel sera décomposé en paquets indépendants, souvent appelés "éléments de configuration". C'est-à-dire, quelles seront les parties principales.
  6. [Bien qu'il ne s'agisse pas d'une fonction d'ingénierie logicielle en soi, vous pouvez également être amené à aider à rédiger des propositions à des clients potentiels, en expliquant comment vous allez développer votre logiciel et pourquoi le vôtre est une approche appropriée pour l'application spécifique. Souvent, les grands projets sont mis en concurrence par différentes entreprises qui ont l'expertise appropriée.]
  7. Déterminer les exigences pour le logiciel et comment elles remontent aux exigences de niveau supérieur du système. Généralement, les exigences sont d'abord établies par les clients ou par des ingénieurs de niveau supérieur qui les définissent dans leur propre terminologie. L'ingénieur logiciel doit les traduire en une terminologie compréhensible pour les développeurs de logiciels. Cela implique souvent de nombreuses discussions, voire des débats, avec les clients et d'autres personnes pour régler les détails et déterminer exactement ce qui est nécessaire. Il arrive souvent que les clients ne sachent pas vraiment ce qu'ils veulent ou, dans le cas d'un grand projet, que différentes parties de l'organisation du client aient des opinions différentes sur ce que devraient être les exigences. Il est également essentiel d'établir une approche de gestion des modifications des exigences. Les exigences sont fréquemment modifiées (généralement par les clients, mais parfois par des ingénieurs qui se rendent compte que les exigences initiales sont trop coûteuses ou techniquement irréalisables). Vous devez être en mesure de comprendre les conséquences des changements proposés sur le coût et le calendrier du logiciel afin que, lorsque des changements sont proposés, vous puissiez faire connaître les conséquences aux décideurs tels que les clients ou les responsables de niveau supérieur (généralement, les changements nécessitent des retards de calendrier et des augmentations de coûts).
  8. Élaborer un plan complet pour le développement du logiciel. En tenant compte de questions telles que les budgets disponibles, les contraintes de temps et les objectifs de calendrier, les risques et les ressources disponibles, il faut concevoir un plan pour savoir comment développer le logiciel. Cela vous permet de savoir de combien de personnes et de quel équipement vous avez besoin, ainsi que de combien d'argent et de temps vous avez besoin. Bien qu'un bon plan exige que vous ayez une compréhension raisonnable des exigences, vous devez souvent faire une grande partie de votre planification dans le cadre de l'étape 6 (ci-dessus), car les clients décident souvent de l'entrepreneur à utiliser en fonction de la qualité de leurs plans de développement de logiciels.
  9. Développement de l'architecture du logiciel. Cela commence en fait aux étapes 4 et 5 (ci-dessus), mais vous devez étoffer beaucoup de détails ici.
  10. Développement de la conception détaillée du logiciel. C'est là que vous arrivez à tous les détails vraiment fins mais très importants.
  11. Écrire le code. Enfin, à l'étape 11, vous commencez à programmer.
  12. Développer un plan d'intégration et de test efficace pour le produit et le logiciel. Cela commence également plus tôt, mais après le début de la programmation, les activités d'intégration et de test deviennent importantes. Sur un grand projet, il est essentiel d'avoir bien réfléchi à cela.
  13. Conduire les processus d'intégration et de test et, lorsque des problèmes sont trouvés, déterminer ce qui n'a pas fonctionné et pourquoi et refaire tout ce qui doit être refait parmi les étapes précédentes afin de résoudre les problèmes.
  14. Déterminer comment le produit sera livré, installé, maintenu et mis à niveau une fois dans l'environnement du client. Ensuite, mettre en œuvre tous les outils et capacités nécessaires pour que cela se produise. (Pensez à tout ce qui est nécessaire pour que les mises à jour de logiciels fonctionnent correctement, par exemple.)
  15. Déterminer quels critères de qualité sont appropriés pour le produit et mettre en œuvre divers examens, inspections et autres mécanismes pour évaluer la qualité et garantir que les normes de qualité sont respectées. [Cette activité commence également beaucoup plus tôt et en parallèle avec une grande partie de ce qui précède.]
  16. Établir et maintenir une approche de contrôle de la configuration pour le projet et mettre en œuvre cette approche. Cela implique des choses comme les conventions de dénomination des versions et des composants logiciels, les méthodes d'autorisation des changements et la garantie que les changements ne se chevauchent pas et ne causent pas de problèmes, la garantie que la bonne version de chaque composant est celle utilisée pour chaque version ou version du produit, etc.
  17. Documenter de nombreuses choses en cours de route afin que ceux qui doivent maintenir et soutenir le produit après que vous soyez passé à autre chose puissent comprendre tous les aspects de tout ce qui précède.

Il y a beaucoup de choses que j'ai laissées de côté dans ce qui précède, dont certaines pourraient ne s'appliquer qu'à certains projets. Un petit projet tel qu'un site Web ou une application typique pour téléphone intelligent pourrait ne pas nécessiter une approche aussi étendue que celle que j'ai décrite ici, mais vous avez demandé ce qu'est le génie logiciel et j'ai pensé vous donner une idée de ce que les vrais ingénieurs logiciels professionnels passent leur temps à faire.

Je dois également mentionner que certaines méthodes de développement de logiciels, comme les méthodes "agiles", sont très itératives, ce qui signifie qu'elles passent par une grande partie de ce qui précède à plusieurs reprises, mais pas nécessairement avec un haut degré de discipline et de rigueur pour chaque itération.

Je dois également mentionner qu'un très gros projet de génie logiciel implique une grande équipe de personnes et que des compétences en gestion des personnes vont être requises de tous les participants, en particulier des chefs d'équipe et d'autres personnes ayant des niveaux de responsabilité plus élevés.