Cette page introduira les notions de génie logiciel, de cycle de vie des logiciels, développement des SI et leurs méthodes. Elle définira les liens entre le développement de SI et le cycle de vie d'un logiciel. Et finalement, cette page traitera des différents intervenants dans un projet de développement de SI.

• Notions de base de génie logiciel (GL)
• Méthode de développement de SI
• Cycles de vie de logiciel (CVL)
• Principaux intervenants dans le processus de développement de SI
• Rôles et qualités de l'analyse de SI

La discipline du génie logiciel (GL) est un ensemble de méthodes, techniques et outils pour la production et la maintenance des systèmes d'information.

Exprimé en d'autres termes, le génie logiciel est l'art de spécifier, de concevoir, de réaliser, et de faire évoluer, avec des moyens et dans des délais raisonnables, des programmes, des documentations et des procédures de qualité en vu d'utiliser un système informatique pour résoudre certains problèmes.

Les objectifs de GL sont les suivants :

• Permettre la description des logiciels :
  • à l’aide de modèles;
  • selon une démarche (étapes) ;
  • en contrôlant la qualité;
• Aider à réaliser les systèmes informatisés (SI) correspondant aux besoins des utilisateurs;
• Diminuer les coûts, les retards et les risques des projets d’informatisation;
• Rendre l’activité de conception et de développement de SI une activité d’ingénierie au même titre que le génie mécanique, le génie civil,
• Permettre à l’équipe de conception et de développement de disposer d’un vocabulaire standard (Normes IEEE 1074/95 et ISO9126).

En GL on éprouve les besoins en:

• formation d’ingénieurs logiciel (universités) : enseignement des principes et des techniques nécessaires :
  • modélisation;
  • architecture;
  • validation;
  • organisation et gestion des projets;
  • qualité;
