Un article dans Sciences&Vie sur les bugs (février - N° 1121)  

Forum ouvert à toute discussion autour de la photographie, le panorama, ou encore informatique et photo.
no avatar
GURL
Member
 
Posts: 2946
Joined: Tue Dec 06, 2005 1:57 pm
Location: Grenoble

Un article dans Sciences&Vie sur les bugs (février - N° 1121)

by GURL » Thu Jan 27, 2011 8:16 pm

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.)
Georges

User avatar
AlexandreJ
Kolor Team
 
Posts: 5911
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Fri Jan 28, 2011 9:38 am

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

User avatar
fma38
Member
 
Posts: 5827
Joined: Wed Dec 07, 2005 6:21 pm
Location: Grenoble, France

by fma38 » Fri Jan 28, 2011 5:51 pm

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)
Frédéric

Canon 20D + 17-40/f4 L USM + 70-200/f4 L USM + 50/f1.4 USM
Merlin/Orion panohead + Papywizard on Nokia N800 and HP TC-1100

no avatar
GURL
Member
 
Posts: 2946
Joined: Tue Dec 06, 2005 1:57 pm
Location: Grenoble

by GURL » Fri Jan 28, 2011 7:23 pm

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

User avatar
AlexandreJ
Kolor Team
 
Posts: 5911
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Mon Jan 31, 2011 11:58 am

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/Barcelona2010_Press.aspx?page=agenda

User avatar
fma38
Member
 
Posts: 5827
Joined: Wed Dec 07, 2005 6:21 pm
Location: Grenoble, France

by fma38 » Mon Jan 31, 2011 12:23 pm

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 on Mon Jan 31, 2011 12:23 pm, edited 1 time in total.
Frédéric

Canon 20D + 17-40/f4 L USM + 70-200/f4 L USM + 50/f1.4 USM
Merlin/Orion panohead + Papywizard on Nokia N800 and HP TC-1100

no avatar
GURL
Member
 
Posts: 2946
Joined: Tue Dec 06, 2005 1:57 pm
Location: Grenoble

by GURL » Mon Jan 31, 2011 6:24 pm

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/Barcelona2010_Press.aspx?page=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.)
Georges


Return to Discussions libre

Who is online

Users browsing this forum: No registered users and 1 guest