Date : 21/02/2011

CONDUITE DE PROJET LOGICIEL (1 ERE PARTIE)

LOGIQUE DE DEROULEMENT dun Projet Logiciel Modles, Mthodes, Normes et standards

EPITA-2000

C. CHEVALLIER

Page : 1

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL

TABLE DES MATIERES

1. GENERALITES ..............................................................................................................................3 1.1. Crise du logiciel ...................................................................................................................3 1.2. Caractristiques du logiciel...................................................................................................4 1.3. Qualit du logiciel ................................................................................................................5 2. CONDUITE DE PROJET LOGICIEL..........................................................................................6 2.1. Dfinition et objectifs ...........................................................................................................6 2.2. Cycle de vie du logiciel ........................................................................................................6 2.3. Modles et mthodes de dveloppement ..............................................................................8 2.3.1. Modle de la cascade ...........................................................................................9 2.3.2. Modle avec prototypage .....................................................................................13 2.3.3. Modle incrmental ..............................................................................................16 2.3.4. Modle par extensions successives........................................................................18 2.3.5. Modle en V ........................................................................................................20 2.3.6. Modle en W .......................................................................................................23 2.3.7. Modle bas sur la Programmation exploratoire ....................................................24 2.3.8. Modle bas sur la transformation formelle ............................................................26 2.3.9. Modle bas sur l'assemblage de composants rutilisables .....................................27 2.3.10. Modle de la spirale ...........................................................................................29 2.3.11. Mthode MERISE .............................................................................................32 2.3.12. Mthode MCP ...................................................................................................34 2.3.13. Mthode AFNOR ..............................................................................................35 2.3.14. Mthode GAM-T17 (V2) ..................................................................................36 2.3.15. Mthode DoD-Std-2167A .................................................................................42 2.3.16. Synthse.............................................................................................................43 3. GESTION DE PROJET (2me Partie)

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

Page : 2

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 1. GENERALITES 1.1. Crise du logiciel La prise de conscience de la crise est apparue vers les annes 1970 avec l'arrive des ordinateurs (de 3me gnration) beaucoup plus puissants permettant des applications jusqu'alors irralisables. Elle est ne du constat suivant : - impossibilit, de la part des services informatiques, de donner priori, une valuation fiable du cot et du dlai de dveloppement et de la qualit d'un logiciel. NB : selon une tude du DoD aux US en 1988, 70 % des projets initialiss sont abandonns avant leur achvement pour : - non conformit (non respect du cahier des charges), - inadquation de la ralisation par rapport au besoin, - retard trop important, - dpassement de budget, et les 30 % restants connaissent un retard moyen de plusieurs annes; Il s'agit bien sr de gros projets, militaires ou technologiquement sensibles, dont la dure de dveloppement est de plusieurs annes. 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 spcificit du logiciel (cf 1.2), - l'absence de cadre mthodologique standard, - les mthodes de dveloppement de logiciel existantes n'taient pas suffisamment bonnes et adaptes, - l'absence d'outil de gestion quantitative du dveloppement, - l'absence de mtrologie de la qualit des processus et des produits logiciels, - la croissance de la part du logiciel, au dtriment du matriel, dans le cot de dveloppement des systmes, - l'augmentation de la part de la maintenance dans le cot total : cot de la maintenance pendant la dure de vie > cot du dveloppement du logiciel La crise a donn lieu l'avnement d'une nouvelle technique : LE GENIE LOGICIEL visant rationaliser le processus de dveloppement du logiciel l'aide de mthodes, procdures et outils (mergence vers la fin des annes 1980 d'ateliers de gnie logiciel intgr : AGLI). La CRISE n'est PAS TERMINEE : les principes et les mthodes ne sont pas fautifs, le PROBLEME est plutt qu'ils ne son PAS APPLIQUES.

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

Page : 3

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 1.2. Caractristiques du logiciel La spcificit du logiciel tient aux caractristiques suivantes qui le distingue du matriel : produit unique (pas de notion de lot/srie) : il est copiable ou reproductible immatriel, invisible, non palpable, abstrait : il est difficile mesurer ne s'use pas, ne se dgrade pas ne se manifeste qu'au travers du matriel; il s'excute sur un calculateur, sa fiabilit augmente avec le temps, au fur et mesure de la maintenance (corrections), le logiciel est considr comme "mallable" : l'exprience montre que s'il est facile modifier, il est difficile de le faire correctement (sans rgression)

la taille du logiciel a de moins en moins domportance technique non encore adulte car rcente; le gnie logiciel est encore en plein essor et en cours de maturation (cf 1.1) NB : Un logiciel, comme le matriel, peut mourir (retrait de service) et devenir obsolte (par exemple le passage lan 2000). Ci-aprs la courbe de comparaison de l'volution des cots de logiciel et de matriel. cot (tendance)
matriel informatique logiciel spcifique

logiciel du commerce

1970 Dans les annes 60 :

1980

1990

- la part du matriel 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 spcialis et les candidats ne manquaient pas - les cot de personnel taient faibles, surtout en comparaison des cots du matriel. Depuis les annes 70 : - les cots des matriels sont de moins en moins levs pour des puissances de traitement et de stockage de l'information toujours plus importantes - les cots du logiciel ont tendance tre de plus en plus levs, cela tant essentiellement d la composante main d'oeuvre. Au dbut des annes 80 : - inversion du rapport entre le poids du logiciel et celui du matriel - le logiciel du commerce permet d'inflchir la courbe du cot des logiciels qui prsente une forte tendance l'inflation. EPITA : Cours de Conduite de Projet Logiciel (C. CHEVALLIER) Page : 4

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 1.3. Qualit du logiciel La NON QUALITE du logiciel est due aux carts de perception du besoin tout au long du droulement du projet. Le schma suivant illustre l'volution de la perception du besoin :
Non Qualit du fait du client Non Qualit du fait du fournisseur Besoin Besoin idal rel exprim Besoin pris en compte Besoin satisfait produit livr produit

La difficult est moins de rpondre un besoin que de le comprendre et de maintenir la finalit du projet tout au long des phases d'laboration de la solution. D'aprs les travaux de Myers en 1988 aux US, le simple transfert des dossiers entre les intervenants d'une phase l'autre entrane une perte d'information de prs de 10% et seulement 35% des besoins couverts en fin du cycle de dveloppement. Un "BON" logiciel doit possder les 4 facteurs cls suivants : - il doit tre fiable , - il doit tre efficace dans son fonctionnement (performant : temps de rponse; sans gaspillage de ressources informatiques : mmoire, unit centrale), - il doit tre simple et souple d'emploi (interface utilisateur approprie : aide en ligne, ergonomie, fonctions d'apprentissage), - il doit tre maintenable (apte subir des modifications et des volutions moindre cot). Il est difficile d'optimiser tous ces facteurs car certains s'excluent mutuellement. Par exemple, une meilleure utilisation, via une interface homme-machine (IHM) sophistique, peut rduire l'efficacit. D'autre part la notion de cot n'est pas ngligeable : le cot augmente de faon exponentielle en fonction de l'efficacit. Le problme n'est pas de proposer le produit le plus sophistiqu mais LE PLUS ADAPTE c'est dire rpondant aux exigences de performance, de cot et de disponibilit . C'est parce que le cot 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).

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

Page : 5

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Solution : adopter un cycle de dveloppement ds la phase de spcification du besoin pour prvoir les moyens utiliser permettant de vrifier et valider chaque phase intermdiaire.

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

