Discussion :

[souviron34]

Avec ce titre volontairement provocateur, je voudrais lancer un débat car la situation me semble……. Malheureusement relativement correspondre au titre….

Je ne vais pas être exhaustif, mais faire en gros :


Historique :

1944 Von Neumann invente le « premier » ordinateur (ou son principe tout du moins)

Années 60-70 :
Matériels : une quinzaine de constructeurs
OS : un OS par constructeur, voire par type de machines
Langages : les scientifiques utilisent FORTRAN, les universitaires C, les banques assurances et autres COBOL.

Fin 70 : le MIT solutionne la communication inter-ordinateur et le donc le
transfert de fichier (Kermit)
Fin 70 : le MIT , plus DEC,IBM,Sun,HP collaborent pour résoudre le problème
d’inter-opérabilité graphique (Projet Athena, ancêtre de XWindow)
Debut 80 : * le MIT , plus DEC,IBM,Sun,HP collaborent et mettent au point
un standard de communication graphique (Xwindow).
* Sur la base de Kermit, le transfert de fichier devient
transparent (ftp)
Années 80 : petit à petit solution d’un OS commun (Unix) existant en 2 puis
3 versions : Unix, POSIX, SystemV
Debut 90 : * le CERN définit un protocole commun d’interconnection
téléphonique (http) pour éviter les différents réseaux nationaux
(Datapac, Europac etc..)
* le CERN définit un langage commun de présentation de
documents (HTML)
* le NCSA définit une interface générale de présentation de
documents suivant HTML (Mosaic)

A part la mode Pascal dans la 2ième moitié des années 80 (liée d’ailleurs à l’utilisation de PC/AT), les langages utilisés restent les mêmes jusqu’au milieu/fin des années 90.

Le mouvement général est donc vers une unification des « processus » :

- langages éprouvés, peu évolutifs
(exemple Fortran, 1 révision/10 ans, 20 ans d’avance pour les éliminations de fonctions ou mots)
- communication unifiée des fichiers (ftp)
- gestion unifiée des ordinateurs (Unix et ses dérivés)
- gestion unifiée des interfaces graphiques (Xwindow, puis Motif)
- gestion unifiée de la communication entre 2 ordinateurs (http)
- gestion unifiée de la description de documents (HTML)
- gestion unifiée de la présentation de documents (Mosaic)

Sauf pour les Pcs, où il n’y a pas d’interface graphique jusqu’à fin des années 80 (DOS). Puis système mono-utilisateur, système propriétaire, fermé…

Pour parer à cette fermeture, développement de Linux par Linus Thornvald., portage de Unix pour les Pcs. Parallèllement, développement sur Win.. d’une foultitude de produits et de langages (VB, Delphi, VC++, IE , ….).

Or maintenant que vois-t-on ?

1) Il semble que la pérennité dûe à la stabilité de Unix soit battue en brêche par Linux (différentes distributions, versions pas forcément compatibles, 1 version par an (au moins !!!)
2) Il semble que la multiplicité des logiciels/langages apparus pour Windows soit reprise sous Unix/Linux pour les interfaces graphiques : maintenant avec Java, VC++, GTK+, …… plusieurs sets de Widgets, aussi avec versions différentes, langages, là aussi sans suivi dans le temps
3) On demande maintenant des gens correspondant aux éléments/langages précis, et non généraux :
Regardez les annonces « Ingénieur NetBeans » « architecte Eclipse » …..
Et chaque fois qu’un nouveau « truc » sort, les anciens sont jetés….

Nous allons donc dans le sens contraire de la gestion unifiée et de l’indépendance vis à vis des constructeurs…

Et quand on nous présente une solution comme étant portable, soit elle se superpose à un standard déjà éprouvé (voir Java / X/Motif), soit elle n’ajoute rien en soi que de l’incompatibilé avec les softs antérieurs (C++)..

(pour réflexion : XWindow/Motif, sorti il y a 25 ans, n’a subi que 2 révisions majeures, qui n’ont correspondu qu’à des AJOUTS , et AUCUNE modification des versions antérieures, ce qui fait qu’un logiciel créé en 1984 tourne toujours aujourd’hui……..)

