_CdP_2000_v1

Date : 21/02/2011

Page : 1

CONDUITE DE PROJET LOGICIEL (1ERE

PARTIE)

LOGIQUE DE DEROULEMENT d’un Projet Logiciel

« Modèles, Méthodes, Normes et standards»

EPITA-2000

C. CHEVALLIER

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL

EPITA : Cours de Conduite de Projet Logiciel (C. CHEVALLIER) Page : 2

TABLE DES MATIERES

1. GENERALITES ..............................................................................................................................3

1.1. Crise du logiciel ...................................................................................................................3

1.2. Caractéristiques du logiciel ...................................................................................................4

1.3. Qualité du logiciel ................................................................................................................5

2. CONDUITE DE PROJET LOGICIEL ..........................................................................................6

2.1. Définition et objectifs ...........................................................................................................6

2.2. Cycle de vie du logiciel ........................................................................................................6

2.3. Modèles et méthodes de développement ..............................................................................8

2.3.1. Modèle de la cascade ...........................................................................................9

2.3.2. Modèle avec prototypage .....................................................................................13

2.3.3. Modèle incrémental ..............................................................................................16

2.3.4. Modèle par extensions successives........................................................................18

2.3.5. Modèle en V ........................................................................................................20

2.3.6. Modèle en W .......................................................................................................23

2.3.7. Modèle basé sur la Programmation exploratoire ....................................................24

2.3.8. Modèle basé sur la transformation formelle ............................................................26

2.3.9. Modèle basé sur l'assemblage de composants réutilisables .....................................27

2.3.10. Modèle de la spirale ...........................................................................................29

2.3.11. Méthode MERISE .............................................................................................32

2.3.12. Méthode MCP ...................................................................................................34

2.3.13. Méthode AFNOR ..............................................................................................35

2.3.14. Méthode GAM-T17 (V2) ..................................................................................36

2.3.15. Méthode DoD-Std-2167A .................................................................................42

2.3.16. Synthèse.............................................................................................................43

3. GESTION DE PROJET (2ème Partie)



1. GENERALITES

1.1. Crise du logiciel

La prise de conscience de la crise est apparue vers les années 1970 avec l'arrivée des ordinateurs (de 3ème

génération) beaucoup plus puissants permettant des applications jusqu'alors irréalisables.

Elle est née du constat suivant :

- impossibilité, de la part des services informatiques, de donner à priori, une évaluation fiable du coût

et du délai de développement et de la qualité d'un logiciel.

NB : selon une étude du DoD aux US en 1988, 70 % des projets initialisés sont abandonnés avant leur

achèvement pour :

- non conformité (non respect du cahier des charges),

- inadéquation de la réalisation par rapport au besoin,

- retard trop important,

- dépassement de budget,

et les 30 % restants connaissent un retard moyen de plusieurs années; Il s'agit bien sûr de gros projets,

militaires ou technologiquement sensibles, dont la durée de développement est de plusieurs années.

La crise était due à :

- la diversification des domaines d'application,

- la croissance quantitative exponentielle,

- l'augmentation de la complexité des applications,

- l'augmentation des attentes des utilisateurs de plus en plus exigeants,

- la faible progression de la productivité,

- la spécificité du logiciel (cf 1.2),

- l'absence de cadre méthodologique standard,

- les méthodes de développement de logiciel existantes n'étaient pas suffisamment bonnes et adaptées,

- l'absence d'outil de gestion quantitative du développement,

- l'absence de métrologie de la qualité des processus et des produits logiciels,

- la croissance de la part du logiciel, au détriment du matériel, dans le coût de développement des

systèmes,

- l'augmentation de la part de la maintenance dans le coût total :

coût de la maintenance pendant la durée de vie > coût du développement du logiciel

La crise a donné lieu à l'avènement d'une nouvelle technique : LE GENIE LOGICIEL visant à rationaliser le

processus de développement du logiciel à l'aide de méthodes, procédures et outils (émergence vers la fin des

années 1980 d'ateliers de génie logiciel intégré : AGLI).

La CRISE n'est PAS TERMINEE :

les principes et les méthodes ne sont pas fautifs, le PROBLEME est plutôt qu'ils ne son PAS

APPLIQUES.



1.2. Caractéristiques du logiciel

La spécificité du logiciel tient aux caractéristiques suivantes qui le distingue du matériel :

- produit unique (pas de notion de lot/série) : il est copiable ou reproductible

- immatériel, invisible, non palpable, abstrait : il est difficile à mesurer

- ne s'use pas, ne se dégrade pas

- ne se manifeste qu'au travers du matériel; il s'exécute sur un calculateur,

- sa fiabilité augmente avec le temps, au fur et à mesure de la maintenance (corrections),

- le logiciel est considéré comme "malléable" : l'expérience montre que s'il est facile à modifier, il est

difficile de le faire correctement (sans régression)

- la taille du logiciel a de moins en moins d’omportance

- technique non encore adulte car récente; le génie logiciel est encore en plein essor et en cours de

maturation (cf 1.1)

NB : Un logiciel, comme le matériel, peut « mourir » (retrait de service) et devenir obsolète (par exemple le

passage à l’an 2000).

Ci-après la courbe de comparaison de l'évolution des coûts de logiciel et de matériel.

coût (tendance)

1970 1980 1990

matériel informatique logiciel spécifique

logiciel du commerce

Dans les années 60 :

- la part du matériel dans les budgets informatiques était nettement plus lourde que celle du logiciel car

il s'agissait de technologies d'avant garde

- le personnel était relativement peu qualifié bien que spécialisé et les candidats ne manquaient pas

- les coût de personnel étaient faibles, surtout en comparaison des coûts du matériel.

Depuis les années 70 :

- les coûts des matériels sont de moins en moins élevés pour des puissances de traitement et de

stockage de l'information toujours plus importantes

- les coûts du logiciel ont tendance à être de plus en plus élevés, cela étant essentiellement dû à la

composante main d'oeuvre.

Au début des années 80 :

- inversion du rapport entre le poids du logiciel et celui du matériel

- le logiciel du commerce permet d'infléchir la courbe du coût des logiciels qui présente une forte

tendance à l'inflation.



1.3. Qualité du logiciel

La NON QUALITE du logiciel est due aux écarts de perception du besoin tout au long du déroulement du

projet. Le schéma suivant illustre l'évolution de la perception du besoin :

Non Qualité du fait du client

Non Qualité du fait du fournisseur

Besoin

réel

Besoin

exprimé

Besoin

pris en

compte

Besoin

satisfait

produit

idéal

produit

livré

La difficulté est moins de répondre à un besoin que de le comprendre et de maintenir la finalité du projet tout

au long des phases d'élaboration de la solution.

D'après les travaux de Myers en 1988 aux US, le simple transfert des dossiers entre les intervenants d'une

phase à l'autre entraîne une perte d'information de près de 10% et seulement 35% des besoins couverts en fin

du cycle de développement.

Un "BON" logiciel doit posséder les 4 facteurs clés suivants :

- il doit être fiable,

- il doit être efficace dans son fonctionnement (performant : temps de réponse; sans gaspillage de

ressources informatiques : mémoire, unité centrale),

- il doit être simple et souple d'emploi (interface utilisateur appropriée : aide en ligne, ergonomie,

fonctions d'apprentissage),

- il doit être maintenable (apte à subir des modifications et des évolutions à moindre coût).

Il est difficile d'optimiser tous ces facteurs car certains s'excluent mutuellement. Par exemple, une meilleure

utilisation, via une interface homme-machine (IHM) sophistiquée, peut réduire l'efficacité.

D'autre part la notion de coût n'est pas négligeable : le coût augmente de façon exponentielle en fonction de

l'efficacité.

Le problème n'est pas de proposer le produit le plus sophistiqué mais LE PLUS ADAPTE c'est à

dire répondant aux exigences de performance, de coût et de disponibilité .