Page : 6

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2. CONDUITE DE PROJET LOGICIEL 2.1. Dfinition et objectifs La conduite de projet a pour objectifs : - de matriser la qualit, les cots et les dlais de dveloppement dans un souci d'efficacit et de rentabilit - d'amliorer le processus de dveloppement du logiciel On peut donc dfinir la conduite de projet comme tant l' ensemble des activits destines assurer le droulement d'un projet dans les meilleures conditions de cot, de dlai et de qualit des rsultats . Autre dfinition possible : ensemble des activits destines assurer la coordination des acteurs et des tches afin de raliser un projet dans des limites donnes de temps, de moyens et de cots. Conduire un projet, c'est donc prendre un ensemble de mesures pour assurer la bonne fin du projet en matrisant l'ensemble des ressources et les rsultats. La conduite de projet s'attache principalement l'enchanement des tapes, phases et tches (appeles aussi activits) effectuer pour mettre en oeuvre la dmarche dcrite par la mthode utilise, ventuellement base sur un ou plusieurs modles. Elle dfinit : - le QUOI FAIRE - le QUI FAIT - le QUAND LE FAIT-IL et non - le COMMENT FAIRE une tche qui appartient au domaine technique; une mthode opratoire , appele plus gnralement mthode de conception (et souvent tort mthode de dveloppement car non lie au processus de dveloppement), prcise le "comment faire" le logiciel. Une mthode de conduite de projet dfinit le processus de droulement dun projet cest 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 dfinit l'enchanement chronologique des diffrentes phases dlaboration et dutilisation d'un logiciel, depuis lmergence du besoin (lide) jusquau retrait de service du produit. Cette organisation permet de dcomposer l'objectif global, induit par les besoins du client, en une succession d'objectifs court terme plus facilement matrisables (que l'on peut vrifier et valider). Elle a pour avantages : - de diminuer les risques dinadquation des solutions adoptes dans chacune des phases

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

Page : 7

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL - d'amliorer l'identification des activits mettre en oeuvre - de valoriser l'exprience acquise au cours des projets antrieurs. Le cycle de vie d'un logiciel est dcompos en 3 tapes : - avant projet, correspondant aux tudes de faisabilit (schma directeur) et de dfinition des besoins (spcification) - projet, correspondant au dveloppement du projet proprement dit - utilisation, correspondant l'exploitation et la maintenance du logiciel aprs sa mise en service oprationnelle Chaque tape se dcompose en phases, ventuellement une seule. Chaque phase reprsente un ensemble d' activits (une activit lmentaire est souvent appele tche) cohrentes entre elles et visant un objectif commun (objectif client ou objectif correspondant un tat du produit). Le rsultat d'une activit est un produit (document, code, rsultats de test, ...). En gnral les produits issus de chaque phase font l'objet de vrifications (revue de fin de phase) avant leur adoption. Le cycle de vie du logiciel (dfinition AFNOR Z61-102) reprsente l'ensemble des phases du cycle de dveloppement : - prcd par la phase de SPECIFICATION - suivi de la phase d'EXPLOITATION et de MAINTENANCE Le cycle de dveloppement du logiciel (dfinition AFNOR Z61-102) reprsente l'ensemble des activits mises en oeuvre dans un ordre donn pour effectuer le dveloppement d'un logiciel. Les priodes pendant lesquelles ces activits sont mises en oeuvre sont appeles "phases". Le cycle de dveloppement commence l'issue de la phase de spcification et se compose des phases suivantes : - conception prliminaire - conception dtaille - ralisation (codage et tests unitaires) - intgration - validation ATTENTION : Bien que la phase de spcification ne fasse thoriquement pas partie du cycle de dveloppement, la pratique montre quun fournisseur, charg du dveloppement dun 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 lorganisation du dveloppement. Le cycle de dveloppement correspond une description schmatique et macroscopique de type "boite noire" du processus de dveloppement, prcisant les lments (conditions et fournitures) d'entre et de sortie de chaque phase. Il permet par ailleurs de garantir la transmission exhaustive des informations entre les diffrentes phases (prvention contre les risques de dliquescence : cf 1.3) Cette prvention tant assure par la dfinition de documents et de moyens de contrle (revue de fin phase). Il existe plusieurs modles de reprsentation du cycle de vie ou du cycle de dveloppement du logiciel.

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

Page : 8

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3. Modles et mthodes de dveloppement Un modle de dveloppement fournit une reprsentation schmatique du cycle de dveloppement et en dcrit les principes. Une mthode de dveloppement dcrit de manire dtaille la dmarche de conduite de projet (ou logique de droulement de projet) mise en oeuvre durant le cycle de dveloppement. Elle s'appuie ventuellement sur un modle ou une combinaison de modles. Pour chaque phase, la mthode de dveloppement dfinit en particulier : - Les conditions de dmarrage (dcision, fourniture des informations dentres), - Les informations en entre, - Les travaux (ou activits) raliser, - Les rsultats, - Les conditions dacceptation des rsultats (vrifications et validations effectues). Il existe 2 catgories de modles : - bass sur les dlivrables : on appelle dlivrables les produits rsultats de chaque phase livrs au client aprs vrifications et acceptation par le client, - bass sur les risques : on appelle risque tout ce qui peut mal se passer. Les modles suivants sont analyss de manire dtaille : - de la cascade, - avec prototypage, - incrmental, - par extensions successives, - en V (cycle en V), - en W, - bas sur la programmation exploratoire, - bas sur la transformation formelle, - bas sur la rutilisation, - de la spirale. Les mthodes de dveloppement suivantes sont dcrites de manire synthtique : - MERISE, - MCP, - AFNOR Z67-101, - GAM-T17 V2, - DoD-Std-2167A. Dautres mthodologies de droulement de projet, non dcrites ici, sont prendre en compte : - SMDS (mthode drive de MERISE), - IEEE-1074 (de 91) norme en Ingnierie du logiciel dcrivant les processus et activits du cycle de vie du logiciel.,

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

Page : 9

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL - ISO-12207 (de novembre 95), norme en Ingnierie du logiciel remplaant la norme AFNOR Z67150, dcrivant les processus et activits du cycle de vie du logiciel. Il existe d'autres mthodes, dites propritaires .

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

Page : 10

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.1. Modle de la cascade Gnralits : - modle issu des tudes de ROYCE en 1970 - modle bas sur les dlivrables (fournitures de fin de phase livres au client) - reprsentation classique du cycle de vie du logiciel - modle le plus connu et le plus rpandu (de part son antriorit : constat de la crise du logiciel) - modle qui a donn lieu plusieurs variantes (modle avec prototypage, incrmental, par extensions successives, en V et en W) Principes : - toutes les phases sont excutes sans exception dans l'ordre indiqu - chaque phase se termine par une tche de vrification et validation des rsultats (afin d'liminer les anomalies et les incohrences) - passage la phase suivante si les rsultats sont valids par un jury de revue, diffrent de l'quipe de dveloppement, ventuellement approuvs par le client ce qui a pour effet d'engager sa responsabilit - retour uniquement la phase prcdente : on ne peut changer que les dcisions prises la phase prcdente La revue de fin de phase a pour mission de vrifier la conformit des rsultats de la phase en cours avec ceux des phases prcdentes (traabilit). Elle aboutit 4 niveaux d'acceptation de la part du client : - lacceptation dfinitive ou approbation : accord avec engagement de la responsabilit du client sur le contenu des rsultats et sur leur exploitation - l'acceptation avec rserve : sans engagement de la responsabilit du client; avec ventuellement complment d'tudes ou de justifications (preuves) - l'acceptation avec rfaction, c'est dire avec rduction du prix due au fait que la fourniture ne correspond pas ce qui tait prvu contractuellement - ajournement de la revue (si au moins un des dcideurs est absent ou si les fournitures sont incompltes).

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

