gestion de projets logiciels chapitre 1: introduction prof. sahnoun zaidi université mentouri de...

Gestion de Projets Logiciels

Chapitre 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

Principales étapes d ’un processus de

développement

8

Schématiquement ...

Analyse des besoins Spécifications

Conception

Test Validation

Maintenance

Implantationcodage

Analyse métiers

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

Activité à modéliser

Définition des besoins

Prototypage

Modèle d’analyse

Revue

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

Spécifications

Architecture

ConceptionProjection des spécifications

sur une architecture

Exemples d’architectures (cf. cours Architecture) Architecture en couchesClient / 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

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

Spécification

Développement

Validation

Version Initiale

Version Finale

Description Générale

Version Intermédiaire

Activités Concurrentes

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

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

Utiliser le PrototypeConstruire un prototype du système

Livrer le Système

Développer une Spécification Abstraite

Prototypage Exploratoire(Evolutif)

Système Approprié?

NON

OUI

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

Etablir une Spécification Abstraite

Développer Prototype

Evaluer le Prototype

Spécifier le Système

Délivrer le Système Valider le SystèmeDévelopper le Système

Réutiliser des Composants

Prototype Jetable

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

Valider l’Incrément Développer l’Incrément du

Système

Intégrer l’Incrément Valider le Système

Non Complet

Complet

Système Final

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

Spécification

Formelle

R1

P1

R2 R3 Programme Exécutable

P3 P4P2

T1 T2 T3 T4

(Preuve)Exemple: Clean Room Process

Application de la Méthode B

60

Suppose l’existence des paries du systèmes Processus de développement consiste à

intégrer ces parties

4- Approche Basée Composants

61

Spécification des BesoinsAnalyse du Composant Modification des Besoins

Conception avec Réutilisations

Développement etIntégration

Validation du Système