Je suis entièrement d'accord avec toi sur la difficulté de remplir tous ces rôles que tu décris. Les développeurs (et les ingénieurs de manière plus générale) sont souvent passionnés par la technique et très souvent capables. Ce sont les autres aspects qui bloquent : comme tu le dis, attirer l'attention sur le projet, trouver une cible et un modèle économique viable, gérer les relations clients/utilisateurs, etc.
J'aimerais revenir sur l'aspect conception et l'exemple que tu prends de l'automobile. Je me suis assez récemment reconverti à l'informatique dans une SSII après avoir suivi des études en Ingénierie des Systèmes. Kézako ?, me direz-vous sûrement... Et bien d'après ce bon vieux Wikipédia :
L'ingénierie des systèmes ou ingénierie système est une approche scientifique interdisciplinaire, dont le but est de formaliser et d'appréhender la conception de systèmes complexes avec succès.
Concrètement, c'est une méthodologie de conception développée initialement dans le milieu du spatial (coucou la NASA) et qui est aujourd'hui utilisée dans de nombreux secteurs (aérospatial, défense, automobile, énergie, et même pharma...).
Certes, les SSII se sont pas forcément représentative de l'ensemble des professionnels du domaine, mais les méthodes de conception que j'y vois, et surtout le fatalisme des développeurs quant à la possibilité d'avoir un process de qualité me font tomber à la renverse ! Combien de fois déjà ai-je entendu des "Non mais faut t'habituer, en info les projets c'est toujours à l'arrache.", "Ah non, te fies pas à la spéc, elle est pas à jour de toute façon.", "Le client a pas encore décidé ce qu'il veut, mais on va s'avancer". Bref, la méthode de la R.A.C.H.E dans toute sa splendeur. Mais je m'écarte un peu du sujet...
Un des principes clés de l'ingénierie système, c'est qu'un système est plus que la somme de ses interfaces avec l'extérieur (ses fonctionnalités si on veut). Les sous-systèmes/composants du système interagissent entre eux et ça a un impact sur la dynamique globale du système. On ne peut pas concevoir un système complexe en ignorant ses interactions internes. On ne peut pas concevoir en ajoutant petit bout par petit bout par petit bout puisque chaque bout amène son lot d'interactions avec les autres bouts en plus de la fonctionnalité voulue. Tu prends l'exemple de l'automobile :
Si vous voulez construire vous même votre voiture, assurez vous que vous arrivez déjà à faire tourner un moteur sur une batterie avant même de commencer à dessiner les plans de la voiture elle même, car une voiture sans moteur restera une boite à savon...
Fût une époque où les constructeurs automobiles travaillaient comme ça, et une voiture mettait entre 5 et 10 ans pour arriver sur le marché. Aujourd'hui, entre la décision de sortir un nouveau modèle et son arrivée chez le concessionnaire, il peut se passer moins de 18 mois. C'est justement parce qu'on réfléchit à l'ensemble plutôt qu'à la somme d'éléments : dès le début on définit le besoin de manière exhaustive (ou on essaye en tout cas...), on conçoit une architecture qui prend l'ensemble des exigences en compte ainsi que l'impact des interactions entre les éléments de notre architecture. De là, on définit les exigences (atteignables si on a bien fait son boulot) que chaque élément/sous-système doit remplir. Puis, tout est conçu en parallèle ! Le châssis de la voiture peut être conçu en parallèle du moteur ! On n'attend pas que le moteur marche pour lancer le reste.
Fabriquer des prototypes et réaliser des tests est ce qu'il y a de plus cher, concevoir une voiture bout par bout, prototyper, tester, réitérer coûte une fortune. Pourtant, c'est ce que je vois dans le développement de systèmes informatiques : on se dit qu'on commence par un petit bout facile, puis on rajoute un petit bout, etc. Mais chaque bout/module/fonctionnalité peut potentiellement affecter le fonctionnement de l'existant, ou bien tu peux te rendre que ton architecture qui était parfaitement adaptée jusqu'alors, ne l'est plus du tout. Alors à chaque petit bout qu'on rajoute, on est obligé de revérifier l'ensemble et éventuellement corriger l'existant. Parfois, tu ne peux pas rajouter cette fonctionnalité sans réécrire une part importante de l'existant, voire tout jeter à la poubelle et repartir sur des bases saines.
Pour écrire du code, et construire des applications, il faut un peu avoir l’instinct de bricoleur. A force de brancher des fils entre eux, on fini par faire tourner quelque chose.
Puis avec l’habitude, on voit plus grand, plus loin. On imagine ce que l’on pourrait faire si seulement on reliait de gros morceaux entre eux. Et un jour, on ouvre un IDE, et on y va, et on se plante.
Il faudra parfois du temps, mais à un moment votre code mal pensé vous dégoûtera. Il y a un travail à faire autour du code à proprement parler sans quoi la structure ne tiendra pas très longtemps.
C'est exactement ce à quoi je fais référence et il me semble que nous sommes d'accord là-dessus. Mais ce n'est pas une fatalité. On peut lutter contre ça, ça demande de se forcer à prendre tout le temps nécessaire pour réfléchir avant de se lancer dans du code. Si on n'a pas les compétences de le faire (ce qui n'a rien de honteux, tout le monde n'est pas un architecte logiciel expérimenté, pas moi en tout cas), il peut être bon d'en discuter avec quelqu'un qui lui a ce genre de compétences.
Pour conclure ce petit commentaire qui a tourné au roman (désolé), je ne dis pas qu'il faut travailler de manière monolithique. Je pense simplement qu'il est nécessaire d'avoir une vision d'ensemble : dès le début d'un projet, réfléchir à l'ensemble de fonctionnalités/contraintes que l'on voudra y ajouter et réfléchir dès le début à une architecture qui permettent cela. Ça ne veut pas dire concevoir une usine à gaz qui permet d'intégrer tout et n'importe quoi, juste ce qui est un besoin réel et réaliste. Puis, durant le développement à proprement parlé, même si on développe et livre module par module, avoir conscience pour chaque module qu'il fait partie d'un tout cohérent.
# Méthodes de conception
Posté par FreeFax . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 6.
Je suis entièrement d'accord avec toi sur la difficulté de remplir tous ces rôles que tu décris. Les développeurs (et les ingénieurs de manière plus générale) sont souvent passionnés par la technique et très souvent capables. Ce sont les autres aspects qui bloquent : comme tu le dis, attirer l'attention sur le projet, trouver une cible et un modèle économique viable, gérer les relations clients/utilisateurs, etc.
J'aimerais revenir sur l'aspect conception et l'exemple que tu prends de l'automobile. Je me suis assez récemment reconverti à l'informatique dans une SSII après avoir suivi des études en Ingénierie des Systèmes. Kézako ?, me direz-vous sûrement... Et bien d'après ce bon vieux Wikipédia :
Concrètement, c'est une méthodologie de conception développée initialement dans le milieu du spatial (coucou la NASA) et qui est aujourd'hui utilisée dans de nombreux secteurs (aérospatial, défense, automobile, énergie, et même pharma...).
Certes, les SSII se sont pas forcément représentative de l'ensemble des professionnels du domaine, mais les méthodes de conception que j'y vois, et surtout le fatalisme des développeurs quant à la possibilité d'avoir un process de qualité me font tomber à la renverse ! Combien de fois déjà ai-je entendu des "Non mais faut t'habituer, en info les projets c'est toujours à l'arrache.", "Ah non, te fies pas à la spéc, elle est pas à jour de toute façon.", "Le client a pas encore décidé ce qu'il veut, mais on va s'avancer". Bref, la méthode de la R.A.C.H.E dans toute sa splendeur. Mais je m'écarte un peu du sujet...
Un des principes clés de l'ingénierie système, c'est qu'un système est plus que la somme de ses interfaces avec l'extérieur (ses fonctionnalités si on veut). Les sous-systèmes/composants du système interagissent entre eux et ça a un impact sur la dynamique globale du système. On ne peut pas concevoir un système complexe en ignorant ses interactions internes. On ne peut pas concevoir en ajoutant petit bout par petit bout par petit bout puisque chaque bout amène son lot d'interactions avec les autres bouts en plus de la fonctionnalité voulue. Tu prends l'exemple de l'automobile :
Fût une époque où les constructeurs automobiles travaillaient comme ça, et une voiture mettait entre 5 et 10 ans pour arriver sur le marché. Aujourd'hui, entre la décision de sortir un nouveau modèle et son arrivée chez le concessionnaire, il peut se passer moins de 18 mois. C'est justement parce qu'on réfléchit à l'ensemble plutôt qu'à la somme d'éléments : dès le début on définit le besoin de manière exhaustive (ou on essaye en tout cas...), on conçoit une architecture qui prend l'ensemble des exigences en compte ainsi que l'impact des interactions entre les éléments de notre architecture. De là, on définit les exigences (atteignables si on a bien fait son boulot) que chaque élément/sous-système doit remplir. Puis, tout est conçu en parallèle ! Le châssis de la voiture peut être conçu en parallèle du moteur ! On n'attend pas que le moteur marche pour lancer le reste.
Fabriquer des prototypes et réaliser des tests est ce qu'il y a de plus cher, concevoir une voiture bout par bout, prototyper, tester, réitérer coûte une fortune. Pourtant, c'est ce que je vois dans le développement de systèmes informatiques : on se dit qu'on commence par un petit bout facile, puis on rajoute un petit bout, etc. Mais chaque bout/module/fonctionnalité peut potentiellement affecter le fonctionnement de l'existant, ou bien tu peux te rendre que ton architecture qui était parfaitement adaptée jusqu'alors, ne l'est plus du tout. Alors à chaque petit bout qu'on rajoute, on est obligé de revérifier l'ensemble et éventuellement corriger l'existant. Parfois, tu ne peux pas rajouter cette fonctionnalité sans réécrire une part importante de l'existant, voire tout jeter à la poubelle et repartir sur des bases saines.
C'est exactement ce à quoi je fais référence et il me semble que nous sommes d'accord là-dessus. Mais ce n'est pas une fatalité. On peut lutter contre ça, ça demande de se forcer à prendre tout le temps nécessaire pour réfléchir avant de se lancer dans du code. Si on n'a pas les compétences de le faire (ce qui n'a rien de honteux, tout le monde n'est pas un architecte logiciel expérimenté, pas moi en tout cas), il peut être bon d'en discuter avec quelqu'un qui lui a ce genre de compétences.
Pour conclure ce petit commentaire qui a tourné au roman (désolé), je ne dis pas qu'il faut travailler de manière monolithique. Je pense simplement qu'il est nécessaire d'avoir une vision d'ensemble : dès le début d'un projet, réfléchir à l'ensemble de fonctionnalités/contraintes que l'on voudra y ajouter et réfléchir dès le début à une architecture qui permettent cela. Ça ne veut pas dire concevoir une usine à gaz qui permet d'intégrer tout et n'importe quoi, juste ce qui est un besoin réel et réaliste. Puis, durant le développement à proprement parlé, même si on développe et livre module par module, avoir conscience pour chaque module qu'il fait partie d'un tout cohérent.