D/T/071.1/02 Chapitre 1 Généralités 1 Copyright RAS 2002 Reproduction interdite Conduite des...

D/T/071.1/02 Chapitre 1 Généralités 1Copyright RAS 2002 Reproduction interdite

Conduite des projets logicielsCdP

FIIFO 4

PLAN DU COURS

Conduite des projets logicielsCdP

FIIFO 4

PLAN DU COURS

I. Généralités et processus de développement

II. Estimation

III. Organisation et planification

IV. Comptabilité analytique et budgétaire des projets

V. Techniques de suivi

VI. Gestion des risques


I. Généralités etprocessus de

développement

Frédéric FICHOT


I.1. Généralités sur la CdP

1. Approche économique de la production de logiciel

2. Les difficultés et les risques de la prévision

3. Ce que l’on sait avec certitude


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

Caractéristiques du logiciel

taille

qualité

temps

Sûretéde fonctionnement

Aléas techniques

Complexité théorique

Aléas économiques


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 !


48% du coût d'un développement est

consacré à la réparation des défauts

Code15%

Algorithme25%Spécification et

conception60%

Code8%

Algorithme9%

Spécification et conception

83%

Nombre de défauts selon leur origine

Coût de réparation des défauts


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

1

2

3

4

5

0 20 40 60 80 100 durée du planningen mois

planning prévu

planning réel

Dépassement moyen des délais : 82 % / 167 projetsDépassement moyen des budgets : 43 % /198 projets

Mais on revient de loin sur les délais : 187 % en 1998240 % en 1990261 % en 1985

… et seulement 12 % sur les projets démarrés depuis 2000 !

Les 5 plus grands développementsachevés en 2001(DOD, NATO)

7,5 ans22 mois


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 productionde 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

PROCESSUS DE GESTION

GESTION DE PROGRAMME & G. DES RISQUES

GESTION DE

CONFIGURATION

GESTION DES PARTENAIRES & DES SS-TRAIT.

ETUDE PREALABLE

AVANT-PROJET

SPECIFICATION & CONCEPTION

PRODUCTION

INTEGRATION & VALIDATION

OPERATION

MAINTENANCE & SUPPORT

PROCESSUS TECHNIQUEPROCESSUS

QUALITE

ASSURANCE QUALITE

CONTRÔLE QUALITE

MESURE

Référentiel Qualité Logiciel


CYCLE EN "V"

spécification

conception globale

conceptiondétaillée

validation

intégration

testsunitaires

codage

organisation Plans projet:: PAQ, PGCL, PT

Document deSpécification (DSL)

Document deConceptionPréliminaire (DCP)

Dossier de TestsUnitaires (DTUL)

Plan de Validation (PVL)

Composantsdéverminés

Composantstestés

Architecturetestée

Plan d’Intégration (PIL)

logicielrecetté

besoinexprimé

Document deConception Détaillée (DCD)

Revues : RFFPS, RFFPCP, RFFPI

ISO/IEEE/EIA12207


La phase de spécification

1. 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

2. 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

3. Exigences qualité• Clauses qualité d’un AO (client/Mou/Moe)• Plan Qualité ou Manuel qualité (prestataire/Moe/Sous Traitant)

4. Norme de référence• Universelle ISO9001• Générales DOD2167 et DOD2168• Sectorielles EUROCAE DO178

Phase de spécification(des besoins)

1 2 3 4

PVL

DSL


Les activités à mener

• 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)

Réalisation des plans :•Plan Qualité•Plan de Gestion des Configurations•Plan de Test

Analyse FonctionnelleAnalyse Opérationnelle

Définition des contraintes de réalisation

Préparation de la validation

Participation aux revuesRDSL RPVL RFFPS

Effort/Effectif

Temps

spécif La loi de l’effort optimal

PQL PGCL PTL

DSL

PVL

PV


ISO 12207

Spécification Externe(Expression des besoins du client)

DSE

Spécification Interne(Définition de la solution proposée)

DSIDSI

PVLRDSE

RPVLRDSI

RFFPS


Contenu du DSL

PLAN-TYPE IEEE

1. Introduction2. Contexte

2.1. objectifs2.2. hypothèses

3. Description générale3.1. intégration dans le système3.2. fonctions principales du logiciel3.3. caractéristiques des utilisateurs3.4. Contraintes générales

3.4.1. contraintes de développement3.4.2. contraintes d’exploitation3.4.3. conformité aux standards (normes)3.4.4. documentation

4. Besoins détaillés

5. Glossaire et références6. Index7. Annexes


Chapitre 4. besoins détaillés (IEEE)

Chap 4. 1 besoins détailles

. 4.1. spécifications fonctionnelles

4.1.x. fonction a4.1.x.1. description de la fonction4.1.x.2. données4.1.x.3. traitement des exceptions

4.2. spécifications d'interfaces

4.2.1. interfaces logiciel/logiciel4.2.2. interfaces matériel/logiciel4.2.3. interfaces homme/machine

4.3. spécifications opérationnelles

