Ouvrir le menu principal

Génie logiciel

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 (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].

Sommaire

DéfinitionsModifier

Selon l'arrêté ministériel du 30 décembre 1983 relatif à l'enrichissement du vocabulaire de l'informatique [Journal officiel du 19 février 1984], 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. 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.

HistoireModifier

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 oeuvrant 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 logicielleModifier

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 graphique, 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 personnel 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 logicielModifier

Article détaillé : Ingénieur logiciel.

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 logicielModifier

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 » ) - Edité 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 logicielModifier

Article détaillé : SWEBOK.
Article connexe : développement logiciel.

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.

Les méthodes et pratiques de développementModifier

 
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 rafiné, 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 AgileModifier

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 4 à 7 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 pratiqueModifier

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]

Voir aussiModifier

Sur les autres projets Wikimedia :

Articles connexesModifier

Liens externesModifier

BibliographieModifier

  • 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érencesModifier

  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 9780769551661, 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 2 juin 2019)
  5. (en) Snyder, Lawrence,, Fluency with information technology : skills, concepts, & capabilities (ISBN 9780134448725, 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 2 juin 2019)
  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)

Erreur de référence : La balise <ref> nommée « uhcl reprint » définie dans <references> n’est pas utilisée dans le texte précédent.