Page : 11

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Enchanement des phases :

E tu d e p r a la b le V V = V rific a tio n s d e fin d e p h a s e

Etape avant projet Etape projet

P la n ific a tio n e t S p c ific a tio Vn

C o n c e p tio n P r lim in a ire V

C o n c e p tio n D ta ill e V

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

cycle de dveloppement

V = te s t d 'in t g ra tio n e t d e v a lid a tio n " u s in e " In t g ra tio n V

In s ta lla tio n

R = R c e p tio n a p r s v a lid a tio n " o p ra tio n n e lle " R

Etape d'utilisation

V = R e -V a lid a tio n E x p lo ita tio n e(a t p r s R e -D v e lo p p e m e n t) M a in te n a n c Ve

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

Page : 12

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Description des phases et des rsultats : Phase ETUDE PREALABLE Activits Etude de faisabilit Analyse des besoins Rsultats (essentiellement des documents) Rapport d'tude Schma directeur Grandes lignes des besoins Cahier des charges Plan de dveloppement (rfrentiel dont le planning) Spcification technique des besoins Spcification (ou plan) des tests d'acceptation Manuel utilisateur prliminaire Architecture des modules logiciels Spcification des interfaces Spcification (ou plan) des tests d'intgration Spcification des modules Spcification (ou plan) des tests unitaires Code source des modules Comptes-rendus des tests unitaires Comptes-rendus des tests d'intgration Comptes-rendus des tests de validation Manuel utilisateur final Bordereau de livraison Comptes-rendus des tests de validation Procs verbal d'acceptation par le client Rapports d'anomalies Demandes d'volutions Versions du produit logiciel

PLANIFICATION Organisation et mise en place du et SPECIFICAT projet Dfinition des ION besoins Dfinition de la stratgie de test Dfinition des interfaces utilisateurs CONCEPTION P Conception de RELIMINAIRE l'architecture Dfinition des interfaces Dfinition des tests d'intgration CONCEPTION Analyse dtaille des DETAILLEE modules Dfinition des tests unitaires CODAGE Codage ou programmation Tests unitaires de chaque module INTEGRATION Intgration Tests d'intgration Recette usine (tests de validation chez le fournisseur) INSTALLATION Livraison chez le client Installation et mise en oeuvre Recette (validation oprationnelle) Formation des utilisateurs Corrections des anomalies Amliorations ou volutions Gestion en configuration des livraisons

EXPLOITATION et MAINTENANC E

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

Page : 13

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Inconvnients : I1) trop rigide (difficult d'adaptation) et trop idal : - aspect trs squentiel des phases; manque de paralllisme - les besoins ne sont pas toujours clairement identifis et les spcifications ne sont pas toujours figes ou bien elles sont modifies aprs la phase de spcification I2) ne garantit pas que : - le logiciel livr correspondra bien aux besoins (besoins mal exprims, incomplets,...) - on ne rencontrera pas de difficult de faisabilit (cas de solution thorique non vrifie en pratique) - la maintenance ne sera pas ruineuse (due une mauvaise conception au dpart) Avantages : A1) organisation rigoureuse du dveloppement en phases : les rgles de passage d'une phase l'autre sont clairement dfinies, A2) facile mettre en oeuvre, A3) favorise la matrise du projet (revue de fin de phase). Conditions d'utilisation (critres de slection) C1) pour les petits ou moyens dveloppements C2) lorsque les besoins sont clairement et compltement exprims ds le dbut du dveloppement C3) en cas de risque l'intgration Recommandations (conseils pour la russite du modle) : R1) consacrer des efforts importants aux phases initiales du cycle de vie, car les dfauts cotent d'autant plus cher corriger qu'ils se situent dans les phases amont du cycle c'est dire en spcification et en conception R2) bien organiser et formaliser les revues de fin de phases

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

Page : 14

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.2. Modle avec prototypage Gnralits : - variante du modle de la cascade Objectif : - pallier l'un des inconvnients majeurs du modle de la cascade savoir le risque d'volution des spcifications; donner plus de souplesse au dbut dveloppement Principes : Il existe 2 nuances de prototype (terme employ au sens large) : - modle dvelopp rapidement avec peu de contraintes qualit, qui sacrifie la prcision dans certains domaines pour permettre une vrification rapide des fonctions du produit - forme d'excutable d'un produit o l'accent est mis sur certains aspects du produit et o d'autres sont ignors ou esquisss Le mme terme anglo-saxon englobe les 2 nuances. En franais il existe un terme pour dsigner chaque nuance, respectivement "maquette" et "prototype". Caractristiques d'une "Maquette" : - sert de base pour spcifier le produit final : on peut dvelopper une maquette partir d'une spcification grossire - permet de valider les besoins de l'utilisateur (garantir l'adquation du produit aux utilisateurs); partir d'exprimentation sur la maquette, l'utilisateur affine et amliore la spcification - permet de garantir la faisabilit technique du produit ou dune partie du produit - logiciel produit le plus rapidement possible que l'utilisateur pourra exprimenter afin de dfinir ou d'affiner les besoins du produit (approche semblable celle de la programmation exploratoire) : - logiciel rcrit afin d'en faire un produit de qualit; logiciel non conserv dont on reprend le dveloppement zro; une maquette est "jetable" - fournit la mme apparence que le produit final, sans en avoir l'architecture interne - dveloppe avec des techniques diffrentes de celles utilises pour le produit final - le maquettage soit est utilis en phase de spcification, soit constitue une phase intermdiaire entre les phases de spcification et de conception prliminaire : "prototype"de spcification Exemple : maquettage des IHM (Interfaces Homme-Machine) Attention : des tests de performance sur une maquette n'ont aucun sens; les fonctions tant simules, les contraintes de temps ne peuvent tre valides Caractristiques d'un "Prototype" : - permet de valider des choix de conception (architecture, protocole dinterface, algorithme) - ne comporte que certaines fonctions (oprationnelles) du produit - il peut voluer vers le produit complet par additions successives sans rupture de continuit dans le dveloppement; un prototype est "rcuprable"

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

Page : 15

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL - dvelopp avec les mmes techniques que celles utilises pour le produit final et avec les mmes contraintes qualit - le prototypage soit est utilis en phase de conception (prliminaire ou dtaille), soit constitue une phase intermdiaire entre les phases de conception et de codage : prototype de conception - exemple : prototypage d'algorithme ou darchitecture NB : il existe des prototypes "jetables" utiliss pour la validation purement technique, et non la validation fonctionnelle; exemples : test des performances d'un rseau de communication soit rel soit simul (modle dfini l'aide d'un langage de simulation de type SIMULA ou Modline). Enchanement des phases :
S p c ific a tio n

a ffin a g e s p c ific a tio n M a q u e tta g e

C o n c e p tio n a ffin a g e c o n c e p tio n P ro to ty p a g e ( p a r f o is ; v it e r )

Codage

(s u ite id e n tiq u e )

