sensibilisation aux projets logiciels l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Sensibilisation aux projets logiciels PowerPoint Presentation
Download Presentation
Sensibilisation aux projets logiciels

Loading in 2 Seconds...

play fullscreen
1 / 26

Sensibilisation aux projets logiciels - PowerPoint PPT Presentation


  • 172 Views
  • Uploaded on

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’échec 50% des projets n’aboutissent jamais

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Sensibilisation aux projets logiciels' - velvet


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
sensibilisation aux projets logiciels
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
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.
en chiffres
... 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
des toiles et des bugs
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
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
Triangle des Bermudes
  • Le niveau de qualité est un compromis
le cycle de vie
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
cycle en v
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)

cycle en v caricature
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

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

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

Pathologies des développeurs
les algorithmes
Les algorithmes
  • Complets
  • Non-ambigus
  • Déterministes
  • Finis
  • Généraux
  • Bien structurés
  • Efficaces
niveau approximatif de langage
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
les tests
Les mauvaises excuses

pas le temps

pas les moyens techniques

pas l’argent

Coût relatif des erreurs suivant la phase

Les tests
quels tests
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
gestion de code
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
la documentation
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
crit res de qualit
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
ii recettes
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!
modularit
Modularité
  • Top-down
  • Makefile
    • entrée ... (programmes, fichiers) ... Sortie
  • Gestion des modules avec RCS
criture
É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
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)

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

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

Conclusion