Discussion :

[survivan]

Bonjour,

Je souhaite développer une application de gestion pour une agence de voyage par car mais je ne sais pas vraiment par où commencer.

Quelqu'un saurait-il me guider un peu (au niveau des directives et il me manque le cahier des charges) ?

Merci d'avance pour votre aide.

[joel.drigo]

Salut,

c'est difficile de te répondre rapidement sur le sujet : gérer un projet de A à Z repose sur des méthodes de gestion, modélisation, suivi, etc qui ne se décrive pas en quelques mots,

mais je peux te donner un canevas simplifié qui peut d'éviter de passer du temps

on commence toujours une application par le cahier des charges, qui va décrire ce que doit faire l'application.

si tu n'as pas de cahier de charge, impossible d'aller plus loin puisque tu ne sais pas vraiment ce que doit faire ton application.

enfin, tu le sais peut être vaguement, mais justement le savoir vaguement est le meilleur moyen pour faire une usine à gaz

donc commence par le cahier des charges :
1) les spécifications fonctionnelles
- décrit les fonctionnalités de manière général : tu peux procéder de manière graphique, si tu ne connais aucune méthodologie :
- liste les documents en entrée et en sortie (comme facture, bordereau, descriptif d'une destination de voyage, fiche client, etc...)
- à partir de là tu sais un peu près ce que fonctionnellement tu dois entrer comme informations et ce que tu dois sortir comme document (sortir = imprimer, envoyer par mail, etc...)
- ensuite décrit les différentes actions que tu veux pouvoir faire, et les documents qui sont concernés par ces actions : tu va avoir des actions de type créer, modifier, supprimer, consulter, imprimer, etc... (tu peux faire ça dans un tableau par exemple)
- enfin décrit les acteurs qui vont intervenir (qui va faire quelle action avec quel document, ils s'agit non seulement des utilisateurs directs de ton logiciel mais également éventuellement les clients, et les acteurs externes comme par exemple le représentant de telle compagnie de transport, les fournisseurs si ceux ci doivent pouvoir intervenir sur tel ou tel doc, etc...)
une précision : ce n'est pas parce qu'au final tu n'auras qu'une seule personne qui se servira de ton application, que tu n'as qu'un seul acteur : définit bien chaque rôle séparément, quitte ensuite à dire que l'unique utilisateur assumera tous les rôles., donc en gros pour chaque role, quelle action il fera avec quel document
- dessine les interfaces graphiques : c'est un bon moyen pour repérer les "trous" dans la description fonctionnelle

2) spécifications techniques détaillées
ensuite décrit de manière plus précise :
- divise tes documents en informations
- liste les informations qui décrivent tes acteurs

ce qui te permet de faire un modèle de données (les différentes informations que tu dois manipuler et les liens entre ces informations)

fait là même chose avec tes actions et tes acteurs, ce qui te permet de définir la dynamique de ton appli (quels menus, quels écrans de saisie, comment ils s'enchainent, etc...)

3) ensuite définis un environnement technique : si tes données seront stockées dans un fichier ou une base de données, si ton appli est web, RDA, RIA, etc...

4) enfin tu peux te lancer dans la programmation

commence par un prototype (une application avec juste les interfaces graphiques, éventuellement quelques fausses données pour que l'affichage soit pas trop vide), limité sur 1 fonction, puis 2 puis 3, etc...

enfin, enrichit ton prototype de code qui fonctionne réellement petit à petit.

Sur l'aspect technique, si tu ne connais rien à la programmation ou à la modélisation, ou à l'installation d'un serveur, etc..., on peut pas te répondre dans un forum, ce serait trop long : cherche dans les tutoriels du site : comme tu as déjà découpé ton cahier des charges en plein de fonctions séparées, tu dois pouvoir trouver des exemples pour certaines de ces fonctions, tu apprendras petit à petit jusqu'à être capable de faire tout seul ce qu'il reste

[survivan]

Merci Joel.drigo pour m'avoir explicité les détails