Sensibilisation aux projets logiciels Les projets logiciels la
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 F. A - Méthodologie - DEA - 1
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% des cas, le planning est établi avant les spécifs. F. A - Méthodologie - DEA - 2
. . . 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 F. A - Méthodologie - DEA - 3
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. . . F. A - Méthodologie - DEA - 4
Projet logiciel projet méthode de développement structure systématique produit logiciel code documentation associée qualité logicielle F. A - Méthodologie - DEA - 5
Triangle des Bermudes Le niveau de qualité est un compromis F. A - Méthodologie - DEA - 6
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 F. A - Méthodologie - DEA - 7
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) F. A - Méthodologie - DEA - 8
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 F. A - Méthodologie - DEA - 9
Différents cycles Programmer-corriger Cascade simple Cascade modifiée avec chevauchement avec sous-projets avec réduction des risques Spirale Prototypage évolutif Livraison par étape Livraison évolutive Conception selon planning Conception selon outils Logiciel standard Les phases de spécification, conception, tests sont présentes î Le cycle dépend du projet F. A - Méthodologie - DEA - 10
Modèle en spirale F. A - Méthodologie - DEA - 11
Comparaison des cycles F. A - Méthodologie - DEA - 12
Pathologies développeurs pervers 1) coder tout de suite 2) jeter logiciel et aller en 1 peu de temps sur conception logiciel fini à 90%, 90% du temps médiocre bûcheur planificateur planning + planning pas le temps pour coder optimal un juste équilibre en tout ! planning + conception pas le temps pour les tests F. A - Méthodologie - DEA - 13
Les algorithmes Complets Non-ambigus Déterministes Finis Généraux Bien structurés Efficaces F. A - Méthodologie - DEA - 14
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 F. A - Méthodologie - DEA - 15
Les tests Les mauvaises excuses pas le temps pas les moyens techniques pas l’argent Coût relatif des erreurs suivant la phase F. A - Méthodologie - DEA - 16
Quels tests ? unitaires d’intégration systèmes validation (fonctions) conception détaillée (modules) conception globale (logiciel) spécification (logiciel) cahier des charges Tests statiques respect architecture respect structure variables commentaires Tests dynamiques unitaires enchaînement performance stress F. A - Méthodologie - DEA - 17
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 F. A - Méthodologie - DEA - 18
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 F. A - Méthodologie - DEA - 19
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 F. A - Méthodologie - DEA - 20
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! F. A - Méthodologie - DEA - 21
Modularité Top-down Makefile entrée. . . (programmes, fichiers). . . Sortie Gestion des modules avec RCS F. A - Méthodologie - DEA - 22
Écriture Header C C. IDENTIFICATION C. TYPE C. LANGUAGE C. AUTHOR C. ENVIRONMENT C. KEYWORDS C. PURPOSE C. COMMENT C $Id: main. c, v 1. 10 1996/08/30 15: 18: 53 Durand Exp$ program FORTRAN C. Durand Unix magnitude, reddening Calcul du derougissement et de la magnitude absolue 1. 0 19 -Feb-1992: 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 F. A - Méthodologie - DEA - 23
Variables et lisibilité Une variable a 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; g. Star. Flux (globale) F. A - Méthodologie - DEA - 24
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 F. A - Méthodologie - DEA - 25
Conclusion La créativité. . . réussir une opération complexe construire un outile à 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 F. A - Méthodologie - DEA - 26
- Slides: 26