Rappel du Génie Logiciel - Cours PDF

Chapitre 1 Rappel du Génie Logiciel 1 Crise du logiciel La crise du logiciel (software-crisis) a émergé à cause de la baisse des coûts du matériel au profit de la hausse de celui des logiciels. Ainsi, afin d’administrer la complexité liée aux grands systèmes logiciels, il est indispensable d’innov...

Chapitre 1 Rappel du Génie Logiciel 1 Crise du logiciel La crise du logiciel (software-crisis) a émergé à cause de la baisse des coûts du matériel au profit de la hausse de celui des logiciels. Ainsi, afin d’administrer la complexité liée aux grands systèmes logiciels, il est indispensable d’innover de nouvelles techniques et méthodes. La crise du logiciel peut être décelée à partir des indices suivants : Défaillance au niveau de la qualité du logiciel. Insatisfaction du consommateur à cause des pannes liées au produit qui consomme plus de ressources. Médiocrité des performances du produit logiciel. Dépassement des fourches fixées dans le cahier de charge quant au développement du logiciel. Montant excessif et inopiné dans le développement d’un logiciel. Incompatibilité du logiciel avec les attentes du consommateur. Entretien compliqué, coûteux et source de nouvelles erreurs. Usage unique du logiciel existant ou de ses composantes dans l’élaboration d’un nouveau. 2 Génie logiciel 2.1 Définition Le génie logiciel est donc l’art de spécifier, de concevoir, de réaliser, et de faire évoluer, avec des moyens et dans des délais raisonnables, de programmes, des documentations et des procédures de qualité. 2.2 Qualités exigées d’un logiciel Les critères qui garantissent la qualité d’un logiciel sont : La validité : capacité d’un produit logiciel à assurer les fonctions exigées dans le cahier de charge.  La fiabilité : capacité d’un produit logiciel à s’adapter et fonctionner dans des situations spécifiques. L’extensibilité : capacité à apporter une modification ou une extension au produit logiciel d’une manière facile. La réutilisabilité : la possibilité de réutiliser la totalité ou une partie du logiciel dans une autre application. La compatibilité : possibilité d’associer le produit logiciel en question avec d’autres. L’efficacité : capacité du logiciel à investir les ressources d’une manière optimale. La portabilité : possibilité de déplacer et de transférer le logiciel dans plusieurs conditions. L’intégrité : capacité du produit logiciel à protéger son code et ses données face à des accès non autorisés. La facilité d’emploi : relative à l’aisance d’apprentissage, d’utilisation, d’interprétation des erreurs et de rattrapage en cas d’erreur d’utilisation. La maintenabilité : facilité à entretenir un produit logiciel 3 Cycle de vie du logiciel 3.1 Définition Le cycle de vie du logiciel renvoie à toutes les étapes du développement d’un logiciel du début jusqu’à la fin du processus du logiciel, c’est-à-dire de sa conception à sa disparition en passant par sa maintenance. Le cycle de vie assure la qualité du produit en détectant puis en maîtrisant d’une manière précoce les erreurs qu’il peut contenir et assurer, ainsi, les délais de sa réalisation et les coûts associés. 3.2 Etapes du cycle de vie Il est important de noter que les étapes qui suivent peuvent s’entremêler en fonction de l’évolution des besoins ou l’échec des tests. Étude d’opportunité (par des économistes en général).  Définition et analyse des besoins, spécification (par le commanditaire et des informaticiens). Élaboration du cahier des charges et des tests de recette/validation. Conception architecturale et élaboration des tests d’intégration. Conception détaillée et élaboration des tests unitaires. Codage (production du code source). Tests unitaires et d’intégration. Implantation chez le commanditaire, essais avec les utilisateurs et validation. Formation des utilisateurs, utilisation, maintenance, évolution. Retrait 4 Modèles de développement d’un logiciel 4.1 Modèle en cascade « Waterfall Model » Inventé par Royce en 1790, il est considéré comme un modèle adéquat aux petits projets ou à ceux dont les spécifications sont fixes et connues. 4.2 Le modèle en V Le modèle en V est dérivé du modèle de cycle de vie en cascade. Il s’attache à exposer l’enchaînement des phases successives et les relations logiques entre des phases plus éloignées. Les dernières étapes du processus de développement sont conditionnées par le début. 4.3 Modèle en spirale B Boehm crée en 1988 des modèles en spirales ayant pour objectif d’améliorer les lacunes de la démarche linéaire en proposant des modèles où toutes formes de risques probables sont continuellement traitées à l’aide de bouclages successifs. Ainsi, chaque spire confirme et affine les spires précédentes en menant des activités de même nature successivement 4.4 Modèle par prototypage Le modèle de processus basé sur le prototypage est adopté lorsqu’il s’avère difficile de fixer tous les besoins avant le début du développement du logiciel. En effet, ce modèle cerne la difficulté de la validation relative à l’ambigüité des besoins et des caractéristiques du système à développer. 4.5 Modèle par incrément Dans ce modèle il s’agit de développer uniquement un sous ensemble contrairement aux autres modèles cités antérieurement (cascade, en V, en spirale) où il est question de développer séparément les composants d’un logiciel décomposé puis les intégrés à la fin du processus. Ce modèle procède de la manière suivante : Développer un logiciel noyau. Développer les incréments selon un des modèles cités précédemment. Intégrer progressivement les incréments développés. Mettre en œuvre des livraisons et des mises en service après chaque intégration.