Aller au contenu

Génie logiciel

Un article de Wikipédia, l'encyclopédie libre.
Génie logiciel
Partie de
Pratiqué par
Ingénieur ou ingénieure logiciel, Ingénieur logiciel de recherche (d)Voir et modifier les données sur Wikidata

Le génie logiciel, l'ingénierie logicielle ou l'ingénierie du logiciel (en anglais : software engineering) est une science de génie industriel qui étudie les méthodes de travail et les bonnes pratiques des ingénieurs qui développent des logiciels. Le génie logiciel s'intéresse en particulier aux procédures systématiques qui permettent d'arriver à ce que des logiciels de grande taille correspondent aux attentes du client, soient fiables, aient un coût d'entretien réduit et de bonnes performances tout en respectant les délais et les coûts de construction[1].

Définitions

[modifier | modifier le code]

Selon l'arrêté ministériel du relatif à l'enrichissement du vocabulaire de l'informatique [Journal officiel du ], le génie logiciel est « l'ensemble des activités de conception et de mise en œuvre des produits et des procédures tendant à rationaliser la production du logiciel et son suivi ».

Est aussi appelée génie logiciel l'ingénierie appliquée au logiciel informatique, c'est-à-dire l'activité par laquelle le code source d'un logiciel est spécifié puis produit et déployé. Le génie logiciel touche au cycle de vie des logiciels. Toutes les phases de la création d'un logiciel informatique y sont enseignées : l'analyse du besoin, l'élaboration des spécifications, la conceptualisation du mécanisme interne au logiciel ainsi que les techniques de programmation, le développement, la phase de test et finalement la maintenance.

Le guide SWEBOK du IEEE définit les champs de connaissance du génie logiciel, comme le Project Management Body of Knowledge (PMBOK) du Project Management Institute (PMI) le fait, pour la gestion de projet.

Le terme anglais « Software » est utilisé la première fois en 1958 par le statisticien John Tukey[2]. Les premières bases du génie logiciel, en anglais « software engineering », sont attribuées à l'informaticienne et mathématicienne Margaret Hamilton, la conceptrice du système embarqué du programme Apollo[3],[4]:

« Quand j'ai proposé la première fois le terme, personne n'en avait entendu parler auparavant, du moins dans notre monde [NdT: à la NASA]. Pendant assez longtemps ils aimaient me charrier sur mes idées radicales. Ce fut une journée mémorable lorsque l'un des gourous les plus respectés dans le domaine du hardware a expliqué lors d'une réunion qu'il était d'accord avec moi pour dire que le processus de construction d'un logiciel devrait également être considéré comme une discipline d'ingénierie, au même titre que le matériel électronique. Pas à cause de son acceptation du nouveau terme en tant que tel, mais parce que nous avions gagné son approbation et celle des autres personnes présentes dans la salle comme œuvrant dans un domaine d'ingénierie à part entière[5].  »

Le terme « software engineering » a été mentionné publiquement pour la première fois en 1968 [6] pour une conférence organisée par l'OTAN sur le sujet[7]. Il a été repris l'année suivante à une conférence concernant la crise du logiciel. La crise du logiciel est une baisse significative de la qualité des logiciels dont la venue coïncide avec le début de l'utilisation des circuits intégrés dans les ordinateurs : l'augmentation de la puissance de calcul des ordinateurs a permis de réaliser des logiciels beaucoup plus complexes qu'auparavant. En 1972, l'IEEE lance un premier périodique, « Transactions on Software Engineering », consacrant ainsi cette discipline émergente de l'ingénierie[2].

Les premières tentatives de création de logiciels de grande ampleur ont vite montré les limites d'un travail informel d'ingénieurs logiciel : les produits réalisés ne sont pas terminés dans les temps, coûtent plus cher que prévu, ne sont pas fiables, sont peu performants et coûtent cher en entretien. La baisse du coût du matériel informatique s'accompagnait d'une augmentation du coût du logiciel. Des études se sont penchées sur la recherche de méthodes de travail adaptées à la complexité inhérente aux logiciels contemporains et ont donné naissance au génie logiciel[8].

Aujourd'hui (en 2004), l'utilisation des méthodes de génie logiciel reste quelque chose de relativement peu répandu dans l'industrie du logiciel. Le programmeur travaille souvent comme un artisan, guidé par son talent, son expérience et ses connaissances théoriques et la crise du logiciel s'apparente à une maladie chronique de l'industrie du logiciel[9].

Complexité des logiciels ayant ouvert la voie à l'ingénierie logicielle

[modifier | modifier le code]

