Discussion :

[jarodknight]

Bonjour a tous,


Voici mes besoins:

Je souhaite developper un logiciel de gestion de flotte de limousine.

Au niveau interface graphique, je voudrais pouvoir visualiser (en HD sur ecran LCD) sous forme de barrettes avec une ligne de temps tous les vehicules et leur disponibilite et sur un autre tableau tous les chauffeurs et leur disponibilite. Une troisieme page doit fournir un tableau de tri croise.

Le soft doit pourvoir gerer la facturation des clients et la paye des chauffeurs.

Il doit pouvoir stocker des centaines de clients et des milliers de reservations d'une annee sur l autre.

Il doit etre stocke sur un serveur connecte a une quinzaine de postes clients.

Dans l'ideal on doit pouvoir lui ajouter une interface de consultation et de reservation sur le web.

Il doit etre reactif lors de tris croisés sur des centaines d'entrees.

Il doit permettre l'envoi automatise de sms ou mail.

merci de me donner vos avis sur le langage et les outils a utiliser.

Jarodknight

[jarodknight]

Personne?

[seeme]

Bonjour,

Ca dépend de pas mal de chose... Déjà des langages que tu maitrises, du volume de données (quelques centaines, ça devrait pas être un critère décisif, mais bon), hétérogènéité du parc des clients, techno dispo sur le serveur, délai, impératif de sécurité...

Là comme ça, à chaud, Java pourrais répondre à tes demandes..

Interface avec une BDD
Pas de problèmes si le parc client est hétérogène (idem pour le serveur)
Pas de soucis pour faire une interface web (en Java ou même dans une autre techno style PHP qui travaillerait sur la même BDD, à voir).

Mais après, Python, C, C++, PHP, .NET... On peut le faire sans problème avec tous ces autres langages...

[el_slapper]

(.../...)
Mais après, Python, C, C++, PHP, .NET... On peut le faire sans problème avec tous ces autres langages...

+1

C'est un projet des plus standards, et, à ce titre, la plupart des solutions marchent. Je dirais que la question est plutôt "de quel parc informatique disposons-nous?", et que partant de là, on choisira une solution qui s'intègre plus facilement. Un parc tout-Windows avantagera .NET, un parc varié Java, etc.....

[jarodknight]

En fait il s'agit d'un petit parc de PME sous windows.

Je n'ai personnellement pas de notions de programmation, c'est mon epouse qui s'y colle.

Mon soucis est de ne pas créer une usine a gaz lourde a lancer et a afficher les requetes. Donc ma question est plus de savoir si on peut privilégier un langage (ou un logiciel de programmation) pour aboutir a une application plus legere en memoire.

merci pour vos remarques

[seeme]

Je n'ai personnellement pas de notions de programmation, c'est mon epouse qui s'y colle.

Le lâche

Plus sérieusement, là ça dépend du niveau de la personne qui va créer le programme. Déjà, si c'est la mémoire qui fait peur (bon sérieusement, présenté comme ça, le projet même mal codé ne devrait pas non plus faire sauter les plombs..) on peut s'orienter vers un langage qui embarque un garbage collector (à moins que l'on sache ce que l'on fait..), ce qui qualifie.... quasiment tous les langages précités (sauf c/cpp).

Si madame n'a pas de notions avancés de programmation, je pencherais pour une solution tout web avec PHP (après c'est un peu solution de facilité et ça peut vite finir en usine à gaz, mais ça peut faire le deal en attendant d'embaucher un escla.. stagiaire qui pourrait reprendre tout ça).

[el_slapper]

+1

avec des volumétries comme ça, les problèmes de performances viendront de la conception et de la réalisation, pas de la techno choisie. Après, si madame n'est pas experte, le risque est réel.

Néanmoins, règle de base de tout projet :"early optimization is the root of evil". Si on cherche à faire un code rapide avant de faire un code qui marche, on va tout droit en enfer. Ce projet, quoique standard, n'a rien de simple. Spécialement le module "paye". Le reste est plus simple - quoique nécéssitant quand même une phase de test complète et intense. Mais le module "paye" me fait peur. Un logiciel du commerce ne peut pas faire? CIEL, ça doit couter moins de 250 €, soit une demi-journée de programmation, là ou il faudra des semaines et des semaines pour faire moins bien.....

Le reste, c'est un simple calendrier en temps réel avec données croisées. Sois sur de faire des spécifications complètes avant d'envoyer madame au casse-pipe, rien de pire que de commencer sans savoir ou on va, c'est l'aller-simple vers l'echec assuré.

[jarodknight]

apparemment on s'oriente vers visual studio 10 et du .net. je vous tiendrai au courant des avancée de "madame" ;-) et on ne manquera pas de revenir vous voir en cas de probleme

Merci

[el_slapper]

C'est un bon choix(parmi d'autres), qui a l'avantage de l'unicité(tout-en-un). Par contre, pour les problèmes spécifiques au langage, merci de s'adresser aux forums dédiés.

Et, je me répète, écrire des spécifications complètes. Rien que le faire, ça permet de voir un tas de problèmes. Et ne commencer à développer qu'une fois qu'on est d'accord sur les specs. Il restera des problèmes non-anticipés, mais ça permet vraiment de débroussailler, et d'éviter des conceptions complètement aberrrantes. Du genre :

==>Dessin de tous les écrans
==>Comportement de tous les écrans
==>Tous les chemins d'utilisation possible
==>Toutes les données dont on a besoin en base

Idéalement en UML, mais faire sans peut aussi marcher. L'important, c'est de tout prévoir(même si il y aura fatalement des oublis, c'est plus facile de les integrer quand il ne manque que 2-3 trucs). Ca peut faire une différence de temps de développement de 1 à 10.