Gestion de Projets Logiciels Chapitre 1: Introduction

Présentation au sujet: "Gestion de Projets Logiciels Chapitre 1: Introduction"— Transcription de la présentation:

1 Gestion de Projets Logiciels Chapitre 1: Introduction
Prof. SAHNOUN Zaidi Université Mentouri de Constantine Laboratoire Informatique Répartie (LIRE)

2 CRISE DU LOGICIELS PROBLEMES: Manifestations: Développer des Logiciels
Maintenir les Logiciels existants Répondre aux Besoins Manifestations: Planning et Coûts estimés souvent erronés Productivité Qualité Clients non satisfais Logiciels existants difficiles à Maintenir

3 Génie Logiciel Fonder sur des Bases Théoriques
Ensembles de Méthodes et Outils Valider par la pratique Pour développer des Logiciels Définir des techniques de fabrications justifiées soit par la théorie soit par la pratique

4 Définition du G.L Etablissement et utilisation de principes en vue d’obtention des logiciels à Moindre Coûts, qui sont Fiables, et qui fonctionnent efficacement sur des machines réelles Fritz Bauer

5 Méthodes Plans et Estimation du Logiciel Analyse des Besoins
Conception Code Test Maintenance

6 Outils Supports Automatiques ou Semi automatiques pour supporter les méthodes Ex: Outils CASE

7 Principales étapes d ’un processus de développement

8 Schématiquement ... Analyse des besoins Spécifications Analyse métiers
Conception Implantation codage Test Validation Maintenance

9 Etapes du processus de développement
Spécification (Expression des besoins et Analyse) établissement du cahier des charges et des contraintes du système Conception Production d’un modèle du système final en cohérence avec les choix d’architecture Implantation (Codage) Réalisation du système

10 Etapes du processus de développement
Test (Validation) vérification de l’adéquation entre les propriétés du système et la description des besoins Déploiement (Installation) Livraison du système au client et vérification de son fonctionnement Maintenance Réparation des fautes du système Enrichissement avec de nouvelles fonctionnalités

11 Analyse des besoins : Etape cruciale
Client Vague idée des requis Requis instables ! Equipe de développement Commencer sans rentrer dans les détails Erreurs potentiels de spécification et par conséquent de développement Se mettre d’accord au plus tôt

12 Analyse des besoins Travailler avec le client pour extraire (définir) les besoins globaux au niveau du produit Construire un modèle d’analyse en définissant : les données, les fonctions, le comportement Prototyper les aspects incertains (zones d’ombre) Développer une spécification qui guidera le design Réaliser des revues techniques formelles

13 Processus d’analyse Prototypage Activité à modéliser Revue
Définition des besoins Modèle d’analyse

14 Modèle d’analyse Modéliser le domaine d’information
définir et représenter les données et leurs relations Modéliser le domaine de la fonctionnalité identifier les fonctions qui transforment les données Modéliser le comportement indiquer les différents états du système spécifier les événements qui engendrent des changements d’état Partitionner le modèle Raffiner chacun des modèles

15 Prototypage rapide Définition Intérêt Différents type de prototype
Un prototype est un modèle opérationnel fonctionnellement équivalent à un sous-ensemble du produit Intérêt Donner rapidement au client une compréhension et un aperçu sur le produit à développer Différents type de prototype Maquette, Simulateur,Modèle opérationnel Un prototype est fait pour être changé

16 Conception Conception Spécifications Projection des spécifications
sur une architecture Spécifications Architecture Exemples d’architectures (cf. cours Architecture) Architecture en couches Client / Serveur (très répandu) Client léger (via un browser) Peer to Peer (utilisation très limitée pour l’instant)

17 Conception : choix techniques
Objectifs liés à la conception  Réduction de coûts de développement et de maintenances  Réutilisation : objets, composants, frameworks, etc

18 Implantation Différents types de programmation
Fonctionnelle Impérative Objet Logique / robot Différents langages de programmation Lisp, Caml C, ADA, .. Java ou C++ Prolog / AOP

19 Validation Objectifs : Exemple
Déterminisme et sûreté de fonctionnement  Preuves formelles, heuristiques. Exemple L'explosion d'Ariane 5, le 4 juin 1996, qui a coûté un demi milliard de dollars Cause : une faute logicielle d'une composante dont le fonctionnement n'était pas indispensable durant le vol.

20 Validation Test de vérification Recette
Vérification de la robustesse et de la cohérence du système en particulier dans les cas d ’exceptions (générateurs de tests) Différentes méthodes de validation Recette Validation client : satisfaction des besoins clients

