2

Plan des cours

Les différents cycles de vie du logiciel

Les modèles linéaires

Les modèles itératifs

Autres modèles

Conclusion

3

Modèles génériques d’un processus de développement

Les différents cycles de vie du logiciel

4

Définition du cycle de vie du logiciel

Un cycle de vie d’un logiciel est un ordonnancement des différents étapes du processus de développement

Comme pour toutes les fabrications, il est important d’avoir un procédé de fabrication du logiciel bien défini et explicitement décrit et documenté.

En GL, il s’agit d’un type de fabrication un peu particulier : en un seul exemplaire, car la production en série est triviale (recopie).

5

Modèles de cycles de vie Les modèles de cycle de vie du logiciel

décrivent à un niveau très abstrait et idéalisé des différentes manières d’organiser la production.

Les étapes, leur ordonnancement, et parfois les critères pour passer d’une étape à une autre sont explicités critères de terminaison d’une étape revue de documents critères de choix de l’étape suivante critères de démarrage d’une étape

6

Modèles génériques Modèles linéaires

modèle en cascade modèle en V

Modèles itératifs modèle de développement incrémental modèle de développement en spirale modèle par prototypage

prototypage jetable prototypage évolutif

Autres modèles

7

Modèles génériques d’un processus de développement

Modèle linéaires

8

Modèles linéaires: Modèle en cascade

Historiquement, la première tentative pour mettre de la rigueur dans le ‘développement sauvage’ (coder et corriger ou ‘code and fix’) a consisté à distinguer une phase d’analyse avant la phase d’implémentation (séparation des questions).

Analyse

Implémentation

9

Modèles linéaires: Modèle en cascade

Un plus grand nombre d’étapes étaient nécessaires pour organiser le développement des applications complexes

Il faut distinguer: l’analyse du ‘quoi faire ?’ qui doit être validée

par rapport aux objectifs poursuivis la conception du ‘comment faire?’ qui doit

être vérifiée pour sa cohérence et sa complétude.

10

Modèles linéaires: Modèle en cascadeLe modèle en cascade décrit cette succession d’étapes

qui sont représentées ici (Six étapes fondamentales)

ConceptionConception

ImplémentationImplémentationet tests unitaireset tests unitaires

ValidationValidationet tests d’intégrationet tests d’intégration

Exploitation Exploitation et maintenanceet maintenance

AnalyseAnalysedes besoinsdes besoins

Analyse Analyse du systèmedu système

Pas de validation intermédiaireHaut risque : erreurs coûteuses !

Peut être viable pour des « petits » projets(Taille + Nbre de participants)

11

Modèles linéaires: Modèle en cascade

Chaque phase se termine à une date précise par la production de certains documents ou logiciels.

Les résultats sont définis sur la base des interactions entre étapes et activités, ils sont soumis à une revue approfondie (on ne passe à la phase suivante que s'ils sont jugés

satisfaisants)

12

Modèles linéaires: Modèle en cascade Certaines phases portent le nom d'une activité

signifie que l'activité est essentielle pour cette phase, mais n'impose pas qu'elle n'ait lieu que dans cette étape.

D'autres activités interviennent, par exemple le contrôle technique et la gestion de la configuration, tout au long du processus.

Le modèle original ne comporte pas de possibilité de retour en arrière. a été rajoutée sur la base qu'une étape ne remet en

cause que l'étape précédente, ce qui, dans la pratique, s'avère insuffisant.

13

Modèles linéaires: Modèle en cascade

Même si on l’étend avec des possibilités de retour en arrière, idéalement limitées à la seule phase qui précède celle remise en cause, le développement reste fondamentalement linéaire.

ConceptionConception

ImplémentationImplémentationet tests unitaireset tests unitaires

AnalyseAnalysedes besoinsdes besoins

Analyse Analyse du systèmedu système

14

Modèles linéaires: Modèle en cascade

Ce modèle se fonde sur l’hypothèse souvent irréaliste que l’on peut dès le départ définir complètement et en détail ce qu’on veut réaliser (expressions des besoins). La pratique montre que c’est rarement le cas.

Même si elle n’est pas réaliste, cette représentation très simplifiée a permis de définir des cadres conceptuels et terminologiques, largement acceptés et normalisés par plusieurs organismes (ISO, AFNOR, IEEE, DOD pour les applications militaires aux USA, ESA, etc.)