C'est parce que le coût de la NON QUALITE est parfois impressionnant que les qualiticiens se

permettent de dire "LA QUALITE, C'EST GRATUIT" (ex : un logiciel non testé ==> charge * 2).



Solution : adopter un cycle de développement dès la phase de spécification du besoin pour prévoir les

moyens à utiliser permettant de vérifier et valider chaque phase intermédiaire.



2. CONDUITE DE PROJET LOGICIEL

2.1. Définition et objectifs

La conduite de projet a pour objectifs :

- de maîtriser la qualité, les coûts et les délais de développement dans un souci d'efficacité et de

rentabilité

- d'améliorer le processus de développement du logiciel

On peut donc définir la conduite de projet comme étant l'ensemble des activités destinées à assurer le

déroulement d'un projet dans les meilleures conditions de coût, de délai et de qualité des résultats .

Autre définition possible : ensemble des activités destinées à assurer la coordination des acteurs et des

tâches afin de réaliser un projet dans des limites données de temps, de moyens et de coûts.

Conduire un projet, c'est donc prendre un ensemble de mesures pour assurer la bonne fin du projet en

maîtrisant l'ensemble des ressources et les résultats.

La conduite de projet s'attache principalement à l'enchaînement des étapes, phases et tâches

(appelées aussi activités) à effectuer pour mettre en oeuvre la démarche décrite par la méthode utilisée,

éventuellement basée sur un ou plusieurs modèles.

Elle définit :

- le QUOI FAIRE

- le QUI FAIT

- le QUAND LE FAIT-IL

et non

- le COMMENT FAIRE une tâche qui appartient au domaine technique; une « méthode

opératoire », appelée plus généralement « méthode de conception » (et souvent à tort « méthode

de développement » car non liée au processus de développement), précise le "comment faire" le

logiciel.

Une « méthode de conduite de projet » définit le processus de déroulement d’un projet c’est à dire

COMMENT GERER le COMMENT FAIRE.

La conduite de projet logiciel tient compte du cycle de vie du logiciel.

2.2. Cycle de vie du logiciel

Le cycle de vie du logiciel définit l'enchaînement chronologique des différentes phases d’élaboration et

d’utilisation d'un logiciel, depuis l’émergence du besoin (l’idée) jusqu’au retrait de service du produit.

Cette organisation permet de décomposer l'objectif global, induit par les besoins du client, en une succession

d'objectifs à court terme plus facilement maîtrisables (que l'on peut vérifier et valider).

Elle a pour avantages :

- de diminuer les risques d’inadéquation des solutions adoptées dans chacune des phases



- d'améliorer l'identification des activités à mettre en oeuvre

- de valoriser l'expérience acquise au cours des projets antérieurs.

Le cycle de vie d'un logiciel est décomposé en 3 étapes :

- avant projet, correspondant aux études de faisabilité (schéma directeur) et de définition des besoins

(spécification)

- projet, correspondant au développement du projet proprement dit

- utilisation, correspondant à l'exploitation et à la maintenance du logiciel après sa mise en service

opérationnelle

Chaque étape se décompose en phases, éventuellement une seule. Chaque phase représente un ensemble d'

activités (une activité élémentaire est souvent appelée tâche) cohérentes entre elles et visant un objectif

commun (objectif client ou objectif correspondant à un état du produit). Le résultat d'une activité est un

produit (document, code, résultats de test, ...). En général les produits issus de chaque phase font l'objet de

vérifications (revue de fin de phase) avant leur adoption.

Le cycle de vie du logiciel (définition AFNOR Z61-102) représente l'ensemble des phases du cycle de

développement :

- précédé par la phase de SPECIFICATION

- suivi de la phase d'EXPLOITATION et de MAINTENANCE

Le cycle de développement du logiciel (définition AFNOR Z61-102) représente l'ensemble des activités

mises en oeuvre dans un ordre donné pour effectuer le développement d'un logiciel. Les périodes pendant

lesquelles ces activités sont mises en oeuvre sont appelées "phases". Le cycle de développement commence à

l'issue de la phase de spécification et se compose des phases suivantes :

- conception préliminaire

- conception détaillée

- réalisation (codage et tests unitaires)

- intégration

- validation

ATTENTION : Bien que la phase de spécification ne fasse théoriquement pas partie du cycle de

développement, la pratique montre qu’un fournisseur, chargé du développement d’un logiciel, commence

souvent (conseillé) son travail par une phase initiale lui permettant de comprendre le besoin du client

(transformer le besoin fonctionnel en besoin technique) et de mettre en place l’organisation du développement.

Le cycle de développement correspond à une description schématique et macroscopique de type "boite

noire" du processus de développement, précisant les éléments (conditions et fournitures) d'entrée et de sortie

de chaque phase.

Il permet par ailleurs de garantir la transmission exhaustive des informations entre les différentes

phases (prévention contre les risques de déliquescence : cf 1.3) Cette prévention étant assurée par la

définition de documents et de moyens de contrôle (revue de fin phase).

Il existe plusieurs modèles de représentation du cycle de vie ou du cycle de développement du

logiciel.



2.3. Modèles et méthodes de développement

Un modèle de développement fournit une représentation schématique du cycle de développement et en

décrit les principes.

Une méthode de développement décrit de manière détaillée la démarche de conduite de projet (ou

logique de déroulement de projet) mise en oeuvre durant le cycle de développement. Elle s'appuie

éventuellement sur un modèle ou une combinaison de modèles.

Pour chaque phase, la méthode de développement définit en particulier :

- Les conditions de démarrage (décision, fourniture des informations d’entrées),

- Les informations en entrée,

- Les travaux (ou activités) à réaliser,

- Les résultats,

- Les conditions d’acceptation des résultats (vérifications et validations effectuées).

Il existe 2 catégories de modèles :

- basés sur les délivrables : on appelle délivrables les produits résultats de chaque phase livrés au

client après vérifications et acceptation par le client,

- basés sur les risques : on appelle risque tout ce qui peut mal se passer.

Les modèles suivants sont analysés de manière détaillée :

- de la cascade,

- avec prototypage,

- incrémental,

- par extensions successives,

- en V (cycle en V),

- en W,

- basé sur la programmation exploratoire,

- basé sur la transformation formelle,

- basé sur la réutilisation,

- de la spirale.

Les méthodes de développement suivantes sont décrites de manière synthétique :

- MERISE,

- MCP,

- AFNOR Z67-101,

- GAM-T17 V2,

- DoD-Std-2167A.

D’autres méthodologies de déroulement de projet, non décrites ici, sont à prendre en compte :

- SMDS (méthode dérivée de MERISE),

- IEEE-1074 (de 91) norme en Ingénierie du logiciel décrivant les processus et activités du cycle de

vie du logiciel.,



- ISO-12207 (de novembre 95), norme en Ingénierie du logiciel remplaçant la norme AFNOR Z67-

150, décrivant les processus et activités du cycle de vie du logiciel.

Il existe d'autres méthodes, dites propriétaires.



2.3.1. Modèle de la cascade

Généralités :

- modèle issu des études de ROYCE en 1970

- modèle basé sur les délivrables (fournitures de fin de phase livrées au client)

- représentation classique du cycle de vie du logiciel

- modèle le plus connu et le plus répandu (de part son antériorité : constat de la crise du logiciel)

- modèle qui a donné lieu à plusieurs variantes (modèle avec prototypage, incrémental, par

extensions successives, en V et en W)

Principes :

- toutes les phases sont exécutées sans exception dans l'ordre indiqué

- chaque phase se termine par une tâche de vérification et validation des résultats (afin d'éliminer les

anomalies et les incohérences)

- passage à la phase suivante si les résultats sont validés par un jury de revue, différent de l'équipe

de développement, éventuellement approuvés par le client ce qui a pour effet d'engager sa

responsabilité

- retour uniquement à la phase précédente : on ne peut changer que les décisions prises à la phase

précédente

La revue de fin de phase a pour mission de vérifier la conformité des résultats de la phase en cours

