Discussion :

[el_slapper]

je dirais que peu importe la méthode, pour peu qu'on en aie une. UML est une méthode très efficace, pour peu qu'elle soit appliquée par des bons. Mais avec une méthode "faite maison", ils peuvent aussi avoir un bon résultat. La seule différence, c'est qu'une méthode standard comme UML est compréhensible plus facilement en dehors du projet - d'ou son succès. Par rapport à une bonne méthode maison, UML n'apprte rien - si ce n'est cette ouverture au monde extérieur. C'est suffisant à mon sens. Mais il faut des gens capables, de toutes façons.

et je suis d'accord pour "qui ne connait rien à l'informatique", voire qui s'en méfie, ou cherche à la planter parceque c'est son ennemi. un bon plan test commence par : "on cherche la faille", "cas non passants", et se termine par "cas exotiques pas prévus dans les specs".....(plus de la moitié des anomalies levées sur le dernier projet ou j'ai fait de l'homologation étaient hors-specs, ou implicites).

[osia1]

Es tu bien sûr de coder à partir du CDC ? et non à partir des spécifications ?[/QUOTE]

Il faut absolument respecter le cahier des charges, mais je ne comprends pas trop ce que tu veux dire "à partir des spécifications"...

[el_slapper]

je suppose : le cahier des charges est établi en premier lieu, et contient l'ensemble des désidératas utilisateurs
les spécifications, elles, détaillent l'intégration du cahier des charges dans le système d'information. C'est une étape en aval. Le programmeur est supposé partir des spécifications, pas du CdC.

exemple de CdC :
_pour saisir un client, on crée un compte "indisponible" que l'on alimente avec la somme saisie, et 60 jours plus tard, on transfère le montant du compte au trésor.

specifications correspondantes
_le compte aura la structure X, il sera sur la même agence que le compte débité()
_il sera consultable mais non accessible en modification par quiconque
_le transfert se fera par l'outil Y.....

le programmeur doit évidemment se baser sur les specs, vérifier qu'elles correspondent au cahier des charges, et anticiper les cas tordus(message d'erreur propre en cas d'erreur à la création, retour si le transfert se passe mal, gestion du client qui change d'agence, ou quitte la banque, ou décède.....)

[osia1]

A d'accord je n'avais pas compris, ce que je voulais dire c'est que le programmeur se base d'abord sur le cahier des charges pour savoir le résultat que veux le client mais après il adapte selon le type de programmation, forcément il ne codera pas pareil si c'est pour un site web ou un programme en java... Mais il doit avant tout arrivé au résultat du cahier des charges...

[_vince_]

plus de la moitié des anomalies levées sur le dernier projet ou j'ai fait de l'homologation étaient hors-specs, ou implicites).

Si ce n'est pas dans les specs, une anomalie n'est pas une non-conformite.

Mais l'utilisateur peut dire que le logiciel ne respecte pas l'etat de l'art (e.g. non robuste a toutes les donnees d'entree corrompues)

[smatador]

je dirais que peu importe la méthode, pour peu qu'on en aie une. UML est une méthode très efficace, pour peu qu'elle soit appliquée par des bons. Mais avec une méthode "faite maison", ils peuvent aussi avoir un bon résultat. La seule différence, c'est qu'une méthode standard comme UML est compréhensible plus facilement en dehors du projet - d'ou son succès. Par rapport à une bonne méthode maison, UML n'apprte rien - si ce n'est cette ouverture au monde extérieur. C'est suffisant à mon sens. Mais il faut des gens capables, de toutes façons.

Le problème c'est qu'UML n'est pas une méthode.

[chiltbrand]

Pour moi ce qu'il faut éviter à tout prix, ce sont les "zones d'ombres" car lors de la livraison finale c'est toujours sur ces points de détails que l'on a minimiser et laissé de coté dans les spec qui ne correspondent pas avec le désir du client.

Certaines fonctionnalités, qui paraissent simples au premier abord, dépendent fortement des méthodes de travail du client et si l'on implique pas ou peux le client lors de la rédaction des specs, cela engendre ce que j'appelle des "zones d'ombres". Le choix de la méthode de travail étant laissée à l'appréciation du ou des développeurs, elle ne correspond que rarement à la méthode de travail du client final.