Techniques dePrototypage : Objectif : dvelopper rapidement un prototype pour des cots minimiss 1) langages de spcification excutables : - non applicable pour le prototypage des IHM - le dveloppement risque de ne pas tre particulirement rapide car la spcification formelle ncessite une analyse dtaille du systme - le systme excutable est en gnral lent et inefficace 2) langages de trs haut niveau, appels tort langage de 5me gnration; ce sont des langages de programmation : Langage LISP PROLOG SmallTalk APL SETL Principe bas sur les listes bas sur la logique (prdicat) bas sur les objets bas sur les vecteurs bas sur les ensembles Type fonctionnel logique orient objet mathmatique ensemble Domaine d'application traitement symbolique traitement symbolique Interface Homme-Machine systme scientifique traitement symbolique Page : 16

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

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL

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

Page : 17

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Inconvnients : I1) surcot priori pour le client, surtout dans le cas d'une maquette "jetable", mais rattrap normalement par la diminution des erreurs de spcification (ou de conception) I2) allongement des dlais d aux aller et retour entre le ralisateur et le client pour affiner les besoins Avantages : A1) offre plus de souplesse; permet de dmarrer un dveloppement sans avoir fig un stade prcoce les spcifications souvent incompltes ou remises en cause A2) constitue un moyen de communication entre le ralisateur et le client; reprsente une approximation de linterprtation que fait le ralisateur A3) facile mettre en oeuvre et modifier; permet une valuation rapide de la conception du produit A4) rduit les risques et donc les cots en diminuant les erreurs, ou mises jour trop frquentes, de spcification et de conception; erreurs qui seraient dceles plus tard dans le dveloppement et dont le cot de correction est d'autant plus important qu'elles se situent dans les phases amont A5) la maquette peut tre utilise 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 prcis qu'aprs dveloppement d'un prototype C2) quand on sait que les spcifications, provenant du ralisateur, vont tre remises en cause C3) quand on veut confirmer par l'exprience des hypothses (IHM, algorithmes,...) C4) quand on veut avoir l'avis du client avant la fin du dveloppement, c'est dire avant la phase de validation Recommandations : R1) expliquer au client les avantages et inconvnients 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 spcialiss (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) intgrer le prototypage comme une composante exprimentale d'une rflexion approfondie

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

Page : 18

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.3. Modle incrmental Gnralits : - variante du modle de la cascade - appel aussi modle dveloppements indpendants (ou parallles) dans GAM-T17 NB : A ne pas confondre avec le vocable anglais Incremental Model qui correspond au modle par extensions successives (cf 2.3.4). Objectif : - pallier le 2me inconvnient majeur du modle de la cascade, savoir le manque de paralllisme Principes : - bas sur une technique du dcoupage du logiciel de faon raliser les composants en parallle plutt qu'en srie Enchanement des phases :
P la n ific a tio n e t S p c ific a tio n

C o n c e p tio n P r lim in a ire

Co m p o sa n t 1 C o n c e p tio n D ta ill e

Co m p o sa n t N C o n c e p tio n D ta ill e Codage

Codage

T e s ts u n ita ire s

T e s ts u n ita ire s

In t g ra tio n (p ro d u it)

V a lid a tio n

L iv ra is o n

E x p lo ita tio n e t m a in te n a n c e

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

Page : 19

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Avantages : A1) permet le paralllisme et donc optimise la dure du dveloppement Inconvnients : I1) risque l'intgration Recommandations : C1) apporter une attention particulire la phase de conception prliminaire C2) bien organiser C3) respecter le plan qualit

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

Page : 20

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.4. Modle par extensions successives Gnralits : - variante du modle de la cascade - modle issu des tudes de WILLIAMS en 1975 puis de MILLS et AL en 1980 Principes : - consiste dcouper le systme en plusieurs sous-ensembles logiques appels extensions (dcoupage non pas en tendue c'est dire par sous-domaine mais en profondeur selon un critre technique) - dveloppement par extensions successives et progressives; les fonctionnalits sont tendues progressivement partir d'une 1re ralisation (noyau regroupant les fonctionnalits minimum) - chaque extension doit sintgrer dans une architecture glob ale du produit et faire l'objet d'une livraison spare Enchanement des phases :
E tu d e p r a la b le

P la n ific a tio n e t S p c ific a tio n

C o n c e p tio n P r lim in a ire

E x te n s io n 1 (n o y a u ) C o n c e p tio n D ta ill e

E x te n s io n N C o n c e p tio n D ta ill e C o d a g e (e t te s ts u n ita ire s )

C o d a g e (e t te s ts u n ita ire s )

In t g ra tio n

In t g ra tio n

In s ta lla tio n

L iv ra is o n 1

In s ta lla tio n

E x p lo ita tio n e t m a in te n a n c e

L iv ra is o n N

E x p lo ita tio n e t m a in te n a n c e

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

Page : 21

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Inconvnients : I1) utilisation limite car il pose des problmes contractuels I2) l'ajout de nouvelles fonctionnalits, ncessitant le dveloppement d'une nouvelle extension, ne doit pas remettre en cause l'architecture globale du produit I3) gestion plus complexe car il faut grer toutes les extensions; une partie du logiciel est en maintenance pendant qu'une autre est en dveloppement; chaque extension peut tre considre comme un projet part entire; plusieurs extensions peuvent tre dveloppes en parallle (avec recouvrement) Avantages : A1) permet de disposer plus tt de versions oprationnelles du logiciel avec des fonctions rduites A2) combine les avantages de la programmation exploratoire et le contrle ncessaire aux dveloppements grande chelle A3) limine le problme des changements incessants de la programmation exploratoire A4) diminue les risques de dpassement de dlai de dveloppement A5) permet d'affiner le besoin (spcification progressive) A6) cot souvent infrieur la dmarche classique car il diminue les demandes d'volution ultrieures; le produit a plus de chance de satisfaire les besoins rels du client A7) capitalise l'exprience de l'quipe de dveloppement car l'exprience 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 Conditions d'utilisation C1) pour des logiciels dvelopps par une quipe rduite sur plusieurs annes, la mme quipe travaillant sur toutes les extensions tales dans le temps C2) quand le client souhaite avoir trs vite un produit minimal, enrichi petit petit, pour pouvoir travailler C3) quand certaines fonctionnalits du produit ne peuvent tre prcises ds le dbut pour certaines raisons, en particulier : l'attente de fournitures externes, la dpendance avec un autre projet Recommandations : R1) ncessite de la rigueur dans la gestion du dveloppement R2) exige un accord avec le client (sinon risque de contentieux) concernant la composition des diffrentes extensions (versions du produit) et les livraisons

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

Page : 22

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.5. Modle en V Gnralits : - issu des tudes de Goldberg en 1986 - modle normalis par l'AFCIQ (Association Franaise pour le Contrle Industriel et la Qualit), l'AFNOR et l'ISO - variante du modle de la cascade Principes : - propose diffrents niveaux associant chaque phase de spcification 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 (dcroissant au fur et mesure) Enchanement des phases :
S p c ific a tio n V a lid a tio n (te s ts d 'a c c e p ta tio n )

n iv e a u 1 (a b s tra it) C o n c e p tio n P r lim in a ire n iv e a u 2 (a rc h ite c tu ra l) C o n c e p tio n D ta ill e n iv e a u 3 (d e s c rip tif) Codage T e s ts U n ita ire s

In t g ra tio 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 s a n t s p a r m e n t)

n iv e a u 4 (p h y s iq u e )

Par exemple, pour le niveau 1 : - l'objectif double est : . spcifier les besoins : analyser les exigences du logiciel dvelopper . planifier la validation : dfinir la stratgie 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 dfaut de spcification gnre un cot de correction lev

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

