Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
OK, mais comme mentionné par plusieurs personnes sur le thread "bonnes pratiques" (http://www.developpez.net/forums/sho...d.php?t=295754), le bon sens prime, et avoir une méthode, aussi modélisatrice soit-elle, ne garantit rien...
Voir l'image mise dans mon post http://www.developpez.net/forums/sho...06#post1875706
Bien sûr que ça ne garantit rien. Le but d'une méthode est de réduire le risque lié au développement logiciel, pas de l'annuler, ce qui est impossible.Envoyé par souviron34
C'est l'exemple typique de schéma réalisé par quelqu'un qui n'a rien compris à l'intérêt de la modélisation, qui est d'illustrer et de clarifier.Voir l'image mise dans mon post http://www.developpez.net/forums/sho...06#post1875706
c'est exactement ce que je disais... Le fait de la montée en puissance des RAD et modèlisations provient du fait que les boîtes pensent que "n'importe qui" peut le faire (pas par rapport à la délocalisation, mais par rapport à la formation et au prix payé), alors que, avec ou sans modèlisation, seul quelqu'un ayant un esprit méthodique et clair va réaliser quelque chose de clair (ce qui se conçoit bien s'énonce clairement) et donc je doute de l'efficacité (mais c'est juste mon opinion).
Un bon instrument dans les mains d'un médiocre donnera toujours quelque chose de médiocre. Un bon ingénieur , même sans bons "instruments" (dans le sens d'ici) donnera toujours quelque chose de bon...
en Rad , il y a Windev qui vous génère du code
Oui mais est-ce que la génération de code est la solution ? Le code généré est souvent difficilement maintenable car on ne le maîtrise pas
Déjà pour moi Modélisation et RAD sont un peu antinomiques. Je m'explique : le but du RAD c'est quand même d'aller vite avec un cycle de développement itératif et des itérations très courtes. Quand on modélise (et là j'entends par modélisation une modélisation complète avec cas d'utilisation, diagrammes de séquences etc. et pas seulement diagrammes de classes) celà prend du temps.
Si vous allez voir un client et que vous lui expliquez que le logiciel qu'il veut dans 6 mois et bien il ne l'aura que dans 1 ou 2 ans parce-que les 6 premiers mois vous modélisez je ne pense pas qu'il soit satisfait
On a donc 2 approches différentes du développement logiciel qui correspondent à 2 besoins différents.
Ensuite les outils que vous utiliserez ne sont que des outils. Ils peuvent permettre d'aller plus vite en phase de développement (outils MDA par exemple) ou permettre d'avoir un langage commun pour dialoguer (outils UML par exemple).
Le problème aujourd'hui je pense ne vient pas de la qualité des outils ou de la compétence des gens qui les utilisent mais plus du manque de dialogue entre les gens qui ont le besoin, les gens qui commandent et financent le projet (souvent ce ne sont pas les mêmes), les gens qui conçoivent et les gens qui réalisent (là aussi souvent ce ne sont pas les mêmes).
Du coup les utilisateurs ont un besoin qui est souvent restreint par les financiers car ils trouvent que c'est trop cher (sans même avoir consulté ceux qui pourraient réaliser). Dès le départ il y a donc un cahier des charges tronqués par rapport au besoin initial.
En suite ceux qui conçoivent savent déjà tout de ce que veut le client sans même se donner la peine de le vérifier. Là encore il y a un écart entre le besoin et la conception. Et enfin les développeurs en rajoutent une couche parce-que sinon ça ne rentre pas dans le budget, le délai ou alors ce n'est pas réalisable dans l'environnement technique.
Vous prenez tous ces facteurs, vous y ajoutez des contraintes de délai très fortes, un client à qui personne n'ose dire non, vous mélangez bien et le résultat est.... un monumental échec !
Salut,
Personnellement, je trouve que tout est à la fois le pire et le meilleur.
Qu'il s'agisse d'une méthode de modélisation, d'un RAD ou meme, car ce peut etre mis dans le meme sac, d'une méthode d'algorithmie, ce seront les meilleures des choses si les méthodes et les outils sont utilisés dans une seule optique: clarifier et/ou simplifier l'étape suivante...
Ce seront par contre les pires des choses si ce n'est utilisé que dans le seul but d'arriver à ce que l'on veut/attend/souhaite, sans tenir compte des problèmes qui seront rencontrés à l'étape suivante.
Utiliser une méthode de modélisation (quelle qu'elle soit) pour etre sur d'avoir en main l'ensemble des tenants et des aboutissements est tres bien en soit... pour autant que les shémas résultants permettent une implémentation aussi simple que possible.
Utiliser un RAD du genre "drag and drop" facilite énormément la tache... Pour autant que l'on crée l'IHM avec un peu de bon sens...
C'est fou le plaisir que l'on éprouve et le temps gagné par le fait d'obtenir le squelette d'un gestionnaire d'événement (clique sur un bouton, par exemple) simplement en... cliquant sur le dit bouton dans la fenetre en construction.
Mais si l'algorithme qui permettra de gérer cet événement n'est pas bon, ou si les classes qui entre en jeu dans cette gestion d'événement ne sont pas correctement modélisées, il ne pourra rien en sortir de bon
Créer un algorithme est très bien, s'il permet à celui qui devra le coder de ne plus avoir à réfléchir à autre chose que "comment dois-je écrire l'instruction, dans le langage que j'utilise, pour ..."
Il ne faut jamais oublier que la force maximale d'une chaine n'est jamais que celle de son maillon le plus faible, et qu'en l'espece, la faiblesse finale d'un raisonnement ou d'une décision sera exponantielle par rapport au moment où le raisonnement a été suivi ou la décision prise: plus une décision aura été prise tot (ou un raisonnement aura été suivi tot), plus le résultat qui en découle sera faible, si la décision (ou le raisonnement) était faible à la base...
Voilà qui me rappelle une récente discussion avec mon chef de service. Dans ma boîte aussi (grosse boîte dans le domaine du contrôle aérien pour le militaire) le mot MDA est devenu très à la mode. Et même d’autres termes encore : « Software Factory »…
Mon interrogation porte sur le point suivant : en allant vers un niveau d’abstraction supérieur grâce à l’utilisation de méthodes et d’outils de modélisation de plus en plus perfectionnés, quel sera au final le profil du développeur (si l’on peut encore l’appeler comme ça..) ? Par profil j’entend niveau de compétence, formation requise ?
Après 6 années d’expérience dans cette entreprise, j’aurais tendance à faire le constat suivant : je suis amené à travailler chaque jour quasi exclusivement avec des ingénieurs (je le suis moi même - il n’y a de fait quasiment aucun technicien) ou formation universitaire équivalente. Malgré le niveau d’étude moyen assez élevé, et même après plusieurs années d’expérience, je constate que la capacité à l’abstraction est loin d’être aussi répandue que l’on voudrait bien le croire... ne serait-ce que la maîtrise des concepts objet! Alors lorsque traîne le préfixe « méta » dans une conversation…
Après cette longue discussion (animée !), mon chef (adoré ;0) a fini par énoncer la vérité suivante : « Parmi tous les postes d’avenir, ceux qui seront en charge de concevoir et réaliser les (outils de) transformations de modèles ont de beaux jours devant eux car ils auront une très forte valeur ajoutée ».
J’aurais tendance à être d’accord avec lui. De même pour les individus les plus aptes à réaliser une modélisation correcte, ce qui, comme je viens de le dire, ne me semble pas si répandu que cela, car nécessitant de fortes capacités d’abstraction.
J’en viens à ma conclusion : l’utilisation de tels outils et méthodes peut sans doute réduire le nombre de postes ou les intervenants auront à intervenir directement au niveau du code (le terme Software Factory semble même pousser certains très haut manager à croire au concept d’ « ouvrier » du code – sans que j’y vois moi quelque chose de péjoratif, dans leur esprit cela se semble se traduire directement par profil faiblement qualifié, donc à bas coût). D’un autre côté, la nécessité d’une plus grande expertise pour les nouveaux artisans du logiciel ne pourra, me semble t-il, que se traduire par une augmentation du niveau de leur rémunération.
L’un des arguments souvent avancé par mes managers concernant le MDA (et autres) est bien entendu la réduction des coûts (même si ce n’est pas le seul), et bien souvent l’un des seuls qui soir retenu au niveau supérieur…
N’y a t’il pas là une certaine illusion ?
Mais peut-être me faut-il encore quelques années de recul!
Je vais rappeler quelques faits :
- Unix est sorti au début des années 70, et on a produit pendant des décennies les meilleurs systèmes d'exploitation (un OS, ça commence à être un gros projet) avec Vi !
- Linux a été fait par des hackers, sans UML ni autres choses dans ce genre, toujours avec Vi, Emacs et make (j'exagère à peine...)
- gcc, peut-être le meilleur compilateur au monde, a été lui aussi fait avec Emacs, et codé en C depuis 1984 : aujourd'hui, il est toujours activement maintenu
- la JVM aussi...
- bien d'autres encore
La génération automatique de code devrait être cantonnée au domaine des interfaces graphiques et des sites Web... quant à la modélisation, le projet TOPCASED prouve non seulement qu'il s'agit de méthodes compliqées et difficiles à maîtriser, mais qu'en plus, la génération de code certifié N'EST PAS du ressort de la modélisation ou de la méta-modélisation (TOPCASED n'engendre pas de code : ce domaine est un projet à part).
Pour bien programmer, mieux vaut rester simple tant sur les "outils" (ou finit la réponse au besoin et ou commence la création de ce besoin) que sur la programmation en elle-même, l'architecture.
Windows Vista et XP (60 millions de lignes de code !!! soit vingt-mille fois plus gros que la Sainte Bible entière !!!) montrent à quel point ce genre de pratique est néfaste tant au point de vue des performances qu'au niveau de la stabilité et de la maintenabilité (Microsoft est obligé de ré-écrire leur bébé régulièrement).
A l'autre extrêmité se trouve OpenBSD, le système le plus sûr du monde, développé avec des méthodes classiques.
Entre autres, la génération automatique de code concerne énormément les applications java, peu fiables et performantes, toujours plus gourmandes en termes de ressources ; or les ressources s'épuisent aujourd'hui, tant au niveau RAM que fréquence d'horloge/nombre d'instructions par seconde, et ce genre de techniques, si on n'y remédie pas, créera un vrai problème en ce qui concerne les performances des ordinateurs. Les besoins augmentent, les applications grossissent, mais les machines n'évoluent plus.
Quelqu'un plus haut évoquait les techniques utilisées dans l'avionique.
Il faut savoir que, par exmple, chez Airbus, les techniques de modélisation sont très très spécifiques au type de programme. Entre autres, les programmes, qui sont algorithmiquement parlant extrêmement simples, sont modélisés par des circuits de flux de données, ressemblant fort aux circuits électriques, implantés par des langages comme Lustre, très très très peu expressifs. Ceci fait, qu'en fin de compte, on a un schéma énorme de circuit de données pour modéliser des programmes très simples. le même genre d'approche pour des applications de bureautique serait entièrement hors de propos.
Répondre avec citation
Partager