Ceci facilite la gestion et le suivi des projets.

15

Modèles linéaires: Modèle en cascade

Étude préliminaire ou étude de faisabilité ou planification : (rapport d’analyse préliminaire ou schéma directeur) définition globale du problème, différentes stratégies possibles avec

avantages/inconvénients, ressources, coûts, délais.

16

Modèles linéaires: Modèle en cascade Analyse des besoins ou analyse préalable : (cahier des

charges + plan qualité) qualités fonctionnelles attendues en termes des services

offerts

qualités non fonctionnelles attendues : efficacité, sûreté, sécurité, facilité d’utilisation, portabilité, etc.

qualités attendues du procédé de développement (ex. procédures de contrôle qualité)

Le cahier des charges peut inclure une partie destinée aux clients (définition de ce que peuvent attendre les clients) et une partie destinée aux concepteurs (spécification des besoins).

17

Modèles linéaires: Modèle en cascade

Analyse du système : (dossier d’analyse + plan de validation) modélisation du domaine modélisation de l’existant

(éventuellement) définition d’un modèle conceptuel (ou

spécification conceptuelle) plan de validation

18

Modèles linéaires: Modèle en cascade

Conception : (dossier de conception + plan de test global et par module) proposition de solution au problème spécifié

dans l’analyse organisation de l’application en modules et

interface des modules (architecture du logiciel) description détaillée des modules avec les

algorithmes essentiels (modèle logique) structuration des données

19

Modèles linéaires: Modèle en cascade

Programmation et tests unitaires : (dossiers de programmation et codes sources) traduction dans un langage de

programmation tests avec les jeux d’essais par module

selon le plan de test

20

Modèles linéaires: Modèle en cascade

Intégration et tests de qualification : composition progressive des modules tests des regroupements de modules test en vraie grandeur du système

complet selon le plan de test global (‘alpha testing’)

21

Modèles linéaires: Modèle en cascade

Installation Mise en fonctionnement opérationnel

chez les utilisateurs. Parfois restreint dans un premier temps à des utilisateurs sélectionnés (‘beta testing’).

22

Modèles linéaires: Modèle en cascade

Maintenance : maintenance corrective (ou curative) maintenance adaptative maintenance perfective

23

Modèles linéaires: Modèle en cascade

Activités transversales à tout le cycle de vie Spécification Documentation validation et vérification management.

24

Modèles linéaires: Modèle en cascade

Des études ont été menées pour évaluer le coût des différentes étapes du développement

Type de système

Conception Implémentation Test

Gestion 44 28 28

Scientifique 44 26 30

Industriel 46 20 34

Mais c’est la maintenance qui coûte le plus cher.

25

Modèles linéaires: Modèle en V

Objectifs Validations intermédiaires pour prévenir les

erreurs tardives : meilleure planification et gestion

Principes du cycle de vie en V Processus linéaire Validation à chaque étape

Préparation des protocoles de validation finaux à chaque étape descendante

Validation finale montante et confirmation de la validation descendante

26

Modèles linéaires: Modèle en V avec toute décomposition doit être décrite la

recomposition, la préparation des dernières phases (validation-

vérification) est explicite par les premières (construction du logiciel)

toute description d'un composant est accompagnée de tests qui permettront de s'assurer qu'il correspond à sa description. permet ainsi d'éviter un écueil bien connu de la

spécification : énoncer une propriété qu'il est impossible de vérifier objectivement après la réalisation.

27

Modèles linéaires: Modèle en V

SpécificationsSpécifications

AnalyseAnalyseConceptionConception

ImplémentationImplémentation

MaintenanceMaintenance

Expression Expression des besoinsdes besoins

Validation Validation fonctionnellefonctionnelle

Validation Validation AnalyseAnalyse

Validation finaleValidation finale

validé parvalidé par Validation Validation besoinsbesoins

Validations des étapes intermédiaires sous forme de documentsValidations des étapes intermédiaires sous forme de documents

28

Modèles linéaires: Modèle en V On distingue donc deux sortes de dépendances :

enchaînement et itération : se déroulent essentiellement de gauche à droite

préparation des phases ultérieures

Par exemple à l'issue de la conception architecturale le protocole et les jeux de test de l'intégration doivent être complètement décrits.

29

Modèles linéaires: Modèle en V Conséquences :

