Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quelles sont les bonnes pratiques à mettre en place sur un projet informatique ?

Le 14 mars 2007 à 10:38, par elitost

345 commentaires

27PARTAGES

Bonjour,

Je souhaite écrire prochainement un article sur les bonnes pratiques à utiliser lorsque l'on travaille sur un projet informatique (quelque soit la technique utilisée).

Ce serait une sorte de "table des commandements" (ou de conseils) contenant des points essentiels pour réussir un projet.

Pour le moment, j'ai listé seulement ces quelques points :
- Documenter le code
- Gestion des versions / sauvegardes
- Audit du code
- Tests

Au final j'extraierai de vos réactions les thèmes les plus abordés et/ou qui semblent les plus interessants pour produire l'article.

Et pour vous, quelles sont ces bonnes pratiques ? Et pourquoi ?

Merci d'avance,

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

345 commentaires

Commenter Signaler un problème

souviron34

Expert éminent sénior

Le 14/03/2007 à 23:22

Moi dans les bonnes pratiques (pour les gros projets) je dirais principalement :

1) Avoir une PETITE équipe
(aucun projet à grosse équipe (> 12 personnes) que j'ai vu n'a marché)
2) Avoir une "équipe de direction" à 2 têtes, avec un chef de projet/informaticien et un représentant utilisateur expert, en permanence tout au long du projet. Eventuellement y adjoindre un ergonome tout au long u projet. Sinon en prendre un au départ, en vue de la conception initiale.
3) Aucun protocole de "consensus parmi les utilisateurs" pour définir les fonctionalités et leur architecture..
(le représentant expert des utilisateurs les interroge, normalement avec un ergonome, et c'est LUI qui tranche).
4) Avoir une équipe de gens venant d'horizons différents, d'expériences différentes
5) Avoir une analyse claire du besoin
6) SURTOUT ne pas se soumettre aux normes de documentation et d'architecture d'équipe à la lettre.
En particulier pas de hiérarchie Chef de projet / Architecte fonctionnel / Architecte système / Analyse programmeur / Programmeur...
A chaque étape du papier, à chaque étape une retraduction , à chaque étape on perd de l'information 'principe du "téléphone arabe". De plus, à chaque étape on perd du temps, et le papier ne suit JAMAIS les modifications...
En particulier il est ABSOLUMENT INUTILE de faire un dossier de maintenance de 500 pages. Personne ne le lira. Un maximum de 5 pages (et encore) sera le maximum qu'une personne chargée de trouver un bug passera avant d'aller fouiller dans le code....
Même chose pour une doc d'installation (ai dessus d'une page c'est déjà trop, surtout si on s'adresse à des informaticiens)..
7) conséquence du 6 : avoir une équipe de gens compétents, mais autonomes, en qui on a confiance, et à qui on délègue l'ensemble conception préliminaire / détaillée / réalisation / documentation.
8) Avoir le soutien de sa hiérarchie en cas de problème (dépassement), mais aussi mise en avant de l'équipe par la hiérarche en cas de réussite.
9) Mettre des commentaires dans le code
10) Coder en pensant que 1) ce sera repris par d'autres, 2) personne n'est irremplaçable, mais aussi 3) quand même chacun est un peu irremplaçable..

Pour le reste, je laisse le soin aux autres, avec ce qu'ils ont dit ci-dessus et diront plus loin..