Page : 23

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Rsultats des phases : documentation technique

CD C ou ST BS et ST I S p c ific a tio n d e s b e s o in s P L STBL MU C o n c e p tio n P r lim in a ire P L D AL MU 2 C o n c e p tio n D ta ill e C L D AD PVL PVQL MU 4 CR T V V a lid a tio n P L CR T I FV MU 3 P IL P G CE In t g ra tio n P L

PM OTV

PM OTI

CR T U L is ta g e c o d e s o u rc e 2

PM OTU

T e s ts U n ita ire s C L

L is ta g e c o d e s o u rc e Codage CL

CDC = Cahier Des Charges du client dont le CDCF (CDC Fonctionnel) STBS = Spcification Technique de Besoin du Systme STI = Spcification Technique des Interfaces STBL = Spcification Technique de Besoin du Logiciel (Produit Logiciel) MU = Manuel Utilisateur (rsultant ventuellement d'une activit de maquettage des IHM) PVL = Plan de Validation du Logiciel (stratgies, responsabilits, moyens, types de test et types de preuves) DAL = Document d'Architecture du Logiciel PIL = Plan d'Intgration du Logiciel PMOTV = Procdures de Mise en Oeuvre des Tests de Validation (conditions, objectifs, jeux d'essais, rsultats attendus) DAD = Document d'Analyse Dtaille PMOTI = Procdures de Mise en Oeuvre des Tests d'Intgration PMOTU = Procdures de Mise en Oeuvre des Tests Unitaires CRTU = Comptes-Rendus des Tests Unitaires CRTI = Comptes-Rendus des Tests d'Intgration PGCE = Procdures de Gnration du Code Excutable FV = Fiche de Version (identification et description du logiciel) CRTV = Comptes-Rendus des Tests de Validation PVQL = Procs Verbal de Qualification du Logiciel (acceptation client)

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

Page : 24

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Cycle de vie du logiciel dans le cycle de vie du systme :
E tu d e d e fa i s a b i l i t d u s y s t m e Dv eloppem ent d u s y s t m e s p c i fi c a ti o n d u s y s t m e

c o n c e p ti o n d u s y s t m e

dv eloppem ent d u m a t r i e l

dv eloppem ent du logiciel

i n t g r a ti o n d u s y s t m e

v a l i d a ti o n d u s y s t m e

E x p l o i ta ti o n e t m a i n te n a n c e d u s y s t m e

Inconvnients : I1) l'utilisateur, ou client intervenant uniquement au niveau 1, doit attendre les tests de validation (appels aussi tests d'acceptation ou de qualification) pour s'assurer que ses exigences ou besoins ont t pris en compte de manire satisfaisante Avantages : A1) modle normalis A2) montre l'interaction non seulement entre les phases successives mais aussi entre les phases de mme niveau A3) le cycle de vie du logiciel est intgr dans le cycle de vie du systme

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

Page : 25

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.6. Modle en W Gnralits : - bas sur le modle en V Objectif : - pallier l'inconvnient majeur du modle 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 dfinition des interfaces externes (cf 2.3.2 : modle avec prototypage) - l'utilisateur peut s'appuyer sur des maquettes d'crans pour juger, ds le stade de la conception, les interfaces utilisateur du futur produit logiciel Enchanement des phases :
S p c ific a tio n d e s b e s o in s S p c ific a tio n d e s in te rfa c e s V a lid a tio n

C o n c e p tio n d ta ill e d u s y s t m e C o n c e p tio n P r lim in a ire 1 C o n c e p tio n g n ra le d u s y s t m e C o n c e p tio n P r lim in a ire 2 In t g ra tio n

C o n c e p tio n D ta ill e C o n c e p tio n d ta ill e d u c o m p o s a n t

T e s ts U n ita ire s

Codage

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

Page : 26

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.7. Modle bas sur la Programmation exploratoire Gnralits : - quivalent la 1re phase du modle avec prototypage - modle non bas sur les spcifications Principe : - dvelopper une 1re implmentation aussi vite que possible - la montrer aux utilisateurs pour commentaires - la modifier en plusieurs itrations jusqu' obtenir un logiciel adquat, c'est dire convenant aux utilisateurs (VALIDATION), plutt qu'un logiciel correct c'est dire conforme un cahier des charges ou une spcification (VERIFICATION)
d fi n i r l e s g r a n d e s lignes des bes oins

c o n s tr u i r e u n s y s t m e lo g icie l m o d i fi e r l e s y s t m e lo g icie l

u ti l i s e r l e s y s t m e lo g icie l

N ON

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

OU I

L i v r e r l e s y s t m e o p r a ti o n n e l

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

Page : 27

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Inconvnients : I1) il n'est pas adapt au dveloppement de la plupart des gros logiciel appels durer longtemps; risque de cot de maintenance lev car la structure du logiciel change souvent I2) documentation trs coteuse du fait que le logiciel change souvent; il n'est pas adapt une approche base sur les documents ce qui a pour consquence de diminuer la visibilit et donc de rendre plus difficile la matrise du projet I3) la vrification est impossible car il n'existe pas de spcification; la notion de logiciel incorrect n'a pas de sens Avantages : A1) permet de dmarrer le dveloppement lorsque les besoins ne sont pas encore formuls de manire suffisamment dtaille A2) sans contrainte de qualit forte (formalisme de la documentation, ...) Conditions d'utilisation C1) ne pas utiliser pour dvelopper des gros systmes logiciel dont la dure de vie est importante C2) bien adapt au dveloppement de systme en IA Recommandations : R1) utiliser des techniques qui permettent des itrations rapides (par exemple des langages de haut niveau tels que LISPS, PROLOG) R2) utiliser par de petites quipes de personnes ultra-comptentes et ultra-motives

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

Page : 28

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.8. Modle bas sur la transformation formelle Objectifs : - dfinir rigoureusement ce que le logiciel doit faire - dtecter les dfauts des spcifications informelles et affiner celles-ci Principe : - partir des spcifications informelles issues de l'itration des phases de Spcification et de Conception Prliminaire (spcification des lments logiciel), crire la spcification formelle dans un langage prcis tant sur le plan syntaxique que smantique - transformer la spcification formelle en programme l'aide de rgles Mthodes et techniques de ralisation : - spcification algbrique dcrivant : . des "sortes" d'objets . des oprations sur ces "sortes" d'objets . une liste de proprits (axiomes) vrifiant ces proprits - langages excutables de spcification - langages de manipulation d'objets : . PLUSS du LRI d'Orsay . LARCH du MIT et de DEC Avantages : A1) modle adapt une approche base sur les documents A2) le formalisme permet de s'assurer de la compltude et de la cohrence des spcifications A3) permet d'obtenir facilement des maquettes A4) permet de faire des preuves; les spcifications formelles se traduisent en pr et post-conditions utilises dans les preuves A5) permet de guider la conception des tests (scnarios) Inconvnients : I1) mauvaise visibilit du processus de conduite de projet car dmarche peu comprhensible par des non techniciens I2) ncessite une solide formation I3) ncessite des outils car devient trs vite complexe pour tre ralis manuellement Conditions d'utilisation C1) adapt au dveloppement de logiciel haut risque de sret de fonctionnement, terme recouvrant la fois la scurit, la disponibilit, la fiabilit et la maintenabilit Recommandations : R1) attendre l'apparition d'outils mrs R2) utiliser pour des petits et moyens projets EPITA : Cours de Conduite de Projet Logiciel (C. CHEVALLIER) Page : 29

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.9. Modle bas sur l'assemblage de composants rutilisables Gnralits : - la rutilisation est un sujet qui devient de plus en plus important dans la conception prliminaire de systme, mais la rutilisation systmatique est peu rpandue - le processus de dveloppement relve plus de l'assemblage que de la cration Il existe 4 types de composants rutilisables : a) les applications compltes b) les sous-systmes d'une application c) les modules ou les objets (ensemble de fonctions, package ADA,...) d) les fonctions (ensembles de composants logiciel implmentant une seule fonction) Les types a) et b) sont peu utiliss; les types c) et d) sont moins utiliss or ils sont plus concerns par le problme de rutilisabilit. Il existe 2 types de rutilisabilit : - oriente COMPOSANT (rutilisation directe) - oriente GENERATION (rutilisation aprs gnration) Principe : Modle de dveloppement bas sur la conception pour dterminer les composants rutiliser . Il comprend 4 tapes successives : 1) concevoir l'architecture du systme 2) spcifier les composants 3) chercher des composants rutilisables 4) incorporer les composants trouvs Il existe une variante qui est le modle de dveloppement bas sur la rutilisation o les besoins sont modifis en fonction des composants disponibles; la conception est alors base sur les composants rutilisables ; elle comprend 6 tapes successives : 1) dfinir les grandes lignes des besoins du systme 2) chercher les composants rutilisables 3) modifier les besoins en fonction des composants trouvs 4) dfinir les grandes lignes de l'architecture du systme 5) chercher les composants rutilisables 6) spcifier les composants du systme en se basant sur les composants rutilisables

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

