La Crise de logiciel - PowerPoint PPT Presentation

1 / 14
About This Presentation
Title:

La Crise de logiciel

Description:

La revue IEEE Software a signal que les programmeurs de la NASA taient nerveux ... Ajouter des personnes un projet de logiciel en retard ne fait que ... – PowerPoint PPT presentation

Number of Views:152
Avg rating:3.0/5.0
Slides: 15
Provided by: campusd
Category:

less

Transcript and Presenter's Notes

Title: La Crise de logiciel


1
La Crise de logiciel
  • La sophistication du matériel informatique a
    dépassé notre capacité d'établir un logiciel qui
    peut utiliser le potentiel du matériel.
  • Notre capacité de concevoir de nouveaux
    programmes ne peut pas suivre la demande de
    nouveaux programmes et notre capacité de mettre à
    jour des programmes existants est menacée par de
    pauvres conçeptions et des ressources
    insatisfaisantes.

2
La Crise de logiciel
  • La revue IEEE Software a signalé que les
    programmeurs de la NASA étaient nerveux pendant
    la première mission de la navette spatiale
    Discovery après le désastre de Challenger.
    Pendant le vol de septembre de Discovery il y
    avait seulement un problème visible. Trente
    secondes de données en temps réel non critiques
    de télémétrie ont été détruites. On a découvert
    plus tard que cette erreur était due à un
    problème dans l'étape des besoins du procédé de
    développement de logiciel. C'était le seul
    nouveau défaut de logiciel détecté sur ce vol,
    mais étonnamment, la navette vole réellement avec
    beaucoup d'erreurs connues de logiciel. L'arriéré
    moyen des erreurs connues est environ 1,800.

3
La Crise de logiciel
  • Unisys tient le contrat de la NASA pour mettre à
    jour et supporter 14 millions de lignes de
    logiciel au sol pour la navette spatiale. Chaque
    changement fait à la navette réelle exige les
    changements de logiciel appropriés des
    simulateurs de navette et des systèmes au sol. Il
    y avait 3,800 changements de condition faits au
    logiciel après la perte de Challengeur. Ces
    changements ont eu comme conséquence 900
    révisions de logiciel, desquelles 30 appliqués au
    centre de commande de mission

4
Lacune de logiciel
  • Le développement de logiciel a tombée derrière le
    développement du matériel informatique.
  • Le logiciel d'application pour de nouveaux
    paradigmes (modèles) est grand et complexe et un
    tel codage exige des équipes de programmeurs et
    des semaines ou années de temps d'écriture.
  • L'industrie de logiciel modulaire a de la
    difficulté à livrer leurs produits en temps
    interrogez juste Microsoft au sujet de Windows
    2000!
  • Une grande partie de ce problème est un résultat
    des développeurs essayant de produire des
    logiciels massifs avec de vieux outils, méthodes
    périmées et techniques de gestion
    insatisfaisantes.

5
Problèmes qui affligent le développement de
logiciel
  • L'information n'a pas été rassemblé sur le
    procédé de développement de logiciel.
  • Sans indication de la productivité, il ne peut
    pas y avoir d'évaluation précise de l'efficacité
    de nouveaux outils, de méthodes ou de normes.
  • Le mécontentement du client en ce qui concerne le
    système réalisé est fréquemment rencontré.
  • Le développement de logiciel est entrepris
    souvent avec seulement une notion vague des
    exigences du client.
  • La qualité du logiciel est souvent suspecte.
  • Souvent il n'y a aucun contrôle systématique et
    complet de testing de logiciel et c'est seulement
    récemment que des concepts quantitatifs solides
    de la fiabilité de logiciel et de l'assurance de
    qualité a commencé à émerger.
  • Il peut être difficile de mettre à jour le
    logiciel existant.
  • L'entretien de logiciel compte pour la majorité
    de tous les budgets de logiciel. L'entretien de
    logiciel n'a pas été souligné en tant que critère
    important pour l'acceptation de logiciel.

6
Mythes de logiciel - gestion
  • Normes et procédures existent déjà pour produire
    le logiciel.
  • Des normes sont rarement utilisées.
  • Les développeurs les savent rarement eux-mêmes.
  • Les normes sont souvent démodées et incomplets.
  • Le matériel moderne est l'ingrédient essentiel
    pour la réussite de production de logiciel.
  • Les outils de logiciel, pas matériel, sont
    habituellement plus important pour atteindre la
    qualité et la productivité.
  • Si nous obtenons du retard, nous pouvons toujours
    ajouter plus de programmeurs et rattraper le
    temps perdu.
  • Le développement de logiciel n'est pas un
    processus mécanistique comme la fabrication.
    Ajouter des personnes à un projet de logiciel en
    retard ne fait que retardé le projet. Cette
    vérité a été découverte la première fois par F.
    Brooks (le Mois-Homme mythique) en 1975! Des
    nouveaux venus doivent être instruits
    (habituellement par ceux travaillant déjà sur le
    projet) réduisant de ce fait la quantité de temps
    dépensée sur l'effort productif de développement.