avec ceux des phases précédentes (traçabilité). Elle aboutit à 4 niveaux d'acceptation de la part du

client :

- l’acceptation définitive ou approbation : accord avec engagement de la responsabilité du client sur

le contenu des résultats et sur leur exploitation

- l'acceptation avec réserve : sans engagement de la responsabilité du client; avec éventuellement

complément d'études ou de justifications (preuves)

- l'acceptation avec réfaction, c'est à dire avec réduction du prix due au fait que la fourniture ne

correspond pas à ce qui était prévu contractuellement

- ajournement de la revue (si au moins un des décideurs est absent ou si les fournitures sont

incomplètes).



Enchaînement des phases :

C o n c e p t io n

P ré lim in a ire

P la n if ic a t io n e t

S p é c if ic a t io n

E tu d e

p ré a la b le

C o n c e p t io n

D é ta illé e

V

V

V

V

T U

C o d a g e

V

In té g ra t io n

E xp lo ita t io n e t

V = V é rif ic a t io n s d e f in d e p h a se

cycle de

développement

T U = T e s ts U n ita ire s

M a in te n a n c e

In s ta lla t io n

R

R = R é c e p t io n a p rè s

V = R e -V a lid a t io nEtape d'utilisation

Etape

avant projet

Etape projet

V

(a p rè s R e -D é v e lo p p e m e n t)

V = te s t d 'in té g ra t io n

e t d e v a lid a t io n " u s in e "

v a lid a t io n " o p é ra t io n n e lle "



Description des phases et des résultats :

Phase Activités Résultats (essentiellement des documents)

ETUDE

PREALABLE

Etude de faisabilité Analyse des

besoins

Rapport d'étude

Schéma directeur

Grandes lignes des besoins

Cahier des charges

PLANIFICATION

et SPECIFICAT

ION

Organisation et mise en place du

projet Définition des

besoins Définition de la stratégie de

test Définition des interfaces

utilisateurs

Plan de développement (référentiel dont le

planning)

Spécification technique des besoins

Spécification (ou plan) des tests d'acceptation

Manuel utilisateur préliminaire

CONCEPTION P

RELIMINAIRE

Conception de

l'architecture Définition des

interfaces Définition des tests

d'intégration

Architecture des modules logiciels

Spécification des interfaces

Spécification (ou plan) des tests d'intégration

CONCEPTION

DETAILLEE

Analyse détaillée des

modules Définition des tests unitaires

Spécification des modules Spécification (ou

plan) des tests unitaires

CODAGE Codage ou programmation Tests

unitaires de chaque module

Code source des modules Comptes-rendus des

tests unitaires

INTEGRATION Intégration Tests

d'intégration Recette usine (tests de

validation chez le fournisseur)

Comptes-rendus des tests d'intégration

Comptes-rendus des tests de validation

Manuel utilisateur final

INSTALLATION

Livraison chez le client Installation et

mise en oeuvre Recette (validation

opérationnelle)

Bordereau de livraison

Comptes-rendus des tests de validation

Procès verbal d'acceptation par le client

EXPLOITATION

et

MAINTENANC

E

Formation des

utilisateurs Corrections des

anomalies Améliorations ou

évolutions Gestion en configuration

des livraisons

Rapports d'anomalies

Demandes d'évolutions Versions du produit

logiciel



Inconvénients :

I1) trop rigide (difficulté d'adaptation) et trop idéal :

- aspect très séquentiel des phases; manque de parallélisme

- les besoins ne sont pas toujours clairement identifiés et les spécifications ne sont pas toujours

figées ou bien elles sont modifiées après la phase de spécification

I2) ne garantit pas que :

- le logiciel livré correspondra bien aux besoins (besoins mal exprimés, incomplets,...)

- on ne rencontrera pas de difficulté de faisabilité (cas de solution théorique non vérifiée en

pratique)

- la maintenance ne sera pas ruineuse (due à une mauvaise conception au départ)

Avantages :

A1) organisation rigoureuse du développement en phases : les règles de passage d'une phase à

l'autre sont clairement définies,

A2) facile à mettre en oeuvre,

A3) favorise la maîtrise du projet (revue de fin de phase).

Conditions d'utilisation (critères de sélection)

C1) pour les petits ou moyens développements

C2) lorsque les besoins sont clairement et complètement exprimés dès le début du développement

C3) en cas de risque à l'intégration

Recommandations (conseils pour la réussite du modèle) :

R1) consacrer des efforts importants aux phases initiales du cycle de vie, car les défauts coûtent

d'autant plus cher à corriger qu'ils se situent dans les phases amont du cycle c'est à dire en

spécification et en conception

R2) bien organiser et formaliser les revues de fin de phases



2.3.2. Modèle avec prototypage

Généralités :

- variante du modèle de la cascade

Objectif :

- pallier l'un des inconvénients majeurs du modèle de la cascade à savoir le risque d'évolution des

spécifications; donner plus de souplesse au début développement

Principes :

Il existe 2 nuances de prototype (terme employé au sens large) :

- modèle développé rapidement avec peu de contraintes qualité, qui sacrifie à la précision

dans certains domaines pour permettre une vérification rapide des fonctions du produit

- forme d'exécutable d'un produit où l'accent est mis sur certains aspects du produit et où

d'autres sont ignorés ou esquissés

Le même terme anglo-saxon englobe les 2 nuances. En français il existe un terme pour désigner

chaque nuance, respectivement "maquette" et "prototype".

Caractéristiques d'une "Maquette" :

- sert de base pour spécifier le produit final : on peut développer une maquette à partir d'une

spécification grossière

- permet de valider les besoins de l'utilisateur (garantir l'adéquation du produit aux utilisateurs);

à partir d'expérimentation sur la maquette, l'utilisateur affine et améliore la spécification

- permet de garantir la faisabilité technique du produit ou d’une partie du produit

- logiciel produit le plus rapidement possible que l'utilisateur pourra expérimenter afin de définir ou

d'affiner les besoins du produit (approche semblable à celle de la programmation exploratoire) :

- logiciel réécrit afin d'en faire un produit de qualité; logiciel non conservé dont on reprend le

développement à zéro; une maquette est "jetable"

- fournit la même apparence que le produit final, sans en avoir l'architecture interne

- développée avec des techniques différentes de celles utilisées pour le produit final

- le maquettage soit est utilisé en phase de spécification, soit constitue une phase intermédiaire entre

les phases de spécification et de conception préliminaire : "prototype"de spécification

Exemple : maquettage des IHM (Interfaces Homme-Machine)

Attention : des tests de performance sur une maquette n'ont aucun sens; les fonctions étant

simulées, les contraintes de temps ne peuvent être validées

Caractéristiques d'un "Prototype" :

- permet de valider des choix de conception (architecture, protocole d’interface, algorithme)

- ne comporte que certaines fonctions (opérationnelles) du produit

- il peut évoluer vers le produit complet par additions successives sans rupture de continuité dans le

développement; un prototype est "récupérable"



- développé avec les mêmes techniques que celles utilisées pour le produit final et avec les mêmes

contraintes qualité

- le prototypage soit est utilisé en phase de conception (préliminaire ou détaillée), soit constitue une

phase intermédiaire entre les phases de conception et de codage : prototype de conception

- exemple : prototypage d'algorithme ou d’architecture

NB : il existe des prototypes "jetables" utilisés pour la validation purement technique, et non la

validation fonctionnelle; exemples : test des performances d'un réseau de communication soit réel

soit simulé (modèle défini à l'aide d'un langage de simulation de type SIMULA ou Modline).



C o n c e p tio n

P ro to typ a g e

M a q u e tta g e

a ff in a g e

sp é c if ic a t io n

C o d a g e

(su ite id e n t iq u e )

a ff in a g e

c o n c e p tio n

( p a rf o is ; à é v it e r)

Techniques dePrototypage :

Objectif : développer rapidement un prototype pour des coûts minimisés