Page : 30

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Avantages : A1) rduit le cot de production et de maintenance A2) rduit le temps de dveloppement et de validation A3) amliore la productivit A4) augmente la fiabilit; les composants rutiliss ont dj t tests en situation oprationnelle A5) rduit les risques d'erreur dans l'valuation; le cot de rutilisation est en gnral plus facile estimer que le cot de dveloppement A6) permet d'utiliser efficacement des spcialistes (encapsulation de leur connaissance) A7) permet d'implmenter des standards Inconvnients : I1) modle non encore viable cause du manque de bibliothques de composants rutilisables dans certains domaines informatiques (temps rel, commande-contrle,...) I2) ncessite un effort supplmentaire de dveloppement pour rendre des composants rutilisables; isoler les parties du programme qui dpendent de l'environnement l'intrieur d'une interface de portabilit (API : Application Programing Interface) I3) ncessite que les composants rutilisables soient comprhensibles avec des informations sur la manire de les rutiliser Conditions d'utilisation C1) suppose que le systme soit compos d'lments dj existants Recommandations : R1) utiliser les types abstraits de donnes et les objets qui sont particulirement adapts l'encapsulation des composants rutilisables R2) utiliser la technique d'hritage qui permet de rutiliser tout en adaptant R3) utiliser au mieux des standards (langage, O.S., rseau, graphique,...) diminuant les problmes de portage (forme de rutilisation)

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

Page : 31

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.10. Modle de la spirale Gnralits : - cre par Boehm en 1988 - modle bas sur les risques et non sur les dlivrables : valuation des risques de gestion tapes rgulires pendant le droulement du projet et sur le dclenchement d'actions pour contrer les risques - reprise de l'ide d'extensions successives : approche itrative du processus de dveloppement du logiciel reprsente par les boucles successives de la spirale Objectif : - modle qui puisse supplanter tous les autres modles gnriques, dfinis prcdemment, et qui satisfasse les besoins des fournisseurs de logiciel. Principes : La 1re boucle de la spirale commence par la revue de dmarrage du projet. A chaque cycle (ou boucle) de la spirale : - au dbut : analyse des risques (tout ce qui peut mal se passer), dfinition des actions permettant de les rduire voire de les rsoudre - puis prototypage (au sens large) suivi d'une simulation servant d'entre aux spcifications - la fin : procdure de revue ou d'acceptation permettant le passage au cycle suivant Le dernier cycle reprsente la fin du cycle en V ( partir de la conception dtaille). Chaque quartier de la spirale possde les objectifs suivants : - 1er quartier (en haut droite puis sens des aiguilles d'une montre) : valuer les alternatives; identifier et rsoudre les risques : ----> choix du modle de dveloppement appropri (par exemple : prototypage si risque d'volution de l'IHM, transformation formelle si risque concernant la sret de fonctionnement, modle de la cascade si risque l'intgration) - 2me quartier : dvelopper et vrifier le produit (prototype) - 3me quartier : planifier les phases du cycle suivant - 4me quartier : dterminer, lors de la revue de fin de cycle, les objectifs (exprims en terme de fonctionnalits et de performances), les alternatives et leurs contraintes pour y parvenir

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

Page : 32

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Diagramme denchanement des phases :

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

Page : 33

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Inconvnients : I1) il oblige considrer toutes les alternatives et tous les risques Avantages : A1) il peut incorporer tous les autres modles de dveloppement : en effet, il n'est pas ncessaire d'adopter un seul modle chaque cycle de la spirale. Exemple 1 : modle avec prototypage dans un cycle pour rsoudre le problme de la spcification de besoin, puis modle conventionnelle de la cascade en cas de risque d'intgration Exemple 2 : modle de transformation formelle dans un cycle pour rsoudre le problme de la sret de fonctionnement, puis modle bas sur la rutilisation pour l'IHM.

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

Page : 34

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.11. Mthode MERISE Gnralits : - issue des tudes de TARDIEU, ROCHFELD et COLLETTI en 1983 - mthode de conception possdant une composante de conduite de projet non ngligeable NB : initialement mthode de conception (dfinissant le COMMENT FAIRE) mise au point sur la demande d'un ministre franais la fin des annes 70 pour tirer le meilleur parti des nouvelles techniques informatiques, en particulier celles concernant les bases de donnes Principes : La dmarche est compose de 8 tapes : 1) le schma directeur : tape de rflexion globale et de planification gnrale (dmarche inspire de la mthode RACINE) 2) l'tude pralable : rflexion sur une grande fonction de l'entreprise dont on a dcid l'informatisation; exploration de diffrentes solutions (prconisation de maquette voire de prototype) 3) l'tude dtaille : tude fonctionnelle exhaustive de la solution retenue 4) l'tude technique : fournir l'architecture du systme et les spcifications internes 5) la production du logiciel : laboration des diffrents programmes et transactions 6) la mise en oeuvre : mise disposition du systme aux utilisateurs 7) la gnralisation : mettre le systme disposition de tous les utilisateurs en intgrant les contextes organisationnel et matriel propres chaque site d'exploitation 8) la maintenance et l'volution : - la maintenance consiste maintenir le systme en tat de marche fonctionnalits constantes - l'volution consiste maintenir le systme en tat de marche fonctionnalits croissantes Les tapes, squentielles pour les 1res, peuvent tre paralllises partir de l'tude dtaille. L'tape de "maintenance-volution" droule un cycle de vie complet pouvant comprendre la conception, la ralisation et la mise en oeuvre d'une nouvelle version. Une variante intgrant le maquettage-prototypage t cre par TARDIEU en 1988 . L'tude pralable est de plus en plus valide par la production de maquette ou de prototype, ceci dans le but de faciliter la vente du systme propos. En tudes dtailles (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 spcifications du systme. Une simulation des rsultats obtenus est alors effectue; elle peut dans certains cas remettre en cause des options retenues.

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

Page : 35

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Maquettage et prototypage dans la dmarche MERISE

m a q u e tte
v e n te d u s y s t m e

E tu d e p r a l a b l e p r o to ty p e v a l i d a ti o n s p a r l e s m a q u e tte s u ti l i s a te u r s

E tu d e s d ta i l l e s

S i m u l a ti o n s

E tu d e s te c h n i q u e s

v a l i d a ti o n s p a r l e s p r o to ty p e s u ti l i s a te u r s v a l i d a ti o n s te c h n i q u e s In t g r a ti o n s

R a l i s a ti o n s e t te s ts

Avantages : I1) mthode devenue un standard de fait dans certains milieux, en particulier les administrations civiles, et dans certains domaines, en particulier la gestion Inconvnients : I1) mthode spcifique, non normalise

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