Jusqu'en 1985, les ordinateurs appartenaient à des sociétés ou des institutions. Dans les années 1950 à 1960 les logiciels étaient développés par des membres des institutions pour leurs propres besoins, la distribution de logiciel était très limitée, et ceux-ci servaient essentiellement à effectuer des traitements par lots (anglais batch).

En 1970 sont apparus de nouvelles notions telles que le multi-utilisateur, les interfaces graphiques, la programmation concurrente, les bases de données et le temps-réel. Les logiciels sont devenus beaucoup plus sophistiqués qu'auparavant, du fait qu'ils mettent en œuvre et exploitent ces nouveautés. C'est à la même époque que sont apparus les premiers éditeurs de logiciels et que le logiciel est devenu un bien du marché.

Depuis 1973, et a fortiori depuis l'arrivée des ordinateurs personnels en 1980, le logiciel devient un bien de grande distribution, orienté vers le consommateur, par l'arrivée des progiciels — des logiciels prêts-à-porter. Le prix du matériel informatique a également beaucoup diminué, ce qui augmente la proportion du coût du logiciel sur le coût total de l'ordinateur.

Entre 1985 et le début des années 2000, avec l'avènement des systèmes distribués, de l'Internet, de l'architecture client-serveur et du cloud computing, le logiciel passe du statut de produit stand-alone indépendant à celui d'élément d'un ensemble, dans lequel plusieurs ordinateurs et plusieurs logiciels travaillent en collectivité. L'arrivée de la programmation orientée objet et la conception orientée objet transforment le travail des ingénieurs et les logiciels incluent alors des formes d'intelligence artificielle telle que la reconnaissance de forme, la déduction automatique, la traduction automatique et l'exploration de données[10].

Professions du génie logiciel

[modifier | modifier le code]

Le génie logiciel s'exerce au travers des diverses professions suivantes :

Les professionnels du génie logiciel sont amenés à travailler dans tous les domaines où le développement de logiciel est nécessaire, par exemple dans les secteurs suivants:

Normes internationales en génie logiciel

[modifier | modifier le code]

Le génie logiciel repose sur un ensemble de normes de niveau international permettant de définir le champ de connaissance et d'application.

  • IEEE Standard for Software Quality Assurance Processes - IEEE Std. 730
  • IEEE Standard for Configuration Management in Systems and Software Engineering - IEEE Std. 828
  • IEEE Standard for Software Test Documentation - IEEE Std. 829
  • IEEE Recommended Practice for Software Requirements Specifications - IEEE Std. 830[11].
  • IEEE Recommended Practice for Software Design Descriptions - IEEE Std. 1016
  • IEEE Standard for Software User Documentation - IEEE Std. 1063
  • SWEBOK - Guide du corpus de connaissances en génie logiciel ( « Software Engineering Body of Knowledge » ) - Édité par l'IEEE et également disponible en tant que rapport technique ISO/IEC TR 19759:2015
  • Normes et Guides d'ingénierie du logiciel pour les très petits organismes - ISO/CEI 29110
  • Software life cycle processes - ISO/CEI/IEEE 12207

Également, ISO 15504 fourni un ensemble structuré de bonnes pratiques destinées à appréhender, mesurer et améliorer la qualité des produits d'une entreprise d'ingénierie informatique.

Domaines de connaissance du génie logiciel

[modifier | modifier le code]

Le domaine de connaissances du génie logiciel couvre en particulier le cycle de vie d'un logiciel, les activités clés du cycle de vie — depuis la demande d'un maître d'ouvrage jusqu'à la mise hors service définitive du produit — et l'ordre dans lequel ces activités sont effectuées. Il couvre également les différentes personnes impliquées: technico commercial, les ingénieurs, les acheteurs, les utilisateurs, et le directeur des systèmes d'information.

Selon le SWEBOK les activités clés du cycle de vie d'un logiciel sont : l'analyse fonctionnelle, l'architecture, la programmation, les tests, la validation, la maintenance et la gestion de projet.

