Conduite des projets logiciels CdP FIIFO 4 PLAN DU COURS _____________I. Généralités Conduite des Projets logiciels Conduite des projets logiciels CdP FIIFO 4 PLAN DU COURS Généralités et processus de développement Estimation Organisation et planification Comptabilité analytique et budgétaire des projets Techniques de suivi Gestion des risques _____________FIIFO 4ème année

Généralités et processus de développement _____________I. Généralités Conduite des Projets logiciels Généralités et processus de développement _____________FIIFO 4ème année Frédéric FICHOT

I.1. Généralités sur la CdP Approche économique de la production de logiciel Les difficultés et les risques de la prévision Ce que l’on sait avec certitude

Caractéristiques du logiciel projet de réalisation d’un prototype de définition inusable complexe immaturité technique des équipes de réalisation turn over, promotion, formation savoir faire très faible sur les tests Aléas techniques Aléas économiques qualité temps Sûreté de fonctionnement Complexité théorique taille

LES DIFFICULTES DU TEST _____________I. Généralités Conduite des Projets logiciels LES DIFFICULTES DU TEST Le processus d'introduction des défauts Spécification, conception, codage Corrections, évolutions, portage Difficultés psychologiques ou "culturelles" : Objectifs "destructifs" du test contraires à la créativité des programmeurs Test mal perçu par la communauté des informaticiens, peu de formations Activité délaissé au profit des activités de spécification et de conception (considérées plus nobles) Difficultés d'ordre formel : Pas d'algorithme général capable de démontrer l'exactitude de tout programme Le test n’a pas de terme Difficultés liées aux délais ! _____________FIIFO 4ème année

_____________I. Généralités Conduite des Projets logiciels 48% du coût d'un développement est consacré à la réparation des défauts Nombre de défauts selon leur origine Coût de réparation des défauts _____________FIIFO 4ème année

Les 10 risques majeurs R1 devis irréaliste (planning et budget) R2 implémentation de fonctions inadaptées R3 réalisation d ’une interface inadaptée R4 taux de défaillance élevé en exploitation R5 évolution continuelle des spécifications R6 performances insuffisantes R7 maintenance ruineuse (chaotique) R8 retards de livraison fournisseurs R9 conception irréaliste R10 défection de personnel (2002)

R1: Devis irréaliste Les 5 plus grands développements achevés en 2001(DOD, NATO) planning prévu planning réel 1 2 3 4 5 0 20 40 60 80 100 durée du planning en mois 22 mois 7,5 ans Dépassement moyen des délais : 82 % / 167 projets Dépassement moyen des budgets : 43 % /198 projets Mais on revient de loin sur les délais : 187 % en 1998 240 % en 1990 261 % en 1985 … et seulement 12 % sur les projets démarrés depuis 2000 !

Ce que l’on sait avec certitude La charge de réalisation d ’un projet s ’accroît exponentiellement par rapport à la taille du logiciel à produire (nombre d ’instructions) La productivité baisse en fonction de l ’accroissement en taille des logiciels à produire L’utilisation de langages de programmation procéduraux de plus en plus évolués (facteur de déflation) accroît d’autant la productivité Les phases de réalisation (CD, codage, TU) représentent une part d’autant plus faible de l’effort de développement que le projet est important La perte de productivité des grandes équipes de réalisation est considérables par rapport à une structuration en équipes réduites (> 8 personnes) La productivité des équipes de réalisation constituées d’ingénieurs est optimale par rapport aux coûts salariaux

I.2 Le processus de production de logiciel C’est la base de tout C’est le socle du Génie Logiciel C’est la seule façon d’être conforme C’est la seule façon de comprendre

Processus et cycle de vie GESTION DE PROGRAMME & G. DES RISQUES GESTION DES PARTENAIRES & DES SS-TRAIT. GESTION DE CONFIGURATION PROCESSUS DE GESTION ETUDE PREALABLE AVANT-PROJET ASSURANCE QUALITE SPECIFICATION & CONCEPTION CONTRÔLE QUALITE PRODUCTION INTEGRATION & VALIDATION OPERATION MESURE MAINTENANCE & SUPPORT PROCESSUS QUALITE PROCESSUS TECHNIQUE Référentiel Qualité Logiciel

_____________I. Généralités Conduite des Projets logiciels CYCLE EN "V" besoin exprimé logiciel recetté Plans projet:: PAQ, PGCL, PT organisation Plan de Validation (PVL) spécification validation Document de Spécification (DSL) Plan d’Intégration (PIL) Architecture testée conception globale intégration Document de Conception Préliminaire (DCP) Composants testés Dossier de Tests Unitaires (DTUL) conception détaillée tests unitaires Document de Conception Détaillée (DCD) Composants déverminés _____________FIIFO 4ème année codage Revues : RFFPS, RFFPCP, RFFPI ISO/IEEE/EIA12207

