Comment dois-je rédiger mon projet ?
Résolu/Fermé
Max_B
Messages postés
426
Date d'inscription
jeudi 14 décembre 2006
Statut
Membre
Dernière intervention
3 juillet 2012
-
Modifié le 23 nov. 2009 à 20:04
Dramy - 28 nov. 2014 à 07:15
Dramy - 28 nov. 2014 à 07:15
A voir également:
- Comment monter un projet d'elevage
- Exemple d'un projet déjà monté - Forum Programmation
- Comment monter un projet d'elevage de mouton ✓ - Forum Loisirs / Divertissements
- Logiciel gestion élevage avicole gratuit - Télécharger - Vie quotidienne
- Monter une image iso - Guide
- Comment projeter une image sur un mur - Forum TV & Vidéo
4 réponses
byLPG
Messages postés
17
Date d'inscription
dimanche 23 août 2009
Statut
Membre
Dernière intervention
26 août 2009
50
23 août 2009 à 18:10
23 août 2009 à 18:10
je sais pas du tout de quoi il s'agit, mais la meilleure approche c'est de raconter la vie des acteurs ou des utilisateurs de ton projet. je m'explique : si par exemple tu veux developper une gestion des entrée-sorties de camion dans une boite (je prend un exemple a la con au hazard) tu vas commencer par expliquer comment ça se passe actuellement, avec les détails, les paperasses, les coup de tel etc... style "le camion arrive, on lui ouvre la grille, on appelle tartenpion, on va chercher le rep. magasin, il geule qu'il a pas que ça a foutre, on rempli un papelard, on pese le camion, on engeule le chauffeur, on decharge le camion, on sais pas ou mettre les cartons, etc... etc.... tu vois le topo ?
donc tu racontes TOUT comment ça se passe. que ce soit pour une fabrication de sucettes, un process de distilation underground ou une salle de traite automatisée.
ensuite tu isoles et identifie dans ton récit les differents acteurs, les éléments clés, les donnés echangées, les papelard produits, les relations etc...
tu fais un beau schema avec visio ou un truc comme ça, et derriere tu vas pouvoir commencer a faire un dictionnaire de données : des tables regroupant les differents element associés entre eux.
par exemple une table "camions" avec les bahuts, les entrepises, chauffeurs etc... une table "employés_magasin", une table "marchandises" avec les references des camions, la descriptions, l'heure d'arrivée etc...
tu dois imperativement construire ta base de donnée et argumenter dans le style "ici on met tout ce qui est en stock, avec une jointure vers la table entrées_magasin, un autre vers la table sorties_magasin etc...".
et tu précises "cette table sera alimentée via une page machin_chose par le pequin de service dans la guérite a l'entrée de la boutique, telle table sera alimentée le soir apres validation des commandes... etc...
bref, tu re-raconte toute la vie de tes tables et de tes données, mais là c'est plus des type qui courrent, c'est des infos qui transites, qui sont saisies par pierre ou paul, des impressions qui sortent, des email qui partent etc...
Donc tu dis clairement où rentrent et où sortent les infos, et qu'est ce qu'on en fait, qui saisie quoi et quand : tu définis un flux de travail (workflow chez les rosbifs) et des process sous forme de pages distinctes qui seront accessibles a tel ou tel gugus en fonction de diverses contraintes.
tu mets suffisament de barbe a papa autour pour que ça fasse grosse étude NASA ou SNCF avec du powerpoint, des graphiques et plein de trucs inutiles, des annexes, des references à des bouquins que personne lira jamais, des remerciements à des inconnus (comme LPG par exemple) et tu boucles.
derriere y aura plus qu'a developper, mais quand c'est bien ficelé, c'est de la rigolade.
voilà, j'ai fait court avec pas mal de "etc..." et de faute d'otho mais j'ai pas non plus que ça a faire.
en esperant t'avoir aidé un chouilla, bon courage !
LPG
donc tu racontes TOUT comment ça se passe. que ce soit pour une fabrication de sucettes, un process de distilation underground ou une salle de traite automatisée.
ensuite tu isoles et identifie dans ton récit les differents acteurs, les éléments clés, les donnés echangées, les papelard produits, les relations etc...
tu fais un beau schema avec visio ou un truc comme ça, et derriere tu vas pouvoir commencer a faire un dictionnaire de données : des tables regroupant les differents element associés entre eux.
par exemple une table "camions" avec les bahuts, les entrepises, chauffeurs etc... une table "employés_magasin", une table "marchandises" avec les references des camions, la descriptions, l'heure d'arrivée etc...
tu dois imperativement construire ta base de donnée et argumenter dans le style "ici on met tout ce qui est en stock, avec une jointure vers la table entrées_magasin, un autre vers la table sorties_magasin etc...".
et tu précises "cette table sera alimentée via une page machin_chose par le pequin de service dans la guérite a l'entrée de la boutique, telle table sera alimentée le soir apres validation des commandes... etc...
bref, tu re-raconte toute la vie de tes tables et de tes données, mais là c'est plus des type qui courrent, c'est des infos qui transites, qui sont saisies par pierre ou paul, des impressions qui sortent, des email qui partent etc...
Donc tu dis clairement où rentrent et où sortent les infos, et qu'est ce qu'on en fait, qui saisie quoi et quand : tu définis un flux de travail (workflow chez les rosbifs) et des process sous forme de pages distinctes qui seront accessibles a tel ou tel gugus en fonction de diverses contraintes.
tu mets suffisament de barbe a papa autour pour que ça fasse grosse étude NASA ou SNCF avec du powerpoint, des graphiques et plein de trucs inutiles, des annexes, des references à des bouquins que personne lira jamais, des remerciements à des inconnus (comme LPG par exemple) et tu boucles.
derriere y aura plus qu'a developper, mais quand c'est bien ficelé, c'est de la rigolade.
voilà, j'ai fait court avec pas mal de "etc..." et de faute d'otho mais j'ai pas non plus que ça a faire.
en esperant t'avoir aidé un chouilla, bon courage !
LPG