Analyse des besoins
Consiste à récolter des informations détaillées concernant l'éventail de fonctions que devra offrir le logiciel, ainsi que les résultats qu'il devra donner. Des connaissances du domaine d'activité du logiciel (exemple: banque, industrie, administration) facilitent le travail de l'ingénieur.
Conception
Consiste à déterminer et schématiser les grandes lignes des mécanismes qui devront être programmés en vue d'obtenir chacune des fonctions que devra offrir le logiciel.
Des plans conceptuels du logiciel selon les formalismes de modélisation (UML par exemple) seront alors réalisé. C'est également à cette étape que l'utilisation de patrons de conception logiciel sont appliqués afin de résoudre certains problèmes de conceptions communs. Le recours à l'architecture logicielle pourra également être effectué.
Construction
Consiste à la rédaction du code source, des instructions de programme qui offriront les fonctions attendues, et qui sont le corps du logiciel. La programmation est alors effectuée en suivant les plans initialement établis lors de la conception. Selon la méthodologie choisie (ex: itératif), les ingénieurs pourront retourner sur les planches a dessin afin d'ajuster la conception avec la réalité de la construction.
Tests
Une suite de vérifications faites par les ingénieurs qui servent à déceler un maximum de bugs, des défauts de programmation qui provoquent des pannes ou des résultats incorrects. La validation est un examen réalisé par le client durant lequel il vérifie que les fonctions offertes par le logiciel correspondent à ses attentes et à ses besoins.
Maintenance
Des opérations d'analyse, de programmation et de test réalisés après coup, une fois que le logiciel a été mis à disposition des utilisateurs et durant lesquelles le logiciel subit des transformations, des corrections ou des améliorations. La facilité de cette maintenance dépendra de l'importance qui lui a été accordé durant la phase de conception.
Gestion de projets
Une activité réalisée tout au long des travaux sur le logiciel, qui consiste à organiser une équipe d'ingénieurs, répartir les tâches et veiller à l'avancée des travaux en vue de finir dans les délais prévus. C'est une activité de management également exercée dans d'autres domaines d'ingénierie.
Les outils et méthodes
Les thématiques du génie logiciel recouvrent notamment les outils et méthodes de spécification de fonctionnalités d'un logiciel, les méthodes formelles (Méthode B par exemple), les outils et les méthodes de conception de logiciel, les outils de conception, atelier logiciel, Ingénierie des modèles Kermeta par exemple, l'automatisation de l'optimisation du code.
D'autres domaines sont connexes au génie logiciel dans la mesure où ils partagent des outils communs : description formelle du code, grammaires des langages manipulés. Ces domaines sont par exemple :
La Gestion de la Qualité
Bien que l'on passe du génie de la production à celui de la décision, ces domaines ont un impact tellement important sur l'activité de génie logiciel qu'ils doivent être mentionnés [12]:
La gestion de la configuration
Permet de contrôler les évolutions du code produit et les différentes versions du produit.

Méthodes et pratiques de développement

[modifier | modifier le code]
cycle en spirale

Le domaine de connaissance des méthodes concerne l'ordre dans lequel sont effectués les différents travaux de développement d'un logiciel - en cascade, en V, itératif, en sprints ou parallèlement:

Cascade
La méthode classique de génie consiste à effectuer successivement, en cascade, les travaux d'analyse fonctionnelle, puis de conception, de programmation et de test.
Cycle en V
Le cycle en V est une autre méthode classique, partagée avec l'ingénierie de systèmes. Elle consiste à concevoir un système fait de parties plus simples, qui à leur tour seront conçues puis réalisées et vérifiées, avant que le système ne soit assemblé et vérifié dans son ensemble.
Itératif
Une autre méthode consiste à effectuer les travaux d'analyse, de programmation, de test et de validation tout d'abord sur un jeu restreint de fonctions du logiciel, puis une nouvelle itération servira à répéter ces opérations sur un jeu de fonctions plus raffiné, et ainsi de suite, selon un cycle en spirale.
Agile
Agile est un qualificatif de divers procédés de développement en rupture avec les procédés d'ingénierie classiques hérités du génie. Ces procédés mettent l'accent sur les changements constants de cahier des charges et de code source des logiciels, une collaboration étroite et une forte implication de l'utilisateur final, et un cycle de développement en spirale avec de nombreuses et courtes itérations. Scrum, Extreme programming et Rational Unified Process sont des méthodes agile[13].

Quelques pratiques agiles

[modifier | modifier le code]
Extreme
Dans la méthode Extreme programming les activités d'analyse, de programmation, de test et de validation sont effectuées continuellement et parallèlement, selon un cycle qui comporte de très nombreuses et fréquentes itérations avec à chaque fois un jeu restreint de fonctionnalités. Ce procédé, appelé intégration continue, implique une forte coopération de l'utilisateur, qui est considéré comme coauteur du logiciel[14].
Scrum (pratique Agile)
Dans la méthode de gestion de projet Scrum, les itérations - sprints - sont d'une durée fixe de 1 à 4 semaines, durant lesquelles les intervenants se voient attribuer des travaux d'analyse, de programmation et de test, conformément à une liste de priorités. Les tâches sont distribuées de façon à occuper une équipe de 3 à 9 personnes et obtenir au bout d'un mois un logiciel candidat - mais incomplet - qui sera présenté au client[15].
Brouillon
Quick-and-dirty, littéralement rapide et sale, traduit vite fait, mal fait, est une méthode de programmation souvent utilisée pour réaliser des prototypes et des maquettes, elle est utilisée en particulier en vue de présenter rapidement au client un brouillon du logiciel.