1) langages de spécification exécutables :

- non applicable pour le prototypage des IHM

- le développement risque de ne pas être particulièrement rapide car la spécification formelle

nécessite une analyse détaillée du système

- le système exécutable est en général lent et inefficace

2) langages de très haut niveau, appelés à tort langage de 5ème génération; ce sont des langages de

programmation :

Langage Principe Type Domaine d'application

LISP basé sur les listes fonctionnel traitement symbolique

PROLOG basé sur la logique (prédicat) logique traitement symbolique

SmallTalk basé sur les objets orienté objet Interface Homme-Machine

APL basé sur les vecteurs mathématique système scientifique

SETL basé sur les ensembles ensemble traitement symbolique



Inconvénients :

I1) surcoût à priori pour le client, surtout dans le cas d'une maquette "jetable", mais rattrapé

normalement par la diminution des erreurs de spécification (ou de conception)

I2) allongement des délais dû aux aller et retour entre le réalisateur et le client pour affiner les

besoins

Avantages :

A1) offre plus de souplesse; permet de démarrer un développement sans avoir figé à un stade

précoce les spécifications souvent incomplètes ou remises en cause

A2) constitue un moyen de communication entre le réalisateur et le client; représente une

approximation de l’interprétation que fait le réalisateur

A3) facile à mettre en oeuvre et à modifier; permet une évaluation rapide de la conception du

produit

A4) réduit les risques et donc les coûts en diminuant les erreurs, ou mises à jour trop fréquentes, de

spécification et de conception; erreurs qui seraient décelées plus tard dans le développement et

dont le coût de correction est d'autant plus important qu'elles se situent dans les phases amont

A5) la maquette peut être utilisée pour former les utilisateurs avant la livraison du produit final

Conditions d'utilisation

C1) quand le cahier des charges, provenant du client, ne peut être précisé qu'après développement

d'un prototype

C2) quand on sait que les spécifications, provenant du réalisateur, vont être remises en cause

C3) quand on veut confirmer par l'expérience des hypothèses (IHM, algorithmes,...)

C4) quand on veut avoir l'avis du client avant la fin du développement, c'est à dire avant la phase

de validation

Recommandations :

R1) expliquer au client les avantages et inconvénients à court terme et à long terme

R2) utiliser des langages de haut niveau (par exemple, le langage de programmation ADA pour le

prototypage) ou des outils spécialisés (par exemple, l'outil XFaceMaker pour le maquettage des

IHM)

R3) formaliser par des documents contractuels les phases de codage du prototype et les

acceptations par le client

R4) intégrer le prototypage comme une composante expérimentale d'une réflexion approfondie



2.3.3. Modèle incrémental

Généralités :


- appelé aussi modèle à développements indépendants (ou parallèles) dans GAM-T17

NB : A ne pas confondre avec le vocable anglais « Incremental Model » qui correspond au modèle

par extensions successives (cf 2.3.4).

Objectif :

- pallier le 2ème inconvénient majeur du modèle de la cascade, à savoir le manque de parallélisme

Principes :

- basé sur une technique du découpage du logiciel de façon à réaliser les composants en parallèle

plutôt qu'en série


C o n c e p t io n

P ré lim in a ire



C o n c e p t io n

D é ta illé e

V a lid a t io n

In té g ra t io n

C o m p o sa n t 1

L iv ra iso n

C o n c e p t io n

D é ta illé e

C o d a g e


m a in te n a n c e

C o m p o sa n t N

T e s ts u n ita ire s

(p ro d u it)

C o d a g e

T e s ts u n ita ire s



Avantages :

A1) permet le parallélisme et donc optimise la durée du développement

Inconvénients :

I1) risque à l'intégration

Recommandations :

C1) apporter une attention particulière à la phase de conception préliminaire

C2) bien organiser

C3) respecter le plan qualité



2.3.4. Modèle par extensions successives

Généralités :


- modèle issu des études de WILLIAMS en 1975 puis de MILLS et AL en 1980

Principes :

- consiste à découper le système en plusieurs sous-ensembles logiques appelés extensions

(découpage non pas en étendue c'est à dire par sous-domaine mais en profondeur selon un

critère technique)

- développement par extensions successives et progressives; les fonctionnalités sont étendues

progressivement à partir d'une 1ère réalisation (noyau regroupant les fonctionnalités minimum)

- chaque extension doit s’intégrer dans une architecture globale du produit et faire l'objet d'une

livraison séparée


C o n c e p tio n

P ré lim in a ire



E tu d e

p ré a la b le

C o n c e p tio n

D é ta illé e

C o d a g e (e t te s ts

In té g ra t io n


m a in te n a n c e

In s ta lla t io n

u n ita ire s )

E x te n s io n 1 (n o ya u )

L iv ra iso n 1

C o n c e p tio n

D é ta illé e

C o d a g e (e t te s ts

In té g ra t io n


m a in te n a n c e

In s ta lla t io n

u n ita ire s )

E x te n s io n N

L iv ra iso n N



Inconvénients :

I1) utilisation limitée car il pose des problèmes contractuels

I2) l'ajout de nouvelles fonctionnalités, nécessitant le développement d'une nouvelle extension, ne

doit pas remettre en cause l'architecture globale du produit

I3) gestion plus complexe car il faut gérer toutes les extensions; une partie du logiciel est en

maintenance pendant qu'une autre est en développement; chaque extension peut être considérée

comme un projet à part entière; plusieurs extensions peuvent être développées en parallèle (avec

recouvrement)

Avantages :

A1) permet de disposer plus tôt de versions opérationnelles du logiciel avec des fonctions réduites

A2) combine les avantages de la programmation exploratoire et le contrôle nécessaire aux

développements à grande échelle

A3) élimine le problème des changements incessants de la programmation exploratoire

A4) diminue les risques de dépassement de délai de développement

A5) permet d'affiner le besoin (spécification progressive)

A6) coût souvent inférieur à la démarche classique car il diminue les demandes d'évolution

ultérieures; le produit a plus de chance de satisfaire les besoins réels du client

A7) capitalise l'expérience de l'équipe de développement car l'expérience s'accumule et s'enrichit

progressivement au fur et à mesure des extensions

A8) facilite la validation car celle-ci s'effectue partiellement sur chaque extension


C1) pour des logiciels développés par une équipe réduite sur plusieurs années, la même équipe

travaillant sur toutes les extensions étalées dans le temps

C2) quand le client souhaite avoir très vite un produit minimal, enrichi petit à petit, pour pouvoir

travailler

C3) quand certaines fonctionnalités du produit ne peuvent être précisées dès le début pour

certaines raisons, en particulier : l'attente de fournitures externes, la dépendance avec un autre

projet

Recommandations :

R1) nécessite de la rigueur dans la gestion du développement

R2) exige un accord avec le client (sinon risque de contentieux) concernant la composition des

différentes extensions (versions du produit) et les livraisons



2.3.5. Modèle en V

Généralités :

- issu des études de Goldberg en 1986

- modèle normalisé par l'AFCIQ (Association Française pour le Contrôle Industriel et la Qualité),

l'AFNOR et l'ISO


Principes :

- propose différents niveaux associant à chaque phase de spécification ou conception (phase

descendante du cycle en V) la phase de tests correspondante (phase montante du cycle en V)

- à chaque niveau correspond :

. un objectif double

. un responsable particulier

. un degré de difficulté particulier (décroissant au fur et à mesure)


C o d a g e

C o n c e p tio n

D é ta illé e

C o n c e p tio n

P ré lim in a ire


T e s ts

U n ita ire s

In té g ra t io n

V a lid a t io n

n iv e a u 1

n iv e a u 2

n iv e a u 3

n iv e a u 4 (p h ys iq u e )