4.3.1. facilite d'utilisation4.3.2. performances4.3.3. modes d'exploitation4.3.4. facteurs qualité4.3.5. installation4.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

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

ConceptionDétaillée

ConceptionPréliminaire

Codage


Les phases classiques

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

Tests de Validation

Tests Unitaires


Le processus de test

Organisationdes tests

Spécificationdes tests

Conceptiondes tests

Réalisationdes tests

Exécutiondes tests

Evaluationdes tests

Stratégie générale de test:Quels tests, par qui, pour qui, avec quels moyens

Organisation des tests :- objectifs- critères d'arrêt

scénariosprocédures

jeux d'essais

Journauxde test

Avis du clientRésultats attendus

PLANS

PVL ou PIL et … PTUL

PLANS

PVL ou PIL et … PTUL

DOSSIERS

DTUL, DTIL, CRL

DOSSIERS

DTUL, DTIL, CRL

Rapportsd’Anomalies

RA

Rapportsd’Anomalies

RA

Rapports de test

RT

Rapports de test

RT


CLASSIFICATION DES TECHNIQUES

DE TEST

Classification boîte noire / boîte blanche

ou fonctionnel / structurel

Classification test statique / test dynamique

DT résultats

DT résultatsProgram P ;begin...end

Exécution Analyse

Manuel par inspectionOutils

FIIFOD/T/071.1/02 Chapitre 1 Généralités 24Copyright RAS 2002 Reproduction interdite

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


Les stratégies d’intégration

Big bang

Ascendante

Descendante

Mixte

Par agrégats (assemblage)

A

CB

FED

A1

A2

A3

Proc x

Proc y

Proc z

Package A

FIIFOD/T/071.1/02 Chapitre 1 Généralités 26Copyright RAS 2002 Reproduction interdite

Choix de la stratégie d'intégration et

planification du projet

CDA CODA TUA I(A+B) I(+C) I(+D) I(+E) I(+F)

MUD

MUE

CDC CODC TUC

CDB CODB TUB

MUF

CDD CODD TUD

CDE CODE TUE

CDF CODF TUF

Step 1

Step 4

Step 5

Step 2

Step 3

Réseau PERT simplifié


Les documents de validation

PVL

CRL N°

PV

PV de la séance de recette

RA

Plan de Validationdu Logiciel

Cahier de Recette

de l ’Etape N°

Procès Verbald ’étape

Rapport d ’Anomalie


Le planning d’une phase de validation

Séance derecette provisoire

(usine)

Séance derecette définitive

(site)

Préexamen

Période probatoire

Période de garantie

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

• 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 & Installation2. Interfaces3. Dialogue homme-machine4. Fonctionnalités5. Performances6. Robustesse - modes dégradés7. Sécurité8. Configuration9. Compatibilité / conversion10. Exploitation

Les étapes d'une validation :

1. Fourniture & Installation2. Interfaces3. Dialogue homme-machine4. Fonctionnalités5. Performances6. Robustesse - modes dégradés7. Sécurité8. Configuration9. Compatibilité / conversion10. Exploitation


Qu’est-ce que la gestion des configurations

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)

SPECIFICATION

Dossier de réalisation

R. A. N° 117

R. A. N° 117


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éstabilisatricedes 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

capture

Projet de développementProjet de développement

Référentiel debesoins

Référentiel dedéveloppement

Référentiel delivraison

Spécification

Spécification

DCPDCP

DCDDCD

DSL PVLDSL PVLContratContrat

CodeCode

teststests

RecetteRecetteRéalisation

Réalisation

CRLCRL .exe.exe

DSLSADT

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

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

XY/M88/URN_DCP.docV03.11


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

• 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.

La traçabilité

F1 F2 F3 F4

PK1 X X

PK2 X

PK3 X X


Le Fait Technique (FT)


Gestion des FT

FTFT

FTFT

Commissionde

correction

Train 1Train 1

Train 2Train 2

Train 3Train 3

Stock

Tri

Processus de correction

REJETREJET

OC OC OC

Utilisé pour :

•L’anomalie

•L’évolution


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 nomenclaturesFiger un état de configurationNotion 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

Spécif C.P. Réalisation

Devis I Devis II Devis III (définitif)

Engagement Confirmé Définitif


Le processus de gestion de projet

ESTIMATION

ANALYSE

PLANIFICATION

SUIVI

Modèles analytiquesWBS- OBS - FBS - RBS

Modèles heuristiquesPERT XX (CPM)

Techniques de suivi et d’analyse

des dérives

Modèles quantitatifs& phénoménologiquesCOCOMO - PUTNAM - PF

Devis

Budget

Planning

Mesures et pronostics


Les modèles utilisables

Modèles de régression

Modèles phénoménologiques

Modèles heuristiques

Modèles analytiques

(HM) = A (KISL)B

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

D/T/071.1/02 Chapitre 1 Généralités 1 Copyright RAS 2002 Reproduction interdite Conduite des...

Documents

Transcript of D/T/071.1/02 Chapitre 1 Généralités 1 Copyright RAS 2002 Reproduction interdite Conduite des...