Organisation et gestion d un projet logiciel

Transcription

1 Organisation et gestion d un projet logiciel Master CCI Génie Logiciel - ORGANISATION DE PROJET - P.Y. CUNIN, I. PARISSIS

2 Activités s de gestion Les acteurs Quels sont les rôles? Quelles sont les responsabilités s? Estimation Combien de temps va durer le projet? Quel effort sera nécessaire n (budget)? Répartition de la durée e et de l effort l le long du cycle de vie? Planification Quelles sont les tâches nécessaires? n Combien de temps durera chaque tâche? Quel effort sera consacré à chaque tâche? Quelles ressources? Qui fait quoi et quand? Suivi Le planning est-il bien respecté? 2

3 Acteurs d un d projet Master CCI Génie Logiciel - ORGANISATION DE PROJET - P.Y. CUNIN, I. PARISSIS

4 Un objectif Qu est est-ce qu un un «projet»? Défini en termes de fournitures Un délaid Des moyens Projet vs Activité 4

5 Acteurs principaux d un d projet Maîtrise d ouvrage d (MOA) Maîtrise d ouvrage d délégud guée e (MOAd( MOAd) Maîtrise d œd œuvre (MOE) Maîtrise d œd œuvre délégud guée e (MOEd( MOEd) 5

6 MOA (maîtrise d'ouvrage), MOAd (... délégud guée) MOA = Entreprise ou service «client» La société X décide d de faire développer d un logiciel de gestion des congés s de son personnel. MOAD = Personne ayant en charge le suivi du projet pour le compte e du client (par exemple un responsable produit) La société X décide d de faire développer d un logiciel de gestion des congés s de son personnel. Madame A. YYY. est chargée e de cette opération ration. 6

7 MOE (maîtrise d'œuvre), MOEd (chef de projet) MOE = Entreprise ou service ayant pris l engagement l de réaliser r le projet pour le MOA La société X décide d de faire développer d un logiciel de gestion des congés s de son personnel. Madame A. YYY est chargée e de cette opération.elle lance un appel d offres. d Elle sélectionne la société de services ABLogiciels. MOEd = Personne chargé par le MOE pour mener le projet Liaison client (MOA délégud gué) Evaluation ressources Gestion projet (éventuellement( assisté par un contrôleur) Décision de passage d une d étape du CV à une autre ABLogiciels nomme Monsieur Z chef de projet. 7

8 Canaux de communication MOA Maître d ouvrage MOE Maître d œuvre MOAd Maître d ouvrage délégué MOEd Maître d œuvre délégué (chef de projet) Utilisateurs Equipe projet 8

9 Schéma récursif (sous-traitance MOA Maître d ouvrage MOA MOE Maître d ouvrage d oeuvre MOE Maître d oeuvre MOAd Maître d ouvrage délégué MOAd MOEd Maître Maître d œuvre d ouvrage délégué (chef délégué de projet) MOEd Maître d œuvre délégué (chef de projet) 9

10 MOAd vs. MOEd Rôles complémentaires mentaires mais opposés MOAd Le meilleur produit au meilleur prix (pour le client) MOEd Le meilleur produit en respectant le budget et les engagements de délaid Cause fréquente d éd échec d un d projet: MOAd = MOEd 10

11 Equipes Equipe qualification validation Equipe projet Chef de projet Experts du domaine technique du projet Analystes Architectes Développeurs Intégrateurs Testeurs Développe les plans de test d intd intégration, système, acceptation (avec chef de projet et client) Equipe qualité Généralement affectée à plusieurs projets Aide à la mise en œuvre de l Assurance l Qualité Organise le Contrôle de la qualité Avertit le Chef de projet en cas de problème constaté Très s souvent réduite r à un "responsable qualité" 11

12 Estimation Master CCI Génie Logiciel - ORGANISATION DE PROJET - P.Y. CUNIN, I. PARISSIS

13 Pourquoi mesurer et estimer? Pourquoi les voitures ont des compteurs de vitesse? Pourquoi se pèsep se-t-on? Combien de personnes font construire une maison sans avoir une idée i e de la taille de la maison? Comment un constructeur communique-t-il il à propos d'une maison et de son coût t de construction? Cela est nécessaire n pour prévoir, contrôler et piloter 13

14 Portée e de la métrologiem Evaluer la charge à consacrer au développement d logiciel Seulement une partie du "coût" total du logiciel (hors vente, commercialisation, maintenance, formation,...) Par la même occasion, évaluer la productivité du développementd Attention à ne pas provoquer un rejet Une pratique pragmatique, basée e sur l'expérience Mais aussi, un besoin de rationalité et de méthodes m afin de ne pas dépendre uniquement de l'expérience 14

15 Quelques considérations préliminaires Tout n'est pas "objectif". Il y a des composantes organisationnelles, financières, stratégiques,... La loi de Parkinson "Le travail s'étend jusqu'à remplir tout le temps alloué à son exécution cution" La loi de Brooks "Ajouter du personnel à un projet en retard ne fait que le retarder" Les aspects mercantiles sont souvent prépond pondérants "Quel prix le client est-il prêt à payer?" Une synthèse se de l'ensemble adapté à chaque projet 15

16 Historique de la mesure : 1 ère vague 16

17 Historique de la mesure : 2ème 2 vague 17

18 Estimation toujours approximative Estimation Basée e sur Expérience du chef de projet Modèles d estimationd Elaborés à partir de la collecte de données issues de plusieurs projets Classification Modèles statiques à une variable à plusieurs variables Modèles dynamiques 18

19 Modèles statiques à une variable Modèles d estimationd Ressource = f(variable) Ressource : effort, durée, taille équipe, doc variable : LOC («( lines of code»), effort, Exemple : étude de Walston & Felix (1977) 60 projets de 4000 à LOC, 12 à hm E = 5,2 x L 0.91 (E : hm, L : KLOC) D = 4,1 x L 0.36 (D : mois) D = 2,47 x E 0.35 DOC = 49 x L 1.01 (DOC : pages de doc) (source : Software Engineering, R. Pressman) Modèles statiques à plusieurs variables Calcul d une d ressource en fonction de plusieurs caractéristiques ristiques Dynamiques L estimation de la ressource dépend d du temps 19

20 Modèles connus Function point Putnam COCOMO 20

21 Function Point (FP)( Norme de fait dans l'informatique de gestion Méthode prédictive, avant le développement d et indépendante de la technologie Elle repose sur la décomposition d technique initiale des fonctionnalités s du projet Se concentre sur les fonctionnalités s dont il faut établir la liste, leur complexité et leur nombre 5 caractéristiques ristiques prises en compte 1. les entrées es (ex. les formulaires de saisie remplis par l'utilisateur) 2. les sorties (ex. les vues et les états fournis par l'application à l'utilisateur) les interrogations (ex. requêtes,,consultation menu, consultation aide, a...) 3. les 4. les groupes de données internes (ex. entités s dans une base de données) 5. les interfaces externes (ex. les fichiers externes partagés) 21

22 Function Point (FP)( : La méthodem Pour chaque fonction, déterminer d le nombre de composantes et la complexité de chacune Exemple : Pour le groupe de données internes on utilise le modèle conceptuel de données et on comptabilise les tables et les relations Soit une table 1 associée à deux autres par une relation "1 to many". La table 1 a 25 champs, la table 2 a 6 champs et la table 3 a 4 champs. On a 3 composantes. c < 20 éléments 1 relation Basse 2 à 5 relations Basse 6 relations et plus Moyenne éléments Basse Moyenne Haute > 50 éléments Moyenne Haute Haute Composantes Complexité basse Complexité moyenne Complexité haute internes externes entrées es sorties interrogations Table 1 est de complexité moyenne. Table 2 et 3 sont de complexité faible On pondère chaque entité/composante au moyen de la table des points et on somme pour obtenir le nombre des points de fonction bruts PFB Dans l'exemple : les entités s internes donnent un total de 24 (10+7+7) 22

23 FP : Ajustement, charge de travail Le total des points bruts est ajusté en fonction de 14 facteurs (notés s de 0 à 5) Transmission des données Configuration Convivialité Réutilisation Installations multiples, portage Distribution Taux de transaction Mise à jour en temps réelr Facilité d'implantation Facilité des modifications, maintenance Performance Entrées des données en temps réelr Complexité du traitement Simplicité d'utilisation Chaque note indique si le facteur introduit de la complexité (0 simple, 5 complexe) On fait la somme des 14 notes et on calcule le facteur de complexit xité technique FCT = 0,65 + 0,01 x Σ i=1..14 facteur i On calcule le nombre total de points de fonctions ajustés s PFA PFA = PFB x FCT A partir du nombre de jour*homme par point de fonction JHPF (connu nu par expérience) on obtient la charge de travail : Charge de travail = PFA x JHPF 23

24 Le modèle de Putnam Optimiser la charge au cours du développement d et maîtriser la relation entre raccourcissement du projet et augmentation de la charge Dynamique à plusieurs variables 2 principes : l effectif optimal de l'équipe de développement d à un temps t doit être proportionnel à la charge de travail restante l efficacité de l él équipe de développement d s ams améliore avec le temps La charge instantanée e au temps t est la dérivd rivée e de la charge cumulée. On obtient une courbe de distribution de la charge (courbe( de Rayleigh- Norden) qui est une courbe exponentielle négativen Le sommet de la courbe indique le nb maximal de personnes travaillant sur le projet en ETP (équivalent( temps plein). Il est atteint dans des délais fonction d'un paramètre C représentatif de la complexité 24

25 Courbe de Rayleigh - Norden 25

26 charge en ETP Courbe de Rayleigh - Norden Besoins Spécification Conception & développement Opération - maintenance nb2 Validation - test nb1 Conception - codage durée 26

27 Le modèle de Putnam Issu d éd études sur de gros projets (>30ha) L = C x E 1/3 D 4/3 C : cte technologique ( ) de complexité D : durée e (années) L : lignes de code E : effort (h.années) On peut déduire d duire : E = L 3 /(C 3 x D 4 ) l effectif de pointe une fois estimées la charge totale et la date de réceptionr la charge totale du projet quand le maximum des effectifs et le temps de développement sont atteints. l impact de la variation de la durée e de développement d sur la difficulté du projet. Exemple : Un raccourcissement du temps de 10% suppose une augmentation de la charge totale de 40% 27

28 CoCoMo (Constructive Cost Model Barry Boehm) Modèle statique à une variable dans sa version de base (DSI : Delivered Source Instructions) Couvre le cycle de vie de la spécification (i.e. après s analyse de besoins) à la livraison Versions Version 1 parue en 1981 Nouvelle version (COCOMOII) définie en 1997 et finalisée e en

29 Niveaux de COCOMO Le niveau indique la complexité du modèle et sa précision Base E = f(dsi) Intermédiaire Paramètres de coût t (statique à plusieurs variables) Sophistiqué Paramètres de coût t pour chaque étape du développement d (dynamique) 29

30 COCOMO de base : trois «modes de développementd veloppement» Le mode de développement d reflète la difficulté du projet «Organic» petits projets, petite équipe expériment rimentée, e, besoins «souples» «Semidetached» «Embedded» projets moyens, équipe hétérogh rogène entre «organic» et «embedded» logiciels embarqués, contraintes de développement d et d opd opération très s fortes. 30

31 ip8 Choix du mode de développementd Organic Semidetached Embedded Définition des besoins Très bonne Bonne Générale Expérience dans le domaine Très forte Bonne Faible Contraintes de développ. - Faibles Moyennes Fortes opération Contraintes d interface Faibles Moyennes Fortes Développement parallèle de Faible Moyen Intensif matériel ou procédures d utilisation Besoin d architectures ou Faible Moyen Fort algorithmes innovants Besoin de livraison rapide Faible Moyen Fort Taille du logiciel <50 KDSI <300 KDSI toute taille 31

32 Diapositive 31 ip8 Animation ip; 05/11/2004

33 Equations du modèle de base Mode Effort (hmois) Durée (mois) Organic 2,4 KDSI 1,05 2,5 Effort 0,38 Semidetached 3,0 KDSI 1,12 2,5 Effort 0,35 Embedded 3,6 KDSI 1,20 2,5 Effort 0,32 32

34 ip9 Application sur projets de tailles variées 2 KDSI 8 KDSI KDSI KDSI KDSI Effort (MM) Organic Semidetached Embedded Productivité (DSI/MM) Organic Semidetached Embedded Durée (mois) Organic Semidetached Embedded Taille moyenne équipe Organic Semidetached Embedded

35 Diapositive 33 ip9 Animation : faire passer en rouge les points à souligner ip; 05/11/2004

36 Variation Effort / taille M*M Embedded Semidetached Organic KDSI 34

37 Variation Durée e / Taille mois Embedded Semidetached 12 6 Organic KDSI 35

38 mois Variation Durée e / Effort Organic Semidetached 36 Embedded MM 36

39 Répartition de l effortl par étape du CV Mode Etape 2 KDSI 8 KDSI 32 KDSI 128 KDSI 256 KDSI Organic Analyse de besoins Spécification Implantation Conception Codage et test unitaire Intégration et test Semidetached Analyse de besoins Soit E l effort du projet consacré aux étapes de Spécification, Programmation, Intégration et test Spécification Implantation Conception Codage et test unitaire % de E sont consacrés à l étape de Spécification 68% de E sont consacrés à l étape de Programmation 26% de E sont consacrés à l étape de Conception 42% de E sont consacrés à l étape de Codage et test unitaire 16% de E sont consacrés à l étape d Intégration et test Intégration et test Embedded Analyse de besoins Spécification Implantation Conception Codage et test unitaire Intégration et test % de E est ajouté pour l étape d Analyse de besoins 37

40 ip12 Répartition de la durée par étape du CV Mode Etape 2 KDSI 8 KDSI 32 KDSI 128 KDSI 256 KDSI Organic Analyse de besoins Spécification Implantation Intégration et test Semidetached Analyse de besoins Spécification Implantation Intégration et test Embedded Analyse de besoins Spécification Implantation Intégration et test

41 Diapositive 38 ip12 Couleurs;exemple ip; 05/11/2004

42 Répartition de l effortl par activité (Embedded mode) Activité Etape Analyse besoins Spécification Codage Intégration & test KDSI Analyse besoins Conception Codage Préparation test V&V Gestion projets Assurance Q Documentation

43 Insuffisance du modèle de base COCOMO intermédiaire 1 projet sur 3 conforme au modèle à un coefficient de 1,3 près 2 projets sur 3 conformes au modèle à un coefficient de 2 près Nécessité de paramètres supplémentaires (autres que la taille estimée du logiciel) 40

44 15 paramètres supplémentaires CoCoMo intermédiaire Paramètres "produit" fiabilité (RELY), taille BD (DATA), complexité (CPLX) Paramètres "matériel" performances (TIME), contraintes mémoire moire (STOR), volatilité (évolution pendant développement) machine virtuelle (VIRT), temps de retour (entre soumission d une d tâche par le programmeur et la réponse r du système, TURN) Paramètres "personnel" qualité programmeurs (PCAP), qualité analystes (ACAP), expérience application (AEXP), expérience du matériel (VEXP), expérience langage (LEXP) Paramètres "projet" méthodes modernes (MODP), outils de GL (TOOL), planning contraint (délai, SCED) Chaque paramètre peut varier de «very low» à «extra high».. A chaque valeur est associé un poids correcteur. Calcul d un d coefficient correcteur par combinaison des poids associés à chaque paramètre( tre(«effort Adjustment Factor») à appliquer sur le résultat r du modèle de base. 41

45 CoCoMo intermédiaire Exemple de poids affectés à des facteurs de coût Très s basse basse nominale haute Très s haute Extra haute Fiabilité RELY Complexité CPLX Contr. exéc. en temps TIME Contr.sur délai SCED

46 COCOMO II COCOMO conçu u pour des développementsd de bout en bout Aujourd hui, les logiciels sont rarement conçus sans réutiliser : Une version existante Des composants existants COCOMO II prend en compte ces aspects La variable d entrd entrée e du modèle (DSI) est affinée DSI développd veloppéeses DSI modifiées DSI réuitilisées 43

47 COCOMO, critiques Facteurs non pris en compte : Volatilité des besoins Disponibilité du personnel Qualité du management Qualité de l'interface homme-machine machine Etudes sur les écarts entre l estimation l du nombre de lignes de code et la valeur réelle r déviation moyenne est de 64% de la taille réelle r seulement 25% des estimations sont à 25% de la taille réelle. r Une étude sur les outils logiciels d estimation d a montré qu ils ne font pas mieux, la déviation d pouvant aller de 100 à 200% 44

48 Conclusion Estimer le coût t du projet pour le fournisseur puis décider d du prix facturé au client L estimation algorithmique du coût t est difficile puisqu elle repose sur des estimations des attributs du logiciel final Importance des modèles d estimation d du coût t du logiciel pour le management : moyen de comparaison entre plusieurs options de développement Le temps requis pour développer d un projet ne se réduit r pas à une fonction simple de la taille de l équipe de projet Chaque organisation doit déterminer d ses propres attributs et ses propres multiplicateurs en fonction de ses spécificit cificités, ses priorités s et ses contraintes (capitalisation de l'expérience, constitution d'une base de données statistiques sur le projets,...) 45

49 Planification-suivi Master CCI Génie Logiciel - ORGANISATION DE PROJET - P.Y. CUNIN, I. PARISSIS

50 Estimation Objectifs Déterminer l ensemble l de "tâches" avec un niveau de détail d suffisant Estimer l effort l nécessaire n pour l accomplissement l de chaque "tâche" Les tâches La définition d et le contenu d'une tâche dépendent d du cycle de vie choisi. une itération dans le cas du processus unifié une (partie de) phase/étape dans le cas d'un cycle de vie en V ou en cascade un incrément dans un cycle de vie incrémental En général g une tâche correspond à la réalisation r d'une fourniture intermédiaire ou finale, interne ou externe Difficultés Produire des données quantitatives à partir d informations d qualitatives imprécises Dans un premier temps il est inutile de rechercher une grande précision, les estimations étant destinées à être ajustées lors du suivi 47

51 Décomposition des tâches Exemple de décomposition (cycle de vie classique) T1 : Analyse besoins T2 : Définition D spécifications T3 : RéalisationR T3.1 : Conception globale T3.2 : Conception détailld taillée, codage et test unitaire T : Module A T : Module B T3.3 : Intégration et test T4 : Livraison 48

52 Plan Planification Définir l ordre l des tâches : graphe de précédence Déterminer la durée e du projet Affecter des ressources Produire le planning Suivi Technique de représentation graphique de l avancementl 49

53 ip14 Planification: graphe de précédence Point de départ d Décomposition du projet en tâches Graphe de précédence (ou réseau) r Tâches Liens entre tâches A B C D 50

54 Diapositive 50 ip14 Rappel : tâche =? ip; 05/11/2004

55 ip15 A A A A A B B B B B Types de liens Début début La tâche B ne peut commencer qu apr après s le début de la tâche A Début fin La tâche B ne peut se terminer qu apr après s le début de la tâche A Fin début (très s courant) La tâche B ne peut commencer qu apr après s la fin de la tâche A Fin fin La tâche B ne peut se terminer qu apr après s la fin de la tâche A Début début et fin - fin La tâche B ne peut commencer qu apr après s le début de la tâche A et ne peut se terminer qu apr après s la fin de A. 51

56 Diapositive 51 ip15 Insèrer exemple ip; 05/11/2004

57 Liens Un lien permet de déclencher d une tâche et non pas de synchroniser deux tâches Exemple : B ne peut commencer qu apr après s le début d de A; A ne peut se terminer qu apr après s la fin de B A B A : arrangements intérieurs B : peinture "Boucle" est souvent due à une mauvaise définition d des tâches B A A A : arrangements préliminaires A : arrangements finaux B : peinture 52

58 Planification: déterminer la durée e du projet Point de départ d : graphe de précédence durée e des tâches estimée e (cf. p.ex. CoCoMo) B 20j A 10j D 10j C 10j 53

59 Planification «début-fin au plus tôt» A C B Calcul du chemin critique A 10j D B C 20j 10j Diagramme de Gantt A D 10j Planification «début-finfin au plus tard» B C D 0j 10j 20j 30j 40j -40j -30j 10j -20j -10j 30j 40j Date de débutd «au plus tôt» Date de débutd but«au plus tard» 54

60 Marges et chemin critique Marge d une tâche date de début d au plus tard date de début d au plus tôt Marge = décalage potentiel d une tâche A 10j B 20j D 10j Marge(A) = Marge(B) = Marge(D) = 0j C 10j Marge(C) = 10j Chemin critique : ensemble des tâches de marge nulle Sur l exemple : A, B, D 55

61 Marges et chemin critique (suite) Le chemin critique détermine la durée minimale du projet,, sans prendre en compte l affectation de ressources Marge totale d une tâche Durée dont une tâche peut être décalée sans décaler la fin du projet Marge libre d une tâche Durée dont une tâche peut être décalée sans en décaler aucune autre 56

62 Marge négative Une marge peut être négative, si la durée du projet est imposée Lors de la planification au plus tard,, on tient compte de le date de fin imposée Exemple : durée imposée de 35j pour le réseau ci-dessous Marge négative = incohérence entre durées es,, liens, dates Eliminer les marges négatives avant l affectation de ressources B 20j A 10j D 10j C 10j 57

63 Les ressources d un d projet Planification : affecter les ressources Caractéristiques ristiques d une d ressource Description Type, nom,... Ressources humaines Ressources logicielles Disponibilité Temps plein - partiel Fixe - variable Ressources matérielles Trois paramètres (2 à fixer) Intensité : % de la disponibilité totale Charge (effort) Durée 58

64 Disponibilité d une ressource Ressources humaines Sur 52 x 5 = 260 jours de l année déduireduire : 10 jours fériés 25 à 30 jours de congés 5 jours maladie 5-10 jours formations (hors projet) 10 jours vie sociale (CE, syndicats, ) 40 jours de support à d autres projets il reste entre 145 et 180 jours à travailler sur un projet précis Ressources logicielles et matérielles Bien penser à la réservation r / commande Évaluer les risques associés 59

65 élevé Ressources humaines Degré de participation Ingénieur «senior» Codage Ingénieur «junior» faible Chef de projet Besoins Spécification Conception & développement Intégration - test 60

66 Plan de charge Point de départ : planning + affectation de ressources A B C D 0j 10j 20j 30j 40j 50j 100% R1 0% R1 A 100% R2 B 100% C 100% D 100% R2 100% 0% 61

67 Nivellement Rendre le planning conforme à la disponibilité des ressources Nécessaire quand une ressource est utilisée plus que sa disponibilité ne le permet Décaler les tâches en surcharge Calculer le nouveau planning Nivellement à durée fixe La durée des tâches n est pas modifiée Nivellement à charge fixe La durée des tâches peut diminuer (attention!!!) ou augmenter 62

68 Respect des dates Date de fin antérieure à la date demandée e par le client OK Date de fin postérieure à la date demandée e par le client mais on peut se ramener au cas précédent si on ajoute des ressources Problème MOE Date de fin postérieure à la date demandée e par le client quelle que soit la quantité de ressources affectées es Problème MOA 63

69 Suivi du planning Des réunions d avancement régulières Vérification du respect du planning Réajustement du planning En pratique Les réunions d avancement ne doivent pas être trop espacées mais pas trop fréquentes non plus... Le temps passé à suivre l avancement fait partie du projet! Pour les projets standards : toutes les deux à quatre semaines (correspond à une itération dans le processus unifié) 64

70 Suivi: diagramme dates-dates Diagramme synthétique tique donnant un aperçu u pertinent de l avancementl Exemple A B C D t0 fa fa2 fa1 fc fc2 fc1 fb fb2 fb1 fd fd2 fd1 RA1 RA2 65

71 A B C D t0 fa fa2 fa1 fc fc2 fc1 fb fb2 fb1 fd fd2 fd1 66

72 t0 fa fa2 fa1 fc fc2 fc1 fb fb2 fb1 fd fd2 fd1 67

73 t0 fa fc fb fd t0 fa1 fc1 fb1 fd1 futur passé Le projet converge si les courbes des tâches se rapprochent de la ligne du présent t0 fa2 fc2 fb2 fd2 présent 68

74 Diagramme dates-dates date d'avancement jalon rendu de jalon 69

75 Diagramme dates-dates Les lignes bleues représentent les dates d'avancement (écrites en bleue) Les lignes mauves représentent la prévision pour le jalon correspondant. A l'intersection des jalons et des dates d'avancement, on trouve des points bleus. Les lignes vertes correspondent à un rendu de jalon. Par exemple rendu du cahier des charges fonctionnel. Lorsqu'une ligne verte reprend la couleur mauve, le client n'a pas accepté le jalon. C'est pour cela qu'il est replanifié. Un jalon "ligne verte" entre deux points bleus est accepté. Pour l'exemple les jalons sont (de haut en bas) : Version finale [En cours de validation] Version beta [Accepté] Cahier des charges technique [Accepté] Maquette Interface graphique [Accepté] Cahier des charges graphique [Accepté] Cahier des charges fonctionnel [Accepté] Cahier des charges [Accepté] 70