Page : 36

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.12. Mthode MCP Gnralits : - Mthode de Conduite de Projet informatique cre par GEDIN en 1975 - modifie en 1986; modifications s'inspirant de la mthode MERISE Principes : La dmarche se compose de 4 divisions ou phases et chaque phase est dcoupe en tapes : 1) la conception, comprenant 4 tapes - l'expression du besoin d'automatisation - l'tude d'opportunit - l'tude du systme d'information futur - l'laboration du cahier des charges 2) la ralisation, comprenant 2 tapes : - l'tude du systme informatique - la programmation et les essais 3) la mise en oeuvre, comprenant 2 tapes : - la rception provisoire par l'utilisateur - le lancement du systme sous contrle 4) l'exploitation, comprenant 2 tapes : - l'valuation de l'application - l'valuation du projet Inconvnients : I1) mthode spcifique, non normalise

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

Page : 37

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.13. Mthode AFNOR Gnralits : - mthode de conduite de projet normalise : normes AFNOR Z67-101 de 1984 dfinissant des recommandation de conduite de projets informatiques - au confluent des mthodes MERISE et MCP - mthode base sur les documents Principes : Cette mthode propose un dcoupage projet travers une srie de documents jalonnant une application informatique ainsi que les grandes tapes qui en dcoulent. Elle est compose de 5 phases comprenant des tapes : 1) l'tude pralable : - l'exploration - la conception d'ensemble (architecture) - l'apprciation de la solution retenue 2) la conception dtaille : - la conception du systme de traitement de l'information - la spcification fonctionnelle du systme informatique - l'tude organique gnrale 3) la ralisation : - l'tude organique dtaille - la programmation et les tests - la validation technique 4) la mise en oeuvre : - la rception provisoire de la ralisation - l'exploitation sous contrle 5) l'valuation : - l'valuation du systme informatique - l'valuation du systme de traitement de l'information A ces recommandations vient s'ajouter un processus gnral d'assurance et de contrle qualit (recommandations de plan logiciel : norme AFNOR Z67-130 de 1987). Avantages : A1) mthode normalise Conditions d'utilisation C1) conseille dans le domaine civil, en particulier dans les domaines de la gestion et des services en gnral

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

Page : 38

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.14. Mthode GAM-T17 (V2) Gnralits : - guide mthodologique de dveloppement de logiciel embarqu pour des systmes militaires franais - mthode cre ( version 2 en 1989) par la DGA (Direction Gnrale de l'Armement) : mthode standard de la dfense franaise - base sur le modle en V (ou cycle en V) normalis par l'AFCIQ (Association Franaise pour le Contrle Industriel et la Qualit) - la dcomposition des activits dans les phases de dveloppement est base sur une approche fonctionnelle de dcomposition du produit Principes : - le cycle de dveloppement du logiciel est intgr dans le cycle de vie du systme : le logiciel est intgr dans l'architecture du systme - il existe, en fonction de la complexit du logiciel, 3 processus de dveloppement : . un processus gnral . un processus rduit (processus gnral allg de contrles qualit) . un processus dveloppements indpendants : le logiciel est dcompos en lments traits, selon le processus gnral, indpendamment les uns des autres (cf 2.3.3 : modle incrmental)

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

Page : 39

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL

D c omposition d'un syst me

s y s t m e

s o u s -s y s t m e

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

q u ip e m e n t

m a t rie l

lo g ic ie l

(P ro d u it L o g ic ie l)

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

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

C o m p o s a n t L o g ic ie l

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

Page : 40

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Architecture logicielle : - Produit logiciel (PL) : fourniture spcifiable, recettable et livrable - Elment logiciel (EL) : constituant du produit caractris par son unit fonctionnelle dont la ralisation est confie un responsable unique; c'est l'unit de documentation d'exploitation et de maintenance. Il s'agit donc galement d'une fourniture spcifiable, recettable et livrable. - Composant logiciel (CL) : constituant du produit logiciel ou d'un lment logiciel rpute indivisible lors de la ralisation et transcriptible directement dans un langage de programmation. Il ne fait pas l'objet d'une spcification ni d'une conception prliminaire mais uniquement d'une conception dtaille. Processus gnral :
RQL responsable systme
S p c ific a tio n d e s b e s o in s P L

(PL)

V a lid a tio n P L

RSL responsable logiciel

C o n c e p tio n P r lim in a ire P L

(PL) ralisateurs

In t g ra tio n P L

RCP
C o n c e p tio n D ta ill e C L

(CL)

T e s ts U n ita ire s C L

RCD
Codage CL

Revues : elles doivent tre planifies et leur cot prvu - RSL = Revue de Spcification du Logiciel (produit logiciel) - RCP = Revue de Conception Prliminaire du logiciel - RCD = Revue de Conception Dtaille du produit logiciel - RQL = Revue de Qualification du Logiciel (revue d'acceptation client)

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

Page : 41

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Processus dveloppements indpendants :

RQL S p c ific a tio n d e s b e s o in s P L RSL In t g ra tio n P L C o n c e p tio n P r lim in a ire P L - a rc h ite c tu re P L - s p c ific a tio n l m e n ts E L i R CP V a lid a tio n E L i RQE V a lid a tio n P L

processus gnral lment i

C o n c e p tio n P r lim in a ire E L i R CPE

In t g ra tio n E L i

C o n c e p tio n D ta ill e C L R CD E

T e s ts U n ita ire s C L

Codage CL

Revues concernant chaque lment ELi : - RCPE = Revue de Conception Prliminaire de l'lment logiciel i - RCDE = Revue de Conception Dtaille de l'lment logiciel i - RQE = Revue de Qualification de l'lment logiciel i (revue d'acceptation du responsable logiciel)

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

Page : 42

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL La documentation du produit logiciel est organise en dossiers : * Dossier de Dfinition (DD) : - STB = Spcification Technique de Besoin des constituants du logiciel (lments logiciel) - DAL = Document d'Architecture du Logiciel - DAD = Document d'Analyse Dtaille - Listing du code source - PGCE = Procdures de Gnration du Code Excutable - FV = Fiche de Version (identification et description du logiciel) * Dossier de Justification de Dfinition (DJD) : - justification de l'architecture du logiciel - justification d'algorithmes (de niveau conception dtaille) - PVL = Plan de Validation du Logiciel NB : distinguer la validation "usine" (de responsabilit fournisseur ) de la validation "oprationnelle" (de responsabilit client) faisant parfois l'objet d'un plan distinct "plan de rception" dfinissant les tests de qualification - PIL = Plan d'Intgration du Logiciel - PMOTV = Procdures de Mise en Oeuvre des Tests de Validation - PMOTI = Procdures de Mise en Oeuvre des Tests d'Intgration - PMOTU = Procdures de Mise en Oeuvre des Tests Unitaires - CRTU = Comptes-Rendus des Tests Unitaires - CRTI = Comptes-Rendus des Tests d'Intgration - CRTV = Comptes-Rendus des Tests de Validation - PVQL = Procs Verbal de Qualification du Logiciel - comptes-rendus de revues

appel

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

Page : 43

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL Inconvnients : I1) mthode trs contraignante au niveau de la qualit (dossiers, documents, revues) I2) mthode franaise non reconnue pour des projets internationaux I3) mthode spcifique au dveloppement de logiciel Avantages : A1) mthode s'appuyant sur le modle en V normalis A2) le logiciel dvelopper est intgr dans l'architecture systme A3) elle dfinit de faon dtaille les actions qualit (contrles de fin de phase), A4) elle prvoit l'allgement 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 ncessaires, A5) le "processus dveloppement indpendant" permet de matriser des dveloppements soustraits, A6) elle reste ouverte toutes les mthodes de conception et de ralisation, A7) mthode franaise bien perue par les organismes nationaux (armes, administrations) A8) bien qu'labore par la DGA (Direction Gnrale de l'Armement), elle peut tre facilement gnralise et ne prsente que trs peu de spcificits lies au domaine militaire. Conditions d'utilisation C1) bien adapte au dveloppement de gros projets logiciel soumis de fortes contraintes qualit Recommandations : R1) recommande, voire exige, pour des projets tatiques, militaires ou non

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

