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.
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 :
En GL on éprouve les besoins en:
En GL on parle des approches :
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 :
Les points de départ d'un projet de développement de systèmes d'information :
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 :
Une méthodologie est constituée :
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
Exemples de modèles utilisés pour la gestion du processus de développement
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 :
Exmples d'outils :
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 :
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 :
| Catégorie | Processus |
|---|---|
| Choix d'un modèle de cycle de vie | <html><ul><li>Inventaire des modèles</li><li>Choix d'un modèle</li></ul></html> |
| Gestion de projet | <html><ul><li>Initiation du projet</li><li>Suivi et contrôle du projet</li></ul></html> |
| Prédéveloppement | <html><ul><li>Exploration du concept</li><li>Définition des fonctionnalités et des besoins</li></ul></html> |
| Développement | <html><ul><li>Spécification et exigences, conception</li><li>Implantation</li></ul></html> |
| Postdéveloppement | <html><ul><li>Installation</li><li>Opération et soutien</li><li>Maintenance</li><li>Retrait</li></ul></html> |
| Processus d'ensemble | <html><ul><li>Validation et vérification</li><li>Gestion des versions</li><li>Développement de la documentation</li><li>Formation</li></ul></html> |
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.
Pendant la phase d'initialisation il faut :
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 :
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 :
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 :