Il faut surtout avoir le soucis de bien et de bien faire quelles que soient le temps et les moyens que çà peut prendre.
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 :
Il faut surtout avoir le soucis de bien et de bien faire quelles que soient le temps et les moyens que çà peut prendre.
J'adore ce genre d'articles bourrés de lieux communs. Je vais ouvrir un blog aussi avec un article.
Comment faire un bon logiciel.
Glutinus, développeur Business Intelligence, nous explique comment faire un bon projet BI.
Alors c'est très simple. Il faut que le sponsor soit chaud bouillant donc on lui fait un POC exprimant le ROI dont il a besoin pour qu'il étale la thune pour faire une bonne équipe.
Les utilisateurs doivent être impliqués et comprendre parfaitement le process. Systématiquement refuser si la spécification de besoin ou le cahier des charges a une incohérence et ne pas lancer les devs.
La MOA et l'AMOA doivent rédiger des spécifications fonctionnelles compréhensibles à 100% par la MOE, et pas du tout vague.
Le chef de projet ne doit rien faire à l'arrache et être à jour dans son fichier excel. Son équipe doit également être composée d'un référent technique, d'un analyste-concepteur, d'un DBA Prod couplé études et des développeurs avec 15 ans d'expérience ainsi que quelques jeunes à la tête bien faites qui se formeront sur des développements.
On ne fait pas de développement sans spec technique validée par tout le monde. Une fois lancé les tests unitaires doivent être détaillés, le code commenté, les specs remises à jour lors des écueils techniques puis un test de performance avec une plate-forme iso DEV / Recette / production.
Les utilisateurs sont impliqués à 100% pour la recette et pas de mise en production le vendredi.
Si tout le projet se passe bien ne pas oublier d'inviter l'équipe MOE et les féliciter au pot de la galette du nouvel an, et pour les prestataires appeler les commerciaux des SSII pour leur dire de verser une prime de 2000€ à chacun d'entre eux.
Vouzenpensezquoi ?
tout le monde crie au loup soit disant que la réponse dépend du domaine, des utilisateurs, de la techno, du projet.
et Non, c'est une réponse de jeune diplômé que vous faîtes en criant plus haut !
Le meilleur logiciel c'est celui qui est k-sécurisé, mettable à jour rapidement et rapidement modifiable et qui rentre dans une logique d'amélioration et de journalisation continue.
Le reste (normé, bien documenté, bien écrit, optimisé, bien nommé dans les variables..etc) est le pré-requis pour un travail de professionnel.
J'entends pas "k-sécurisé, le code dont on connait les limites de sécurité et qu'on a acté en fonction de.
Il est évident que les failles de sécurité ne sont pas forcément "connues" au moment de la programmation.
Un programme maintenable, ça peut être corrigé lors qu'il y a des défauts de fonctionnements, et on a la garantie dans 10 ans l'application tournera encore, y compris sur un autre système (c'est la définition de maintenable).Envoyé par Logan Mauzaize
Un programme impossible à maintenir qui fonctionne aujourd'hui, tu peux être à peu près sûr que 10 ans plus tard soit il ne fonctionne plus (ou il t'a coûté 20 fois le prix d'une maintenance normale)
Après ceux qui bossent en SSII je peux comprendre que fournir un outil qui fonctionne c'est le principal pour être payé (à condition d'en avoir rien à f**** de l'abruti qui devra reprendre le travail).
Dans un monde parfait, je serai d'accord avec toi
Par contre, ce beau principe se fracasse sur le mur des réalités.
Dans le monde réel, tout le monde ne fait pas un travail 100% au carré et bien dans les normes et tu ne peux pas te servir de ça comme excuse
Si tu es développeur, tu ne peux pas dire à ton CP "je me tourne les pouces en attendant que les spec soient validées"
Ton CP va te dire : "commence à développer avec la version beta actuelle des spec et tu ajusteras quand elles seront validées" (si elles sont validées un jour...)
De même, dans le monde réel, on veut un responsable pour chaque chose mais tout le monde veut être responsable de rien car en cas de problème, il faut tjrs un coupable à désigner et pourvu que ça ne soit pas moi...
Du coup, pour la validation des documents...
Hihihi !
Hahaha !
Hohoho !
Sauf qu'un programme qui ne fait pas ce qu'on lui demande ne sert à rien. Encore moins qu'un programme écrit en chinois.
Sinon je me demande pourquoi je met un exemple ... Le code est maintenable, performant, minimaliste mais ne fait pas ce qu'on attend de lui.
Sinon "Make It Work Make It Right Make It Fast".
+1000 Jai déjà mis ce lien il n'y a pas longtemps, mais il illustre tellement bien le débat... Peu importe la méthodologie, tant qu'elle est appliquée par des gnous qui ne comprennent pas ce qu'ils font(un peu moi quand je fais du système, hélas), on va dans le mur. Et, au contraire, n'importe quelle méthodologie peut être détournée par des gens qui savent ce qu'ils font pour obtenir un résultat brillant.Pour avoir de meilleur logiciel, que faut-il faire ?
C'est simple... être meilleur...
alors, certains vont partir dans la direction de l'amélioration des processus (agile, TDD, autres)...
d'autres vont pointer la formation des développeurs, la reconnaissance, etc...
d'autres vont miser sur le temps, l'écoute, le partage...
d'autres vont miser sur la reconnaissance de l'expérience qui permet, normalement (mais pas toujours), d'obtenir de meilleurs choses plus on a l'habitude d'en faire...
-------------
Après, on tape sur les SSII.. mais finalement, la SSII n'est que la réponse a un besoin exprimé par un client...
Les SSSI aimeraient bien vendre des développeurs expérimentés à 500€/jours à leurs clients... sauf que le client (principalement les gros industriels plus que les petites boites) a tendance à croire que développer, c'est simple, facile, rapide et donc, "hurle" dès qu'on lui mets des tarifs élevés.. (d'ailleurs, souvent les entreprises "compensent" le TJM bas par plus de jours de prestations!!!
+1 aussi sur la culpabilité des grands comptes sur l'existence des SSII à la Française. J'en ai vu refuser un expert à 600€ sur 30 jours mais accepter 3 gnous à 350€ 60 jours chacun. Et, au final, les gnous n'ont pas fait ce que l'expert aurait fait - en 30 jours. Mais comme le TJM a baissé, les gens des achats ont eu leur prime.
Que faut-il faire pour avoir de meilleurs logiciels ?
Arrêter de recruter des développeurs comme on recruterait une actrice porno ou un commercial (je ne mets pas les deux dans le même panier).
Et le mec a 100% raison...
Travailler sur les entrées sorties.
Dans la majorité des cas, les logiciels n'acceptent en "entrée" que des formats de fichiers saisis depuis le logiciel et ne permettent en sortie que des formats très restreints.
On rendrait les logiciels bien plus évolutifs s'ils pouvaient admettre en entrée des formats texte (i.e. le logiciel va chercher les infos dans un fichier txt à charge pour l'utilisateur de l'organiser correctement et à charge pour le développeur d'expliciter l'organisation nécessaire du fichier txt) et s'ils permettaient une sortie en format texte permettant de réorganiser les sorties suivants les besoins de l'utilisateur.
Je suis très souvent confronté à des problèmes du genre "je voudrais sortir les états par type d'heure/formateur/formé" mais ce n'est pas prévu par le concepteur à l'origine. Les infos sont dans la machine et si je pouvais les récupérer en format txt je pourrais facilement répondre à la demande sans avoir à intervenir sur la structure du programme.
Salut à toutes et à tous.
Le titre est "Que faut-il faire pour avoir de meilleurs logiciels ?" La question que je me pose est ce que l'on entend pas "meilleurs" ?
Est-ce en terme de bugs technique, de temps de réalisation, de coûts, de fonctionnels, d'objectifs, de faisabilités, d'intégrations, de performances ... et la liste n'est pas exhaustive.
La question n'est pas anodine et encore moins les moyens que l'on va mettre en œuvre pour tenir ses objectifs.
Ce n'est pas en utilisant des outils de versionnages et en respectant la chaine de l'intégration même "en continue" que l'on fait de la qualité.
Les points faibles, car j'en voie trois, sont le respect de "la fonctionnelle", "la rédaction" du code et l'environnement de développement.
a) on pourrait croire que la fonctionnelle est parfaitement rédigée dans le cahier des charges.
Il arrive que des choix faits sont parfois incompréhensibles pour l'informaticien en charge du développement.
Ou pire que ces choix ne sont plus d'actualités car trop anciennes ou pas encore mis en place et personne ne sait de quoi il s'agit.
Si dès le départ, le projet est mal posé, il y a forcement des problèmes que l'on va rencontrer par la suite.
Plus le projet est gros, et plus il y aura des retours sur ces choix, plus cela va occasionner des coûts et des retards.
b) La rédaction du code implique une connaissance des langages informatiques et des méthodes de développements.
Les notions de lisibilités, de performances, voir même de sécurités sont très souvent délaissées pour des raisons de temps.
On s'attache fréquemment au respect de la fonctionnelle, puisque c'est le but de ce que l'on demande au développeur.
La constitution des équipes est importante, tant par la qualité des intervenants, que par leur nombre et les moyens mise à leur disposition.
Sans compter sur la qualité rédactionnelle du code, sur la bonne compréhension du travail demandée et sur les choix à faire.
c) Ce qui est à la charge du développeur est de faire des tests pour supprimer des bugs techniques et de respecter le cahier des charges.
Je nomme cela du travail de plomberie que le développeur prendre en charge par un jeu d'essai de son cru.
Rien avoir avec les tests fonctionnels, de performances, d'intégrations et voire même de productivités.
Pour réaliser cela, il a besoin d'avoir un environnement de test conforme à sa futur mise en production.
Il se peut que les utilitaires à la disposition des développeurs ne sont pas ceux de la production, ou pas dans la même version.
Et voir aussi des problèmes de charges que ont été mal dimensionnés dès le départ.
Le noeud critique se trouve bien au niveau du développeur et du cahier des charge.
Tout erreur ou oublie impliquera en terme de temps, des retards, et en terme de coûts, des dépassements.
Donc, non, je ne suis pas d'accord avec ce Mr. Jim Bird, sur sa façon de gérer la chaine de vie d'un logiciel.
Je prends un exemple afin d'illustrer ce que je ressens. Un lecteur s’aperçoit qu'un livre pose quelques problèmes et de ce fait le signal.
L'éditeur va changer le format du livre en passant du format pocket à un grand format mais rien n'y fait, le problème persiste.
L'éditeur signale à son tour le problème à l'imprimeur qui va changer la qualité du papier. Toujours pareil.
L'imprimeur augmente la taille des caractères, change la mise en page, passe du noir au blanc et met plus de couleur...
L'éditeur ne sachant plus quoi faire passe du format papier au format numérique, pensant que le problème était l'imprimeur.
L'éditeur fait redescendre le problème au correcteur. Le correcteur change sa pair de lunette, de dictionnaires ... mais le problème persiste.
L'éditeur passe à un correcteur automatique ... et signal ce problème au rédacteur.
Le rédacteur pense alors que c'est son écriture qui pose problème et fait quelques efforts. Il change même de stylos, de papier...
Par la suite, le rédacteur demande à une personne de retranscrire son texte afin d'être plus lisible.
Le rédacteur passe alors du papier au traitement de texte. Il utilise même un correcteur automatique de fautes d'orthographe mais rien n'y fait.
Ne sachant plus comment résoudre ce problème, l'éditeur ne sait plus quoi faire et décide de changer de rédacteur en prenant un professionnel.
Et là, au miracle, le problème a totalement disparu.
Morale de cette histoire, ce n'est pas en mettant plusieurs couches que l'on résout un problème, ni en injectant des moyens à de mauvais endroits.
Si dès le départ, on se donne les moyens d'obtenir de la qualité, alors on fera des économies.
Inversement, si on désire faire des économies, alors les objectifs ne seront pas tenus, ni les économies non plus pour cause.
J'ai même entendu dire que l'on ne devrait pas donner cette responsabilité du développement à des informaticiens car cela posait trop de problèmes.
En fait, j'ai entendu toutes sortes d'absurdités de managements dont le problème se trouve dans ces choix et dans la réorganisation de ceux-ci.
Tant que l'on ne se donne pas les moyens d'avoir de la qualité, on a beau réfléchir sur l'organisation du travail et le cheminement des contrôles, le problème persistera.
C'est pourtant une évidence, mais nos dirigeants n'ont toujours pas compris cela. La solution se trouve dans la productivité et non dans la gestion financière.
J'ai parfois l'impression que nos dirigeants recherchent le secret de la pierre philosophale.
On a beau avoir de belle hôtesses, une musique de rêve, dans un endroit très accueillant, et vous vendre un paquet dans un bel emballage, n'empêche que de la merde reste toujours de la merde.
Tout le problème est dans l'approche commerciale où justement la qualité et le facteur humain ont complétement été oubliés car trop onéreux.
@+
excellent blog
Très bon blog
Et, à mon avis , ce blog
reflète exactement les problèmes
Que l'on rencontre
lors du développement
en entreprise.
Je souligne meme sur l'un des points cité,
en général,
si le développement n'ai jamais réellement fonctionnel lors de sa sorti, c'est en majeure parti par le manque d'attention en ce qui concerne les tests QA .
Il ne faut pas avoir peur de tester et retester , jusqu'au point où l'on ai plus aucune appréhension sur les résultats attendus en fonction de notre code.
C'est pour cela qu'il faut aussi s'efforcer
de communiquer à l'équipe entière avec professionnalisme ,en étant convaincant et
d'y transmettre le message,《 donnez nous le temps de tester notre développement avant de l'envoyer en test d'intégration. 》, car la plupart des entreprises sont limites par le temps et donc
l'argent, et au bout du compte dans presque tous les cas ,déficit ou au pire abandon du projet en cours et alors perte d'emplois
Personne n'est capable de créer une
application complexe à la vitesse de la
lumière sans y rencontrer des oublies ou bugs.
À mon humble avis, le développement est basé sur des techniques méthodiques et recherchés avant son départ , ce qui aurait pour but de limiter aussi les coûts des tests.
Avant toute programmation, la chose essentielle est de comprendre le problème a résoudre. Si nous ne maitrisons pas notre problème, nous ne maîtriserons pas la solution.
Cela semble une évidence mais poser convenablement la question est un exercice très difficile qu'il ne faut surtout pas négliger. Mon truc pour me guider dans cette recherche est de me poser continuellement la question: Comment puis-je voir ce problème pour écrire le minimum de code pour obtenir les mêmes résultats? Pour ma part, moins de code impose habituellement, une plus grande optimisation, une plus grande robustesse et surtout moins de code à tester et à maintenir. Tout ce que nous attendons d'un bon logiciel (Et ce sans trop d'effort).
C'est vrai, et en même temps, se mettre à coder permet souvent de comprendre mieux le problème à résoudre. Ce qui implique, tout au long du process de création, de se remettre en question et de vérifier que l'on ne fait pas fausse route, tant au niveau du problème à résoudre, que de la méthode utilisée.
Comme beaucoup, je ne pense pas qu'il faille chercher à faire le meilleur logiciel, mais à faire celui qui réponde au mieux aux besoins et contraintes.
Sur ce point, je ne suis pas d'accord. Avant de coder, il est important de poser le problème [et c'est vrai dans tous les cas]. C'est d'ailleurs à ça que sert généralement l'étape de conception. On se pose des questions, on modélise les possibles réponses et on voit lesquels sont les plus adapté. Et lorsque l'on commence à coder, la solution doit être relativement précise.
C'est une illusion, je crois. On peut beaucoup planifier, mais il y a toujours des surprises. Par définition, une "conception" est un produit de l'esprit humain, et est donc limitée. Il faut la faire, évidemment, parce que ça anticipe un gros paquet de soucis. Mais partir en codant en se disant "y'a plus qu'à" et en croyant qu'on a pensé à tout, c'est un excellent moyen de se planter. Celui qui code est dans un disposition d'esprit différente de celui qui fait la conception de haut niveau, et verra des choses que le concepteur de haut niveau ne verra pas. Ce complément est indispensable.
La forme et le fond
Ce débat est la variante du débat sur la forme et le fond adaptée à la programmation. La forme c'est le codage, le fond l'analyse. Il faut les deux et on sait que c'est indissociable. On comprendra le problème en le codant et on le codera quand on l'aura analysé. Il faut donc faire très tôt des aller-retours entre le code et le cahier des charges et continuer tout au long de l'élaboration du projet. Malheureusement les contraintes de temps et de personnes font que c'est impossible et ...
Attention je vais sûrement faire lever des boucliers:
C'est pour cette raison que dans une équipe "Méthode Agile" il faut 2-3 séniors: c'est pour pourvoir faire la conception avec un retour d'expérience tout en codant et donc avancer plus rapidement en évitant les premières embuches.
Article de Monsieur Jim BIRD: Facteurs de Réussite Logiciel
Je ne suis pas d'accord sur le fond : la "compilation continue", la revue du code par ses pairs, et la "refactorisation" ne sont
pas les clefs principales pour batîr un logiciel complèxe, bien qu'l y contribuent certainement, mais bien moins
que d'autres choses.
En ce qui me concerne, les facteurs principaux sont :
1) Une architecture technique qui represente une solution efficace au problème à traiter, à travers les "design patterns"
qui conviennent le mieux, en vue d'obtenir un code qui : a) marche sans erreurs, b) marche rapidement, de manière
optimisée, c) qui possède une cohérence interne, et une certaine "beauté" structurelle: c'est tout simplement une
re-expression de la fameuse devise de Dennis Ritchie, plus que jamais d'actualité :
"Make it work, make it fast, make it beautiful";
Utiliser le bon algorithme, esquissé sur une feuille de papier, est beaucoup plus important, que le codage précoce avec un algo bancale.
"Réflechir plus et coder moins"
2) Adopter une solution en couches, mais toujours "botton up" (de bas en haut) : l'essentiel c'est de batîr une solution où les différentes
couches techniques et applicatives soient "etanches" , independantes, et surtout testables en isolation;
3) Tester, via un automate, le logiciel, avec des tests unitaires et d'intégration, le plus précocement possible;
4) Redresser des erreurs de conception le plus tôt possible, afin de ne pas mettre en danger les couches qui en
dépendent plus tard, avec un coût differé très élévé;
5) N'utiliser que des technologies qui ont fait leur preuves dans le temps, et qui ont un niveau de transparence, de fiabilité, de rapidité et de
support adéquat; comme corrolaire, il faut que les architectes applicatifs rejettent les outils et techniques qui ne sont ni robuste, ni perenne,
ni accessibls aux programmeurs moyens;
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager