Analogie mécanique
Mon entreprise fait de la conception mécanique. Nous fournissons des arbres à cames pour l'industrie automobile.
Le cahier des charges d'un nouveau produit est établi en fonction d'un objectif qui dresse un ensemble de conditions d'utilisation assez large (Encombrement, ordre de grandeur des couples appliqués, etc)
Une première équipe d'ingénieurs va ébaucher le travail sur la pièce : plans en deux dimensions, premières idées sur les matériaux, etc.
Une autre va déjà commencer à travailler sur la qualité, les conditions de test qui vont être appliquées aux prototypes, etc. en fonction de plan de qualités déjà établis pour d'autres produits. Si des opérations de tests nouvelles doivent être élaborées, elles seront rajoutées au catalogue avec un processus de validation. Et il faut également veiller à respecter des normes nationales ou internationales dont la vérification est clairement documentée.
Puis, ces plans sont fournis à des concepteurs par ordinateur, qui vont utiliser un produit comme CATIA ou SolidWorks pour concevoir la pièce en trois dimensions.
En modélisant correctement dans ces outils, c'est à dire en définissant correctement les ensembles mécaniques, leurs matériaux, leurs jonctions, les relations entre les côtes, et les liaisons mécaniques,etc, mon outil de modélisation va pouvoir d'hors et déjà
Si les pièces sont simples, nos modèles sont dérivables en instructions pour les machines outil, mais dans une majorité des cas, il faut concevoir un procédé de fabrication à partir de plans, qui de toute façon sont automatiquement imprimés à partir de définitions de coupes intelligentes sur notre modèle.
Le procédé de fabrication, c'est simplement un ensemble d'instructions simples (dont de grandes parties sont réutilisables) qui, enchainées dans le bon ordre, permettent à des techniciens spécialistes sur différentes machines outil de créer des prototypes. En phase de production, certaines tâches seront automatisables sur des robots d'une chaine de fabrication.
On obtient, après le travail des techniciens en machines outils, des prototypes sur lesquels les équipes de qualité vont pouvoir appliquer leurs tests.
Si les tests ne sont pas concluants, on remonte à la conception.
Une fois les tests passés, on obtient une pièce, qualifiée non pas par son cahier des charges, mais par des critères objectifs et quantifiables :
Voila comment cela fonctionne grossièrement dans l'industrie mécanique. Je dis grossièrement, car en réalité je ne travaille pas dans cette industrie, mais sortant d'une ancienne école de mécanique, j'en ai mangé pas mal. Mais on connait la différence entre l'école et la réalité, donc je ne pousserai pas le pédantisme jusqu'à dire que tout ce que j'ai dit est une vérité absolue. Mais cela brosse un bon tableau.
Une des conséquences de tout ce que je viens de dire est qu'un fabricant automobile par exemple, a un certain niveau de certitude quand il sort une voiture. C'est important parce qu'une voiture mal conçue est quelque chose d'extrêmement mortel.
Pourrions nous dire de même dans le monde de l'informatique ? Je ne crois pas. Il suffit de voir certains CLUF : certains vont jusqu'à dire qu'il n'y a aucune garantie à ce que le produit dont vous payer la licence d'utilisation fonctionnera.
Alors qu'est-ce qui foire ? Qu'on ne vienne pas me parler d'immaturité, parce que je suis absolument persuadé que l'informatique n'a presque rien inventé depuis 40 ans. L'immaturité de la science informatique est un argument facile pour se dédouaner. L'immaturité n'est pas dans l'informatique elle même, mais en réalité chez les informaticiens. (je vous renvoie à ces deux excellents articles de friends.praxeme
http://friends.praxeme.org/2009/08/get-out-of-the-immaturity-model-part-1/
http://friends.praxeme.org/2009/08/get-out-of-the-immaturity-model-part-2/
)
Reprenons la chaine que j'ai décrite ci dessus point par point
Le cahier des charges d'abord. Trop souvent, cela se résume à une vague demande d'un client, pas détaillée, parfois même non notée, à laquelle on répond par une solution "universelle" qu'on tentera d'adapter.
C'est pourtant la base de la qualité d'un produit. Mon ancien directeur de génie informatique se tue à le répéter il faut avoir en tête ce que signifie le mot "qualité"
Comment puis-je vanter la qualité d'un produit logiciel si je ne sais pas quels sont les besoins de mes utilisateurs ? Et non, 95% de couverture en tests unitaires, géré en code source et bâtit sur une usine de développement n'est pas une réponse.
Plus le cahier des charges est complet (et des fois cela veut dire tirer les vers du nez à l'utilisateur), plus il est possible de certifier la qualité du produit.
Pour ce qui est de l'ébauche de conception, je n'ai pas envie de revenir sur l'absence de spécifications techniques.
Les modèles... Est-ce idéaliste de se dire qu'on peut concevoir un modèle informatique aussi complet qu'un modèle mécanique ? Je ne crois pas. J'ai posé la question à mon mentor récemment sur ce que pouvait bien signifier qu'un modèle informatique est complet. Sa réponse, faute de mieux pour l'instant, est que tout est décrit et qu'il est exécutable. (Corrige moi si je me trompe parce que je sais que tôt ou tard tu liras ces lignes).
Mon rêve en la matière serait d'avoir un atelier de conception tel que, une fois que j'ai écrit mon modèle, posé les contraintes, décrit les diagrammes statiques et dynamiques, je puisse appuyer sur un bouton pour
Dans la même veine : pourquoi est-ce qu'à chaque fois que je conçois une application je dois TOUT modéliser, y compris des choses qui ont été faites des dizaines de fois. Pourquoi ne puis-je pas récupérer dans des catalogues des modèles standards et des modèles venant de catalogues d'éditeurs logiciels ?
Ici on voit l'immaturité des informaticiens. On passe notre temps à tout reconcevoir, tout persuadés qu'on fera mieux que notre petit voisin. Si vous trouvez cette idée intéressante, d'ailleurs, je vous renvoie sur cet autre article de friends.praxeme )
La qualité et les tests... Bon sang, avec la récurrence de certains problèmes, vous ne pensez pas que depuis le temps nos équipes de Q/A devraient avoir des bibliothèques COMPLETES sur comment vérifier la couverture du besoin et des contraintes.
Pourquoi, en 2009, une recette est-elle toujours faite SPECIFIQUEMENT pour chaque projet, bordel ?
Quant à la réification des modèles... Bien sur que certaines opérations sont automatisables (genre votre atelier UML ne fait pas de génération de code ?), il suffirait ensuite de décrire correctement comment les modèles se réifient et transmettre l'exécution à des techniciens.
Et enfin, pourquoi n'est-on pas capables, une fois un produit complet, de le qualifier de façon quantifiable ? Qu'est-ce qu'on gagnerait comme temps si on avait des catalogues complets avec des abaques ! Finies les grandes études de choix de solution faites sur des intuitions et des a priori, soutenues par des diagrammes radar approximatifs... Finies les heures passées sur le net à trouver le framework qui répond à vos besoins (si vous êtes développeurs .Net, vous détestez tellement ça que vous priez St Microsoft qu'il vous le fournisse un jour)
Si Sisyphe était masochiste, il serait informaticien
Parce que bon sang en fait c'est ça. Dans le monde de l'informatique, on passe notre temps à repousser notre rocher en haut de sa cuvette, et si possible en chantant et avec la banane.
Il y a un réel refus d'apprendre, de capitaliser et de partager dans le monde de l'informatique. C'est mal.
Tenez une petite blague devinette.
La DDE vient d'embaucher un nouveau gars pour peindre les signalisations sur les routes de campagne. Travail manuel, le gars a son seau et son pinceau.
Le premier jour, il fait son rapport, et son supérieur est impressioné : c'est une distance record qu'il a couverte de bandes blanches.
Le second jour par contre, c'est tout juste moyen
Le troisième c'est mauvais
Le quatrième c'est catastrophique.
Comment se fait-ce ?
Facile : le gars ne transporte pas son seau.
L'analogie dans le monde de l'informatique, c'est que le quatrième jour, on fait un projet pharaonique de refonte des systèmes.
Bien sur, ce dont je rêve est invendable actuellement. Les instances dirigeantes ne comprennent rien à l'informatique, c'est un fait. L'effort initial de conception complète et partagée demanderait un sponsoring et un investissement assez massifs. A terme, les couts seraient bien moindres.
Mais aujourd'hui, les clients de l'informatique refusent les solutions viables et chères, parce qu'elles ne comprennent pas leur différence de cout et de délais avec les offres peu chères et alléchantes des requins.
Avouez que ca fait un peu mal au cul ce genre de comportement venant de gens qui roulent en Ferrari et ne se nourissent que de produits haut de gamme, tout persuadés qu'ils sont que l'excellence et la qualité, ça a un prix.
Le cahier des charges d'un nouveau produit est établi en fonction d'un objectif qui dresse un ensemble de conditions d'utilisation assez large (Encombrement, ordre de grandeur des couples appliqués, etc)
Une première équipe d'ingénieurs va ébaucher le travail sur la pièce : plans en deux dimensions, premières idées sur les matériaux, etc.
Une autre va déjà commencer à travailler sur la qualité, les conditions de test qui vont être appliquées aux prototypes, etc. en fonction de plan de qualités déjà établis pour d'autres produits. Si des opérations de tests nouvelles doivent être élaborées, elles seront rajoutées au catalogue avec un processus de validation. Et il faut également veiller à respecter des normes nationales ou internationales dont la vérification est clairement documentée.
Puis, ces plans sont fournis à des concepteurs par ordinateur, qui vont utiliser un produit comme CATIA ou SolidWorks pour concevoir la pièce en trois dimensions.
En modélisant correctement dans ces outils, c'est à dire en définissant correctement les ensembles mécaniques, leurs matériaux, leurs jonctions, les relations entre les côtes, et les liaisons mécaniques,etc, mon outil de modélisation va pouvoir d'hors et déjà
- Me simuler le comportement mécanique de ma pièce (Lois de mécanique du solide)
- Me simuler la résistance (Lois de mécanique du solide et de résistance des matériaux)
- Optimiser ma pièce selon des contraintes qui m'intéressent
Si les pièces sont simples, nos modèles sont dérivables en instructions pour les machines outil, mais dans une majorité des cas, il faut concevoir un procédé de fabrication à partir de plans, qui de toute façon sont automatiquement imprimés à partir de définitions de coupes intelligentes sur notre modèle.
Le procédé de fabrication, c'est simplement un ensemble d'instructions simples (dont de grandes parties sont réutilisables) qui, enchainées dans le bon ordre, permettent à des techniciens spécialistes sur différentes machines outil de créer des prototypes. En phase de production, certaines tâches seront automatisables sur des robots d'une chaine de fabrication.
On obtient, après le travail des techniciens en machines outils, des prototypes sur lesquels les équipes de qualité vont pouvoir appliquer leurs tests.
Si les tests ne sont pas concluants, on remonte à la conception.
Une fois les tests passés, on obtient une pièce, qualifiée non pas par son cahier des charges, mais par des critères objectifs et quantifiables :
- Encombrement
- Poids
- Utilisation nominales, avec des abaques
- L'ajout au catalogue d'une nouvelle pièce avec son objectif global (qui est un peu un argument de vente)
- Le modèle CATIA ou SolidWorks (ou autre) de l'arbre à cames, que le constructeur automobile pourra intégrer tel quel dans son modèle de voiture
- Les spécifications techniques complètes de la pièce (et donc également ses abaques de conditions d'utilisation nominales)
- Est-ce que mon entreprise a les reins solides, suffisamment pour que je puisse le fournir tant qu'il aura besoin de la pièce ? (et à partir d'études financières, il pourra négocier un contrat d'assurance pour les défauts de livraison, ou négocier des prix financier pour couvrir son risque)
- Quelle est notre capacité de production ? Pourra-t-on couvrir leur demande ?
- Quelle est notre capacité à délivrer ? Parce qu'ils travaillent en flux tendu
- Respectons nous correctement les normes, afin qu'eux puissent respecter leurs normes et autres contraintes ?
- Quelle est notre réputation ?
Voila comment cela fonctionne grossièrement dans l'industrie mécanique. Je dis grossièrement, car en réalité je ne travaille pas dans cette industrie, mais sortant d'une ancienne école de mécanique, j'en ai mangé pas mal. Mais on connait la différence entre l'école et la réalité, donc je ne pousserai pas le pédantisme jusqu'à dire que tout ce que j'ai dit est une vérité absolue. Mais cela brosse un bon tableau.
Une des conséquences de tout ce que je viens de dire est qu'un fabricant automobile par exemple, a un certain niveau de certitude quand il sort une voiture. C'est important parce qu'une voiture mal conçue est quelque chose d'extrêmement mortel.
Pourrions nous dire de même dans le monde de l'informatique ? Je ne crois pas. Il suffit de voir certains CLUF : certains vont jusqu'à dire qu'il n'y a aucune garantie à ce que le produit dont vous payer la licence d'utilisation fonctionnera.
Alors qu'est-ce qui foire ? Qu'on ne vienne pas me parler d'immaturité, parce que je suis absolument persuadé que l'informatique n'a presque rien inventé depuis 40 ans. L'immaturité de la science informatique est un argument facile pour se dédouaner. L'immaturité n'est pas dans l'informatique elle même, mais en réalité chez les informaticiens. (je vous renvoie à ces deux excellents articles de friends.praxeme
http://friends.praxeme.org/2009/08/get-out-of-the-immaturity-model-part-1/
http://friends.praxeme.org/2009/08/get-out-of-the-immaturity-model-part-2/
)
Reprenons la chaine que j'ai décrite ci dessus point par point
Le cahier des charges d'abord. Trop souvent, cela se résume à une vague demande d'un client, pas détaillée, parfois même non notée, à laquelle on répond par une solution "universelle" qu'on tentera d'adapter.
C'est pourtant la base de la qualité d'un produit. Mon ancien directeur de génie informatique se tue à le répéter il faut avoir en tête ce que signifie le mot "qualité"
Je répète : satisfaire les besoins des utilisateursAptitude d'un produit ou d'un service à satisfaire, au moindre coût et dans les moindres délais les besoins des utilisateurs.
Comment puis-je vanter la qualité d'un produit logiciel si je ne sais pas quels sont les besoins de mes utilisateurs ? Et non, 95% de couverture en tests unitaires, géré en code source et bâtit sur une usine de développement n'est pas une réponse.
Plus le cahier des charges est complet (et des fois cela veut dire tirer les vers du nez à l'utilisateur), plus il est possible de certifier la qualité du produit.
Pour ce qui est de l'ébauche de conception, je n'ai pas envie de revenir sur l'absence de spécifications techniques.
Les modèles... Est-ce idéaliste de se dire qu'on peut concevoir un modèle informatique aussi complet qu'un modèle mécanique ? Je ne crois pas. J'ai posé la question à mon mentor récemment sur ce que pouvait bien signifier qu'un modèle informatique est complet. Sa réponse, faute de mieux pour l'instant, est que tout est décrit et qu'il est exécutable. (Corrige moi si je me trompe parce que je sais que tôt ou tard tu liras ces lignes).
Mon rêve en la matière serait d'avoir un atelier de conception tel que, une fois que j'ai écrit mon modèle, posé les contraintes, décrit les diagrammes statiques et dynamiques, je puisse appuyer sur un bouton pour
- l'optimiser si ce n'est pas précoce dans la conception
- le voir vivre, s'animer
- tester sa résistance
Dans la même veine : pourquoi est-ce qu'à chaque fois que je conçois une application je dois TOUT modéliser, y compris des choses qui ont été faites des dizaines de fois. Pourquoi ne puis-je pas récupérer dans des catalogues des modèles standards et des modèles venant de catalogues d'éditeurs logiciels ?
Ici on voit l'immaturité des informaticiens. On passe notre temps à tout reconcevoir, tout persuadés qu'on fera mieux que notre petit voisin. Si vous trouvez cette idée intéressante, d'ailleurs, je vous renvoie sur cet autre article de friends.praxeme )
La qualité et les tests... Bon sang, avec la récurrence de certains problèmes, vous ne pensez pas que depuis le temps nos équipes de Q/A devraient avoir des bibliothèques COMPLETES sur comment vérifier la couverture du besoin et des contraintes.
Pourquoi, en 2009, une recette est-elle toujours faite SPECIFIQUEMENT pour chaque projet, bordel ?
Quant à la réification des modèles... Bien sur que certaines opérations sont automatisables (genre votre atelier UML ne fait pas de génération de code ?), il suffirait ensuite de décrire correctement comment les modèles se réifient et transmettre l'exécution à des techniciens.
Et enfin, pourquoi n'est-on pas capables, une fois un produit complet, de le qualifier de façon quantifiable ? Qu'est-ce qu'on gagnerait comme temps si on avait des catalogues complets avec des abaques ! Finies les grandes études de choix de solution faites sur des intuitions et des a priori, soutenues par des diagrammes radar approximatifs... Finies les heures passées sur le net à trouver le framework qui répond à vos besoins (si vous êtes développeurs .Net, vous détestez tellement ça que vous priez St Microsoft qu'il vous le fournisse un jour)
Si Sisyphe était masochiste, il serait informaticien
Parce que bon sang en fait c'est ça. Dans le monde de l'informatique, on passe notre temps à repousser notre rocher en haut de sa cuvette, et si possible en chantant et avec la banane.
Il y a un réel refus d'apprendre, de capitaliser et de partager dans le monde de l'informatique. C'est mal.
Tenez une petite blague devinette.
La DDE vient d'embaucher un nouveau gars pour peindre les signalisations sur les routes de campagne. Travail manuel, le gars a son seau et son pinceau.
Le premier jour, il fait son rapport, et son supérieur est impressioné : c'est une distance record qu'il a couverte de bandes blanches.
Le second jour par contre, c'est tout juste moyen
Le troisième c'est mauvais
Le quatrième c'est catastrophique.
Comment se fait-ce ?
Facile : le gars ne transporte pas son seau.
L'analogie dans le monde de l'informatique, c'est que le quatrième jour, on fait un projet pharaonique de refonte des systèmes.
Bien sur, ce dont je rêve est invendable actuellement. Les instances dirigeantes ne comprennent rien à l'informatique, c'est un fait. L'effort initial de conception complète et partagée demanderait un sponsoring et un investissement assez massifs. A terme, les couts seraient bien moindres.
Mais aujourd'hui, les clients de l'informatique refusent les solutions viables et chères, parce qu'elles ne comprennent pas leur différence de cout et de délais avec les offres peu chères et alléchantes des requins.
Avouez que ca fait un peu mal au cul ce genre de comportement venant de gens qui roulent en Ferrari et ne se nourissent que de produits haut de gamme, tout persuadés qu'ils sont que l'excellence et la qualité, ça a un prix.
©2009 Another geek in the wall. All Rights Reserved.
Tout est decrit en largeur.
En profondeur, il faut bien sur savoir placer ses ambitions a un niveau de detail necessaire. Le reste serait du luxe, qu'on aimerait bien se payer, certes, et qui serait intellectuellement satisfaisant, humainement un progres, mais difficile a faire avaler dans notre economie. Encore au-dela, bien sur, il y a les limites (mouvantes) imposees par les grands principes de la difference entre la carte et le territoire et la grande question de l'existence de la realite objectivable...
Pour reprendre ton analogie mecanique, pour une partie de l'arbre a came (les cames et les paliers de roulements), on precise les cotes au 100eme de mm, mais certaines parties sont fournies seulement au 10eme (les fameuses games d'usinage que tu pourrais inclure dans l'analogie).
Excellent post, vraiment.
Je ne resiste pas bien sur a l'envie de resumer la reponse que ce post attend : Praxeme, initiative pour une methode de conception de SI (et plus des qu'affinites il y a) ouverte, qui explique de facon tres detaillee comment l'info pourrait aujourd'hui passer brillamment du mode de l'immaturite d'ados attardes a celui de la maitrise et du controle de parents responsables.
To get know information about this topic, people should <a href=" http://www.gogetessays.com">buy essay</a> at the paper writing services.