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

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

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

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

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

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

Principales étapes d ’un processus de développement

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

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

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

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

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

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

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

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é

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)

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

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

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.

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

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.

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

Modèles du Processus Logiciel

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

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

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)

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é

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

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

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.

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.

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.

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

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

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

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

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

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é?

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

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

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

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.

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)

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.

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)

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)

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)

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

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.

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.

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.

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

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.

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

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

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

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

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