Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Julie Vachon, Hiver 2003 IFT6803: Génie logiciel du commerce électronique Chapi

Julie Vachon, Hiver 2003 IFT6803: Génie logiciel du commerce électronique Chapitre 1: Introduction Section 3: Processus de développement Chap.1, Sect.3, p.2 Sommaire Chapitre 1, Section 3 « Processus de développement » 1.3.1 Cycle de vie du logiciel 1.3.2 Processus de développement 1.3.2.1 Modèle en cascade 1.3.2.2 Modèle en V 1.3.2.3 Modèle par prototypage 1.3.2.4 Modèles évolutifs 1.3.4.5 Modèle transformationnel 1.3.2.6 Modèle en spirale 1.3.2.7 Rapid Application Development (RAD) 1.3.3 Ingénierie système Chap.1, Sect.3, p.3 1.3.1 Cycle de vie du logiciel Le logiciel est l’objet de plusieurs activités de développement au cours de sa vie… Activités en continu documentation, validation et vérification, gestion Conception et spécification Analyse et spécification Programmation Test Installation Maintenance Chap.1, Sect.3, p.4 Cycle de vie: analyse Analyse 1. Etude préliminaire: définition globale du problème (diag. contexte) évaluation des stratégies possibles évaluation des ressources, coûts et délais Documents: rapport d'analyse 2. Expression et analyse des besoins exigences fonctionnelles attendues: opérations, etc. qualités non fonctionnelles attendues: performance, portabilité,etc. Documents: cahier des charges, document d’analyse (spécification) et plan de test du système Quoi faire? Chap.1, Sect.3, p.5 Cycle de vie: conception Conception 1. Conception architecturale: décomposition et organisation de l'application en composants plus simples (modules) définis par leurs interfaces (fonctions et services offerts). 2. Conception détaillée: pour chaque module, description de la manière dont les services et fonctions sont réalisés: algorithmes essentiels structures de données utilisées, etc. Documents: document de conception (spécification), plan de test global et plan de test par module. Comment faire? Chap.1, Sect.3, p.6 Cycle de vie: programmation Programmation Traduction de la conception dans un langage de programmation Documents: dossiers de programmation, codes sources commentés. Chap.1, Sect.3, p.7 Cycle de vie: test Test 1. Tests unitaires: Tests avec les jeux d'essais par module selon le plan de test. 2. Tests d'intégration: Composition progressive des modules Tests des regroupement de modules 3. Test du système: Test en vraie grandeur du système complet selon le plan de test global. Documents: rapport de vérification par test. Est-ce bien fait? Le programme répond-t-il à la spécification? Chap.1, Sect.3, p.8 Cycle de vie: installation et maintenance Installation: Mise en fonctionnement opérationnel chez les utilisateurs. Parfois restreint (dans un 1er temps) à des utilisateurs sélectionnés. Maintenance: Maintenance corrective (corriger erreurs) Maintenance adaptative (modifications) Maintenance perfective (améliorations) Aussi: maintenance préventive (pour faciliter les opérations de maintenance à venir). Chap.1, Sect.3, p.9 Cycle de vie: autres activités Activités exécutées en continu Validation Le produit répond-il aux besoins du client? «Construit-on le bon produit?» S’assurer de répondre aux exigences du client. Vérification Le produit est-t-il correct (par rapport à la spécification)? «Construit-on le produit comme il faut?» S’assurer de la qualité du produit (révisions et inspections) S’assurer de satisfaire la spécification. Gestion Du processus de développement (suivi de projet, révision, etc.) De la configuration: politique de gestion des versions, des documents, politique de réutilisation Des ressources humaines Du risque Documentation Chap.1, Sect.3, p.10 L’équipe de développement: le rôle des membres dans le cycle de vie Analyse et spécification Conception architect. Programmation Test d’intégration Installation Maintenance Test système Tests unitaires Analyste Conception détaillée. Concepteur Programmeur Testeur Formateur Chap.1, Sect.3, p.11 1.3.2 Processus de développement Processus : Description abstraite et idéalisée des différentes manières d'organiser les activités du développement d’un logiciel). Décrit un ensemble de tâches ordonnées impliquant des activités (celles du cycle de vie) des contraintes (sur le temps, ressources, etc.) des ressources (humaines, matérielles, etc.) Doit être «personnalisé» pour l'entreprise de façon à définir l'ordonnancement idéal des activités. spécifier les artéfacts à produire (types de documents, format, échéancier). attribuer activités & artéfacts aux développeurs (cf. membres de l’équipe de développement) proposer des critères pour superviser l'évolution du projet, ses résultats et prévoir plans futurs (vérification, validation, documentation, etc.) proposer une méthodologie pour gérer les changements tant dans le processus et que le logiciel. Chap.1, Sect.3, p.12 Processus de développement Le processus de développement est à définir en équipe, de préférence, car ce travail permet: Compréhension commune des activités, ressources et contraintes. Identification des incohérences, redondances et omissions dans le processus. Identification des activités permettant de réaliser les objectifs de qualité. Adaptation du processus aux besoins spécifiques du projet et compréhension de ses particularités. Chap.1, Sect.3, p.13 Processus de développement Quelques modèles existants … à personnaliser Modèle en cascade Modèle en V Modèle par prototypage Modèles évolutifs: incrémental et itératif Modèle transformationnel Modèle en spirale Modèle RAD Chap.1, Sect.3, p.14 1.3.2.1 Modèle en cascade Etapes réalisées de façon strictement séquentielle. Attention centrée sur les artéfacts produits à la fin chaque étape. (document-driven) Analyse et spécification Conception et spécif. (architect. et détaillée) Programmation Test (unitaire, intégration, système) Installation Maintenance Chap.1, Sect.3, p.15 Modèle en cascade Inconvénients Hypothèses souvent irréalistes que l'on peut dès le départ définir complètement et en détail ce qu'on veut réaliser les résultats intermédiaires obtenus Ne reflète pas la façon dont le code est réellement développé. Trop rigide, manque de flexibilité pour imprévus. Pas de «feedback» avant la livraison au client.... Avantages Plan simple de ce qu'il faut faire. Facile à comprendre Cette première définition a permis la normalisation des cadres conceptuels et terminologiques des différentes activités. Chap.1, Sect.3, p.16 1.3.2.2 Modèle en V Variation du modèle en cascade Attention centrée sur la correction: vérification et validation Analyse et spécification Conception architecturale Test du système Installation et maintenance Conception détaillée Test unitaire et d’intégration Test de validation validation vérification Programmation Chap.1, Sect.3, p.17 Modèle en V Avantages Montre comment les activités de «test» sont liées à celles d'«analyse et de conception». Inconvénients Manque de « feedback ». Pas de résultats intermédiaires dont on peut discuter avec le client. Chap.1, Sect.3, p.18 1.3.2.3 Modèle par prototypage À chaque étape, un ou plusieurs prototypes sont soumis au client pour évaluation/révision. Permet d'examiner et d'explorer certains aspects du système pour évaluer et choisir les meilleures stratégies/solutions. Liste de révisions Liste de révisions Liste de révisions Révision du prototype Évaluation avec client/utilisateur Implémentation et prototypage Test Installation & maintenance Analyse des besoins et prototypage Conception et prototypage Besoins (description informelle, souvent incomplète) Chap.1, Sect.3, p.19 Modèle par prototypage Types de prototypes Prototype jetable: maquette exploratoire développée pour mieux comprendre les besoins du client, évaluer différentes solutions, etc. Développé rapidement et jeté ensuite. Prototype évolutif (ou réutilisable): maquette destinée à être complétée/optimisée dans les prochaines étapes du développement jusqu’à l’obtention du produit final. Chap.1, Sect.3, p.20 Modèle par prototypage Avantages Améliore la compréhension mutuelle du problème entre client, développeur et utilisateur. Favorise les activités de vérification et de validation intermédiaires. Inconvénients Tentation d’abréger le processus et de se contenter d’un prototype incomplet… Chap.1, Sect.3, p.21 1.3.2.4 Modèles évolutifs Le processus de développement d’un logiciel peut être très long (mois, années…) Le logiciel est un produit de nature évolutive… Pour être compétitif, il faut réduire le temps de mise en marché et pouvoir produire versions partielles du système ajouter graduellement de qualités et fonctionnalités. Solution: Modèle évolutif: développement au cours duquel des versions du logiciel de plus en plus complexes et détaillées sont développées. Deux versions du logiciel existent alors en parallèle logiciel opérationnel (version utilisée actuellement) logiciel en développement (prochaine version) Chap.1, Sect.3, p.22 Modèle évolutif - incrémental Approche incrémentale division du système en sous-systèmes (un par fonctionnalité). 1re version: système partiel. Chaque nouvelle version (incrément) ajoute une nouvelle fonctionnalité. Version 1 cycle de vie complet Version 2 cycle de vie complet noyau Version 3 Chap.1, Sect.3, p.23 Modèle évolutif - itératif Approche itérative division du système en sous-systèmes (un par fonctionnalité). 1re version: coquille complète du système. Chaque nouvelle version apporte une modification/amélioration à une fonctionnalité. cycle de vie complet cycle de vie complet Version 1 Version 2 Version 3 Chap.1, Sect.3, p.24 Modèles évolutifs Avantages Formation précoce des utilisateurs. Réponse rapide possible. Création précoce de nouveaux marchés pour nouvelles fonctionnalités. Focus sur nouveau domaine d'expertise à chaque étape (version). Détection précoces des problèmes imprévus (correction immédiate du système en développement). Inconvénients Risque de la remise en cause du noyau (fonctionnalités de base) au cours du développement. Chap.1, Sect.3, p.25 1.3.4.5 Modèle transformationnel Développement consistant en une séquence d'étapes qui transforment graduellement une spécification en implémentation. Enregistrement des étapes de transformation formelle Valider et mettre à jour Transformation N Spécification formelle Transformation 2 Test Transformation 1 Besoins Ex. de transformations •Changer la représentation des données •Sélectionner un algorithme •Optimisation •Compilation Installation & maintenance Chap.1, Sect.3, p.26 Modèle transformationnel Avantages Chaque transformation est prouvée formellement. Preuves gardées dans un registre. Favorise le développement de programme correct et documenté formellement. Modifications répercutées dans le code & spécification. Pas de divergences. Environnement et outils Développer des composants réutilisables. Outils intelligent d’aide à la preuve. Inconvénients Demeure une approche expérimentale et de recherche. uploads/Ingenierie_Lourd/ chapitre1-3.pdf