obligation de concevoir les jeux de test et leurs résultats réflexion et retour sur la description en cours meilleure préparation de la branche droite du V

Les activités de chaque phase peuvent être réparties en 5 catégories : assurance qualité production contrôle technique gestion contrôle de qualité

30

Modèles linéaires: Modèle en V

SpécificationsSpécifications

AnalyseAnalyseConceptionConception

ImplémentationImplémentation

Expression Expression des besoinsdes besoins

Validation Validation fonctionnellefonctionnelle

Validation Validation AnalyseAnalyse

Validation finaleValidation finale

Validation Validation besoinsbesoins

Protocoles de validation définis par l’analyse descendanteProtocoles de validation définis par l’analyse descendante

Processus descendant

Val

idat

ion

mon

tant

e

31

Modèles linéaires: Modèle en V

intérêts Validations intermédiaires

bon suivi du projet : avancement éclairé et limitation des risques en cascade d’erreurs

favorise la décomposition fonctionnelle de l’activité

génération de documents et outils supports Modèle très utilisé et éprouvé

32

Modèles linéaires: Modèle en V

Limitations Un modèle séquentiel (linéaire)

manque d’adaptabilité maintenance non intégrée : logiciels à

vocation temporaire validations intermédiaires non formelles :

aucune garantie sur la non transmission d’erreurs

Un modèle adaptée aux problèmes si les besoins sont bien identifiés, l’analyse et

la conception sont claires

33

Modèles linéaires: Modèle en V

Améliorations Retours de correction des phases précédentes

Fonctionne si corrections limitées casser la linéarité : cycle de vie itératif

SpécificationsSpécifications

AnalyseAnalyseConceptionConception

ImplémentationImplémentation

Expression Expression des besoinsdes besoins

34

Modèles génériques d’un processus de développement

Modèle itératifs

35

Modèles itératifs: Modèle par incrément

Face aux dérives bureaucratiques de certains gros développements, et à l’impossibilité de procéder de manière aussi linéaire, le modèle incrémental a été proposé dans les années 80.

temps

Incrémentsdélivrés

36

Modèles itératifs: Modèle par incrément Le produit est délivré en plusieurs fois, de manière

incrémentale, c’est à dire en le complétant au fur et à mesure et en profitant de l’expérimentation opérationnelle des incréments précédents.

Chaque incrément peut donner lieu à un cycle de vie classique plus ou moins complet.

Les premiers incréments peuvent être des maquettes (jetables s’il s’agit juste de comprendre les besoins des utilisateurs) ou des prototypes (réutilisables pour passer au prochain incrément en les complétant et/ou en optimisant leur implantation).

Le risque de cette approche est celui de la remise en cause du noyau.

37

Modèles itératifs: Modèle par incrément

Différents des autres modèles où un logiciel est décomposé en composants développés séparément et intégrés à la fin du processus

Dans les modèles par incrément un seul ensemble

de composants est développé à la fois : des incréments viennent s'intégrer à un noyau

de logiciel développé au préalable chaque incrément est développé selon l'un des

modèles précédents

38

Modèles itératifs: Modèle par incrément

Intérêts chaque développement est moins complexe

les intégrations sont progressives

possibilité de livraisons et de mises en service après chaque incrément

meilleur lissage du temps et de l'effort de développement à cause de la possibilité de recouvrement des différentes phases

39

Modèles itératifs: Modèle par incrément

Risques mettre en cause le noyau ou les incréments

précédents ne pas pouvoir intégrer de nouveaux incréments

Recommandations Le noyau, les incréments ainsi que leurs

interactions doivent donc être faites globalement, au début du projet

Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du développement.

40

Modèles itératifs: Modèle par incrément

Modèle de développement incrémental

Identifie Identifie les incréments les incréments

Produit les Produit les incréments incréments

Evalue les Evalue les incrémentsincréments

Spécifie et implémenteSpécifie et implémenteles incréments les incréments

41

Modèles itératifs: Modèle en spirale Proposé par B. Boëhm en 1988, ce modèle général

met l'accent sur l’évaluation des risques

A chaque étape, après avoir défini les objectifs et les alternatives, celles-ci sont évaluées par différentes techniques (prototypage, simulation, ...)

L’étape est réalisée et la suite est planifiée

Le nombre de cycles est variable selon que le développement est classique ou incrémental