7
Mythes de logiciel - Client
  • Un énoncé général des objectifs est suffisant
    pour commencer des écritures de programmes les
    détails peuvent être complétés plus tard.
  • La connaissance insuffisante au sujet des besoins
    est la cause principale des efforts de logiciel
    échoués. Des descriptions formelles et détaillées
    des données, de la fonctionnalité, des
    contraintes de conception et des critères de
    validation sont essentielles. La transmission
    entre le client et le développeur est
    essentielle.
  • Les besoins de projet changent continuellement,
    mais le changement peut être facilement accordé
    parce que le logiciel est flexible.
  • L'impact du changement varie avec le temps auquel
    il est présenté.
  • Des demandes tôt de changement peuvent être
    accordé facilement et à bon marché.
  • Des changements faits pendant la conception, la
    mise en place et l'installation ont un impact
    grave sur le coût.

8
Mythes de logiciel - Développeur
  • Une fois le programme écrit et fonctionnel, le
    travail est fini.
  • Entre 50 et 70 pour cent de tout l'effort déployé
    sur un programme sera dépensé après qu'il soit
    remit au client.
  • Jusqu'a ce que le programme fonctionne, il
    n'existe aucune méthode d'évaluer sa qualité.
  • Un des mécanismes les plus pertinents d'assurance
    de la qualité de logiciel est la revue technique
    formelle et ceci peut être appliqué à partir du
    commencement du projet.
  • Le seul livrable est le(s) program(s)
    fonctionnel(s).
  • Un programme fonctionnel est seulement une partie
    d'une configuration de logiciel qui inclut des
    besoins et des documents de spécifications, de
    l'informa-tion de test et toute autre information
    développementale et d'entretien.

9
Contrôle de qualité et Mise en oeuvre
  • Objectif de conception ? Fiabilité
  • Un système fiable est celui qui ne présente pas
    de défaillances dangereuses ou coûteuses
    lorsquon lutilise dune façon considérée comme
    normale
  • Deux niveaux de fiabilité
  • Répondre correctement aux besoins des
    utilisateurs
  • Le fonctionnement du système livré à
    lutilisateur
  • Différence entre erreur et défaut
  • Il y a erreur lorsque le système ne produit pas
    la sortie attendue
  • Il y a défaut lorsque la présence dune erreur de
    logiciel produit des résultats avec un
    coefficient de gravité.

10
Fiabilité de système
  • Trois façons daborder la fiabilité
  • Prévention des erreurs
  • prevenir purement et simplement les erreurs
  • Détection et correction des erreurs
  • Tolérance des erreurs
  • Redondance du matériel
  • Traitement dégradé
  • Causes des erreurs
  • Conception
  • Production
  • Défaillances du matériel

11
Maintenance des systèmes
  • Commentaires sur la maintenance
  • 70 à 90 des dépenses totales de logiciel sont
    consacrées à la maintenance pendant la vie du
    sytème
  • La maintenance est souvent de mauvaise qualité
  • La demande de logiciel croît a un rythme plus
    rapide que loffre
  • Correction 20
  • Adaptation 20
  • Perfectionnement 60
  • Règles pour réduire la maintenance future
  • Définition plus précise des besoins pendant le
    développement
  • Réalisation dune meilleure documentation
  • Meilleurs méthodes de conception et de
    communication
  • Meilleure utilisation des techniques et des
    outils existants
  • Gestion efficace du processus de conception du
    système

12
Techniques de conception
  • Structure de Haut en Bas
  • Modularité
  • Outils de conception de logiciel et documentation
  • Organigrammes structurés
  • HIPO
  • Diagramme HIPO
  • Table des matières visuelle
  • Diagrammes fonctionels
  • Diagrammes de Warnier/Orr

13
Contrôle de qualité
  • Niveaux de contrôle
  • Test
  • est une opération dessai dun système coûteuse
    mais indispensable
  • Vérification
  • trouver les erreurs
  • Validation
  • utiliser le logiciel dans un environnement réel
    pour détecter les erreurs
  • Certification
  • témoigne du fait que le programme est correct

14
Méthodes de test
  • Test de programmation
  • Examiner la logique du programme
  • Test de spécifications
  • Ce que le programme doit faire
  • Techniques de test
  • Test dunité
  • tester les programmes qui constituent un système
  • localiser les erreurs dans les modules et
    routines
  • Test de système
  • Tester lintégration des diver modules
  • recherche les différences entre le système et
    lobjectif original, les spécifications et la
    documentation
  • Test de système spéciaux
  • Période de pointe, performance, capacité de
    stockage, reprise, etc..
Write a Comment
User Comments (0)
About PowerShow.com