• création et amélioration de méthodes et outils (recherche et industrie) : amélioration des :
  • langages de programmation (niveau d'abstraction plus élevé, syntaxe et sémantique non ambiguë);
  • outils de modélisation (UML);
  • outils et techniques de validation (tests, preuves, débogage, réunion de validation,…);
• établissement de normes de gestion, d’organisation, techniques (industrie) :
  • normes de certification (ISO 900x, ISO 12207,..);
  • référentiels d'évaluation et d'aide à l'amélioration (CMM, …).

En GL on parle des approches :

1. Microscopiques : étude du logiciel en tant que produit :
   • étude des fautes de programmation (meilleur niveau d’abstraction des langages de programmation, sémantique rigoureuse et absence d’ambiguïté );
   • modèles de programmation favorisant la réutilisation (objets, composants, …);
   • test et preuve de programmes (tests structurels ou fonctionnels, relecture de code, méthodes formelles intégrant des preuves).
2. Macroscopiques : étude du processus de fabrication du logiciel :
   • définition de cycles de vie des projets (planification tâches, répartition effort, gestion des risques, estimation de coûts … );
   • statistiques sur les étapes d’introduction des fautes (identification des étapes à l’origine de l’introduction des fautes coûteuses);
   • assurance et Contrôle Qualité (établissement de normes et procédures à respecter lors déroulement du projet);
   • outils de gestion de versions;
   • environnements de développement de logiciels.

• Obtentions du modèle adéquat pour concevoir un système d'information. La qualité de chaque modèle demeure liée à la qualité des outils employés et à la maîtrise du processus d'analyse du problème à résoudre.
• Compréhension et maîtrise des processus du GL. Les statistiques montrent que plus de 30% de tous les projets de logiciel sont abandonnés avant la fin; plus de 70% du reste échouent à la livraison des caractéristiques attendues; le projet moyen dépasse de 189% son budget et de 222% son échéancier.
• Développement des outils en GL. Le GL est à la fois limité par ses outils de développement des SI et progresse au rythme de leur développement.

Le processus (le cycle) de développement de systèmes d'information consiste à construire un produit qui répond aux besoins des utilisateurs, qui s'intègre bien aux activités de l'organisation et qui est techniquement correct en respectant les budgets et les échéances préalablement établis.

La méthode (méthodologie) de développement de systèmes d'information est un ensemble d'activités utilisant divers modèles, outils et techniques qui permettent de discipliner le processus de développement de systèmes en le rendant rigoureux, donc plus facile à gérer.

Le développement de SI est un ensemble d'activités qui consiste :

• à analyser un processus d'affaire et le SI qui en est le sous-ensemble;
• à en faire le diagnostic afin d'en définir les faiblesses;
• à concevoir un nouveau processus d'affaire et/ou le nouveau SI qui lui correspond;
• à réaliser et à mettre en place SI et le processus d'affaire.

Les points de départ d'un projet de développement de systèmes d'information :

• Le système d'information existant pose des problèmes liés à la qualité de l'information;
• Les processus d'affaire ne satisfont plus les exigences de compétition.

Mais en général, les deux points de départ sont liés et dans les deux cas, la même démarche doit être suivie :

• On a besoin de transformer un processus d'affaire si certaines activités ou tâches sont modifiées dans l'entreprise;
• La transformation des processus d'affaire peut être décidée volontairement (pour améliorer le processus d'affaire existant, après l'acquisition de nouveau matériel, si de nouveaux besoins apparaissent, etc) ou s'imposer impérativement (problèmes dans les processus d'affaire et des SI existants, failles, retards, incertitudes, etc);
• Le développement de SI accompagne la transformation de processus et consiste à modifier le SI existant ou installer un nouveau SI (le processus très complexe et coûteux.

Une méthodologie est constituée :

• d'un processus prédéfini avec l'ensemble d'activités permettant d'atteindre le but de la méthode;
• d'un vocabulaire utilisé pour décrire le processus et les produits créés par l'application de celui-ci;
• d'un ensemble de règles et lignes de conduite qui définissent la qualité

Un modèle est une abstraction de quelque chose de réel (représentation d'un aspect important quelconque du monde réel) qui permet de comprendre un problème avant d'implémenter une solution.

Un modèle ne tenant compte que des éléments essentiels de l'entité originale est plus facile à manipuler. Pour construire des systèmes complexes, les développeur doit abstraire différentes vues du système, construire des modèles en utilisant la notation précise, vérifier que les modèles satisfont aux spécifications du systèmes et progressivement ajouter des détails pour transformer les modèles en une implémentation.

L'abstraction est l'examen sélectif de certains aspects d'un problème. L'objectif de l'abstraction est d'isoler les aspects d'une même chose. Toute abstraction est incomplète et imprécise. Il n'y a pas de modèle « correcte » unique d'un système, seulement des modèles adéquats ou inadéquats.

Les SI étant complexes, nécessitent une modélisation pour réduire cette complexité, pour visualiser et tester avant d'implémenter et pour communiquer avec les clients. Donc, un modèle est une simplification de la réalité pour mieux comprendre un système complexe.

Exemples de modèles utilisés pour le développement de SI

• Approche classique (structuré)
  • diagramme d'entité-relation (DER)
  • Diagramme de flux de données (DFD)
  • …
• Approche orientée-objet
  • Diagramme de cas d'utilisation
  • Diagramme de classes
  • Diagramme de séquence
  • …

Exemples de modèles utilisés pour la gestion du processus de développement

• Organigramme
• Diagramme de Gantt
• …

Dans le contexte de développement de SI, un outil est un support logiciel qui aide à créer les modèles ou les autres composantes de SI.

L'outil le plus complet à la disposition des développeurs se nomme outil CASE (Computer Aided Software Engineering) et se traduit parfois en français comme AGL (Atelier de Génie Logiciel).

Les outils CASE fondamentalement :

• aident le développeur à créer les principaux modèles d'un SI;
• vérifient que les modèles sont complets et compatibles avec d'autres modèles;
• permettent de générer le code à partir des modèles.

Exmples d'outils :

• Outils de gestion de projets (Microsoft Project, Merlin, etc);
• Éditeurs de texte (Word, OpenOffice);
• Environnement de développement intégré (IDE) → outils d'aide à la programmation (NetBeans, Eclipse, Visual Studio);
• Application de gestion de bases de données;
• Outils de

Un cycle de vie (CV) défini généralement les grandes phases par lesquelles passent un objet, un produit, une personne pour expliquer son évolution.

Un projet de développement d’un SI est composé d’étapes. Le découpage du projet en étapes et l’organisation de ces étapes varie selon le modèle utilisé. Représentation des étapes de développement et de maintenance permet de faciliter :

• planification et gestion du projet;
• contrôle de la qualité;
• communication;
• identification des métiers et des techniques propres à chaque étape.

La norme du cycle de vie du logiciel (la norme IEEE 1074-1995) (Institute of Electrical and Electronics Engineers) a été définie sur la base des processus à mettre en place pour le développement et la gestion des applications logicielles jusqu'à leur retrait (la norme la plus récente: IEEE 12220). Ses étapes qui sont de nature à limiter les risques d'un projet, comportent 6 catégories de processus :

Remarque générale : les normes constituent un ensemble de moyens et outils pour accroître la qualité des travaux effectués et la satisfaction des clients et utilisateurs (améliorer la visibilité et faciliter la communication), mais ils ne sont pas d'un grand secours pour résoudre le problème majeur, celui de l'obtention d'un modèle conceptuel satisfaisant pour amorcer le développement d'une solution. Seule une démarche éclairée d'analyse et de modélisation, accompagnée à l'occasion du développement d'un prototype, permettra de produire ce modèle.

La norme citée prévoit initialement le choix d'un modèle de cycle de vie, après quoi les mécanismes de gestion de projet seront mis en place.

1. Initialisation ou Inception
2. Élaboration
3. Construction
4. Transition

Pendant la phase d'initialisation il faut :

• Définir la vision globale du projet;
• Définir les processus métiers (processus d'affaire) impliqués avec le SI;
• Délimiter les frontières du projet;
• Identifier les entités externes qui interagiront avec le SI;
• Identifier et décrire les principaux cas d'utilisation et scénarios.
• Identifier les risques.
• Définir les bornes pour chaque incrément.

L’inception peut se définir en une phrase : Déterminer la portée, la vision et l’opportunité du projet ou du produit.

Le principal problème à résoudre pendant la phase d’inception peut se résumer en une phrase : Les parties prenantes sont-elles globalement d’accord sur la vision du projet et celui-ci mérite-t-il une étude approfondie ?

La durée de la phase d’inception ne doit pas dépasser une à quelques semaine (une semaine dans la plupart de cas).

L'élaboration qui correspond à la spécification des particularités du produit, à la planification des activités, à la détermination des ressources, à la conception, l’implémentation et à la validation itérative de l'architecture noyau du logiciel (vision plus élaborée du projet, estimations plus réalistes, résolution des risques élevés, identification de la plupart des besoins et du périmètre réel du projet). Cette phase fournit plusieurs prototypes d'architecture dans le but de définir une bonne architecture de base.

Pendant la phase d'élaboration il faut :

• Définir des exigences;
• Analyser le domaine;
• Définir un glossaire du domaine;
• Créer une ossature de l'architecture;
• Planifier le projet;
• Définir des scénarios supportés par chaque incrément;
• Éliminer les facteurs de risques les plus élevés.

La construction regroupe la réalisation du produit, à l'adaptation de la vision, de l'architecture et des plans, jusqu'à la livraison du produit (implémentation itérative des composantes, préparation du déploiement). Cette phase progresse au rythme des prototypes de développement, dont l'objectif premier est de mesurer les progrès et de garantir la stabilisation de la conception. La phase de construction se termine par la livraison de version préliminaire (version bêta) qui est placée chez des utilisateurs en vue d'être testée dans l'environnement de déploiement.

Pendant la phase de construction il faut :

• Définir les cas d'utilisation restants;
• Décrire les scénarios pour les cas d'utilisation définis;
• Développer un modèle objet complet;
• Détailler les diagrammes de séquence;
• Implémenter les classes;
• Créer les scénarios de tests basés sur les cas d'utilisation et sur l'architecture.

La transition rassemble la fabrication à grande échelle, la formation, le déploiement dans la communauté des utilisateurs, le support technique et la maintenance. Cette phase débute par l'installation des versions bêta sur le site et progresse au rythme de livraisons des versions qui viennent corriger les défauts détectés par les utilisateurs. Selon les organisations, la phase de transition s'arrête lorsque la version de production est disponible, ou que la génération suivante est livrée aux utilisateurs.

Pendant la phase de transition il faut :

• Confier le SI aux utilisateurs;
• Préparer les plans de formation pour les utilisateurs;
• Décrire les livrables;
• Mettre au point et résoudre les besoins mal compris;
• Définir la portée de la prochaine mise à jour.

• http://www.enterpriseunifiedprocess.com/
• http://www.agilemodeling.com/