[super_navide]

Voici les bonnes pratiques pour moi :

Faire un prototype le plus tot possible pour éviter de devoir refaire des choses car la MOA et la MOE se sont mal comprit.

Diviser pour mieux régner en faisant des petits lots.

Utiliser des test units (JUnit CUnit etc ...)

Mutualiser les cas de tests les enregistrer dans une base de donnée par exemple.

Il vaut mieux en code mal écrit et bien documenté avec de nombreux cas de tests qu' un code propre correspondant à la norme en vigueur sans documentation et sans cas de tests.

La notions de style de programmation n'est valable que si ca vérification est automatisé.

[_vince_]

Il vaut mieux en code mal écrit et bien documenté avec de nombreux cas de tests qu' un code propre correspondant à la norme en vigueur sans documentation et sans cas de tests.

Il vaut mieux un code bien écrit avec des cas de tests qui verifient les fonctionnalites les plus importantes. Car personne n'a envie de maintenir un code mal ecrit.

Et quelques remarques pele-mele :

Il faut aussi penser a mettre les numeros des exigences dans les fichiers source (tracabilite verticale). Ca permet de savoir quels fichiers source implementent quelles fonctionnalites.

Mais il y a tellement de chose a dire... Un point important est de pouvoir connaitre a n'importe moment quelle baseline on doit implementer. Ca necessite donc de pouvoir tracer tous les changements en cours.

Et un ouvrier a de bons outils: un outil de GED pour la doc, c'est incontournable !

[LoDev]

Bravo pour ce débat. La discussion est enrichissante et m'a permis de prendre de nombreuses informations et de mettre des étapes sur des choses que je faisais machinalement.

Je suis sur ma première expérience de développement. Pas d'équipe, je m'occupe de tout. J'ai du reprendre 4 applications sans aucune documentation, ni diagramme. Juste un peu de commentaires. Sincèrement, heureusement que mon chef ne m'a pas mis la pression parce que c la misère.

En pratique:
1) Analyse de la demande. Comment l'intégrer et les conséquences pour le reste de ou des applications?
2) Décomposer en un diagramme général
3) Décomposer les étapes du diagramme, soit en sous diagramme, soit en texte. Il arrive fréquemment que cette étape me fasse revenir à l'étape 1.
4) Définir les éléments critiques ou non, puis réfléchir aux tests.
5) Codage
En général, je commence par coder une partie, je valide, je teste...
6) Test complet de l'application

Pour la documentation, j'ai créé un document par application pour les mises à jour. Mais, même moi j'ai du mal à le mettre à jour à chaque développement. C'est simplement un document word avec la liste des développements à réaliser et les mises à jour faites.
Si qqun connait un bon moyen de répertorier les bugs et les correctifs...

Pour la mauvaise pratique, je vous présente le "responsable" de l'équipe de dév de mon ancienne boîte. J'étais au support client et ont été débordé par les appels.

Mauvaises pratiques sur une équipe d'une dizaine de développeurs:
1) je rentre dans l'open space.
2) je pousse une gueulante, car le client vient de m'en mettre une.
3) je prend le 1er développeur.
4) je lui dis de faire ça en lui criant dessus, parce que je suis très très énervé.
5) je retourne dans mon bureau.
Ensuite,
6) le développeur n'a pas tout compris, aucun écrit (juste la gueulante). Mais comme j'ai crié fort, tout le monde peut l'aider, comme tout le monde a entendu.
7) il développe comme il peut. Un peu le principe du téléphone arabe.
8) Comme c ultra urgent, on met en prod.
9) comme c pas testé, ça marche pas.
10) on désinstalle.
11) comme le développeur a fait n'imp, je lui passe une branlée, en lui disant qu'il n'a rien compris, que c un nul. Comme le client n'a pas su utiliser un truc qui marchait pas, c'est un con.
Après, on repasse au 3). En général, il changeait de développeur à chaque fois.

C cyclique, cherchez pas la fin.

[jeromek]

Hello,

Moi du coté analyse avant de coder le projet, le pense que la réalisation de diagrammes des cas d'utilisation (en passant par la rédaction des scénarios qui seront effectués par le produit final).