Mais ceci est basé sur mon expérience de 23 ans, dont 5 très très gros projets industriels (ce qui s'appelle pudiquement "mission critical software"

...

souviron34

Expert éminent sénior

Le 16/03/2007 à 13:17

je rajouterais comme point fondamental :

avant tout avoir et garder du bon sens

c'est à dire :

ne pas choisir une techno et s'y maintenir alors que d'autres permettraient de faire la même chose plus simplement
ne pas choisir une techno en fonction du "buzz" à la mode
ne pas utiliser un marteau pour écraser une mouche (exemple prendre OracleTM pour gérer une BD à 4 clés)
ne pas utiliser tout un tas d'algos sophistiqués alors qu'une simple réflexion peut amener une solution simple (et donc compréhensible et maintenable facilement)
ne pas continuer à dire "c'est dans la spec on fait comme ça" si on s'aperçoit que la demande/la conjoncture a évolué
ne pas dire dans une réunion d'avancement "on discute pas de ça mais de la proposition machin truc" alors que le "ça" résout peut-être le problème
ne pas utiliser une lourde gestion de projet pour une équipe de 5 personnes
ne pas oublier que ce qu'on veut faire, c'est ce qui est demandé (eh oui, ça a l'air évident, mais dans la plupart des gros projets, au fur et à mesure du temps qui passe, on oublie ça..) pour les utilisateurs auxquels s'est destiné...
si un utilisateur ne comprend pas un mot, une fonction, etc... c'est qu'il faut réviser sa copie. Ce n'est pas à lui de s'adapter, mais à l'info. de l'aider..
........

En bref être souple et avoir du bon sens...

C'est ce que je voulais dire sur l'application des normes, qu'elles soient de gestion ou de programmation.

NOTE : je chercherais dans mes docs pour scanner, j'ai quelques références explicites, y compris dans des compilations de normes.. Mais sans doute quelque part d'ici la semaine prochaine...

souviron34

Expert éminent sénior

Le 17/03/2007 à 2:27

Envoyé par mhamedbj

si j'ai bien compris il faut préciser ses objectifs dés le début et ne rien changer en cours de chemin ?

Euh !!!! Me suis-je si mal exprimé que ça ?? c'est le contraire que j'ai dit (comme je l'ai redis ci-dessus)...

Avant toute chose, du bon sens et de la souplesse.

Ensuite, oui il faut qund même une idée claire et précise de ce qu'on veut faire (rajouter une sous-sous fonctionalité plus tard n'est pas mortel, par contre oublier une fonctionalité principale (et même une sous fonctionalité) au départ peut s'avérer dramatique , au point d'avoir à tout casser et refaire..

Mais au vu de ce que tu dis, vous devriez d'abord (visiblement vous avez déjà commencé à coder, et c'est une grave erreur) lire différentes normes de développement, et vous imprégner de ce qu'on a besoin de faire à chaque étape du cycle normal.

Une fois ça fait, vous pouvez commencer le cycle de développement , avec une analyse et une spécification globale, succinte mais complète.

A partir de là, pour moi, on rentre plutôt dans ce qui maintenant s'appelle "les méthodes agiles", mais que j'ai toujours utilisées et vu utiliser autour de moi (et les cas où c'était pas utilisé ont foiré...

).

Mais sans en savoir plus sur le projet, il me semble d'après la description que tu en fais que vous allez vers l'échec, si vous partez dans tous les sens et que vous n'avez pas les bases du cycle en tête....

Donc le seul conseil en l'état est de dire : arrêtez vous tout de suite. Prenez le temps (une semaine, 2, 1 mois) de bien lire et vous pénétrer des différentes normes de développement (en gros bien sûr) mais du cycle en V en entier...

Et ensuite, surtout ne codez rien......

Réunissez vous si c'est collégial, sinon juste le chef, doit "pondre" une spécification.... c'est à dire au moins l'arborescence ordonnée des fonctionalités et le genre de paramètres/ressources nécessaires à chacune.

mhamedbj

Membre confirmé

Le 17/03/2007 à 11:57

merci infiniment !!!!!!!

chabz

Membre du Club

Le 19/08/2011 à 15:06

Envoyé par B.AF

Oui mais là c'est une question d'apprentissage et de personne.

Mais on ne peut pas demander à quelqu'un qui sort de l'école d'avoir innée la science de la satisfaction d'un client, il ne sait pas ce que c'est.

C'est de l'expérience et de la maturité et aussi une question d'encadrement.

On ne peut pas demander à un développeur qui n'a jamais pu discuter avec un client ou voir la réaction d'un client final à son travail en prendre compte dans son travail quotidien.

Ce n'est pas que la plupart des développeurs ne comprennent pas les clients, c'est que la plupart des organisations empêche le développeur de s'imprégner des attentes du client et qu'ils font ce que d'autres interfaces relatent comme étant le souhait du client.

Bonjour, j'ai suivi la discussion en cours et je tiens à apporter ma petite expérience personnelle. Je suis étudiante ingénieur en technologies de l'information pour la santé. Comme dit dans un post précédent, ma formation n'est pas faite pour que je sois développeur. Elle est faite pour faire le pivot entre les développeurs et les utilisateurs.

On nous a appris à développer, mais on n'est certainement pas les meilleurs pour ça. Mais ce dont on nous a rabâché les oreilles pendant toute notre formation c'est : "des ingénieurs qui nous disent comment faire, y'en a des cars entiers, des ingénieurs qui nous disent pourquoi, c'est ça qu'on veut", on nous a tanné avec les feedback utilisateurs, en nous disant clairement :"on vous empêchera de voir vos utilisateurs finaux, mais c'est à eux qu'il faut parler pour concevoir votre produit", on a dit que ça serait pas facile. Ils nous ont mis en projet, pour découvrir les outils de gestion de projet qu'on avait eu en cours juste avant. Et je peux vous dire que la différence entre la théorie du archi logicielle et la réalité, on sait qu'elle est énorme et encore, nous, nous étions de bonne volonté pour appliquer ce qu'on nous avais enseigné. Mais surtout, dans ces outils de gestion, on nous a fait comprendre que ce n'était que des outils, et que l'important, c'était de savoir où on allait, et être sur que c'est là-bas qu'il faut aller. C'est pour ça aussi qu'on a eu 1/3 de notre formation sur le monde de la santé et sur son informatisation. On doit comprendre et savoir ce que c'est cet univers qui a des besoins très particuliers en informatique. Enfin bref, tout ça pour dire que oui, les écoles d'ingé ne forment peut-être pas les meilleurs chef de projet, mais je sais que ma formation m'a donné tous les outils pour.

GrandFather

Expert éminent

Le 18/10/2011 à 12:03

Envoyé par souviron34

D'abord il est résolument idiot de former des gens à "ingénieur en technologies de l'information pour la santé". Les technologies pour la santé sont des technologies.

Toujours aussi péremptoire, hein ?

La technologie de la santé reste certes de la technologie (belle tautologie, au passage), il n'en reste pas moins qu'un bug dans un logiciel de gestion commerciale, bien que fâcheux, n'aura pas les mêmes répercussions qu'un bug dans un système expert d'aide au diagnostic... Les exigences en matière de qualité n'étant pas les mêmes, les projets dans ce secteur obéissent à des règles, des normes techniques et à des impératifs juridiques spécifiques. Il n'est donc pas idiot, contrairement à ce que tu formules de manière assez désobligeante, d'être formé spécifiquement à ce domaine, sachant que la maîtrise technologique est nécessaire mais pas suffisante pour exercer une activité d'ingénieur.

souviron34

Expert éminent sénior

Le 18/10/2011 à 15:46

Envoyé par GrandFather

Toujours aussi péremptoire, hein ?

Quant on touche à ce sujet, ma foi, oui, puisque j'y ai travaillé quand même une bonne dizaine d'années, de la recherche R&D industrielle (dans le labo central d'un des 4 grands groupes mondiaux) à la fabrication de machines d'IRM (dans l'un des 7 fabricants mondiaux à l'époque) et au Dossier Médical (dans l'un des 6 projets existants à l'époque).. (et que, dans ces projets et mes équipes, j'ai vu dépenser 175 millions de francs en France et 85 millions de dollars au Canada)

(et, soit dit en passant, en France ça a été pour 2 équipes de 12 personnes, ces sommes-là..)

Envoyé par GrandFather

La technologie de la santé reste certes de la technologie (belle tautologie, au passage), il n'en reste pas moins qu'un bug dans un logiciel de gestion commerciale, bien que fâcheux, n'aura pas les mêmes répercussions qu'un bug dans un système expert d'aide au diagnostic...
Les exigences en matière de qualité n'étant pas les mêmes, les projets dans ce secteur obéissent à des règles, des normes techniques et à des impératifs juridiques spécifiques. Il n'est donc pas idiot, contrairement à ce que tu formules de manière assez désobligeante, d'être formé spécifiquement à ce domaine, sachant que la maîtrise technologique est nécessaire mais pas suffisante pour exercer une activité d'ingénieur.

Ce qui est également vrai pour les avions, les trains, les voitures, les satellites, bref tout un tas de systèmes logiciels dits "critiques", qui, tout en ayant chacun des contraintes légales et judiciaires spécifiques, n'en ont pas moins en commun d'être des logiciels...

Je n'ai qu'un (tout petit peu) touché à la gestion, mais ma carrière s'est faite sur ces fameux logiciels "critiques", et que ce soit le logiciel de décision de fermeture d'un aéroport, ou celui d'une machine d'IRM, il n'y a pas vraiment de différence de fond : faire un logiciel béton, à l'épreuve de tout de cqui est envisageable, résistant aux pannes, et dispo 24/24 7/7 365/365

C'est pourquoi j'ai dit cela : que l'on soit CP ou programmeur, si l'on est dans un des domaines "critiques" (c'est à dire où la vie de gens est en jeu), que ce soit la robustesse, les spécificités légales (avoir un avion militaire qui crashe n'est pas la même chose qu'avoir un avion civil, faire un logiciel pour une machine d'IRM ou pour une machine de prise/analyse de sang ou un logiciel de gestion du dossier médical ne rencontre pas les mêmes écuels juridiques) est relativemnt commun à tous, et le nombre de domaines est relativement infini, et la capacité de les absorber est à mon avis ce qui est demandé dans l'industrie, pas une connaissance ponctuelle ciblée, mais justement parce que ponctuel dépendant de l'état des lois et de la techno... On demande en réalité un esprit ouvert sur l'avenir et une réflexion indépendante de la technologie, pour si possible rassembler justement sous une même problématique des choses qui n'ont pas l'air d'être liées, ou au contraire dissoicier des choses qui ont l'air liées mais éthiquement ou pratiquement ne le sont pas...

Alors soit on forme des CP "trains", des CP "santé", des CP "avion", des CP "machine truc", et on n'a pas fini de ne PAS pouvoir comparer, et de plus on "bouche" l'avenir de ces formés, ou bien on forme plus général, des "têtes bien faites plutôt que bien pleines"...

On s'étonne du chômage des jeunes, et du pourcentage d'échecs des projets, resté le même depuis 20 ans... Pas trop étonnant.... sur les 2 plans...

souviron34

Expert éminent sénior

Le 18/10/2011 à 16:08

Envoyé par Luckyluke34

Réduire "les outils pour la santé" à l'affaire du dossier médical personnalisé et à la dimension sécurité sociale me parait un raisonnement légèrement tronqué. Un peu comme si on disait que l'aviation était une cause perdue à cause du crash de l'Airbus Rio Paris... L'informatique dans le domaine de la santé et du médical, c'est bien plus vaste que ça.

OK, mais alors la plupart de ces softs rentrent soit dans le cadre de logiciels industriels (pilotages de machine) soit de logiciels de traitements d'images, auquel cas ils sont communs à l'analyse des images satellites, à la géomatique, à l'astronomie, aux jeux vidéo, etc, soit ce sont des logiciels de gestion...

Pourquoi donc les différencier par un domaine, et non pas par leur "communauté" d'intérêt ???

Envoyé par Luckyluke34

Ben pourquoi ? Il existe bien des écoles spécifiques pour former les développeurs de jeux vidéo... Je ne vois pas en quoi se spécialiser dans un domaine d'application de l'informatique est mauvais en soi, du moment qu'on y acquiert aussi les bases généralement admises en génie logiciel, etc.

Le jeu vidéo est, aussi bien économiquement que pratiquement, un ensemble relativement défini, dont l'utilisation est, comme son nom l'indique, purement ludique..

Cependant son domaine d'application et ses plateformes sont relativement bien définies, et surtout son contenu est "virtuel".

Comme je dis dans le post ci-dessus, "le domaine de la santé" n'est pas un domaine, et recouvre différents types de logiciels, qui eux sont à regrouper avec d'autres d'autres domaines..

C'est pour ça que je trouve ça absurde..

Envoyé par Luckyluke34

C'est une constante quel que soit le domaine mais il est idiot d'y former les gens ? J'avoue que je comprends pas trop là

Simplement parce que des solutions existantes dans un domaine ne sont pas forcément les bonnes solutions, et qu'il faut voir ce qui se passe dans d'autres domaines..

Et que, en ce qui concerne l'ergonomie des logiciels, c'est un problème général, et dont la solution n'est pas dans la dépendance des intervenants par rapport au métier, mais au contraire dans "l'horizontalité" et la perméabilité des connaissances d'un domaine à l'autre, avec une vue plus généraliste bien que "au courant des technologies du domaine"..

Que l'on forme des gens à ça, très bien. Mais il n'y a pas "une ergonomie des logiciels de la santé" par rapport à "une ergonomie des logiciels de la gestion" ni par rapport à "une ergonomie des logiciels d'avion"..

Et donc j'avoue être plus que dubitatif quant aux sorties de gens formés avec une optique de domaine particulière...

Envoyé par Luckyluke34

Il n'empêche qu'il y a des outils plus ou moins adaptés à chaque situation, et il est bon que la formation initiale donne un premier vernis sur ces outils et leur utilisation... Même si effectivement rien ne remplace l'expérience.

Voir toutes les discussions ci-dessus...

Je suis d'accord, c'est juste la manière de présenter :

les écoles d'ingé ne forment peut-être pas les meilleurs chef de projet, mais je sais que ma formation m'a donné tous les outils pour

Non, elle a donné un survol de quelques outils pouvant être utiles... (ou pas)

Sans plus..

mchk0123

Membre éclairé

Le 14/03/2007 à 15:47

Tu peux rajouter aussi :

- conventions d'écriture (pour améliorer la lisibilité et la maintenance)
perso. j'utilise les conventions GNU (il existe un document bien fait)

- respect de métriques calibrées pour le projet (à une époque j'avais lu un
article de Grady Booch qui était extraordinairement clairvoyant dans le
cadre de la POO)

- conception & modélisation visuelle (UML, ...)

- bug tracking pour les grosses applications et/ou commerciales

- espace collaboratif et de diffusion d'informations (pas que pour le code
source, mais aussi pour la doc, les forums, les news, ...)

... la liste peut être trés longue

elitost

Expert éminent

Le 14/03/2007 à 16:48

Envoyé par mchk0123

- conventions d'écriture (pour améliorer la lisibilité et la maintenance)
perso. j'utilise les conventions GNU (il existe un document bien fait)

Aurais tu le lien vers ce document ?

Sinon, oui la liste peut être longue, le but étant d'extraire les principales bonnes pratiques.

D'autres contributions ?

Commenter Signaler un problème