42

Modèles itératifs: Modèle en spirale

AnalyseAnalyse

SpécificationsSpécificationsConceptionConception

ImplémentationImplémentation

ValidationValidation

TestsTests

V1.0 V1.3V1.1 V1.2

43

Modèles itératifs: Modèle en spirale

Les principaux risques et leurs remèdes, tels que définis par Boëhm

RisqueRisque RemèdeRemèdeDéfaillance de personnel Embauches de haut niveau, formation mutuelle,

leaders, adéquation profil/fonction, …

Calendrier et budgets irréalistes Estimation détaillée, développement incrémental, réutilisation, élagage des besoins, …

Développement de fonctions inappropriées Revues d’utilisateurs, manuel d’utilisation précoce, ...

Développement d’interfaces utilisateurs inappropriées

Maquettage, analyse des tâches, …

Volatilité des besoins Développement incrémental de la partie la plus stable d’abord, masquage d’information, ...

Problèmes de performances Simulations, modélisations, essais et mesures,maquettage, …

Exigences démesurées par rapport à la technologie

Analyses techniques de faisabilité, maquettage, ...

Tâches ou composants externes défaillants Audit des sous-traitants, contrats, revues, analyse de compatibilité, essais et mesures, ...

44

Modèles itératifs: Prototypage Idée : fournir rapidement un prototype

exécutable pour permettre une validation concrète (ici expérimentale) et non sur papier (document)

Progressions par incréments successifs de versions successives du prototype : itérations

Certains prototypes peuvent être « validés » par le client

Ne dispense pas de fournir des documents intermédiaires

45

Modèles itératifs: Prototypage jetable

Spécification Spécification schématiqueschématique

Codage duCodage duprototypeprototype

Evaluation duEvaluation duprototype prototype

Spécification Spécification du systèmedu système

Modèle gérable d’un point de vue changement des spécifications

Les spécifications sont générées par prototypage

46

Modèles itératifs: Prototypage évolutif

Spécification Spécification schématiqueschématique

Codage duCodage duprototypeprototype

Evaluation duEvaluation duprototype prototype

Acceptation Acceptation du systèmedu système

Modèle difficile à gérer

47

Modèles itératifs: Intérêts

Validation plus concrète (pas sur document)

Correction à chaque itération : risques limités et flexibilité modification des spécifications maintenance

Client impliqué dès le début : Besoins du client apparaissent progressivement

(et pas la veille de la livraison) Meilleure Planification

une nouvelle itération

48

Modèles itératifs: Intérêts

Processus itératif Adapté à une démarche incrémentale

Modèle de programmation orientée objet Nécessitant une planification rigoureuse

et ne supportant pas l’improvisation Planification supportant abstraction et

raffinements successifs Ayant une portée générale

49

Modèles génériques d’un processus de développement

Autres modèles

50

Autres modèles: Transformationnels

Spécification Spécification formelleformelle

TransformationTransformationcorrectecorrecte

SpécificationSpécificationformelle concrète formelle concrète

Génération de Génération de codecode

ProgrammeProgrammecorrectecorrecte

Modèle gérable Difficile à mettre en œuvre : Passage du formel au concret =>nécessite de connaissances

avancées (techniques et formelles)

51

Autres modèles: Hybrides

Principe : Système complexe = composition de

sous-systèmes Utilisation d’un processus de

développement adapté à chaque sous-systèmes Utilisation du modèle à chute d’eau pour les

sous-systèmes bien connus Utilisation du modèle de prototypage évolutif

pour les sous-systèmes « délicats »

52

Conclusion Il n’y a pas de modèle idéal car tout dépend des circonstances

le modèle en cascade ou en V est risqué pour les développements innovants car les spécifications et la conception risquent d’être inadéquats et souvent remis en cause.

Le modèle incrémental est risqué car il ne donne pas beaucoup de visibilité sur le processus complet.

Le modèle en spirale est un canevas plus général qui inclut l’évaluation des risques.

Souvent, un même projet peut mêler différentes approches, comme le prototypage pour les sous-systèmes à haut risque et la cascade pour les sous systèmes bien connus et à faible risque.

53

Questions Citer les différentes étapes du processus de

développement d’un logiciel

Donner une définition d’un Cycle de vie

Citer quelques exemples de cycles de vie d’un logiciel