Je confirme. Tous les générateurs de code et les générateurs automatiques de base de données pour les nuls, ça finit toujours en cacahuète...
Le problème, c'est que ça semble fonctionner parfaitement au début. Mais quand on veut modifier ou pire ajouter une fonction qui n'est pas prévue dans le système de base, c'est une galère épouvantable.
Je me souviens d'un logiciel générateur de code qui générait 100 000 lignes de code en COBOL alors que je faisais la même chose en Fortran écrit avec VI en quelques centaines de lignes. Il m'était assez facile de modifier tandis que mon collègue devait lire un épais listing et faire les modifications du code qui rendaient impossible de le gérer ensuite autrement qu'à la main.
J’avais essayé UML il y a presque 20 ans. Cela m'a autant inspiré que le cycle de développement en V responsable des plus gros échecs en informatique.
Il y a des raisons à cela :
* informatiser une tâche change le mode de travail de l'utilisateur donc rendent les spécifications obsolètes;
* on peut vérifier qu'un logiciel est conforme à ses spécifications mais il n'existe pas de méthode pour vérifier que les spécifications étaient conformes aux besoins;
* l'environnement et les conditions de travail évoluent;
* les spécifications sont faites par des personnes qui ne connaissent pas le métier ou croient le connaitre.
Alors quelles solutions ? Pour moi il faut avoir une double compétence en informatique et dans le métier. Lorsque l'utilisateur n'est pas l'informaticien, il faut deux personnes qui apprennent chacune le métier de l'autre. Cela évite de demander des choses complexes que l'on croyait simples mais peu utiles et de proposer des choses simples, vite réalisées mais très efficaces qu'un non informaticien n'oserait pas imaginer.
Je me suis toujours dit : cela me demande 10h de travail, ce sera rentabilisé en moins d'un an, donc c'est urgent. Si ça me demande 200h pour économiser 10h de travail par an aux utilisateurs de mon entreprise, ça peut attendre.
En bref je crois méthodes agiles et à l’efficacité.
[^] # Re: Allez, on se lance...
Posté par Pierre Jarillon (site web personnel) . En réponse à la dépêche Développement très rapide d’applications libres : Extended Man/XML Frames. Évalué à 9. Dernière modification le 25 octobre 2017 à 00:11.
Je confirme. Tous les générateurs de code et les générateurs automatiques de base de données pour les nuls, ça finit toujours en cacahuète...
Le problème, c'est que ça semble fonctionner parfaitement au début. Mais quand on veut modifier ou pire ajouter une fonction qui n'est pas prévue dans le système de base, c'est une galère épouvantable.
Je me souviens d'un logiciel générateur de code qui générait 100 000 lignes de code en COBOL alors que je faisais la même chose en Fortran écrit avec VI en quelques centaines de lignes. Il m'était assez facile de modifier tandis que mon collègue devait lire un épais listing et faire les modifications du code qui rendaient impossible de le gérer ensuite autrement qu'à la main.
J’avais essayé UML il y a presque 20 ans. Cela m'a autant inspiré que le cycle de développement en V responsable des plus gros échecs en informatique.
Il y a des raisons à cela :
* informatiser une tâche change le mode de travail de l'utilisateur donc rendent les spécifications obsolètes;
* on peut vérifier qu'un logiciel est conforme à ses spécifications mais il n'existe pas de méthode pour vérifier que les spécifications étaient conformes aux besoins;
* l'environnement et les conditions de travail évoluent;
* les spécifications sont faites par des personnes qui ne connaissent pas le métier ou croient le connaitre.
Alors quelles solutions ? Pour moi il faut avoir une double compétence en informatique et dans le métier. Lorsque l'utilisateur n'est pas l'informaticien, il faut deux personnes qui apprennent chacune le métier de l'autre. Cela évite de demander des choses complexes que l'on croyait simples mais peu utiles et de proposer des choses simples, vite réalisées mais très efficaces qu'un non informaticien n'oserait pas imaginer.
Je me suis toujours dit : cela me demande 10h de travail, ce sera rentabilisé en moins d'un an, donc c'est urgent. Si ça me demande 200h pour économiser 10h de travail par an aux utilisateurs de mon entreprise, ça peut attendre.
En bref je crois méthodes agiles et à l’efficacité.