Sensibilisation aux projets logiciels

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

2. La réalité... • Taux d’échec • 50% des projets n’aboutissent jamais • 25% n’apportent aucune valeur ajoutée aux utilisateurs • Retard • 2/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.

3. ... en chiffres • Défauts • la cause la plus fréquente de dépassement de planning • à l’origine de 50% des abandons de projets • Incompréhension • 65% des projets ont des mésententes avec le client • 10% sont annulés suite à des attentes irréalistes • Efficacité • 40% des erreurs sont générées par le stress • 65% du temps à des activités contre-productrices

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

5. Projet logiciel • logiciel projet logiciel  projet • méthode de développement • structure systématique •  produit logiciel • code • documentation associée •  qualité logicielle

6. Triangle des Bermudes • Le niveau de qualité est un compromis

7. Le cycle de vie • Période entre l’idée du logiciel et sa mise en service • Phases de développement • Spécification des besoins • Conception préliminaire • Conception détaillée • Codage : 15% du travail • Tests unitaires • Tests d’Intégration • Validation • Entouré par spécification et maintenance

8. Cycle en V Expression des besoins Maintenance Spécifications Validation (recette) Conception générale Tests d’intégration Conception détaillée Tests unitaires Réalisation (codage)

9. Cycle en V, caricature ;-) Cahier des charges Maintenance Euphorie Promotion des autres Études Mise en œuvre Inquiétude Punition des innocents Développement Production Panique Recherche des coupables Tests

10. 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 Différents cycles

11. Modèle en spirale

12. Comparaison des cycles

13. 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 ! Pathologies des développeurs

14. Les algorithmes • Complets • Non-ambigus • Déterministes • Finis • Généraux • Bien structurés • Efficaces

15. Niveau (approximatif) de langage • 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

16. Les mauvaises excuses pas le temps pas les moyens techniques pas l’argent Coût relatif des erreurs suivant la phase Les tests

17. unitaires  (fonctions) d’intégration (modules) systèmes (logiciel) validation (logiciel) conception détaillée   conception globale   spécification   cahier des charges Quels tests ? • Tests statiques • respect architecture • respect structure • variables • commentaires • Tests dynamiques • unitaires • enchaînement • performance • stress

18. Gestion de code • Version • ensemble de modules + compilés + linkés • gelés en configuration • Domaine public: RCS ou SCCS • gestion des versions • travail collectif • sauvegarde

19. La documentation • Au minimum • définition des besoins • spécification logicielle • description des interfaces • sources • tests (procédures+résultats) • manuel utilisateur • La règle ne doit pas se substituer à l’intelligence • volume documentation  volume du projet

20. Critères de qualité • Aptitude à être utilisée en l’état • sûreté • efficacité • commodité • Aptitude à être transférée • Aptitude à être maintenue • testée • comprise • modifiée

21. II) Recettes • Réutiliser des composants logiciels • documentés • re-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!

22. Modularité • Top-down • Makefile • entrée ... (programmes, fichiers) ... Sortie • Gestion des modules avec RCS

23. Écriture • Header C C.IDENTIFICATION $Id: main.c,v 1.10 1996/08/30 15:18:53 Durand Exp$ C.TYPE program C.LANGUAGE FORTRAN C.AUTHOR C. Durand C.ENVIRONMENT Unix C.KEYWORDS magnitude, reddening C.PURPOSE Calcul du derougissement et de la magnitude absolue C.COMMENT 1.0 19-Feb-1992: C • Utiliser la même trame • gérant l ’option -h avec une fonction usage() • passage d ’argument sur la ligne de commande • Nombre de lignes • fonction: quelques dizaines • module: quelques centaines

24. 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) Variables et lisibilité

25. 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 Erreurs classiques

26. 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 Conclusion