(PS : il est à noter également que la profession des informaticiens a également elle-même participé à ça, pour des raisons que je supputerais être de confort : se créer son propre travail…. En effet, je me souviens d’un temps où gérer un parc de 150 machines avec VMS n’occupait qu’une personne à mi-temps (fin des années 80))


Voilà…

Il me semble donc que l'on est en plein dans la société de consommation, avec des biens (logiciels) jetables, et du coup des dépenses gigantesques et du temps perdu à ré-écire, re-transformer, ré-adapter, re-tester....

[Edit] Donc une des questions que j'aimerais vous poser est :

Peut-on s'opposer à la dégradaton de l'unification des systèmes et interfaces (provenant en grande partie du monde PC) ?

Par exemple pourquoi ne promeut-on pas l'utilisation de X/Motif pour les IHM (reconnu, éprouvé, répondant à tous les besoins en graphisme) ?? Quitte à demander et/ou développer une version Windows, et à rajouter un widget PHP ou Flash.... Au lieu de prendre de nouveaux outils, à qui il faudra au moins 10 ans pour arriver à maturité (voir les widgets de Java ou de wxwidgets comparés à ceux de Motif), et qui nécessite de re-fournir l'effort (et il fut considérable) ayant présidé à l'avènement de X ?

Mais il y a bien d'autres questions du même style....

[/Edit]


J’attend vos commentaires/réflexions, car la pente me semble dangereuse…

[souviron34]

je rajouterais une petite précision :