(te s ts d 'a c c e p ta t io n )

(te s ts d e s in te rfa c e s)

(te s ts d e c h a q u e c o m p o sa n t sé p a ré m e n t)

(a b s tra it)

(a rc h ite c tu ra l)

(d e sc rip t if )

Par exemple, pour le niveau 1 :

- l'objectif double est :

. spécifier les besoins : analyser les exigences du logiciel à développer

. planifier la validation : définir la stratégie de test à mettre en oeuvre lors de la phase de

validation

- les intervenants sont le chef de projet et le client :

- le degré de difficulté est élevé car un défaut de spécification génère un coût de correction élevé



Résultats des phases : documentation technique

C o d a g e C L

C o n c e p tio n

P ré lim in a ire P L


T e sts

U n ita ire s C L

In té g ra t io n P L

V a lid a t io n P Ld e s b e so in s P L

C o n c e p tio n

D é ta illé e C L

C D C

o u S T B S e t S T I

S T B L

P V L

P M O T V

P IL

P M O T U

P M O T I

L is ta g e c o d e so u rc e

C R T U

C R T I

C R T V

M U

FV

P G C E

M U

P V Q L

M U

D A L

M U

D A D

L is ta g e c o d e so u rc e22

3

4

CDC = Cahier Des Charges du client dont le CDCF (CDC Fonctionnel)

STBS = Spécification Technique de Besoin du Système

STI = Spécification Technique des Interfaces

STBL = Spécification Technique de Besoin du Logiciel (Produit Logiciel)

MU = Manuel Utilisateur (résultant éventuellement d'une activité de maquettage des IHM)

PVL = Plan de Validation du Logiciel (stratégies, responsabilités, moyens, types de test et types

de preuves)

DAL = Document d'Architecture du Logiciel

PIL = Plan d'Intégration du Logiciel

PMOTV = Procédures de Mise en Oeuvre des Tests de Validation (conditions, objectifs, jeux

d'essais, résultats attendus)

DAD = Document d'Analyse Détaillée

PMOTI = Procédures de Mise en Oeuvre des Tests d'Intégration

PMOTU = Procédures de Mise en Oeuvre des Tests Unitaires

CRTU = Comptes-Rendus des Tests Unitaires

CRTI = Comptes-Rendus des Tests d'Intégration

PGCE = Procédures de Génération du Code Exécutable

FV = Fiche de Version (identification et description du logiciel)

CRTV = Comptes-Rendus des Tests de Validation

PVQL = Procès Verbal de Qualification du Logiciel (acceptation client)



Cycle de vie du logiciel dans le cycle de vie du système :

s p é c i fi ca tio nd u s y s tè m e

co n ce p tio nd u s y s tè m e

d é v e lo p p e m e n td u m a té r ie l

i n té g ra tio nd u s y s tè m e

v a l id a tio nd u s y s tè m e

d é v e lo p p e m e n td u lo g ic ie l

Ex p lo i ta ti o n e t

d u s y s tè m em a in te n a n ce

Etu d e d e

d u s y s tè m efa is a b i l i té

D é v e lo p p e m e n td u s y s tè m e

Inconvénients :

I1) l'utilisateur, ou client intervenant uniquement au niveau 1, doit attendre les tests de validation

(appelés aussi tests d'acceptation ou de qualification) pour s'assurer que ses exigences ou besoins

ont été pris en compte de manière satisfaisante

Avantages :

A1) modèle normalisé

A2) montre l'interaction non seulement entre les phases successives mais aussi entre les phases de

même niveau

A3) le cycle de vie du logiciel est intégré dans le cycle de vie du système



2.3.6. Modèle en W

Généralités :

- basé sur le modèle en V

Objectif :

- pallier l'inconvénient majeur du modèle en V à savoir le manque de visibilité et d'acceptation de la

part du client avant la phase de validation

Principes :

- introduit une phase de définition des interfaces externes (cf 2.3.2 : modèle avec prototypage)

- l'utilisateur peut s'appuyer sur des maquettes d'écrans pour juger, dès le stade de la conception,

les interfaces utilisateur du futur produit logiciel


C o d a g e

C o n c e p tio n

D é ta illé e

C o n c e p tio n

P ré lim in a ire 2


T e s ts

U n ita ire s

In té g ra t io n

V a lid a t io n

C o n c e p tio n

P ré lim in a ire 1


d e s in te rfa c e s

C o n c e p tio n g é n é ra le d u sys tè m e

C o n c e p tio n d é ta illé e d u sys tè m e

C o n c e p tio n d é ta illé e d u c o m p o sa n t

d e s b e so in s



2.3.7. Modèle basé sur la Programmation exploratoire

Généralités :

- équivalent à la 1ère phase du modèle avec prototypage

- modèle non basé sur les spécifications

Principe :

- développer une 1ère implémentation aussi vite que possible

- la montrer aux utilisateurs pour commentaires

- la modifier en plusieurs itérations jusqu'à obtenir un logiciel adéquat, c'est à dire convenant aux

utilisateurs (VALIDATION), plutôt qu'un logiciel correct c'est à dire conforme à un cahier des

charges ou une spécification (VERIFICATION)

L iv re r l e s y s tè m e

o p é ra tio n n e l

s y s tè m e a d é q u a t ?

OU I

u ti l i s e r l e s y s tè m e

lo g ic ie l

co n s tru i re u n s y s tè m elo g ic ie l

N ON

d é fin i r l e s g ra n d e s

l ig n e s d e s b e s o in s

m o d i fi e r l e s y s tè m elo g ic ie l



Inconvénients :

I1) il n'est pas adapté au développement de la plupart des gros logiciel appelés à durer longtemps;

risque de coût de maintenance élevé car la structure du logiciel change souvent

I2) documentation très coûteuse du fait que le logiciel change souvent; il n'est pas adapté à une

approche basée sur les documents ce qui a pour conséquence de diminuer la visibilité et donc de

rendre plus difficile la maîtrise du projet

I3) la vérification est impossible car il n'existe pas de spécification; la notion de logiciel incorrect n'a

pas de sens

Avantages :

A1) permet de démarrer le développement lorsque les besoins ne sont pas encore formulés de

manière suffisamment détaillée

A2) sans contrainte de qualité forte (formalisme de la documentation, ...)


C1) à ne pas utiliser pour développer des gros systèmes logiciel dont la durée de vie est importante

C2) bien adapté au développement de système en IA

Recommandations :

R1) utiliser des techniques qui permettent des itérations rapides (par exemple des langages de haut

niveau tels que LISPS, PROLOG)

R2) à utiliser par de petites équipes de personnes ultra-compétentes et ultra-motivées



2.3.8. Modèle basé sur la transformation formelle

Objectifs :

- définir rigoureusement ce que le logiciel doit faire

- détecter les défauts des spécifications informelles et affiner celles-ci

Principe :

- à partir des spécifications informelles issues de l'itération des phases de Spécification et de

Conception Préliminaire (spécification des éléments logiciel), écrire la spécification formelle dans

un langage précis tant sur le plan syntaxique que sémantique

- transformer la spécification formelle en programme à l'aide de règles

Méthodes et techniques de réalisation :

- spécification algébrique décrivant :

. des "sortes" d'objets

. des opérations sur ces "sortes" d'objets

. une liste de propriétés (axiomes) vérifiant ces propriétés

- langages exécutables de spécification

- langages de manipulation d'objets :

. PLUSS du LRI d'Orsay

. LARCH du MIT et de DEC

Avantages :

A1) modèle adapté à une approche basée sur les documents

A2) le formalisme permet de s'assurer de la complétude et de la cohérence des spécifications

A3) permet d'obtenir facilement des maquettes

A4) permet de faire des preuves; les spécifications formelles se traduisent en pré et post-conditions

utilisées dans les preuves

A5) permet de guider la conception des tests (scénarios)

Inconvénients :

I1) mauvaise visibilité du processus de conduite de projet car démarche peu compréhensible par

des non techniciens

I2) nécessite une solide formation

I3) nécessite des outils car devient très vite complexe pour être réalisé manuellement


