Design de projet - Page 1

Ce sujet m'intéresse aussi ! J'ai eu le même problème il y a peu : on code, on code et il y a un moment où il faut implémenter quelquechose mais où cela devient très difficile à cause de ce qui a déjà été codé et de tout ce qu'il faut changer.

Du coup maintenant j'essaye de mettre sur papier les fonctions auxquelles je pense avant de me lancer dans le code.

Les statistiques ont montré que 70% des projets en informatique échouaient pour les raisons suivantes:
-Complexité
-Prolème de sizing (personne, temps etc.)
-Non adapté aux besoins du clients.

Ce chiffre date des année 90, mais je pense pas qu'il ait beaucoup baissé entre temps.
Tout cela pour dire que vous êtes normaux

Les méthodes de développement de logiciels qui fournissent les meilleurs résultats sont des méthodes itératives. En gros commencer par faire les petites briques pour les assembler et en faire d'autres (mots clées: lean scrum cristal XP).
Elles apportent de nombreux concepts importants tels que l'intégration continue, une mise en valeur de la communication, mais aussi de la qualité du code via certaines métriques.

Pour les projets perso, sincèrement je pense pas qu'il y a besoin de se prendre la tete, il faut que ca reste avant tout fun Il y a aussi 90% des problèmes qui sont résolus du fait que vous soyez seuls, votre propre client etc.
Après niveau développement, il suffit de savoir subdivisionner sont projet en petites étapes réalisables (ne pas perdre son temps a tout planifier car c'est iréaliste)
Pour la programmation, il faut respecter certains principes pour eviter d'effacer du code, creer des bugs etc. (Single responsability Principle, Open Close principle, Inversion dependency Principle...).
Mais il faut surtout rester simple dans une première étape quite à revenir aux optimisations apres (bouffer 90% de son énergie à optimiser par exemple une recherche d'op code peut aboutir a un projet non fini car manque de motivation pour le reste ).

JackosKing (./3) :
Les méthodes de développement de logiciels qui fournissent les meilleurs résultats sont des méthodes itératives. En gros commencer par faire les petites briques pour les assembler et en faire d'autres (mots clées: lean scrum cristal XP).Elles apportent de nombreux concepts importants tels que l'intégration continue, une mise en valeur de la communication, mais aussi de la qualité du code via certaines métriques.

C'est une des "voies" possibles, mais je trouve qu'associer le développement logiciel à XP et quelques autres méthodes agiles est assez réducteur. Elles donnent de bon résultats dans certaines configurations très spécifiques (équipes limitées, client très disponible, seulement sur certains types de projets, etc) mais ce serait suicidaire que d'envisager les appliquer partout.

Pour les projets perso, sincèrement je pense pas qu'il y a besoin de se prendre la tete, il faut que ca reste avant tout fun Il y a aussi 90% des problèmes qui sont résolus du fait que vous soyez seuls, votre propre client etc.

C'est vrai que ça simplifie voire élimine beaucoup de problèmes, mais il reste quand même ceux qu'évoquait Folco dans son topic : quand on travaille sur un projet vraiment gros pour une seule personne, si on se lance directement dans le code on a pas une vision globale suffisante pour "bien" partir (ou alors par coup de bol) et on risque de se bloquer soi-même assez rapidement.

Ça introduit les notions d'analyse et de conception (à développer plus tard parceque là y'a de quoi en écrire des pages et des pages ^^)

[edit] petite remarque d'ordre général pour JackosKing : je pense que tes posts seraient bien plus faciles à exploiter si tu remplaçais tes "single responsibility principle" et autres expressions anglaises par des équivalents français, surtout quand ce sont des principes fondamentaux assez simples qui s'expliquent très facilement en une ou deux phrases comme ici

Folco (./4) :

JackosKing (./3) :
(bouffer 90% de son énergie à optimiser par exemple une recherche d'op code peut aboutir a un projet non fini car manque de motivation pour le reste ).

Ca c'est précisément MA spécialité, je ne supporte pas d'écrire 10 lignes non optimisées

Oui mais il vaut mieux privilégier les optimisations globales que locales

Zephyr (./5) :
[edit] petite remarque d'ordre général pour JackosKing : je pense que tes posts seraient bien plus faciles à exploiter si tu remplaçais tes "single responsibility principle" et autres expressions anglaises par des équivalents français, surtout quand ce sont des principes fondamentaux assez simples qui s'expliquent très facilement en une ou deux phrases comme ici

D'un autre côté si Folco veut chercher plus d'informations sur google il trouvera sûrement plus de choses avec la version anglaise (et c'est pour ça que JS parle de mots-clé). Ce qui n'interdit pas de mettre aussi la VF, bien sûr ^^

à ce moment là pas besoin d'un topic, il suffit de faire au choix [google]software engineering[/google] ou [google]méthodes de développement logiciel[/google] et on aura la liste de tous ces mots-clés sans avoir besoin de se casser la tête à tout réexpliquer avec une approche différente ^^

[edit] erk le premier résultat pour la recherche en français pointe vers l'article Wikipedia sur les méthodes agiles

il y a peut-être un juste milieu entre tout expliquer de A à Z et se contenter de dire "google est ton ami" ?...

d'où ma remarque, parcequ'une liste de mots clés à rechercher sans contexte ni explication ça ressemble pas mal à du "google est ton ami" je trouve :/

ben il donne juste une vue d'ensemble et se réfère à google pour les détails, je vois pas le problème : si tu veux écrire un post plus complet/détaillé, libre à toi, mais c'est pas pour autant que son post est inutile

Ah pas inutile, loin de là, mais j'aurais trouvé bien d'avoir justement une vue d'ensemble avant d'introduire des concepts plus précis. En l'occurrence, soit j'ai loupé l'explication qui porte sur la subdivision d'une application en ensembles de fonctionnalités homogènes, soit "single responsibility principle" est arrivé sans introduction.

Tu sais Zephyr, pour le moment partout ou je suis allé on m'a dit les methodes agiles etc, c'est pas possible pour nous. En fait il s'agissait juste d'un manque de volonté... c'est tellement plus facile d'envoyer en Inde pour que cela coute plus cher au final :P
Pour les mots-clé cela ne m'étonne pas car justement ces méthodes ont pour "défaut" de demander des ingénieurs/IUT/... logiciels compétents

Hmm pas d'accord. La première chose que l'on m'a apprise quand on a abordé les méthodes agiles, c'est justement qu'elles n'étaient adaptées qu'à certains cas de figure à cause entre autres des contraintes que j'ai évoquées plus haut.

J'en prends une parmi d'autres : la disponibilité du client. XP et d'autres méthodes requièrent une forte implication de la part du client puisque tu es censé lui faire valider ton avancement très régulièrement pour limiter au maximum les écarts entre les besoins et ta solution ; c'est l'un des principes fondateurs de la méthode il me semble. Et dans certains projets, c'est tout simplement inimaginable : le client ne peut pas se permettre d'être à ta disposition pendant 1 ou 2 ans. Au contraire, il ne veut être sollicité qu'en cas de nécessité, si il y a un point critique à trancher, mais en aucun cas toutes les semaines ou pire, et c'est à toi d'assurer le bon déroulement du développement entre chaque "revue" ou validation. Dans ce genre de situation, XP ne peut pas être appliqué. Et ce n'est qu'un exemple parmi beaucoup d'autres.

(par contre je ne pense pas que ce soit ces aspects qui intéressent beaucoup Folco et Daniel Vouaux )

Pas tout à fait, c'est un point interessant pour le client, libre à lui d'en profiter ou non. Dans le cas du non, il restera une relation contractuelle qui ne sera qu'en defaveur du client. Mais cela n'est qu'un point des methodes agiles. Il reste beaucoup de choses qui sont toutes aussi importantes.
Le point fondamental de ces méthodes sont de ne pas les appliquer directement mais de les adapter à son projet. Celui qui te dit qu'il faut tout prendre ou rien prendre n'a pas du tout saisi la logique de fond de ces mehodes

Folco (./1) :
J'ai plus d'un projet qui n'a pas abouti, parce qu'au bout de 20/40/60% de code, ça devenait hallucinant parce que j'avais pas pensé à tout avant.

Si tu code en asm, c'est normal. Avec des languages de plus haut niveau, c'est pas du tout un problème.

JackosKing (./15) :
Le point fondamental de ces méthodes sont de ne pas les appliquer directement mais de les adapter à son projet. Celui qui te dit qu'il faut tout prendre ou rien prendre n'a pas du tout saisi la logique de fond de ces mehodes

Ça c'est vrai, mais si tu dois faire des concessions sur les points les plus importants des méthodes agiles, alors tu n'es plus vraiment en train de l'utiliser (ou bien alors tout est une méthode agile finalement... mais ça devient une définition un peu trop facile).

Jyaif (./16) :
Si tu code en asm, c'est normal. Avec des languages de plus haut niveau, c'est pas du tout un problème.

Travailler avec un langage de plus haut niveau repousse peut-être la limite à partir de laquelle on a du mal à avoir une vision globale d'une appli, mais ça ne la supprime pas pour autant.

Zephyr (./17) :

Jyaif (./16) :
Si tu code en asm, c'est normal. Avec des languages de plus haut niveau, c'est pas du tout un problème.

Travailler avec un langage de plus haut niveau repousse peut-être la limite à partir de laquelle on a du mal à avoir une vision globale d'une appli, mais ça ne la supprime pas pour autant.

Je ne parle pas d'avoir une vision globale, je parle de la facilité d'apporter des modifications importantes.

Zephyr (./17) :

JackosKing (./15) :
Le point fondamental de ces méthodes sont de ne pas les appliquer directement mais de les adapter à son projet. Celui qui te dit qu'il faut tout prendre ou rien prendre n'a pas du tout saisi la logique de fond de ces mehodes

Ça c'est vrai, mais si tu dois faire des concessions sur les points les plus importants des méthodes agiles, alors tu n'es plus vraiment en train de l'utiliser (ou bien alors tout est une méthode agile finalement... mais ça devient une définition un peu trop facile).

Jyaif (./16) :
Si tu code en asm, c'est normal. Avec des languages de plus haut niveau, c'est pas du tout un problème.

Travailler avec un langage de plus haut niveau repousse peut-être la limite à partir de laquelle on a du mal à avoir une vision globale d'une appli, mais ça ne la supprime pas pour autant.

Parce que pour toi XP, c'est uniquement avoir le client sur site?
Le problème de ce genre de méthode c'est qu'il faut etre pragmatique et les appliquer avec compréhension et intélligence. Si tu peux appliquer tous les principes alors c'est super, mais parfois il faut savoir faire des concessions...
Cependant s'arreter au premier principe et dire ca c'est pas fait pour nous est sacrément dommage. D'ailleurs un gros probleme de l'industrie et tout comme au dev logiciel, c'est qu'on veut des procedures appliquées à la virgule près. C'est loin de toute logique lean...

JackosKing (./19) :
Parce que pour toi XP, c'est uniquement avoir le client sur site?

Non, c'est tout un ensemble de pratiques et de contraintes, celles-ci en faisant partie et étant plutôt forte.

Le problème de ce genre de méthode c'est qu'il faut etre pragmatique et les appliquer avec compréhension et intélligence. Si tu peux appliquer tous les principes alors c'est super, mais parfois il faut savoir faire des concessions...Cependant s'arreter au premier principe et dire ca c'est pas fait pour nous est sacrément dommage. D'ailleurs un gros probleme de l'industrie et tout comme au dev logiciel, c'est qu'on veut des procedures appliquées à la virgule près. C'est loin de toute logique lean...

Si je suis ton raisonnement, une méthode agile est pour toi un regroupement de pratiques, et c'est à moi de piocher ce qui m'intéresse dans le lot ? Du coup, ça m'avance à quoi ? Autant mettre au point ma propre méthode, au moins elle aura le niveau de rigueur que je veux lui donner. L'objectif d'une méthode c'est quand même de donner des lignes de conduites, un truc souple à l'extrême n'apporte aucune solution à mon avis.

Jyaif (./18) :
Je ne parle pas d'avoir une vision globale, je parle de la facilité d'apporter des modifications importantes.

Alors c'est un peu moins faux, mais ça reste quand même une histoire d'échelles... oui bien sûr on pourra toujours modifier dans son coin la petite fonction bien isolée en bout de chaine, mais en cas de gros changements dans la conception c'est pas vraiment elle qu'on va viser, et haut niveau ou pas on risque d'être coincé assez rapidement.

[edit] désolé pour le HS, ça vaudrait le coup de se recentrer sur le développement parcequ'appliquer des méthodes quand on bosse tout seul... voilà quoi ^^

Il n'a jamais dit qu'il faisait de l'Agile ou du XP, il dit qu'il peut être utilise d'utiliser certaines idées de ces méthodes même quand on ne peut pas les suivre entièrement.

oh, alors c'est vrai pour n'importe quelle méthode, pas seulement pour les méthodes agiles dans ce cas (ce n'est pas du tout comme ça que j'avais compris sa remarque).

Folco, pour essayer de répondre à ton problème, voilà une proposition de quelques étapes à suivre. C'est une méthode qui peut sembler très "orientée objet", mais c'est souvent le cas (ce sont les langages objets qui ont été créés pour mieux coller aux méthodes, pas l'inverse) et tout ça reste parfaitement applicable à des langages non objet (ASM, C, etc). Voilà un plan très macroscopique, chacun pourra étoffer l'une des parties (ou en proposer un différent), j'écris juste ce qui me vient à l'esprit en vrac :

Avant de commencer un jeu, une application, ou n'importe quel programme, la seule chose dont tu disposes est une idée. C'est elle qu'il va falloir creuser pour en tirer peu à peu tous les besoins de ton futur programme. À ce niveau, ça reste très littéraire, tu pourrais imaginer un document qui ne contienne que des phrases du style "le programme doit permettre de faire ça". Pour faire la liaison avec le développement pour un client, c'est ici qu'on verrait apparaître le cahier des charges.

Une fois ces idées listées, tu vas pouvoir les regrouper par nature, en décomposant ton programme en entités logiques. Il n'y a pas de formule magique pour ça, et c'est donc la première réelle difficulté, mais ça reste souvent assez intuitif : pour un SMA, on va avoir des besoins liés au joueur (je veux que le personnage se déplace, je veux qu'il perde de la vie quand il touche un ennemi, etc...), des besoins liés au "monde" (je veux que mon niveau soit composé de tiles, je veux que ces tiles portent des informations sur leur nature : espace traversable, sol, échelle, etc...), des besoins liés aux interactions du joueur (je veux que le personnage se déplace en appuyant sur des touches...). Bref, tu vas te retrouver avec tout un tas d'entités logiques avec pour chacune un ensemble de fonctionnalités. Certaines de ces fonctionnalités peuvent d'ailleurs être partagées par plusieurs entités (par exemple "mon personnage ne tombe pas quand il est sur le sol" est lié aussi bien au personnage qu'au monde).

De ces fonctionnalités on peut extraire deux composantes : ce qui définit chaque entité, et les actions qu'elle peut faire. Avec "je veux que mon personnage perde de la vie quand il touche un ennemi", on met en évidence une caractéristique de mon personnage (ses points de vie) mais également le fait qu'il va falloir détecter les collisions avec les ennemis.

Si toutes ces étapes sont suivies et que tu n'oublies rien à chacune d'elles (c'est là que se situe la deuxième difficulté), tu devrais avoir alors une vision assez décomposée de tous les objets que ton programme doit savoir gérer, et de toutes les interactions qui vont devoir exister entre chacun d'eux. Il est alors temps de descendre encore d'un niveau.

Maintenant, il va falloir traduire tout ce que tu as obtenu dans quelque chose de beaucoup plus bas niveau : un langage informatique. C'est seulement maintenant qu'il entre en considération, ce qui veut dire que tout ce qui précède y fait complètement abstraction. Tes points de vie vont devenir des int sur 16 bits, ta détection de collision va devenir une fonction qui retourne un booléen (ou une section de code qui va activer je ne sais quel flag du cpu), etc. Tu vas pouvoir aussi en profiter pour découper ton programme en respectant la logique que tu avais déjà obtenue des étapes précédentes : ce qui est lié au joueur, ce qui est lié aux interactions homme-machine, ce qui est lié au monde...

Le fait d'avoir suivi ces étapes devrait t'apporter deux avantages :

- Tu sais à l'avance tout ce que tu vas devoir coder. Tu pourrais même avoir une "todo list" complète dès le départ, et cocher au fur et à mesure les fonctionnalités que tu codes pour te rendre compte de ton avancement et de ce qu'il te reste à faire, plutôt que d'avoir à te dire "hmm... je dois en être à 75% à peu près"
- Tu ne devrais pas être bloqué par un aspect auquel tu n'avais pas pensé au départ, puisque tu avais une vision complète de ton application avant de la coder, et que tu es arrivé progressivement au code

Bien sûr, tout ça mérite d'être très largement complété, discuté, remis en cause, etc... mais peut-être que ça te donnera des pistes à creuser pour te construire ta propre méthode de développement et pouvoir mieux appréhender des grosses applications.

Folco (./20) :
Comment on été faits des SMA, SMA, CF, PedroM, et d'autres (ok ça fait un peu PpHd-only là, mais c'est pas ma faute )

Comme ca a déja été dit dans le topic, il a du s'en sortir en découplant les différentes parties de ses programmes.
En ce qui concerne SMA, il a du utiliser des concepts de POO, où les objets/ennemies/joueur héritent d'entitées communes.

(cross)

Pour recentrer un peu le sujet, je vais répondre par rapport à mon expérience personnelle (que ça soit pour des projets strictement persos ou pour le travail, ça revient un peu au même dans la mesure où je n'ai pas à travailler avec un "client" à proprement parler, mais que j'ai toujours été laissé extrêmement libre dans ma conduite de travail - ce qui a des avantages, mais aussi d'énormes inconvénients dès qu'on aborde des projets importants).

Je n'ai jamais travaillé sur des langages aussi bas niveau que de l'assembleur, donc j'espère que ça va quand même t'aider.
Le premier point, c'est de lever les doigts du clavier. Essayer de dessiner une trame de ce que va faire ton programme. C'est à dire, dans ton cas, les différents flux à traiter, en entrée et en sortie (code source, code compilé), puis en fractionnant de plus en plus pour avoir une granularité de plus en plus fine (séparer en traitements primaires, puis à l'intérieur de chaque traitement, etc.). Ca, ça peut très bien se faire sous forme de schéma avec des flèches, des cubes, des ronds et des bidons. Il existe un certain nombre de normalisations mais, à part pour du gros travail d'équipe, je pense qu'à peu près tout le monde adapte les normalisations à ses besoins. Donc crée ta normalisation. Une fois que tu auras la méthodologie, si tu as à l'appliquer dans une autre norme, ça ne sera pas tellement compliqué.

Ensuite, il faut rédiger ou noter en français les processus de ton application. Les numéroter et les associer aux schémas que tu as fait précédemment. Ca te permettra, si tu reprends ton projet dans 6 mois ou un an (un nouveau bout de chou ou autre, on ne sait jamais ^^) d'avoir un support. Je sais que c'est ce qui m'a sauvé à plusieurs reprises quand j'ai bossé au taff et que j'ai dû reprendre des projets laissés en suspens pendant un ou deux ans.

Là, tu peux déjà commencer à écrire des bouts de codes. Sépare les bien par processus (là, par contre, je ne sais pas dans quelle mesure c'est applicable à l'assembleur... faire plusieurs fichiers ? faire une bibliothèque de fonctions ? j'avoue que ce n'est absolument pas mon domaine ) et documente ce dont tu as besoin en entrée et en sorties (dans un langage procédural, ce sont les paramètres et les retours d'une fonction ; là encore, je ne sais pas comment c'est géré en ASM...).

Ensuite (ce conseil t'es proposé uniquement parce que tu fais de l'ASM, c'est vraiment pas un truc que je fais), tu peux soit garder une organisation bien découpée et structurée (plus facile à maintenir), soit incorporer dans un seul fichier de projet toutes les petites briques que tu as construites. Un peu comme un maître d'oeuvre qui a fait construire ses portes d'un côté, ses chapes de béton d'un autre et qui, petit à petit, assemble sa maison. Cette seconde façon peut - peut-être - te permettre de faire des optimisations sauvages une fois que tout est bouclé.

Bon, je ne sais pas si j'ai répondu à la question. Le handicap principal est que je connais très peu les asm et leurs possibilités (j'ai bien dû écrire trois programmes en x86 et cinq en 6809, et encore c'étaient des TP à la con, autant dire que ça n'est rien par rapport à ce que tu fais).

(Bon, je suis aussi d'accord avec la vision de Zephyr, c'est rigolo, il pense entité et je pense processus )

Zephyr (./23) :
oh, alors c'est vrai pour n'importe quelle méthode, pas seulement pour les méthodes agiles dans ce cas (ce n'est pas du tout comme ça que j'avais compris sa remarque).

Je pense que tu n'as jamais évolué dans un projet a forte inspiration XP. L'intégration continue rien qu'elle est fantastique.
Quand à une méthode universelle qui s'aplique à tous les projets, cela s'appelle une méthode de merde. Les méthodes comme les méthodes lean sont des méthodes qui t'aident en fait à trouver tes points faibles (gaspillage), et te propose des solutions adaptées.
Si ton client ne veut pas suivre l'évolution du projet c'est son choix, faut il pour autant tout abandonner pour?
Beaucoup de boites s'inspirent grandement des methodes leans (dans l'industrie) et agile dans le dev (MS, Google etc.), car ils y ont trouvé beaucoup de solutions à leurs propres problèmes.

Après la question que je pose aux gens qui démonte les méthodes sont: quel est ton dernier bouquin, publication ou article lu dans ce domaine? Quel ouverture d'esprit as tu eu face a ce sujet?
Qui est Kent beck? Robert C Martin etc. Et là de suite, soit on entre dans un dialogue constructif ou il me fait part de son experiences sur d'autres méthods soit comme c'est bien souvent le cas on me repond non mais tout ca de toute maniere ca peut pas fonctionner ici.

Nil (./27) :
(Bon, je suis aussi d'accord avec la vision de Zephyr, c'est rigolo, il pense entité et je pense processus )

Analyse orienté objet vs analyse procédurale?
Tu t'interesses aux verbes d'une phrase et lui aux noms?

JackosKing (./29) :

Nil (./27) :
(Bon, je suis aussi d'accord avec la vision de Zephyr, c'est rigolo, il pense entité et je pense processus )

Analyse orienté objet vs analyse procédurale?
Tu t'interesses aux verbes d'une phrase et lui aux noms?

Possible... bon, en même temps, j'ai aussi essayé de m'adapter au projet de Folco, donc ça biaise un peu. Mais c'est vrai que, de façon générale, je trouve que le processus est plus discriminant que l'entité dans la mesure où (bien souvent), on peut toujours travailler (enfin, je généralise peut-être un peu, disons que "je" peux toujours travailler ^^) avec des entités génériques que j'adapte par la suite aux spécificités du produit.
Et il est aussi fort probable que ça vienne du fait que je n'ai pas eu à faire de "vraie" POO depuis quelques années (c'est ça d'être obligé de développer en/maintenir du PHP4 ), donc que même si mon analyse est orientée objet, elle va vite trouver des limites au niveau de l'implémentation (que ça soit à cause des contraintes du PHP4 ou de la spécificité des définitions des entités LDAP).