Ça permet déjà de dégager une idée globale de ce que doit faire le produit fini,
de présenter sa propre réflexion/réflexion du groupe de travail aux différentes personnes à l'origine de la demande. En effet toute personne n'est pas forcément capable de bien percevoir un diagramme de classes UML tandis qu'avec ce type de diagrammes les concepts et règles de gestion abordées sont beaucoup plus perceptible/compréhensible. Comme on dit par chez nous, un BON dessin vaut mieux qu'un long discours

La méthode d'extrême programming (quand c'est possible) permet également de bien gérer le déroulement du projet.

Extreme_programming

[_vince_]

Si qqun connait un bon moyen de répertorier les bugs et les correctifs...

Dans les outils de suivi de bugs, j'ai entendu parler de ces outils open-source:

a) "trac" permet de suivre les bugs et de definir des "milestones" avec les dates des prochaines versions a venir et les corrections prevues.
http://fr.wikipedia.org/wiki/Trac_(logiciel)
Avec un plug-in pour CVS ou subversion, tu peux faire reference au numero du bug dans le message de commit. Tu peux donc voir facilement pour chaque bug ce qui a ete change dans le code.

b) Et l'outil bugzilla: http://www.bugzilla.org/

Je dirais que quelque soit la taille du projet, c'est un outil indispensable.
De plus, ecrire un bon rapport de bug, c'est un metier a part entiere.
Pour chaque anomalie, il faut noter la version du logiciel utilisee par le client, le comportement anormal, le comportement attendu, les etapes pour reproduire le probleme, les pieces a convictions, etc. Ce rapport doit decrire les faits techniques et doit etre denue de tout sentiment ou emotions. Ca ne doit par etre ressenti comme une soufflante par le developpeur.

Les bugs sont inevitables. N'importe qui ayant ecrit un peu de code le sait.
Et dans le meilleur des mondes, les testeurs ne sont pas les developpeurs. Si le developpeur teste lui-meme le logiciel il ne verra pas s'il a oublie une fonctionnalite ou oublie un cas particulier. De toute facon, c'est mieux d'avoir un autre regard pour tester.

[cladsam]

alors un truc bête qui me passe par la tete mais que je vis comme un torture en ce moment : BIEN FIXER LE PERIMETRE DU PROJET.
Que les exigences et le code change parcequ'il faut de plus en plus s'orienter vers l' iteratif et les méthodes de dév modernes avec prototypage rapide ca je suis pour. Par contre changer l'objectif meme du projet N fois en cours de route c'est une catastrophe

EX: actuellement je travaille sur un projet SAP, le SAP est connecté a 3 appli, une qui lui fourni des données, les 2autres auxquelleq il fourni des données.

le but initial est de mettre de nouvelle fonction dans ce SAP et en particulier intégré de nouvelles données depuis le système source, en envoyer de nouvelles à l'un des systèmes cibles et maintenir les données envoyées au 2eme système cible.

Sauf que : les exigences sur les nouvelles fonctions bougent >> ca ok c'est le ko c'est le côté itératif
Mais : on ne sait pas si au final l'un des 2 systeme cible ne va pas etre supprimé ou remplacer par un autre >> pour moi c'est un autre projet.

Il va y avoir une montée de version sur SAP et son 2eme système cible >> pour moi c'est un autre projet

On risque à terme de remplacer le système source >> autre projet

résultat on perd un temp fous à prévoir tout et son contraire et niveau conception d'architecture c'est assez limite ^^

[berceker united]

Pour moi ce qu'il faut éviter à tout prix, ce sont les "zones d'ombres" car lors de la livraison finale c'est toujours sur ces points de détails que l'on a minimiser et laissé de coté dans les spec qui ne correspondent pas avec le désir du client.

Certaines fonctionnalités, qui paraissent simples au premier abord, dépendent fortement des méthodes de travail du client et si l'on implique pas ou peux le client lors de la rédaction des specs, cela engendre ce que j'appelle des "zones d'ombres". Le choix de la méthode de travail étant laissée à l'appréciation du ou des développeurs, elle ne correspond que rarement à la méthode de travail du client final.

