Gestion de Projets Logiciels Chapitre 1: Introduction

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

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. 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. 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 Analyse des besoins : Etape cruciale 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 • 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 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 : • 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 • 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. 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 OUI Système Approprié? Livrer le Système

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. 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

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.