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 , par elitost

27PARTAGES

0  0 
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-le nous !

Avatar de souviron34
Expert éminent sénior https://www.developpez.com
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"...
7  1 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
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...
3  0 
Avatar de GrandFather
Expert éminent https://www.developpez.com
Le 18/10/2011 à 12:03
Citation Envoyé par souviron34 Voir le message
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.
2  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 17/03/2007 à 2:27
Citation 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.
1  0 
Avatar de mhamedbj
Membre confirmé https://www.developpez.com
Le 17/03/2007 à 11:57
merci infiniment !!!!!!!
1  0 
Avatar de chabz
Membre du Club https://www.developpez.com
Le 19/08/2011 à 15:06
Citation Envoyé par B.AF Voir le message
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.
1  0 
Avatar de mchk0123
Membre éclairé https://www.developpez.com
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
0  0 
Avatar de elitost
Expert éminent https://www.developpez.com
Le 14/03/2007 à 16:48
Citation 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 ?
0  0 
Avatar de mchk0123
Membre éclairé https://www.developpez.com
Le 14/03/2007 à 16:53
En anglais :

http://www.gnu.org/prep/standards/

Il existe surement une traduction française, ... à trouver sur google :
GNU coding standards (fr : conventions/standards de codage GNU).
0  0 
Avatar de mhamedbj
Membre confirmé https://www.developpez.com
Le 14/03/2007 à 18:56
pour la modélisation UML faut il la faire a fure et a meusure qu'on avance? une fois fini (avec le reverse engineer)?, avant de commencer a taper du code ??,
pq si on le fesait avant de taper le code et qu'on se rend compte qu'on s'ait planter et qu'il faut revoir une certaine partie du programme(ce qui est frequent!!! ).... il refaire les diagrammes dans ce cas et c'est pénible !!!
0  0