F.A - Méthodologie - DEA - 1 Sensibilisation aux projets logiciels Les projets logiciels + la réalité en chiffres + les cycles de vie + les problèmes +

F.A - Méthodologie - DEA - 1

Sensibilisation aux projets logiciels

Les projets logiciels la réalité en chiffres les cycles de vie les problèmes la qualité logicielle

Les errements de la pratique bonnes habitudes erreurs classiques


La réalité...

Taux d’échec50% des projets n’aboutissent jamais25% n’apportent aucune valeur ajoutée aux

utilisateurs

Retard2/3 des projets dépassent largement les délais les grands projets ont un retard de 25% à 50%50% des cas, le planning est établi avant les

spécifs.


... en chiffres

Défauts la cause la plus fréquente de dépassement de

planningà l’origine de 50% des abandons de projets

Incompréhension65% des projets ont des mésententes avec le

client10% sont annulés suite à des attentes irréalistes

Efficacité40% des erreurs sont générées par le stress65% du temps à des activités contre-productrices


Des étoiles et des bugs

Commission d’enquête pour Ariane 5: “le logiciel a été considéré correct tant qu’il ne

s’était pas révélé défaillant” “s’assurer que les revues prennent en compte

le bien- fondé des argumentations au lieu de contrôler que les vérifications ont été faites”

“il faut une définition nette des responsabilités” Et d’autres...


Projet logiciel

logiciel projet logiciel projet méthode de développement structure systématique

produit logiciel code documentation associée

qualité logicielle


Triangle des Bermudes

Le niveau de qualité est un compromis

Coût

Délai

Performance


Le cycle de vie

Période entre l’idée du logiciel et sa mise en service

Phases de développementSpécification des besoinsConception préliminaireConception détailléeCodage : 15% du travailTests unitairesTests d’IntégrationValidation

Entouré par spécification et maintenance


Cycle en V

Expression des besoins

Expression des besoins

SpécificationsSpécifications

Conception généraleConception générale

Réalisation (codage)Réalisation (codage)

Tests d’intégrationTests d’intégration

Validation (recette)Validation (recette)

MaintenanceMaintenance

Conception détaillée

Conception détaillée

Tests unitairesTests unitaires


Cycle en V, caricature ;-)

Cahier des chargesCahier des charges

ÉtudesÉtudes

DéveloppementDéveloppement

TestsTests

ProductionProduction

Mise en œuvreMise en œuvre

MaintenanceMaintenance

Euphorie

Inquiétude

Panique Recherche des coupables

Punition des innocents

Promotion des autres


Différents cycles

Programmer-corriger Cascade simple Cascade modifiée

avec chevauchement avec sous-projets avec réduction des risques

Spirale

Les phases de spécification, conception, tests sont présentes

Le cycle dépend du projet

Prototypage évolutif Livraison par étape Livraison évolutive Conception selon

planning Conception selon outils Logiciel standard


Modèle en spirale


Comparaison des cycles

Capacité du cycle Programmer-corriger

Cascade Spirale Prototypageévolutif

Spécifications mal comprises - 1 - 1 +1 +1

Architecture mal comprise - 1 - 1 +1 - 1/0

Fiabilité (taux de défauts) - 1 +1 +1 0

Capacité d’extension en taille - 1/0 +1 +1 +1

Gestion des risques - 1 - 1 +1 0

Respect du planning - 1 0 0 - 1

Temps d’utilisation efficace +1 - 1 0 0

Possibilités de modifications - 1/+1 - 1 0 +1

Indice d’avancement (client) 0 - 1 +1 +1

Indice d’avancement (projet) - 1 0 +1 0

Faible compétence +1 0 0 - 1


Pathologies des développeurs

pervers

médiocre

bûcheur

planificateur

optimal

1) coder tout de suite 2) jeter logiciel et aller en 1

peu de temps sur conception logiciel fini à 90%, 90% du

temps

planning + conception pas le temps pour les tests

planning + planning pas le temps pour coder

un juste équilibre en tout !