C1) adapté au développement de logiciel à haut risque de sûreté de fonctionnement, terme

recouvrant à la fois la sécurité, la disponibilité, la fiabilité et la maintenabilité

Recommandations :

R1) attendre l'apparition d'outils mûrs

R2) à utiliser pour des petits et moyens projets



2.3.9. Modèle basé sur l'assemblage de composants réutilisables

Généralités :

- la réutilisation est un sujet qui devient de plus en plus important dans la conception préliminaire de

système, mais la réutilisation systématique est peu répandue

- le processus de développement relève plus de l'assemblage que de la création

Il existe 4 types de composants réutilisables :

a) les applications complètes

b) les sous-systèmes d'une application

c) les modules ou les objets (ensemble de fonctions, package ADA,...)

d) les fonctions (ensembles de composants logiciel implémentant une seule fonction)

Les types a) et b) sont peu utilisés; les types c) et d) sont moins utilisés or ils sont plus concernés par

le problème de réutilisabilité.

Il existe 2 types de réutilisabilité :

- orientée COMPOSANT (réutilisation directe)

- orientée GENERATION (réutilisation après génération)

Principe :

Modèle de développement basé sur la conception pour déterminer les composants à réutiliser .

Il comprend 4 étapes successives :

1) concevoir l'architecture du système

2) spécifier les composants

3) chercher des composants réutilisables

4) incorporer les composants trouvés

Il existe une variante qui est le modèle de développement basé sur la réutilisation où les besoins sont

modifiés en fonction des composants disponibles; la conception est alors basée sur les

composants réutilisables; elle comprend 6 étapes successives :

1) définir les grandes lignes des besoins du système

2) chercher les composants réutilisables

3) modifier les besoins en fonction des composants trouvés

4) définir les grandes lignes de l'architecture du système

5) chercher les composants réutilisables

6) spécifier les composants du système en se basant sur les composants réutilisables



Avantages :

A1) réduit le coût de production et de maintenance

A2) réduit le temps de développement et de validation

A3) améliore la productivité

A4) augmente la fiabilité; les composants réutilisés ont déjà été testés en situation opérationnelle

A5) réduit les risques d'erreur dans l'évaluation; le coût de réutilisation est en général plus facile à

estimer que le coût de développement

A6) permet d'utiliser efficacement des spécialistes (encapsulation de leur connaissance)

A7) permet d'implémenter des standards

Inconvénients :

I1) modèle non encore viable à cause du manque de bibliothèques de composants réutilisables

dans certains domaines informatiques (temps réel, commande-contrôle,...)

I2) nécessite un effort supplémentaire de développement pour rendre des composants réutilisables;

isoler les parties du programme qui dépendent de l'environnement à l'intérieur d'une interface de

portabilité (API : Application Programing Interface)

I3) nécessite que les composants réutilisables soient compréhensibles avec des informations sur la

manière de les réutiliser


C1) suppose que le système soit composé d'éléments déjà existants

Recommandations :

R1) utiliser les types abstraits de données et les objets qui sont particulièrement adaptés à

l'encapsulation des composants réutilisables

R2) utiliser la technique d'héritage qui permet de réutiliser tout en adaptant

R3) utiliser au mieux des standards (langage, O.S., réseau, graphique,...) diminuant les problèmes

de portage (forme de réutilisation)



2.3.10. Modèle de la spirale

Généralités :

- crée par Boehm en 1988

- modèle basé sur les risques et non sur les délivrables : évaluation des risques de gestion à étapes

régulières pendant le déroulement du projet et sur le déclenchement d'actions pour contrer les

risques

- reprise de l'idée d'extensions successives : approche itérative du processus de développement du

logiciel représentée par les boucles successives de la spirale

Objectif :

- modèle qui puisse supplanter tous les autres modèles génériques, définis précédemment, et qui

satisfasse les besoins des fournisseurs de logiciel.

Principes :

La 1ère boucle de la spirale commence par la revue de démarrage du projet.

A chaque cycle (ou boucle) de la spirale :

- au début : analyse des risques (tout ce qui peut mal se passer), définition des actions permettant

de les réduire voire de les résoudre

- puis prototypage (au sens large) suivi d'une simulation servant d'entrée aux spécifications

- à la fin : procédure de revue ou d'acceptation permettant le passage au cycle suivant

Le dernier cycle représente la fin du cycle en V (à partir de la conception détaillée).

Chaque quartier de la spirale possède les objectifs suivants :

- 1er quartier (en haut à droite puis sens des aiguilles d'une montre) : évaluer les alternatives;

identifier et résoudre les risques :

----> choix du modèle de développement approprié (par exemple : prototypage si risque

d'évolution de l'IHM, transformation formelle si risque concernant la sûreté de fonctionnement,

modèle de la cascade si risque à l'intégration)

- 2ème quartier : développer et vérifier le produit (prototype)

- 3ème quartier : planifier les phases du cycle suivant

- 4ème quartier : déterminer, lors de la revue de fin de cycle, les objectifs (exprimés en terme de

fonctionnalités et de performances), les alternatives et leurs contraintes pour y parvenir



Diagramme d’enchaînement des phases :



Inconvénients :

I1) il oblige à considérer toutes les alternatives et tous les risques

Avantages :

A1) il peut incorporer tous les autres modèles de développement : en effet, il n'est pas nécessaire

d'adopter un seul modèle à chaque cycle de la spirale.

Exemple 1 : modèle avec prototypage dans un cycle pour résoudre le problème de la

spécification de besoin, puis modèle conventionnelle de la cascade en cas de risque d'intégration

Exemple 2 : modèle de transformation formelle dans un cycle pour résoudre le problème de la

sûreté de fonctionnement, puis modèle basé sur la réutilisation pour l'IHM.



2.3.11. Méthode MERISE

Généralités :

- issue des études de TARDIEU, ROCHFELD et COLLETTI en 1983

- méthode de conception possédant une composante de conduite de projet non négligeable

NB : initialement méthode de conception (définissant le COMMENT FAIRE) mise au point

sur la demande d'un ministère français à la fin des années 70 pour tirer le meilleur parti des

nouvelles techniques informatiques, en particulier celles concernant les bases de données

Principes :

La démarche est composée de 8 étapes :

1) le schéma directeur : étape de réflexion globale et de planification générale (démarche inspirée

de la méthode RACINE)

2) l'étude préalable : réflexion sur une grande fonction de l'entreprise dont on a décidé

l'informatisation; exploration de différentes solutions (préconisation de maquette voire de

prototype)

3) l'étude détaillée : étude fonctionnelle exhaustive de la solution retenue

4) l'étude technique : fournir l'architecture du système et les spécifications internes

5) la production du logiciel : élaboration des différents programmes et transactions

6) la mise en oeuvre : mise à disposition du système aux utilisateurs

7) la généralisation : mettre le système à disposition de tous les utilisateurs en intégrant les contextes

organisationnel et matériel propres à chaque site d'exploitation

8) la maintenance et l'évolution :

- la maintenance consiste à maintenir le système en état de marche à fonctionnalités constantes

- l'évolution consiste à maintenir le système en état de marche à fonctionnalités croissantes

Les étapes, séquentielles pour les 1ères, peuvent être parallélisées à partir de l'étude détaillée.

L'étape de "maintenance-évolution" déroule un cycle de vie complet pouvant comprendre la

conception, la réalisation et la mise en oeuvre d'une nouvelle version.

Une variante intégrant le maquettage-prototypage à été créée par TARDIEU en 1988.

L'étude préalable est de plus en plus validée par la production de maquette ou de prototype, ceci dans

le but de faciliter la vente du système proposé. En études détaillées (où il est envisageable de produire

des maquettes) et lors des études techniques (où il est envisageable de produire des prototypes), cette

élaboration permet d'aboutir aux validations fonctionnelles et techniques des spécifications du système.

Une simulation des résultats obtenus est alors effectuée; elle peut dans certains cas remettre en cause

des options retenues.