Sans reprendre le tread "Pour ou contre 'l'Open source ?" (http://www.developpez.net/forums/showthread.php?t=4637)
l'argument principal des partisans est de ne pas ré-inventer la roue...

Or il me semble que c'est justement ce qui se passe.... Nouveaux langages, nouveaux widgets, nouveaux paradigmes, nouvelles philosophies...

Je ne suis pas contre le progrès, entendez-bien...

Mais maintenant l'nformatique est dans nos vies au même titre que l'electricité ou l'automobile...

Si chaque fabricant de matériel éléctroménager avait SES propres composants et SES propres prises, ou si chaque fabricant automobile avait SA propre conception d'un moteur a explosion, comment ferais-t-on ? (déjà aujourdhui avec l'électronique embarquée je ne vous souhaite pas de tomber en panne dans un trou perdu.... [je suis pour la 2CV n'importe qui peut réparer avec un morceau de fil de fer]

Or je pense que c'est ce qui est en train de se passer en informatique...
Et que du coup on oublie le fond pour ne penser qu'à la forme...

Et je voulais juste connaître (car c'est à tous les niveaux que le problème se situe, aussi bien des décideurs que des chefs de projets) votre opinion là-dessus...

[Caine]

Bonjour, ton historique est intéressante bien qu'un peu trop résumée sur Windows mais passons.

En tant qu'ingénieur de développement, ces dernières années j'ai aussi le sentiment d'un trop plein de nouvelles technologies. Surtout que comme tu l'indiques on recherche des profils spécialisés sur celles-ci.


Mais il faut aussi voir que ces technologies répondent à une évolution des besoins des entreprises. Par exemple Java répond (cet mon avis) à la monté en puissance des parts de marchés Linux. Les entreprises craignent à cette époque d'avoir à coder en double leurs applications et donc de multiplier par deux leurs coûts de dév. Java sort alors du chapeau de Sun et permet avec un code source unique de déployer une appli sur Windows et Unix.

Dans un sens, je trouve que c'est plutôt une unification non?

La où je trouve plus un effet de mode (et sûrement car ce n'est pas mon domaine de dev), c'est le Web 2.0 parti d'un beau titre dans un livre et devenu obligatoire en moins d'une année!

Un autre exemple est l'UML. Les RH pensent qu'un ingénieur qui ne possède pas cette méthode ne sait pas concevoir! Inquiétant de constater que les RH reprennent l'argument marqueting d'UML.

J'ai pour ma part constaté ce phénomène; de plus en plus, les entreprises courent après toutes les nouveautés. Elles misent alors sur l'embauche de jeunes diplômés à la place de la formation des "oldies" (à même pas 35 ans ça fait mal).

Je sens que le débat va être long

[souviron34]

Java sort alors du chapeau de Sun et permet avec un code source unique de déployer une appli sur Windows et Unix.

Dans un sens, je trouve que c'est plutôt une unification non?
....


Un autre exemple est l'UML. Les RH pensent qu'un ingénieur qui ne possède pas cette méthode ne sait pas concevoir! Inquiétant de constater que les RH reprennent l'argument marqueting d'UML.

Pour la première partie, même si je vais me répeter un peu, en termes de langages compilés, XWindow était ce me semble très portable.. Et fait pour.. C'est juste que sur les PC il n'y avait (jusqu'il y a peu) que SCO qui l'avait porté. En termes de langages non compilés, il me semblait que tcl/tk faisait bien l'affaire pour un truc portable, puisque la seule restriction était (voir ci-dessus) le portage de X sur Windows... Donc là on détruit tout, on redémarre autre chose, en éspérant qu'on va mieux faire..... Moi je trouve ça désespérant..

Quant à la seconde partie, je suis entièrement d'accord avec toi... J'i l'impression qu'on oublie le TRAVAIL à faire, et qu'on se focalise sur MODELISER le travail...

Sur les gros projets sur lesquels j'ai travaillé, il m'a semblé que quand il y avait des grosses équipes, elles passaient leur temps à FAIRE DU PAPIER (en particulier penser à ce qu'il faudrait qu'elles fassent) au lieu de FAIRE le boulot...

Mais justement je voulais savoir si il n'y avait que moi, ou si le sentiment était partagé.. Car dans ce cas je pense qu'il faudrait remuer pas mal les décisonnaires et DRH...

[yann2]

Bonsoir

Intéressant.

Je vous avoue que je n'ai pas assez de recul par rapport à ce que je vais dire car je n'ai pas encore assez d'expérience.

Pour moi, la multitude des technologies proposées n'est pas du tout une régression. Chacune permet de répondre efficacement à un problème donné (l'informatique est vaste).

Nous allons donc dans le sens contraire de la gestion unifiée et de l’indépendance vis à vis des constructeurs…

C'est là que l'on voit que cette multitude des technologies compliquent le travail des décideurs. Devoir parier sur quelque chose et en être dépendant.

Par contre il y a un mauvais exemple que vous avez cité : UML
Ce langage définie par l'OMG est là pour unifier (comme son nom l'indique d'ailleurs) les langages de modélisation (ce qui répond à la question de départ). Associer avec l'approche MDA, UML devient un langage de premier choix.

L'approche MDA introduit la notion de PIM (Platform Independent Model) et PSM (Platform Specific Model)

Et que du coup on oublie le fond pour ne penser qu'à la forme...

Le PIM (le fond) est un modèle qui représente un système indépendemment des technologies utilisées pour le mettre en oeuvre

Le PSM est un modèle qui représente un système ainsi que les technologies qui permettent sa mise en oeuvre.

PM (la forme) (Platform Model) est le modèle d'une plateforme (cad "les technologies" dans ce qui est dit plus haut).

Ainsi : PIM + PM = PSM.

Les PIM sont donc des modèles pérennes qui peuvent être exprimés à l'aide d'UML.

Modéliser le travail à faire est une nécessité pour des projets impliquant plusieurs personnes.

De plus, l'architecture orienté service (client - prestataire) est une solution pour faire communiquer différents blocs applicatifs, ceci indépendemment des technologies utilisées dans chaque bloc.

Donc la multiplicité (et même la redondance) des technologies, je suis pour. J'aime bien avoir le choix.

yann

[gangsoleil]

Bonjour,

Je pense que le problème ne vient pas de la volonté d'unfier la modélisation masi de la volonté de trop modéliser...

Lorsque je souhaites faire Makefile pour compiler un projet, la modélisation n'est pas utile. Et pourtant, dans certaines grosses boites, on va me demander de modéliser tout, jusqu'au makefile.

Alors je sais, j'exagère (volontairement), mais c'est juste pour enfoncer le clou.

Sinon, je suis d'accord pour dire que nous sommes dan sune phase de spécialisation à outrance, ce qui pose de nombreux problèmes.

Java est portable ? Oui, mais du code prévu pour Java 1.3 risque d'avoir de graves soucis pour tourner sur Java 1.5.... Je fais quoi, je ré-écris tout ? Je fais juste un portage à coup de rustines ?
Dans tous les cas, j'ai perdu du temps, alors que mon but était à la base d'en gagner.

Je suis pour l'uniformisation, mais cela demande une certaine rigueur, qui n'est plus de mise aujourd'hui.
De même, on parle de réutilisabilité du code, mais je constate que cela est globalement faux et peu utilisé. Ah si, c'est utilisé dans le sens où si j'écris une librairie propriétaire, je risque de la réutiliser dans un de mes futurs codes. Mais cette librairie existera surement en deux ou trois exemplaires au sein de l'entreprise, car chacun va redévelopper la sienne, soit par simple manque de communication, soit parce que cette brique en correspond pas exactement à ce que souhaite la voisin, et donc plutot que d'apporter des fonctionalités à l'existant, autant en recréer une !

Mon problème est de savoir à quel niveau il faudrait intervenir pour pouvoir faire avancer les choses dans le bon sens.

[souviron34]

je n'ai jamais utilisé UML, bien que je le voie partout...

Mais je ne citerais que 2 exemples :

- ISO9001 : cette norme est censée garantir que le processus est reproductible... Elle ne garanti pas cependant qu'il produit ce qui était désiré... Si à la conception on a produit une m.rde, tout ce que cela garanti est qu'on repoduira exactement cela autant de fois qu'on le souhaite

J 'ai beaucoup travaillé en ergonomie des IHM, et c'est malheureusement ce qui se passe dans un bon nombre de cas...

- CMM, CMMI, ou l'équivalent... : cette norme est censée définir des niveaux de maturité, et donc également de prise en compte des imprévus..
En regardant les retards du nouvel Airbus (alors que je suis prêt à parier que tout le monde du haut en bas doit utiliser CMM), on peut se poser des questions (puisque même la direction générale découvre qu'il y aura 2 ans de retard....)

[Caine]

Juste un petit bémole sur les normes:
- ISO9001 garanti que le processus de développement est maîtrisé. Chaque metiers entrant en jeu dans le développement du produit fini se base sur des procédures écrites plus que sur l'empirisme ou la rustine personnelle. Elle se base sur la tenue rigoureuse d'une version de documents pour chaque étapes du développement, avec un statut allant jusqu'à "Valider". Mais le processus devrait être évolutif: Par interview de chaques acteurs, par enquête de satisfaction du client. Ceci aboutit normalement, chaque année à une mise à jour des procédures.

Mais voilà, trop souvent cette évolutivité se fige trop vite.

- CMMI donne des outils pour mesurer le niveau de maturité du cycle de vie d'un projet dans son ensemble. Elle ne garanti pas que tous les documents produits son correctements analysés.

Pour le reste, nous nous éloignons même si vos remarques sont intéressantes et que je les partage.

Tient, la réutilisation du code source et des modèles de conception tombe bien dans le débat non ?

[souviron34]

Juste un petit bémole sur les normes
...

Bien sûr... En général ce n'est pas la norme qui est mauvaise, c'est sa mise en oeuvre.. Mais la tendance est donc qu'au lieu de diagnostiquer ça, on en refait une ou au contraire on dit que puisque on l'applique tout est bon et que donc quelqu'un qui ne l'applique pas est forcément pas bon

Tient, la réutilisation du code source et des modèles de conception tombe bien dans le débat non ?

Absolument, oui...

[gl]

Bien sûr... En général ce n'est pas la norme qui est mauvaise, c'est sa mise en oeuvre.. Mais la tendance est donc qu'au lieu de diagnostiquer ça, on en refait une ou au contraire on dit que puisque on l'applique tout est bon et que donc quelqu'un qui ne l'applique pas est forcément pas bon

Les normes qualites (enfin pour ISO9001, CMM je connais moins) ne sont la que pour mettre en place un processus de reproductibilite et de suivi et absolument pour corriger les problemes metiers dans le processus.
Or bien souvent elle est vu comme la solution miracle qui va regler tout les problemes.
A mon sens le plus gros probleme est un probleme de communication et d'education autour de ses normes, il est important de faire comprendre qu'elles ne sont qu'une aide dans le processus ni plus ni moins.

Malheureusement, comme tu le dis, la tendance est plutot a "l'aveuglement".

[GrandFather]

S'interroger sur les évolutions technologiques dans l'informatique sans les mettre en rapport avec les évolutions intervenant dans ses domaines d'application n'a pas beaucoup de sens. La croissance de la complexité de l'offre technologique informatique va de paire avec des échanges commerciaux de plus en plus mondialisés, l'accès à un public de plus en plus large à des technologies de plus en plus avancées, à des process industriels toujours plus sophistiquées, etc. Il est évident que face à de tels défis, le panel de technologies informatiques ne peut que s'étoffer, car nous savons bien tous qu'il n'existe pas de langage, de plateforme, d'architecture uniques optimaux pour absolument tous les usages.

Bien sûr, comme dans tous les secteurs fortement concurrentiels, le marketing fait ses ravages, avec ses "buzzwords", et telle techno ou langage sexy un jour sera oublié le lendemain. Il y a aussi les ratages et les fausses bonnes idées. Mais malgré cela on va vers une offre toujours plus riche et diversifiée, c'est inévitable.

L'informatique est une industrie qui a effectivement une tendance à s'auto-alimenter, mais les seules choses pérennes chez elle sont celles justifient son usage depuis sa création : l'accroissement de la productivité générale.

Debut 90 : * le CERN définit un protocole commun d’interconnection téléphonique (http) pour éviter les différents réseaux nationaux (Datapac, Europac etc..)

Il n'y aurait pas là une légère confusion entre les termes WWW et HTTP ?

[epsilon68]

Bonjour,

Je pense que le problème ne vient pas de la volonté d'unfier la modélisation masi de la volonté de trop modéliser...

Lorsque je souhaites faire Makefile pour compiler un projet, la modélisation n'est pas utile. Et pourtant, dans certaines grosses boites, on va me demander de modéliser tout, jusqu'au makefile.

Alors je sais, j'exagère (volontairement), mais c'est juste pour enfoncer le clou.

Sinon, je suis d'accord pour dire que nous sommes dan sune phase de spécialisation à outrance, ce qui pose de nombreux problèmes.

Juste un petit mot la dessus ...
si on nous demande de modeliser tout jusqu'au detail,
c'est pour l'envoyer dans un pays ou la main d'oeuvre est terriblement moins cher. Le plus important etant la modelisation dans ce cas puisque ca sera un document de reference en cas de probleme.

[souviron34]

Il n'y aurait pas là une légère confusion entre les termes WWW et HTTP ?

Non...

Http était la solution technique au problème d'interconnection.
WWW était le résultat de l'application de cette solution.

Historique de HTTP :

http://www.apacheweek.com/features/http11

Historique du WWW par l'auteur :

http://www.w3.org/People/Berners-Lee/ShortHistory.html

[souviron34]

Juste un petit mot la dessus ...
si on nous demande de modeliser tout jusqu'au detail,
c'est pour l'envoyer dans un pays ou la main d'oeuvre est terriblement moins cher. Le plus important etant la modelisation dans ce cas puisque ca sera un document de reference en cas de probleme.

je ne suis pas convaincu de cela, bien que cela soit une part de la vérité.

Je pense plus précisément que (il suffit de voir le cycle en V et la description des étapes associées) on a voulu, dans la grande époque du taylorisme des années 70/80 dans l'informatique, copier la production de logiciels sur une chaîne de production manufacturière.. Et donc, comme une telle chaîne, les étapes se suivent et sont reproductibles... Et que donc le travail peut être fait par un "ouvrier à la chaîne", à qui on va dire :"tu fais ça, puis ça"..

C'est ce qui se passe avec le découpage progammeurs, analystes, architectes fonctionnels, etc...

Là où le bât blesse, c'est que une chaîne de production REPRODUIT un prototype établi par le bureau d'étude. Et que la création d'un logiciel EST le bureau d'étude.

Comme donc on n'arrive pas vraiment à faire rentrer dans le moule la production de code (dépassement de durée, insatisfaction, non conformité, bugs, etc..) on essaye par tous les moyens de modéliser les processus, sans s'apercevoir que c'est l'hypothèse de départ qui est fausse....

Primo il est évident que le processus de création d'un prototype dans le bureau d'études n'est pas linéaire, que des contraintes peuvent arriver à tout moment (par exemple, dans l'autoobile, un concurrent peut arriver 3 mois avant un salon avec un proto. bi-carburant, et le marketing exigera du bureau qu'il produise lui-aussi un tel proto.)
Secondo il est tout aussi évident que le processus de création d'un prototype n'est pas "modélisable", tant il repose sur des personnes, et leurs forces ou faiblesses.

Partir du postulat que tout le monde est équivalent et remplaçable, ce qui à mon avis est la principale source de modèlisation dans nos domaines, est à mon sens une abherration..
(voir le post ci-dessus sur la création du WWW par exemple)..

[GrandFather]

Secondo il est tout aussi évident que le processus de création d'un prototype n'est pas "modélisable", tant il repose sur des personnes, et leurs forces ou faiblesses.

Bien sûr que si, c'est modélisable. Mais le modèle seul ne sert à rien, s'il n'est pas accompagné de tout un processus de contrôle qui vérifie en permanence sa validité au regard des résultats obtenus, et procède aux ajustements nécessaires. C'est le fondement d'une démarche qualité. Et je ne vois pas en quoi l'industrie logicielle ne pourrait pas s'inscrire dans ce cadre, là où d'autres industries ont réussi. CMM-I par exemple a quand même été adopté et promu par des géants du logiciel comme IBM...

Partir du postulat que tout le monde est équivalent et remplaçable, ce qui à mon avis est la principale source de modèlisation dans nos domaines, est à mon sens une abherration..
(voir le post ci-dessus sur la création du WWW par exemple)..

Je ne vois pas trop le rapport entre ce postulat et le post sur le WWW...

[souviron34]

. CMM-I par exemple a quand même été adopté et promu par des géants du logiciel comme IBM...

D'abord ce n'est pas une raison parce que des géants comme tu dis l'ont adopté que c'est bon.. Si cela correspond à leur structure et leurs besoins commerciaux pour eux c'est aussi une raison.

Ensuite je suis d'accord (je l'ai dit plus haut), que ce ne sont pas les normes en soi qui sont mauvaises, mais leurs mises en oeuvre .

Cependant, contrairement aux autres industries auxquelles tu fais référence, l'industrie du logiciel est une industrie intellectuelle. Même si l'on peut tenter de donner des grandes lignes, le processus intellectuel est toujours hautement volatile, et les contraintes/solutions arrivant au fur et à mesure ne sont pas forcément modèlisables, ou alors nécessiteront éventuellement une démarche prenant infiniment plus de temps.

Et, si les modèles comme CMMM-I étaient si bons, il n'y aurait pas de ratages magnifiques comme il y en a régulièrement dans l'industrie (voir le problème Airbus déjà cité, pour ne citer que lui, mais j'en ai des 10aines (Socrate, carte Vitale, etc..)).

Enfin

. Je ne vois pas trop le rapport entre ce postulat et le post sur le WWW...

Si bien sûr.. C'est que TOUT peut dépendre d'une seule personne, qui a la bonne idée au bon moment....

La solution à beaucoup de problèmes (et même si il peut y en avoir un certain nombre (de solutions je veux dire)), dépend de la manière de penser, d'analyser, de certaines personnes....
(et ça n'est pas limité à l'informatique... Comme on le disait ces jours-ci, sans quelq'un comme Badinter, la peine de mort existerait toujours. Sans quelqu'un comme Simone Weil, l'avortement serait toujours illégal, sans DeGaulle, peut-être qu'il n'y aurait pas eu de résistance, etc etc....)

Tout le monde n'est pas interchangeable...

[GrandFather]

Cependant, contrairement aux autres industries auxquelles tu fais référence, l'industrie du logiciel est une industrie intellectuelle. Même si l'on peut tenter de donner des grandes lignes, le processus intellectuel est toujours hautement volatile, et les contraintes/solutions arrivant au fur et à mesure ne sont pas forcément modèlisables, ou alors nécessiteront éventuellement une démarche prenant infiniment plus de temps.

C'est surtout volatile quand on ne décolle pas du plan empirique. Toute la valeur du génie logiciel est justement de rendre tangible et formel ce qui sinon ne resterait que dans la tête des développeurs. Imagine-t-on la navette spatiale rester clouée au sol parce que le "Software Chief Engineer" de la NASA en charge du calculateur de vol est parti à la retraite ?

Et, si les modèles comme CMMM-I étaient si bons, il n'y aurait pas de ratages magnifiques comme il y en a régulièrement dans l'industrie (voir le problème Airbus déjà cité, pour ne citer que lui, mais j'en ai des 10aines (Socrate, carte Vitale, etc..)).

Déjà il faudrait s'assurer que les échecs que tu cites ne soient pas imputables justement à une absence ou un irrespect du processus qualité, d'autre part la mise en place de démarche qualité et de normes n'est pas une garantie absolue de succès, mais l'assurance que tout a été mis en oeuvre pour réduire au maximum les risques.

Si bien sûr.. C'est que TOUT peut dépendre d'une seule personne, qui a la bonne idée au bon moment....

La solution à beaucoup de problèmes (et même si il peut y en avoir un certain nombre (de solutions je veux dire)), dépend de la manière de penser, d'analyser, de certaines personnes....
(et ça n'est pas limité à l'informatique... Comme on le disait ces jours-ci, sans quelq'un comme Badinter, la peine de mort existerait toujours. Sans quelqu'un comme Simone Weil, l'avortement serait toujours illégal, sans DeGaulle, peut-être qu'il n'y aurait pas eu de résistance, etc etc....)

Là, tu me parles d'innovation. Jusqu'ici, la discussion portait sur la pertinence des normes en matière d'industrialisation, et les deux activités sont radicalement différentes. On ne peut pas mettre sur le même plan et imposer les mêmes standards de travail à la fois à un Tim Berners-Lee et à un ingénieur développement lambda. Le premier a inventé un concept (on peut aussi dire un paradigme, pour faire classe), le deuxième ne fait que le mettre en oeuvre pour créer un produit commercialisable. Le processus créatif du premier n'est pas mesurable ni modélisable, le "travail d'assemblage" du second l'est déjà beaucoup plus.

[souviron34]

bien évidemment je suis assez d'accord avec ce que tu dis, mais on s'est éloignés du sujet initial...

Mais je rajouterais quand même que quand tu dis :

GrandFather a écrit :

On ne peut pas mettre sur le même plan et imposer les mêmes standards de travail à la fois à un Tim Berners-Lee et à un ingénieur développement lambda Le premier a inventé un concept (on peut aussi dire un paradigme, pour faire classe), le deuxième ne fait que le mettre en oeuvre pour créer un produit commercialisable. Le processus créatif du premier n'est pas mesurable ni modélisable, le "travail d'assemblage" du second l'est déjà beaucoup plus.

eh bien justement je pense que ça fait un peu partie du problème....

D'une part un ingénieur de développement lambda devrait à mon avis être d'un niveau tel qu'il ne devrait pas juste mettre en oeuvre.....

Personnellement je me considère et j'ai toujours travaillé dans des environnements où j'étais plutôt du côté de 1) que de 2). Et j'estime que cela devrait être normal.

Un ébéniste n'est pas un menuisier.

Et pour en revenir au développement pérenne ou à court terme, je pense justement que dans notre société du court terme, on renforce ce genre de profil, pour pouvoir les jeter plus facilement après.... et que tout s'enchaîne... Formations hyper pointues sur le truc du moment, d'où boulots correspondants, d'où blocage plus tard car de nouveaux arrivants auront plus la dernière nouveauté, d'où nécessité de normes et d'encadrement et de méthodes, car on a enseigné un langage mais pas une manière de penser....

(il n'y a qu'à regarder ce qui se dit à propos des langages objet..
Pratiquement TOUS les jeunes programmeurs et 90% des commerciaux ne savent même pas que c'est la CONCEPTION qui est objet, et que ça peut se faire même en assembleur ou en Fortran ou en C, et que c'est d'ailleurs traduit comme ça dès que c'est compilé, et que le langage n'est fait que pour faciliter la vie (et éventuellement l'utilisation de gens n'ayant pas les capacités de raisonner objet dans l'absolu...))

[epsilon68]

je suis d'accord, on essaie de nous faire croire que le developpement est de qualité egale quelque soit la personne, et ce n'est pas vrai !
et maintenant de qualité egale è travers le monde, pas vrai non plus !

alors qu'on parle d'industrie logicielle ? ca arrange les grands groupes ca oui je veux bien le croire, parce qu'il y a enormement d'argent a gagner ...

On ne peut pas tout reposer la qualité sur les tests, ceux ci ne peuvent prouver qu'un code est fiable, il faut faire beaucoup de code reviews, ... pour peu qu'ils en tiennent compte a la fin ....

arretez de croire que les tetes pensantes resteront en europe, elles seront bien sur dans les memes pays que la ou le code se fait, comme d'ailleurs les protos etc, ce n'est qu'une question de temps, tres peu de temps d'ailleurs.

[yann2]

Bonjour

(il n'y a qu'à regarder ce qui se dit à propos des langages objet..
Pratiquement TOUS les jeunes programmeurs et 90% des commerciaux ne savent même pas que c'est la CONCEPTION qui est objet, et que ça peut se faire même en assembleur ou en Fortran ou en C, et que c'est d'ailleurs traduit comme ça dès que c'est compilé, et que le langage n'est fait que pour faciliter la vie (et éventuellement l'utilisation de gens n'ayant pas les capacités de raisonner objet dans l'absolu...))

Ben oui, les jeunes développeurs sont des crétins finis. Comme tous les jeunes d'ailleurs.

J'aime bien quand les gens parlent des jeunes comme un groupe à part. Les jeunes sont éduqués par vous, les moins jeunes qui ont été jeunes. Et puis 80 ans ramenés à l'humanité, je ne trouve pas ça vieux.

Pourtant c'est vous les moins jeunes qui ont utilisé des cycles de vie en cascade accompagnés du célèbre effet tunnel, c'est vous qui avez utilisé la conception objet avec des langages non objets. C'est donc grâce à vous que nous utilisons des méthode agiles, des langages objets. Et maintenant vous n'êtes pas content parce que les solutions aux problèmes rencontrés dans le passé sont utilisées.

Je remercie mes anciens enseignants qui ont fait le choix de nous enseigner ces solutions qui offrent bien plus de perspectives que le Fortran.

Il existe plusieurs structures pour normaliser les outils (technologies) pour le développement dont l'OMG et le W3C.

L'industrialisation du développement est une solution pour ne pas être dépendant d'une technologie. Couplage faible entre le fonctionnel et la technique (voir mon post sur le MDA). Couplage faible que l'on essaie également d'obtenir entre les composants d'une application. A propos de l'industrialisation : les chaises ne sont plus construites à la main.

bisous