21 Maintenance Une enquête effectuée aux USA en 1986 auprès de 55 entreprises a révélé que 53% du budget total d'un logiciel est affecté à la maintenance. Coût de maintenance réparti comme suit : 34% maintenance évolutive : modification des spécifications initiales ; 10% maintenance adaptative : nouvel environnement, nouveaux utilisateurs ; 17% maintenance corrective : correction des bogues ; 16% maintenance perfective : améliorer les performance sans changer les spécifications ; 6% assistance aux utilisateurs ; 6% contrôle qualité ; 7% organisation/suivi ; 4% divers.

22 Maintenance (suite) La maintenance s'explique par :
l'augmentation de la complexité des logiciels la montée en puissance des performances du matériel. Deux types de maintenance corrections demandes d ’évolution

23 Modèles du Processus Logiciel

24 Processus Logiciel Ensemble d’activités et de résultats associés qui produisent un logiciel Différents Processus décomposent ces activités de manières différentes Complexités du Processus logiciel: Font intervenir plusieurs activités Choix d’un processus de développement dépend des caractéristiques du produit et du contexte de développement

25 Modèles du Processus Logiciel
Nécessité d’avoir des modèles de développements généraux qui décrivent les enchaînements et les interactions entre les activités: Modèles du Processus Logiciels Modèle du Processus Logiciel: Méthodes, Outils, autres Modalités associés à chacune des activités

26 Objectifs des MPL Obtenir des Processus de Développement
Rationnels, Reproductibles, et Contrôlables Notion de Maturité du Processus de Développement a été définie par SEI (Software Engineering Institute)

27 Les Processus sont classés selon 5 niveaux:
Initial: processus chaotique Reproductible: processus artisanal Défini: processus bien suivi d’une manière qualitative Géré: processus contrôlable et mesuré Optimisé

28 1- Modèles Séquentiels Etapes (ou Phases): une étape se termine par la production de documents qui sont vérifiés et validés avant de passer à l’étape suivante Programmer et traquer les erreurs v

29 ANALYSE DES BESOINS PLANIFICATION
FAISABILITE ANALYSE DES BESOINS PLANIFICATION CONCEPTION PRELIMINAIRE CONCEPTION DETAILLEE CODAGE INTEGRATION INSTALLATION EXPLOITATION MAINTENANCE

30 Les flèches descendantes matérialisent l’enchaînement des étapes (version initiale pas de retour arrière) Les flèches ascendantes expriment le fait qu’une étape ne remet en cause que l’étape précédente (Version actuelle) Les versions actuelles font apparaître les validation et vérification dans chaque étape.

31 AVANTAGES Plus on avance dans les étapes, moins il devrait avoir de risque. On avance donc par pas. L'avantage de ce modèle est que chaque phase est finie, elle est donc gérable tant au niveau du temps que des ressources. Le code est créé assez tardivement, il y a donc une bonne compréhension du système.

32 INCONVENIENTS Au niveau des inconvénients, on peut noter que ce modèle ne représente pas la réalité. Il est possible de revenir en arrière, car des erreurs ont été découvertes, car on doit créer des tests ce qui implique du code. Il y a des risques de découvrir des erreurs qu'a la fin et qui nécessiteront de refaire toutes les étapes. L'ajout de nouvelle exigence implique qu'il faille refaire toutes les étapes. Plus un problème ou un changement doit être fait tard, plus il coûtera cher.

33 Ce modèle est encore très utilisé, mais a été revu dans sa version initiale. Dans la nouvelle version, il est possible de revenir en arrière et des prototypes sont créé à chaque phase. Il est ainsi dans cette nouvelle version, plus près de la réalité. Modèle approprié lorsque les besoins sont bien identifiés

34 2- Modèles Evolutifs ou Graduels
Développer une implémentation initiale, l’exposer à l’utilisateur et raffiner à travers plusieurs versions Les activités de spécification, développement et validation sont menées d’une manière concurrente Deux approches

35 Version Initiale Spécification Version Intermédiaire Développement Description Générale Version Finale Validation Activités Concurrentes

36 OBJECTIF: Livraison du Système aux Utilisateurs
Prototypage Exploratoire (Evolutif) Systèmes Délivrés Besoins Généraux Prototypage Jetable Prototype Exécutable + Spécification du Système OBJECTIF: Valider ou Obtenir les Besoins du Système

37 2-1: Développement Exploratoires
Débuter par les parties du système qui sont comprises et évoluer en ajoutant les nouvelles caractéristiques Objectif: développer le système d’une manière évolutive

38 Prototypage Exploratoire (Evolutif) Utiliser le Prototype Développer une Spécification Abstraite Construire un prototype du système NON Livrer le Système OUI Système Approprié?

39 2-2: Prototypes Jetables
Comprendre les besoins de l’utilisateur et mieux cerner les besoins du système. Se concentrer sur l’expérimentation des besoins mal compris et mal définis par l’utilisateur Objectif: Spécification du système