Les algorithmes

Complets Non-ambigus Déterministes Finis Généraux Bien structurés Efficaces


Niveau (approximatif) de langage

Assembleur 1

C 2.5

Fortran 77 3

Pascal 3.5

Ada 83 4.5

C++ 6.5

Visual Basic 3 10

Perl 15

Tableur Excel ~50

on développe à peu près le même nombre de lignes/mois

(la productivité individuelle variant néanmoins de 1 à 10)

donc développement plus ou moins rapide

mais dépend de l’utilisation


Les tests

Les mauvaises excuses pas le temps pas les moyens

techniques pas l’argent

Coût relatif des erreurs suivant la phase

Correction erreur Coût

Étude préalable 1Étude détaillée 3Étude technique 10Réalisation 20Mise en oeuvre 50Maintenance 100


Quels tests ?

unitaires (fonctions)

d’intégration (modules)

systèmes (logiciel)

validation (logiciel)

conception détaillée conception globale spécification cahier des charges

Tests statiques respect architecture respect structure variables commentaires

Tests dynamiques unitaires enchaînement performance stress


Gestion de code

Versionensemble de modules + compilés + linkésgelés en configuration

Domaine public: RCS ou SCCSgestion des versions travail collectifsauvegarde


La documentation

Au minimumdéfinition des besoinsspécification logicielledescription des interfacessources tests (procédures+résultats)manuel utilisateur

La règle ne doit pas se substituer à l’intelligence

volume documentation volume du projet


Critères de qualité

Aptitude à être utilisée en l’étatsûretéefficacitécommodité

Aptitude à être transférée Aptitude à être maintenue

testéecomprisemodifiée


II) Recettes

Réutiliser des composants logicielsdocumentésre-testés!

Écrire des commentaires significatifs Prototyper le programme Avoir un bon environnement de

développement Utiliser des outils de génie logiciel (UML) Porter sur une autre architecture Éviter d’en faire trop!


Modularité

Top-down

Makefileentrée ... (programmes, fichiers) ... Sortie

Gestion des modules avec RCS

Impressions

Sécurité


Écriture

HeaderCC.IDENTIFICATION $Id: main.c,v 1.10 1996/08/30 15:18:53 Durand Exp$C.TYPE programC.LANGUAGE FORTRANC.AUTHOR C. DurandC.ENVIRONMENT UnixC.KEYWORDS magnitude, reddeningC.PURPOSE Calcul du derougissement et de la magnitude absolueC.COMMENT 1.0 19-Feb-1992:C

Utiliser la même tramegérant l ’option -h avec une fonction usage()passage d ’argument sur la ligne de commande

Nombre de lignes fonction:quelques dizainesmodule: quelques centaines


Variables et lisibilité

Une variable a un type Une variable n’a qu’un

type Une variable n’a qu’un

sens Donner des noms

significatifs Convention de nommage Éviter les variables

globales

« implicit none » éviter a=2; a=“oui”; éviter i=k; i=2*i+a; result=3; plutôt que

i=3; gStarFlux (globale)


Erreurs classiques

passage d’argument dépassement de tableau mauvaise initialisation ordre d’évaluation affectation vs

comparaison commentaires mal

fermés fuite de mémoire erreurs aléatoires

utiliser un prototype option compilateur, tests initialiser pointeurs à 0,

tester éviter a[i++]=b[i++] if (3==i) au lieu de (i==3) #idfef COMMENT allouer/désallouer souvent accès mémoire

interdit


Conclusion

La créativité... réussir une opération

complexe construire un outil utile à

soi-même et aux autres acquérir des nouvelles

connaissances … n’exclue pas la

méthode maîtriser ses objectifs et

ses ressources être lié aux autres contraint à la rigueur

Les 4 dimensions d’un projet logiciel

les personnes les méthodes le produit les technologies

Documents

F.A - Méthodologie - DEA - 1 Sensibilisation aux projets logiciels Les projets logiciels + la réalité en chiffres + les cycles de vie + les problèmes +