Croyances erronées de la pratique

[modifier | modifier le code]

Les études en génie logiciel ont également relevé diverses croyances erronées de la communauté des ingénieurs qui ont un impact direct sur leurs méthodes de travail. exemples :

  • un logiciel peut être construit uniquement par assemblage de fonctions et de standards
Les standard et fonctions existantes sur le marché sont une aide utile, mais ne sont pas suffisamment complets et adaptables pour permettre la construction complète du logiciel[réf. nécessaire].
  • ajouter des personnes à une équipe d'ingénieurs permet de rattraper le retard
C'est le contraire: les personnes qui arrivent doivent être formées et informées sur le logiciel en cours de construction par les autres ingénieurs, ce qui entraîne des retards supplémentaires. (loi de Brooks)
  • le travail est terminé une fois que le logiciel fonctionne
L'expérience montre que la majeure partie du travail commence après la livraison du logiciel au client. (phase de maintenance)[16]

Le génie logiciel empirique est la branche du génie logiciel qui s'intéresse à la validation ou à la réfutation de ces croyances.

Personnalités liées

[modifier | modifier le code]
  • Mary Shaw (1943-), ingénieure en logiciel américaine et professeure d'informatique.

Sur les autres projets Wikimedia :

Articles connexes

[modifier | modifier le code]

Liens externes

[modifier | modifier le code]

Bibliographie

[modifier | modifier le code]
  • Strohmeier A., Buchs D., Génie logiciel : principes, méthodes et techniques, Lausanne, Presses polytechniques et universitaires romandes, 1996.
  • SWEBOK: Software Engineering Body Of Knowledge, norme IEEE, 2014.
  • Wohlin, Claes, Per Runeson, Martin Höst, Magnus C. Ohlsson, Björn Regnell, and Anders Wesslén. Experimentation in software engineering. Springer Science & Business Media, 2012.

Notes et références

[modifier | modifier le code]
  1. Marylène Micheloud et Medard Rieder, Programmation orientée objets en C++: Une approche évolutive, PPUR presses polytechniques, 2002, (ISBN 9782880745042)
  2. a et b (en) Bourque, Pierre, Fairley, Richard E. et IEEE Computer Society, Guide to the software engineering body of knowledge (SWEBOK) (ISBN 978-0-7695-5166-1, OCLC 1100623800, lire en ligne)
  3. (en) « About Margaret Hamilton »
  4. (en) « NASA - NASA Engineers and Scientists-Transforming Dreams Into Reality », sur www.nasa.gov (consulté le )
  5. (en) Snyder, Lawrence,, Fluency with information technology : skills, concepts, & capabilities, , 816 p. (ISBN 978-0-13-444872-5, 0134448723 et 9780133577396, OCLC 960641978, lire en ligne)
  6. (en) Wohlin, Claes, Per Runeson, Martin Höst, Magnus C. Ohlsson, Björn Regnell, and Anders Wesslén. Experimentation in software engineering. Springer Science & Business Media, 2012,page 3 (ISBN 9783642290435)
  7. « NATO Software Engineering Conference 1968 », sur homepages.cs.ncl.ac.uk (consulté le )
  8. (en) Ian Sommerville, Software engineering, International computer science series, Pearson Education, 2001, (ISBN 9780321313799)
  9. (en) Pankaj Sharma, Software Engineering - Volume 2, APH Publishing, 2004, (ISBN 9788176485401)
  10. (en) Bharat Bhushan Agarwal et Sumit Prakash Tayal,Software Engineering,Firewall Media, (ISBN 9788131802151)
  11. Version anglaise, version française
  12. Alain April et Claude Laporte, Assurance qualité logicielle 1: concepts de base, Lavoisier, 2011, (ISBN 9782746231474), page 387
  13. (en) Peter Schuh,Integrating agile development in the real world,Cengage Learning - 2005, (ISBN 9781584503644)
  14. (en) James,Software Engineering,PHI Learning Pvt. Ltd., (ISBN 9788120335899)
  15. (en) Mike Cohn,User stories applied: for agile software development,Addison-Wesley - 2004, (ISBN 9780321205681)
  16. (en) A.A.Puntambekar,Software Engineering,Technical Publications - 2009 (ISBN 9788184313963)