La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Gestion de Projets Logiciels Chapitre 1: Introduction Prof. SAHNOUN Zaidi Université Mentouri de Constantine Laboratoire Informatique Répartie (LIRE)"— 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 2 CRISE DU LOGICIELS PROBLEMES: 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 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 4 Définition du G.L Etablissement et utilisation de principes en vue dobtention des logiciels à Moindre Coûts, qui sont Fiables, et qui fonctionnent efficacement sur des machines réelles Fritz Bauer

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

6 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 8 Schématiquement... Analyse des besoinsSpécifications Conception Test Validation Maintenance Implantation codage Analyse métiers

9 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 dun modèle du système final en cohérence avec les choix darchitecture Implantation (Codage) Réalisation du système

10 10 Etapes du processus de développement Test (Validation) vérification de ladé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 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 daccord au plus tôt

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

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

14 14 Modèle danalyse Modéliser le domaine dinformation 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 15 Prototypage rapide Définition 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 16 Conception Spécifications Architecture Conception Projection des spécifications sur une architecture Exemples darchitectures (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 linstant)

17 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 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 19 Validation Objectifs : 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 20 Validation Test de vérification 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 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 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 24 Processus Logiciel Ensemble dactivité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 dun processus de développement dépend des caractéristiques du produit et du contexte de développement

25 25 Modèles du Processus Logiciel Nécessité davoir 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 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 27 Les Processus sont classés selon 5 niveaux: Initial: processus chaotique Reproductible: processus artisanal Défini: processus bien suivi dune manière qualitative Géré: processus contrôlable et mesuré Optimisé

28 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 29 FAISABILITE ANALYSE DES BESOINS PLANIFICATION CONCEPTION PRELIMINAIRE CONCEPTION DETAILLEE CODAGE INTEGRATION INSTALLATION EXPLOITATION MAINTENANCE

30 30 Les flèches descendantes matérialisent lenchaînement des étapes (version initiale pas de retour arrière) Les flèches ascendantes expriment le fait quune é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 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 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 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 34 2- Modèles Evolutifs ou Graduels Développer une implémentation initiale, lexposer à lutilisateur et raffiner à travers plusieurs versions Les activités de spécification, développement et validation sont menées dune manière concurrente Deux approches

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

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

37 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 dune manière évolutive

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

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

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

41 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 dune manière incrémentale au fur et à mesure que lutilisateur à une meilleure compréhension de son problème Non visibilité car on produit des documents pour chaque version Pauvre structuration Nécessité davoir des outils et des techniques

42 42 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 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 dincréments qui sont développer au fur et à mesure (spécification partie du contrat?) Développer les besoins et délivrer le système dune 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 44 Lutilisateur identifie une descriptions des services à fournir par le système (en commençant par ceux qui sont les plus importants) Un nombre dincré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 45 1er Incrément: les services sont définis et lincrément sera développé en utilisant un processus de développement approprié Durant ce temps, lanalyse des besoins des autres incréments peut seffectuer sans changer lincrément en cours de développement Une fois lincrément en cours est complété et délivré, les utilisateurs peuvent lutiliser 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 46 Avantages On nest pas obligé dutiliser 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) Lutilisateur nattend pas jusquà la fin Utiliser lincrément comme prototype Risque réduit Priorité aux services importants (plus testés)

47 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 48 1ere Description des Besoins Affecter les besoins aux Incréments Architecture et Conception du Système Valider lIncrément Développer lIncrément du Système Intégrer lIncrément Valider le Système Non Complet Complet Système Final

49 49

50 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 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 52

53 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 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 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 56

57 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 58 Définition Des Besoins Spécification Formelle Transformation Formelle Intégration et Test du Système

59 59 Spécification Formelle R1 P1 R2R3Programme Exécutable P3 P4 P2 T1T2T3T4 (Preuve) Exemple: Clean Room Process Application de la Méthode B

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

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


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

Présentations similaires


Annonces Google