La phase de spécification 1 2 3 4 Phase de spécification (des besoins) PVL DSL Document écrit émanant du client Cahier des charges, clauses techniques,… Etude préalable, d’opportunité, de faisabilité,… Document de spécification système/d’équipement/de segment/externe Besoins exprimés oralement par le client Lors de l’analyse fonctionnelle Au cours d’enquêtes de satisfaction/ d’opportunité Au cours d’une analyse de la valeur Lors de la Revue du DSL ou du PVL Exigences qualité Clauses qualité d’un AO (client/Mou/Moe) Plan Qualité ou Manuel qualité (prestataire/Moe/Sous Traitant) Norme de référence Universelle ISO9001 Générales DOD2167 et DOD2168 Sectorielles EUROCAE DO178

Analyse Fonctionnelle Les activités à mener Réalisation des plans : Plan Qualité Plan de Gestion des Configurations Plan de Test PQL PGCL PTL Analyse Fonctionnelle Analyse Opérationnelle Définition des contraintes de réalisation DSL Préparation de la validation PVL Participation aux revues RDSL RPVL RFFPS PV L’ordre d’exécution des tâches et bien souvent plus compliqué Généralement on s’efforce de respecter la Loi de RAYLEIGH (modèle de L. PUTNAM) spécif La loi de l’effort optimal Effort /Effectif Temps

Spécification Externe Spécification Interne ISO 12207 Spécification Externe (Expression des besoins du client) DSE PVL RDSE Spécification Interne (Définition de la solution proposée) DSI RDSI RPVL RFFPS

Contenu du DSL PLAN-TYPE IEEE Introduction Contexte 2.1. objectifs 2.2. hypothèses Description générale 3.1. intégration dans le système 3.2. fonctions principales du logiciel 3.3. caractéristiques des utilisateurs 3.4. Contraintes générales 3.4.1. contraintes de développement 3.4.2. contraintes d’exploitation 3.4.3. conformité aux standards (normes) 3.4.4. documentation Besoins détaillés Glossaire et références Index Annexes

Chapitre 4. besoins détaillés (IEEE) Chap 4. 1 besoins détailles . 4.1. spécifications fonctionnelles 4.1.x. fonction a 4.1.x.1. description de la fonction 4.1.x.2. données 4.1.x.3. traitement des exceptions 4.2. spécifications d'interfaces 4.2.1. interfaces logiciel/logiciel 4.2.2. interfaces matériel/logiciel 4.2.3. interfaces homme/machine 4.3. spécifications opérationnelles 4.3.1. facilite d'utilisation 4.3.2. performances 4.3.3. modes d'exploitation 4.3.4. facteurs qualité 4.3.5. installation 4.3.6. sécurité, intégrité et sûreté 4.3.7. base de données

Les sept pèches capitaux des spécifications . Bruit: élément du texte n'apportant d'information sur aucune des caractéristiques du problème . Silence: caractéristique du problème a laquelle ne correspond aucun élément du texte . Sur spécification: éléments du texte correspondant a une caractéristique non pas du problème mais d'une solution possible . Contradiction: élément du texte contredisant un autre élément de ce texte . Ambiguïté: élément du texte permettant de comprendre une caractéristique du problème de deux façons ou plus . Référence en avant: élément du texte utilisant une caractéristique du problème définie plus loin dans le texte . Voeu pieux: élément du texte décrivant une caractéristique du problème de telle façon qu'il sera impossible de valider une solution relative a cette caractéristique

Spécifications fonctionnelles LE QUOI PAS LE COMMENT L’objectif est de décrire complètement ce qu’il faut faire Identifier l’ensemble des fonctions à réaliser Identifier les liens entre fonctions Identifier les modes de fonctionnement Identifier les conditions de déclenchement Cette activité s’appelle l’Analyse Fonctionnelle

Les phases classiques Conception Préliminaire Conception Détaillée Concevoir la structure de l’ensemble Prévoir l’intégration Concevoir le détail de chacun des composants Prévoir les tests du composants Réaliser chacun des composants et les déverminer Conception Détaillée Codage

_____________I. Généralités Conduite des Projets logiciels Les phases classiques Tests de Validation Test du logiciel considéré comme un tout vis-à-vis des spécifications (DSL) et à la fin devant le client Test de l'architecture définie pour le logiciel (statique et dynamique) par assemblage progressif des composants vis-à-vis de la conception de l'architecture (DCP) Test d'un composant isolé, dans un environnement simulé vis-à-vis de l'implémentation de la conception (DCD et code) Tests d'Intégration _____________FIIFO 4ème année Tests Unitaires