Parfaitement d'accord avec toi. Le phénomène de zone d'ombre est très vicieux et peut mettre en péril la date de fin d'un projet.
Dans l'équipe ou je me trouve nous avons eu ce cas là. Celui qui devait valider les specs pensait de manière totalement naturel que nous avons inclus certaines fonctionnalité. De notre coté nous pensions tout naturellement que la fonctionnalité que nous proposons était ce qu'il fallait. Cette zone d'ombre a fait que nous avons continuer sans s'inquiéter jusqu'à que l'affaire nous tombe dessus.
Un peut comme les deux équipes aéronautiques américaines ont perdu une sonde parce qu'ils travaillaient avec des unités de mesure différente mais pour eux chacun pensait que l'autre travaillais sous le même système. Cela leur paraissaient totalement normal. Mais voila...

En résumé, même si des choses paraissent évidentes il faut le noter noir sur blanc.

[_vince_]

Dans l'équipe ou je me trouve nous avons eu ce cas là. Celui qui devait valider les specs pensait de manière totalement naturel que nous avons inclus certaines fonctionnalité. De notre coté nous pensions tout naturellement que la fonctionnalité que nous proposons était ce qu'il fallait. Cette zone d'ombre a fait que nous avons continuer sans s'inquiéter jusqu'à que l'affaire nous tombe dessus.

Penses-tu que ca aurait pu etre evite ou diagnostique plus tot avec un plan de tests fonctionnels porte a la connaissance des developpeurs ?

[berceker united]

Penses-tu que ca aurait pu etre evite ou diagnostique plus tot avec un plan de tests fonctionnels porte a la connaissance des developpeurs ?

En faite, ça été découvert ainsi par le principal utilisateur. La phrase dit "Mais ! nous ne travaillons pas comme ça ". C'est tout les fonctionnels qui à été revus. C'est lié à un petit détails qui à tout changé.

[el_slapper]

Penses-tu que ca aurait pu etre evite ou diagnostique plus tot avec un plan de tests fonctionnels porte a la connaissance des developpeurs ?

la question n'est pas pour moi, mais je prends quand même.

si les développeurs prennent le temps de bien lire tout le plan, alors oui. Si ils sont surbookés et qu'ils le survolent, ils ne verront pas grand chose. Et ils perdront bien plus de temps par la suite. Ma dernière mission en homologation, les programmeurs bossaient dans un contexte de retard permanent(à cause de délais mal fixés au départ). Ils avaient accès libre à mes cas-tests(sous Test Director).

Pourtant, il y a des cas-tests dont j'étais sur qu'ils allaient provoquer des anomalies. Parcequ'ils n'avaient pas le temps de se plonger là-dedans, et de comprendre toutes les subtilités. Et, évidemment, j'ai eu le bug attendu(je ne suis plus un perdreau de l'année).

[super_navide]

Aussi une chose très important prévoir un budget de refonte de code avant
toutes évolution pour éviter que le code se dégrade en qualité.

Mieux vaut procéder ainsi que d'éssayer de faire un code trop générique.

[_vince_]

la question n'est pas pour moi, mais je prends quand même.

C'est l'interet d'un forum

Pourtant, il y a des cas-tests dont j'étais sur qu'ils allaient provoquer des anomalies. Parcequ'ils n'avaient pas le temps de se plonger là-dedans, et de comprendre toutes les subtilités. Et, évidemment, j'ai eu le bug attendu(je ne suis plus un perdreau de l'année).

Trouver les cas particuliers, subtilites et les bugs potentiels avant les utilisateurs, c'est deja une petite victoire en soit. Et ca montre l'interet d'avoir des testeurs independants des developpeurs.

Pour generaliser et ainsi revenir au fil principal de la discussion, ca confirme le besoin de faire des tests d'acceptation, des recettes avec les utilisateurs avant l'installation sur site operationnel.

On peut aussi dire que les scenarios des tests fonctionnels doivent etre elabores et/ou approuves par les representants des utilisateurs.

On peut debattre sans fin du sujet, c'est un sujet qui ne n'arreta pas de passionner les foules... donc la question est: est-ce que le posteur originel a eu assez d'infos ?

[elitost]

[...] donc la question est: est-ce que le posteur originel a eu assez d'infos ?

J'ai plein d'infos, et j'imagine encore plus au fur et à mesure des réactions, idées, etc.

En attendant, merci à tous pour vos réactions, je vous laisse continuer le sujet.