 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | Rules | You are not logged in.
Les utilisateurs sont toujours un peu surpris quand il y a un bug dans un programme, les programmeurs le sont toujours un peu quand leur programme semble fonctionner correctement, l'article en question parvient à donner une vue d'ensemble de la situation...
EXEMPLES
Le réseau téléphonique longue distance d'AT&T qui s'effondre, 50 millions d'appels perdus à cause d'une parenthèse mal placée (à localiser dans 3 millions de lignes de code.) - Le projet américain d'automatisation du trafic aérien, débuté en 1981, n'a toujours pas abouti. - Lors du vol inaugural d'Ariane 5 la fusée dévie de sa trajectoire et doit être détruite. - La station spaciale internationnale a reconnu 500 bugs. - Microsoft observe entre 1 et 10 bugs pour 1000 lignes de code, il y a 50 millions de lignes de code dans Windows Vista donc au minimum 50 000 bugs.
VERIFICATION
A la NASA cette tâche occupe 88% du temps contre 12% consacré à l'écriture. - D'une manière générale pour 32% de projets réussis on compte 44% de projets en difficulté et 24% de projets abandonnés.
CA VA S'ARRANGER ?
La taille des équipes ne peut croître significativement sans perdre d'efficacité. - Nous n'avons jamais cessé de bâtir des systèmes qui dépasse le cadre de notre savoir théorique. - Entre le potentiel offert de nos jours par le matériel informatique et notre maîtrise intellectuelle le fossé est en train de s'élargir. - Processeurs à plusieurs coeurs (plusieurs algorithmes fonctionnent en même temps) : nous n'avons pas encore trouvé d'algorithme de programmation adapté, et nous ne sommes pas sur d'y arriver un jour...
Tout ceci étant dit - l'article est bien sur beaucoup plus détaillé que ce qui précède et sa force viens de la multitude d'exemples et de citations qu'il comporte - ça fait plus d'un demi siècle qu'ont retenti les premières alertes démontrant que l'édifice ne pourrait manquer de s'effondrer s'il continuait à reposer sur des fondations aussi fragiles. On peut en conclure que personne n'a compris pourquoi ça marche (quand ça marche.)
Offline
C'est tout à fait juste Georges.
Maintenant, avant d'arriver à des cas aussi extreme, en tant que développeur, il y a beaucoup de techniques qui peuvent être mise en place pour améliorer la qualité du code et la qualité du soft final :
- revue de code
- unit testing
- QA
Offline
C'est clair que les techniques de dev. ont énormément évoluées ces dernières années, et que les gens qui prennent la peine de les mettre en oeuvre ont beaucoup moins de problèmes ;o)
Offline
Un aspect intéressant de l'article est de prévoir qu'il continuera à y avoir autant de bugs même si la vérification et le reste font des progrès parce que le progrès du hardware permet de faire des choses de plus en plus compliquées. Les théoriciens paniquent parce qu'ils ne maîtrisent pas le parallélisme.
Ce que je me demande souvent c'est ce qu'en pensent ceux qui n'ont aucune raison de s’étonner qu'un logiciel fonctionne bien. D'accord il y a des bugs partout et ils ont eu le temps de s'y habituer, m'enfin...
Offline
GURL wrote:
Les théoriciens paniquent parce qu'ils ne maîtrisent pas le parallélisme.
Je veux pas me jeter des fleurs, mais on maitrise bien cet aspect. Intel nous a même classé dans les 'rock star' developer sur le sujet :
http://softwareproductconference.com/Ba … age=agenda
Offline
Je me suis mis il y a quelques temps à développer sur des FPGA (pour le boulot) : là, tout est parallélisme, ou presque ! Du coup, quand tu reviens à la programmation séquentielle, le thread, ça ne fait plus peur 
Peut-être faudrait-il mixer les équipes de développement hard et soft...
Last edited by fma38 (2011-01-31 12:23:23)
Offline
AlexandreJ wrote:
GURL wrote:
Les théoriciens paniquent parce qu'ils ne maîtrisent pas le parallélisme.
Je veux pas me jeter des fleurs, mais on maitrise bien cet aspect. Intel nous a même classé dans les 'rock star' developer sur le sujet :
http://softwareproductconference.com/Ba … age=agenda
En fait il est question dans l'article d'outils d'analyse formelle ("fastidieux, 100 à 1000 fois plus coûteux" même s'ils évitent un nombre infini d'essais) qui permettent de vérifier un programme sans le faire tourner. Hélas, quand il y a plusieurs algorithmes qui tournent en parallèle aucune méthode de vérification n'a été trouvée (et ça concerne aussi les réseaux!)
fma38 wrote:
Peut-être faudrait-il mixer les équipes de développement hard et soft...
J'ai participé (en autre en écrivant la notice pour les programmeurs ) à l'implémentation hardware de sémaphores à la mode Dijskra sur un ordinateur destiné à la conduite de process (sans lesquels les actions prioritaires démolissaient de temps en temps les ressources des actions moins prioritaires.) Les relations avec l'équipe hardware sont restées bonnes mais elle a insisté pour ne pas accorder sa validation à ma description des choses: les points de vue étaient trop différents, l'équipe hard savait exactement comment ça marchait mais ne s'intéressait pas à la manière de l'utiliser (et inversement.)
Offline