40 Prototype Jetable Développer Prototype Evaluer le Prototype Etablir une Spécification Abstraite Réutiliser des Composants Spécifier le Système Délivrer le Système Valider le Système Développer le Système

41 Avantages, Inconvénients
Modèle efficace pour produire des systèmes qui répondent aux besoins immédiats. Les spécifications peuvent être développées d’une manière incrémentale au fur et à mesure que l’utilisateur à une meilleure compréhension de son problème Non visibilité car on produit des documents pour chaque version Pauvre structuration Nécessité d’avoir des outils et des techniques

42 Pour des systèmes plus larges, combiner les deux approches:
Approche graduelle appropriée pour des systèmes de petites tailles (100,000 LOC) ou de tailles moyennes (jusqu’à 500,000 LOC) Pour des systèmes plus larges, combiner les deux approches: Développer un prototype jetable pour résoudre les incertitudes dans les spécifications Ré implémenter ce système en utilisant une approche plus structurée Exemple: développer les parties bien comprises par une approche séquentielle et développer les autres parties (interfaces avec les utilisateurs) par une approche exploratoire.

43 2-3: Développement Incrémental (Mills 1980)
Spécification, Conception et Implémentation sont divisées et coupées en plusieurs séries d’incréments qui sont développer au fur et à mesure (spécification partie du contrat?) Développer les besoins et délivrer le système d’une manière incrémentale Donner des opportunités aux clients de reporter les détails de leurs besoins (avoir une certaine expérience avec le système)

44 L’utilisateur identifie une descriptions des services à fournir par le système (en commençant par ceux qui sont les plus importants) Un nombre d’incréments à développer sont définis. Chaque incrément doit répondre à un sous-ensemble de fonctionnalités du système. Les services prioritaires sont développés en premier au client.

45 1er Incrément: les services sont définis et l’incrément sera développé en utilisant un processus de développement approprié Durant ce temps, l’analyse des besoins des autres incréments peut s’effectuer sans changer l’incrément en cours de développement Une fois l’incrément en cours est complété et délivré, les utilisateurs peuvent l’utiliser pour expérimentation (clarifier les besoins des autres incréments) Lorsque des incréments sont complétés, ils seront intégrer aux incréments existants (amélioration du système à chaque addition de nouveaux incréments)

46 Avantages On n’est pas obligé d’utiliser le même processus pour tous les incréments (utiliser le modèle séquentiel pour les spécifications bien définies et les approches évolutives pour les spécifications mal définies) L’utilisateur n’attend pas jusqu’à la fin Utiliser l’incrément comme prototype Risque réduit Priorité aux services importants (plus testés)

47 Modèle utilisé dans le clean room process
Approche « Programmation Extrême »: les incréments sont de fonctionnalités très réduites (Beck 1999)

48 1ere Description des Besoins Affecter les besoins aux Incréments
Architecture et Conception du Système Développer l’Incrément du Système Valider l’Incrément Valider le Système Intégrer l’Incrément Complet Système Final Non Complet

49

50 2-4: Modèle en V Le principe de ce modèle, est que chaque étape de décomposition du système possède une phase de test. Chaque phase du projet à une phase de test qui lui est associé. Beaucoup de tests sont ainsi créés, ce qui implique une réflexion.

51 On sait progressivement si on s'approche de ce que le client désire.
Ce modèle est convenable pour les projets complexes. C'est un modèle dérivé du modèle en cascade.

52

53 2-5 Modèle en spirale Ce modèle est plus récent, il date du milieu des années 80. L'emphase de ce modèle et mise sur la réduction des risques. Ce modèle est adapté pour les gros projets complexes. Les risques sont sans cesse évalués à chaque cycle.

54 Un cycle est décomposé en étapes.
Analyse préliminaire pour le premier cycle, pour les autres cycles, on détermine les objectifs, contrainte à partir du résultat du cycle antérieur. Analyse des risques, création de prototype Développement et test Planification du cycle suivant

55 Les prototypes créés à chaque cycle permettent de réduire les risques et de guider la conception pour obtenir un système qui répond au besoin du client. Chaque cycle de la spirale fait en sorte que le système est de plus en plus complet.

56

57 3- Approche Formelle Produire des spécifications formelles par transformation en utilisant des méthodes mathématiques pour aboutir à un programme (préservation de la correction).

58 Définition Des Besoins Spécification Formelle Transformation Formelle Intégration et Test du Système

59 T1 T2 T3 T4 Spécification Formelle R1 R2 R3 Programme Exécutable P2 P3 P4 P1 (Preuve) Exemple: Clean Room Process Application de la Méthode B

60 4- Approche Basée Composants
Suppose l’existence des paries du systèmes Processus de développement consiste à intégrer ces parties

61 Modification des Besoins Analyse du Composant
Spécification des Besoins Conception avec Réutilisations Développement et Intégration Validation du Système