Maquettage et prototypage dans la démarche MERISE

Etu d e p ré a la b le

Etu d e s d é ta i l l é e s

Etu d e s te ch n iq u e s

R é a l i s a tio n s e t te s ts

m a q u e tte

p ro to ty p e

Sim u la tio n s

v e n t e d u s y s t è m e

v a l id a tio n s p a r l e s

u ti l i s a te u rs

v a l i d a tio n s p a r l e s

u ti l i s a te u rs

v a l i d a tio n s te ch n iq u e s

In té g ra tio n s

m a q u e tte s

p ro to ty p e s

Avantages :

I1) méthode devenue un standard de fait dans certains milieux, en particulier les administrations

civiles, et dans certains domaines, en particulier la gestion

Inconvénients :

I1) méthode spécifique, non normalisée



2.3.12. Méthode MCP

Généralités :

- Méthode de Conduite de Projet informatique créée par GEDIN en 1975

- modifiée en 1986; modifications s'inspirant de la méthode MERISE

Principes :

La démarche se compose de 4 divisions ou phases et chaque phase est découpée en étapes :

1) la conception, comprenant 4 étapes

- l'expression du besoin d'automatisation

- l'étude d'opportunité

- l'étude du système d'information futur

- l'élaboration du cahier des charges

2) la réalisation, comprenant 2 étapes :

- l'étude du système informatique

- la programmation et les essais

3) la mise en oeuvre, comprenant 2 étapes :

- la réception provisoire par l'utilisateur

- le lancement du système sous contrôle

4) l'exploitation, comprenant 2 étapes :

- l'évaluation de l'application

- l'évaluation du projet

Inconvénients :

I1) méthode spécifique, non normalisée



2.3.13. Méthode AFNOR

Généralités :

- méthode de conduite de projet normalisée : normes AFNOR Z67-101 de 1984 définissant des

recommandation de conduite de projets informatiques

- au confluent des méthodes MERISE et MCP

- méthode basée sur les documents

Principes :

Cette méthode propose un découpage projet à travers une série de documents jalonnant une

application informatique ainsi que les grandes étapes qui en découlent. Elle est composée de 5 phases

comprenant des étapes :

1) l'étude préalable :

- l'exploration

- la conception d'ensemble (architecture)

- l'appréciation de la solution retenue

2) la conception détaillée :

- la conception du système de traitement de l'information

- la spécification fonctionnelle du système informatique

- l'étude organique générale

3) la réalisation :

- l'étude organique détaillée

- la programmation et les tests

- la validation technique

4) la mise en oeuvre :

- la réception provisoire de la réalisation

- l'exploitation sous contrôle

5) l'évaluation :

- l'évaluation du système informatique

- l'évaluation du système de traitement de l'information

A ces recommandations vient s'ajouter un processus général d'assurance et de contrôle qualité

(recommandations de plan logiciel : norme AFNOR Z67-130 de 1987).

Avantages :

A1) méthode normalisée


C1) conseillée dans le domaine civil, en particulier dans les domaines de la gestion et des services

en général



2.3.14. Méthode GAM-T17 (V2)

Généralités :

- guide méthodologique de développement de logiciel embarqué pour des systèmes militaires

français

- méthode créée ( version 2 en 1989) par la DGA (Direction Générale de l'Armement) : méthode

standard de la défense française

- basée sur le modèle en V (ou cycle en V) normalisé par l'AFCIQ (Association Française pour le

Contrôle Industriel et la Qualité)

- la décomposition des activités dans les phases de développement est basée sur une approche

fonctionnelle de décomposition du produit

Principes :

- le cycle de développement du logiciel est intégré dans le cycle de vie du système : le logiciel est

intégré dans l'architecture du système

- il existe, en fonction de la complexité du logiciel, 3 processus de développement :

. un processus général

. un processus réduit (processus général allégé de contrôles qualité)

. un processus à développements indépendants : le logiciel est décomposé en éléments

traités, selon le processus général, indépendamment les uns des autres (cf 2.3.3 : modèle

incrémental)



sys tè m e

so u s-sys tè m e

é q u ip e m e n t

é q u ip e m e n t

lo g ic ie l

E lé m e n t L o g ic ie l

m a té rie l (P ro d u it L o g ic ie l)

E lé m e n t L o g ic ie l

C o m p o sa n t L o g ic ie l

D é c omposition d'un systè me

(P ro d u it m a té rie l e t lo g ic ie l)



Architecture logicielle :

- Produit logiciel (PL) : fourniture spécifiable, recettable et livrable

- Elément logiciel (EL) : constituant du produit caractérisé par son unité fonctionnelle dont la

réalisation est confiée à un responsable unique; c'est l'unité de documentation d'exploitation et de

maintenance. Il s'agit donc également d'une fourniture spécifiable, recettable et livrable.

- Composant logiciel (CL) : constituant du produit logiciel ou d'un élément logiciel réputée

indivisible lors de la réalisation et transcriptible directement dans un langage de programmation. Il

ne fait pas l'objet d'une spécification ni d'une conception préliminaire mais uniquement d'une

conception détaillée.

Processus général :

C o d a g e C L

C o n c e p tio n



T e s ts

U n ita ire s C L


V a lid a t io n P Ld e s b e so in s P L

responsable système

responsable logiciel

réalisateurs

RSL

RCP

RCD

RQL

(PL)

(PL)

(CL)C o n c e p tio n

D é ta illé e C L

Revues : elles doivent être planifiées et leur coût prévu

- RSL = Revue de Spécification du Logiciel (produit logiciel)

- RCP = Revue de Conception Préliminaire du logiciel

- RCD = Revue de Conception Détaillée du produit logiciel

- RQL = Revue de Qualification du Logiciel (revue d'acceptation client)



Processus à développements indépendants :

C o d a g e C L

C o n c e p tio n

P ré lim in a ire E L i

C o n c e p tio n

T e s ts

U n ita ire s C L

In té g ra t io n E L i

V a lid a t io n E L i


R C P

R C P E

R C D E

C o n c e p tio n

D é ta illé e C L


d e s b e so in s P L

R S L

V a lid a t io n P L

R Q E

processus

général

élément i

R Q L


- a rc h ite c tu re P L

- sp é c if ic a t io n é lé m e n ts E L i

Revues concernant chaque élément ELi :

- RCPE = Revue de Conception Préliminaire de l'élément logiciel i

- RCDE = Revue de Conception Détaillée de l'élément logiciel i

- RQE = Revue de Qualification de l'élément logiciel i (revue d'acceptation du responsable logiciel)



La documentation du produit logiciel est organisée en dossiers :

* Dossier de Définition (DD) :

- STB = Spécification Technique de Besoin des constituants du logiciel (éléments logiciel)

- DAL = Document d'Architecture du Logiciel

- DAD = Document d'Analyse Détaillée

- Listing du code source

- PGCE = Procédures de Génération du Code Exécutable

- FV = Fiche de Version (identification et description du logiciel)

* Dossier de Justification de Définition (DJD) :

- justification de l'architecture du logiciel

- justification d'algorithmes (de niveau conception détaillée)

- PVL = Plan de Validation du Logiciel

NB : distinguer la validation "usine" (de responsabilité fournisseur ) de la validation

"opérationnelle" (de responsabilité client) faisant parfois l'objet d'un plan distinct appelé

"plan de réception" définissant les tests de qualification

- PIL = Plan d'Intégration du Logiciel

- PMOTV = Procédures de Mise en Oeuvre des Tests de Validation

- PMOTI = Procédures de Mise en Oeuvre des Tests d'Intégration

- PMOTU = Procédures de Mise en Oeuvre des Tests Unitaires

- CRTU = Comptes-Rendus des Tests Unitaires

- CRTI = Comptes-Rendus des Tests d'Intégration

- CRTV = Comptes-Rendus des Tests de Validation

- PVQL = Procès Verbal de Qualification du Logiciel

- comptes-rendus de revues