_____________I. Généralités Conduite des Projets logiciels Le processus de test PLANS PVL ou PIL et … PTUL Organisation des tests Stratégie générale de test: Quels tests, par qui, pour qui, avec quels moyens Spécification des tests Organisation des tests : - objectifs - critères d'arrêt Conception des tests scénarios procédures Réalisation des tests jeux d'essais DOSSIERS DTUL, DTIL, CRL Exécution des tests Journaux de test _____________FIIFO 4ème année Avis du client Résultats attendus Evaluation des tests Rapports de test RT Rapports d’Anomalies RA

CLASSIFICATION DES TECHNIQUES DE TEST _____________I. Généralités Conduite des Projets logiciels CLASSIFICATION DES TECHNIQUES DE TEST ¬ Classification boîte noire / boîte blanche ou fonctionnel / structurel Classification test statique / test dynamique DT résultats Program P ; begin ... end DT résultats Exécution Analyse _____________FIIFO 4ème année Manuel par inspection Outils

LES TESTS D'INTEGRATION _____________I. Généralités Conduite des Projets logiciels LES TESTS D'INTEGRATION Construction progressive du logiciel à partir de composants testés unitairement Installation du logiciel sur les machines cible (intégration Système) Le but de l'intégration Tester le respect des exigences de conception préliminaire (choix d'architecture, degré de parallélisme, etc) Assembler progressivement les composants pour limiter les risques (défauts dans l'architecture, problèmes d'interface avec le matériel) Vérifier que le composant intégré fonctionne bien avec les autres et (s'il y a lieu) avec le matériel Vérifier le bon fonctionnement du logiciel Organisée en étapes (steps) : ajout d'un ou de plusieurs composants à l'assemblage existant selon une stratégie prédéterminée _____________FIIFO 4ème année FIIFO

Les stratégies d’intégration Package A A1 Proc x A2 Proc y A3 Proc z A B C D E F Big bang Ascendante Descendante Mixte Par agrégats (assemblage)

Choix de la stratégie d'intégration et planification du projet _____________I. Généralités Conduite des Projets logiciels Choix de la stratégie d'intégration et planification du projet Step 1 Step 2 Step 3 Step 4 Step 5 CDA CODA TUA I(A+B) I(+C) I(+D) I(+E) I(+F) MUD MUE CDB CODB TUB MUF CDC CODC TUC _____________FIIFO 4ème année CDD CODD TUD CDE CODE TUE CDF CODF TUF Réseau PERT simplifié FIIFO

Les documents de validation Plan de Validation du Logiciel PVL Cahier de Recette de l ’Etape N° CRL N° Rapport d ’Anomalie RA PV Procès Verbal d ’étape PV de la séance de recette

Le planning d’une phase de validation Préexamen Période de garantie Séance de recette provisoire (usine) Séance de recette définitive (site) Période probatoire Préexamen : période de 3 jours à 4 semaines consacrée à l ’analyse minutieuse et systématique de la fourniture par le client. Période probatoire : période de 2 semaines à 6 mois consacrée à l ’expérimentation du logiciel par le client et à la formation des utilisateurs. Période de garantie : durée pendant laquelle le client peut exiger la réparation gratuite des vices cachés (législation CEE) Toutes ces périodes sont définies précisément dans le contrat et reprises dans le PVL.

La séance de test de validation _____________I. Généralités Conduite des Projets logiciels La séance de test de validation Tests "formels" : Parcours d'un cahier de recette ou d'un dossier de validation préétabli But : montrer que chaque élément des spécifi-cations est réalisé Un "procès-verbal" résume les résultats Réalisée dans un environnement Simulé Pré-opérationnel (environnement réel par-tiel) Opérationnel Les étapes d'une validation : 1. Fourniture & Installation 2. Interfaces 3. Dialogue homme-machine 4. Fonctionnalités 5. Performances 6. Robustesse - modes dégradés 7. Sécurité 8. Configuration 9. Compatibilité / conversion 10. Exploitation _____________FIIFO 4ème année

Qu’est-ce que la gestion des configurations SPECIFICATION Dossier de réalisation Ensemble des activités (manuelles ou automatisées) permettant d'identifier et de définir les éléments de configuration et toutes leurs relations. Elle permet de contrôler les évolutions durant le cycle de vie du logiciel, d'archiver chacun des états successifs et de vérifier que chacun de ces états est complet et cohérent. (AFNOR Z61-102)

Objectifs Gestion des configurations : La discipline consistant à appliquer des règles et une surveillance technique et administrative pour : Identifier les configurations Contrôler les modifications (corrections & évolutions) Suivre le traitement de ces modifications Garantir une livraison Garantir la maintenabilité Assurer la cohérence du produit face à l’action déstabilisatrice des demandes de correction et d’évolution S. BRANTON

Les 3 composantes de la G.C. La mise en configuration Préparation des référentiels Capture et contrôle des articles Identification des articles et de leurs liens La gestion des modifications Gestion des corrections Gestion des évolutions L’administration des configurations Définition d’un état de configuration Edition des nomenclatures Audit des configurations

La mise en configuration Projet de développement capture Référentiel de besoins Référentiel de développement Référentiel de livraison Spécification Réalisation Recette Contrat DSL PVL DCP CRL .exe DCD Code SADT DSL tests DE

Le référentiel Constitué d’articles de configuration organisés sur une arborescence logique de classement (structure du référentiel) Spécification CP CD Codage TU TI TV Référentiel Fonctionnel Référentiel de Développement Référentiel de Livraison

Le nommage des articles XY/M88/URN_DCP.docV03.11 Appartenance Identification Type Version Etat d'un élément, d'un article de configuration ou d'un logiciel, mis à la disposition des utilisateurs, comprenant les évolutions apportées à l'état précédent. La version est caractérisée par un identifiant précisant le degré d'évolution d'un article de configuration ou d'un logiciel Révision Modification d'un élément, d'un article de configuration ou d'un logiciel correspondant à des corrections ou des amendements qui préservent les fonctions externes de l'état précédent

Que faut-il gérer ? Documentation Ensemble des documents (dossiers, plans, rapports, fiches d'anomalies, ...) liés au projet Composants de programmation Ensemble des codes sources (programmes sources, sources copy, macro-instructeurs, bibliothèques sources, écrans, JCL, ...) Composants de fabrication Ensemble des systèmes et outils nécessaires pour le développement (outil de documentation, AGL, compilateurs, ...) Ensemble des procédures nécessaires à la fabrication des exécutables (Procédure de compilation, Link, génération base, ...) Composants d'exécution Ensemble des éléments fabriqués par transformation ou duplication des éléments de programmation (objets, exécutables, codes de commande, ...) Composants de test Ensemble des éléments (hors plans de test) produit pour ou par les tests (procédures de test, jeux d'essais, lanceurs, muets, résultats des tests, ...)

Les liens entre les articles F1 F2 F3 F4 Implémente Matrice fonction x organe Appelle Link Assignation de fichier Manipule Outillage Création Modification édition Assemble Intégration d’éléments pour une édition Constitution de dossier Documente Ect. PK1 X X PK2 X PK3 X X La traçabilité

Le Fait Technique (FT)

Processus de correction Gestion des FT REJET Utilisé pour : L’anomalie L’évolution FT Tri FT Stock Commission de correction Processus de correction Train 1 Train 2 Train 3 OC OC OC

Administration des configurations Etat de configuration Ensemble d'articles de configuration (AFNOR) : Assemblés dans un objectif commun Exprimés dans la documentation associée Ensemble des caractéristiques fonctionnelles et physiques d'un logiciel, exprimées dans la documentation (comprenant les sources) et atteintes par le produit (DoD) Edition des nomenclatures Figer un état de configuration Notion de moins en moins utilisée en logiciel Audit des configurations Audit de traçabilité Audit du cycle correctif ISO 900X Analyse de l’évolution du stock de FT

I.3. Le processus de gestion de projet Processus rythmé par le cycle de vie À chaque problème une solution Des modèles originaux

I.3. Code minimal de bonne conduite Gérer un projet, c'est : prévoir organiser faire le point d'où les techniques : d'estimation de planification de suivi Devis I Devis II Devis III (définitif) Engagement Confirmé Définitif Spécif C.P. Réalisation

Le processus de gestion de projet ESTIMATION Modèles quantitatifs & phénoménologiques COCOMO - PUTNAM - PF Devis ANALYSE Modèles analytiques WBS- OBS - FBS - RBS Budget PLANIFICATION Modèles heuristiques PERT XX (CPM) Planning Techniques de suivi et d’analyse des dérives SUIVI Mesures et pronostics

Les modèles utilisables Modèles de régression Modèles phénoménologiques Modèles heuristiques Modèles analytiques B (HM) = A (KISL) COCOMO/NATO : modèle de régression stochastique répartition phénoménologique de l’effort (II ESTIMATION) ventilation analytique coûts/effort x phase