Page : 44

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.15. Mthode DoD-Std-2167A Gnralits : Cette mthode est dcrite par comparaison la mthode GAM-T17 V2. - standard de la dfense US (de fvrier 88) Principes : - mme logique de dveloppement d'un systme pour aboutir une architecture matrielle et logicielle : . dcoupage 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 DoD2167 Inconvnients : I1) elle ne possde pas de mthode de dveloppement de type "processus dveloppements indpendants" I2) mthode Amricaine mal perue par certains organismes Franais I3) elle est moins prcise que GAM-T17 en ce qui concerne les actions qualit (contrles de fin de phase) Avantages : A1) elle est moins contraignante que GAMT-17 sur l'aspect logiciel A2) adapt au dveloppement de systme matriel et logiciel Conditions d'utilisation C1) bien adapte au dveloppement de gros projets systmes, matriel et logiciel Recommandations : R1) recommande, voire exige, pour des projets internationaux, europens en particulier

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

Page : 45

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL 2.3.16. Synthse S1) Concernant les modles bass sur les dlivrables : - ils permettent un meilleur suivi d'avancement : organisation en phases et activits; phase termine si les produits rsultats sont accepts ou approuvs (avec engagement de sa responsabilit) par le client, - ils offrent une meilleure visibilit au client (documents d'tudes, comptes-rendus de test, revues,...), - le modle de la cascade n'est pas le plus adquat mais il continuera tre utilis car il simplifie grandement la gestion du processus de dveloppement; en effet beaucoup d'organismes gouvernementaux et de fournisseurs de gros logiciels ont adopt comme standard gnral le modle de la cascade - ils ont naturellement tendance limiter le nombre d'itrations "spcification-conception" chaque niveau de dcomposition, car les documents sont gels (grs en versions aprs livraison) et deviennent coteux modifier; cela peut entraner, lorsqu'un problme est rencontr, le choix d'une solution peu lgante pour viter le cot d'une itration et pour ne pas modifier un document final, - du fait que les gestionnaires ont besoin de documents fournis intervalles rguliers de manire valuer l'tat d'avancement du projet, si le calendrier de gestion est diffrent du calendrier rel li au dveloppement cela risque de gnrer des documents artificiels qui augmenteraient le cot du projet, - le fait qu'un document issu d'une phase soit utilis en entre de la phase suivante est biais car cela sous-entend que le processus de dveloppement est linaire or, n'importe quel phase du processus, les dveloppeurs prennent en compte les tapes prcdentes comme les tapes suivantes (par exemple, il n'y a aucun intrt crer une conception qui sera difficile implmenter mme si elle correspond aux besoins); ----> dans la ralit 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 ralit les phases se recouvrent (on ignore les procdures formelles et on dmarre une phase avant que les documents de la phase prcdente aient t achevs), - on ne peut rsoudre tous les problmes en crant une spcification dtaille puis une conception puis une implmentation; ----> en appliquant aveuglment le modle de la cascade bas sur les documents on a rendu un certain nombre de projets trs coteux.

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

Page : 46

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL S2) Adquation des modles vis vis des documents : Modle cascade prototypage programmation exploratoire transformation formelle cycle en V orient rutilisation Adquation de la documentation bien adapt , conu autour des documents prolifique en phase d'initialisation et d'itrations rapides mal adapt ; les itrations sont si rapides que la gnration de document revient cher. bien adapt ; les documents formels sont essentiels. bien adapt , conu autour des documents mal adapt ; les documents dcrivant le systme risquent de limiter la rutilisation.

S3) la meilleure alternative, actuellement, est le modle de la spirale bas sur le risque car il permet d'adapter le processus de dveloppement en fonction du domaine d'application et de l'tat d'avancement du dveloppement (un modle diffrent chaque boucle). S4) Utilisation des mthodes de dveloppement 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 dfense, de l'arospatiale et de l'industrie : GAM-T17 V2 pour les projets Franais et DoD-std-2167A pour les projets Europens.

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

Page : 47

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL CONCLUSION : Les cadres mthodologiques constituent des cadres gnraux de conduite de projet. Ils dfinissent : - le dcoupage des travaux en phases/tapes/activits/tches, - les rles des principaux acteurs - les formalisations de reprsentation (plan type des documents) Caractristiques d'un cadre mthodologie : - ce n'est pas un recueil plus ou moins ordonn de mthodes particulires ddies l'ingnierie du logiciel - diffre des mthodes qui guident la rsolution de problmes ponctuels - indique CE QU'IL FAUT FAIRE (ou QUOI FAIRE) de faon plus ou moins exhaustive, mais PAS, ou peu, COMMENT Y PARVENIR Une mthode est construite selon une dmarche la fois rationnelle et empirique, dductive et inductive. Elle ne peut servir des buts fondamentalement divergents. Elle dfinit un ensemble de procds visant un objectif unique dans un domaine ddi. Une mthode de conduite de projet propose travers des techniques, et ventuellement des outils, de s'intresser aux procdures de gestion d'un projet au fur et mesure de son cycle de vie. Une mthode de conduite de projet indique non seulement CE QU'IL FAUT FAIRE mais dfinit le COMMENT GERER le COMMENT FAIRE, c'est le cas pour : - MERISE (mme si parfois assimile un cadre mthodologique; considre comme un standard) - MCP (de RATP et GFI) - SDM/S (de CEGELOG) - MEDIA (de SOPRA) - Method ONE (d'Arthur Andersen) - AXIAL (d'IBM) Sont considrs comme cadres mthodologiques, indpendants des mthodes et outils de dveloppement : - normaliss ou standards : . AFNOR Z67-101 . GAM-T17 V2 . DoD-std-2167A - propritaires : - 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 prmunir contre les dbordements d'un processus de crativit sans fin. EPITA : Cours de Conduite de Projet Logiciel (C. CHEVALLIER) Page : 48

LOGIQUE DE DEROULEMENT DE PROJET LOGICIEL

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

Page : 49