Inconvénients :

I1) méthode très contraignante au niveau de la qualité (dossiers, documents, revues)

I2) méthode française non reconnue pour des projets internationaux

I3) méthode spécifique au développement de logiciel

Avantages :

A1) méthode s'appuyant sur le modèle en V normalisé

A2) le logiciel à développer est intégré dans l'architecture système

A3) elle définit de façon détaillée les actions qualité (contrôles de fin de phase),

A4) elle prévoit l'allégement des contraintes qualité en fonction de la complexité du logiciel, de sa

taille et de son niveau de criticité; pour les logiciels simples et/ou de petites tailles et non critiques

seules les revues des phases amont sont nécessaires,

A5) le "processus à développement indépendant" permet de maîtriser des développements sous-

traités,

A6) elle reste ouverte à toutes les méthodes de conception et de réalisation,

A7) méthode française bien perçue par les organismes nationaux (armées, administrations)

A8) bien qu'élaborée par la DGA (Direction Générale de l'Armement), elle peut être facilement

généralisée et ne présente que très peu de spécificités liées au domaine militaire.


C1) bien adaptée au développement de gros projets logiciel soumis à de fortes contraintes qualité

Recommandations :

R1) recommandée, voire exigée, pour des projets étatiques, militaires ou non



2.3.15. Méthode DoD-Std-2167A

Généralités :

Cette méthode est décrite par comparaison à la méthode GAM-T17 V2.

- standard de la défense US (de février 88)

Principes :

- même logique de développement d'un système pour aboutir à une architecture matérielle et logicielle

:

. découpage en phases rythmé par des revues,

. architecture documentaire,

- il n'existe pas d'équivalence entre la structure documentaire de DoD-2167 et celle de

GAM-T17:

. les notions de DD, DJD, PQL et OT de GAM-T17 n'ont pas vraiment d'équivalent dans le DoD-

2167

Inconvénients :

I1) elle ne possède pas de méthode de développement de type "processus à développements

indépendants"

I2) méthode Américaine mal perçue par certains organismes Français

I3) elle est moins précise que GAM-T17 en ce qui concerne les actions qualité (contrôles de fin de

phase)

Avantages :

A1) elle est moins contraignante que GAMT-17 sur l'aspect logiciel

A2) adapté au développement de système matériel et logiciel


C1) bien adaptée au développement de gros projets systèmes, matériel et logiciel

Recommandations :

R1) recommandée, voire exigée, pour des projets internationaux, européens en particulier



2.3.16. Synthèse

S1) Concernant les modèles basés sur les délivrables :

- ils permettent un meilleur suivi d'avancement : organisation en phases et activités; phase terminée

si les produits résultats sont acceptés ou approuvés (avec engagement de sa responsabilité) par le

client,

- ils offrent une meilleure visibilité au client (documents d'études, comptes-rendus de test,

revues,...),

- le modèle de la cascade n'est pas le plus adéquat mais il continuera à être utilisé car il simplifie

grandement la gestion du processus de développement; en effet beaucoup d'organismes

gouvernementaux et de fournisseurs de gros logiciels ont adopté comme standard général le

modèle de la cascade

- ils ont naturellement tendance à limiter le nombre d'itérations "spécification-conception" à

chaque niveau de décomposition, car les documents sont gelés (gérés en versions après

livraison) et deviennent coûteux à modifier; cela peut entraîner, lorsqu'un problème est rencontré,

le choix d'une solution peu élégante pour éviter le coût d'une itération et pour ne pas modifier un

document final,

- du fait que les gestionnaires ont besoin de documents fournis à intervalles réguliers de manière à

évaluer l'état d'avancement du projet, si le calendrier de gestion est différent du calendrier réel lié

au développement cela risque de générer des documents artificiels qui augmenteraient le

coût du projet,

- le fait qu'un document issu d'une phase soit utilisé en entrée de la phase suivante est biaisé car

cela sous-entend que le processus de développement est linéaire or, à n'importe quel phase du

processus, les développeurs prennent en compte les étapes précédentes comme les étapes

suivantes (par exemple, il n'y a aucun intérêt à créer une conception qui sera difficile à

implémenter même si elle correspond aux besoins);

----> dans la réalité les phases interagissent dans les 2 sens

- il est rare que l'on passe facilement d'une phase à l'autre du processus car il faut un certain temps

pour lire et approuver un document;

----> dans la réalité les phases se recouvrent (on ignore les procédures formelles et on

démarre une phase avant que les documents de la phase précédente aient été achevés),

- on ne peut résoudre tous les problèmes en créant une spécification détaillée puis une conception

puis une implémentation;

----> en appliquant aveuglément le modèle de la cascade basé sur les documents on

a rendu un certain nombre de projets très coûteux.



S2) Adéquation des modèles vis à vis des documents :

Modèle Adéquation de la documentation

cascade bien adapté, conçu autour des

documents

prototypage prolifique en phase d'initialisation et

d'itérations rapides

programmation

exploratoire

mal adapté; les itérations sont si rapides

que la génération de document revient

cher.

transformation formelle bien adapté; les documents formels

sont essentiels.

cycle en V bien adapté, conçu autour des

documents

orienté réutilisation mal adapté; les documents décrivant le

système risquent de limiter la

réutilisation.

S3) la meilleure alternative, actuellement, est le modèle de la spirale basé sur le risque car il

permet d'adapter le processus de développement en fonction du domaine d'application et de l'état

d'avancement du développement (un modèle différent à chaque boucle).

S4) Utilisation des méthodes de développement de logiciel en fonction du domaine d'application :

- dans les domaines civils de la gestion et des services : MERISE ou AFNOR Z67-101,

- dans les domaines militaires de la défense, de l'aérospatiale et de l'industrie :

GAM-T17 V2 pour les projets Français et DoD-std-2167A pour les projets Européens.



CONCLUSION :

Les cadres méthodologiques constituent des cadres généraux de conduite de projet. Ils définissent :

- le découpage des travaux en phases/étapes/activités/tâches,

- les rôles des principaux acteurs

- les formalisations de représentation (plan type des documents)

Caractéristiques d'un cadre méthodologie :

- ce n'est pas un recueil plus ou moins ordonné de méthodes particulières dédiées à l'ingénierie du

logiciel

- diffère des méthodes qui guident la résolution de problèmes ponctuels

- indique CE QU'IL FAUT FAIRE (ou QUOI FAIRE) de façon plus ou moins exhaustive, mais

PAS, ou peu, COMMENT Y PARVENIR

Une méthode est construite selon une démarche à la fois rationnelle et empirique, déductive et inductive. Elle

ne peut servir des buts fondamentalement divergents. Elle définit un ensemble de procédés visant un objectif

unique dans un domaine dédié.

Une méthode de conduite de projet propose à travers des techniques, et éventuellement des outils, de

s'intéresser aux procédures de gestion d'un projet au fur et à mesure de son cycle de vie.

Une méthode de conduite de projet indique non seulement CE QU'IL FAUT FAIRE mais définit le

COMMENT GERER le COMMENT FAIRE, c'est le cas pour :

- MERISE (même si parfois assimilée à un cadre méthodologique; considérée comme un

standard)

- MCP (de RATP et GFI)

- SDM/S (de CEGELOG)

- MEDIA (de SOPRA)

- Method ONE (d'Arthur Andersen)

- AXIAL (d'IBM)

Sont considérés comme cadres méthodologiques, indépendants des méthodes et outils de développement :

- normalisés ou standards :

. AFNOR Z67-101

. GAM-T17 V2

. DoD-std-2167A

- propriétaires :

- ARAMIS (de SG2)

- MELUSINE (de CAP SESA)

- VSOP (de CISI)

- ASMODEE (de ALCATEL TITN)

La conduite de projet n'est pas une fin en soi mais un moyen de se prémunir contre les

débordements d'un processus de créativité sans fin.

_CdP_2000_v1

Documents

Transcript of _CdP_2000_v1