Comment bien reflechir à la conception de son application?

Question

Voila j'ai la motivation de créer une application en VB pour ma société. Le problème c'est que je ne sais pas par quel bout commencer! L'application doit gerer le porte feuille client, la liste des articles, les commandes ainsi que leur archivage et leur impression en pdf etc.... ( je ne vous ai donner qu une infime partie de ce que je souhaite qu il fasse. Je me tourne donc vers vous : -Quel est le point de départ pour créer une application? * j ai essayé de répertorier toutes les fonction avec leurs effets et leur causes * j'ai essayé de le faire au feeling.....loupé! d autre essais sans succès et le pire c est que j arrive a faire beuguer excell tout le temps "...a cessé de fonct...." voila je sais que mon problème peut vous paraître anodin, mais ma DL est pour semaine 8. d'avance merci a tous pour votre aide...

galopin01 · Answer

Avec une infime partie de l'objectif tu n'auras qu'une infime partie des réponses... Le point de départ c'est la conception des BD (tables ou tableaux) et des listes Une table client Une table produit Une table commande Ces BD étant des tables ou tabeaux bruts sans formats ni décoration avec des en-têtes de colonne sur la première ligne... Trop souvent les novices commencent à coller un superbe logo tout à fait inutile sur la première feuille du classeur (quand ce n'est pas sur chaque feuille...) A ce stade de nombreuses questions implicites et recommandations sous jaccentes pourrait déjà être formulées. (des noms de feuilles courts, 3 à 5 lettres maxi, idem pour les entêtes de colonnes, 2 à 7 caractères maxi) En général une (ou plusieurs )feuille(s) avec des listes complémentaires seront la plupart du temps indispensable. Tout dépend du degré d'exigence de ton appli... Les listes se présentent comme de mini tables en général 1 à 5 colonnes au grand maximum. Les listes doivent être séparées entre elles par une colonne vide (ce qui permet de les trier séparément sans désorganiser les listes voisines) Les listes les plus longues doivent toujours être dans les premières colonnes. Dans les feuilles comportant des listes, il ne doit y avoir aucune autre données plus bas dans la même colonne : Si une liste ne comporte que 7 lignes tout le reste de la colonne est perdu. On ne glisse pas une autre liste à la ligne 100 par exemple pour gagner de la place... La manière dont on gère ces BD (Consultation, modification, ajout) n'est pas anodine et influe grandement sur le développement futur. Une BD gérée uniquement par UserForm et non consultable ou modifiable en direct est en général très difficile à mettre au point et peut demander plusieurs mois de développement. Tout le reste archivage, impression, ce sont des actions donc de la prog. Si tes tables sont au départ mal conçues, sans index, et développées au fil de l'eau, tu peux t'attendre à remettre à plat ton ouvrage très souvent. Donc à perdre du temps dans la gestion de ton entreprises. Réflexions subsidiaires : Commencer un projet avec 2007 revient à démarrer ton entreprise avec une Juvaquatre... Si tu en as la possibilité, il faut passer tout de suite à 2010. Enfin un objectif à semaine 8 me semble très présomptueux à moins de maîtriser parfaitement au moins un autre langage de programmation... Ce qui ne semble pas le cas ! Cordialement...

galopin01 · Answer

Bah... ça dépend de ton attente ! Mais c'est clair qu'on ne va pas gérer de la même manière, un camion de pizza et une petite entreprise de vente de produits spécialisés sur internet... La partie analyse est en général zappé par les apprentis "progr'amateurs" d'excel. Bien y réfléchir suppose qu'on a une bonne connaissance de la problématique professionnelle et une bonne connaissance des moyens à mettre en oeuvre pour la résolution des besoins. Voici quelques généralités que je respecte en général pour ce qui concerne mes créations les plus sensibles. En général quand on monte une société on devrait passer le moins de temps possible sur des opérations de gestion improductive (comme l'apprentissage de la programmation) et le plus de temps possible à la production, et à la commercialisation (c'est à dire à faire rentrer l'argent dans la caisse...) La frontière entre les deux est bien mince. A mon avis pas de temps à perdre : Créer des bonnes bases de données pour pouvoir en extraire facilement les données utiles, c'est bien. Passer son temps à peaufiner des interfaces ou des statistiques est inutilement improductif.. Dans un premier temps il faut se contenter d'automatiser les opérations répétitives qui font vraiment perdre du temps en procédant de manière concentrique en élargissant progressivement le champ d'intervention. La plupart des utilisateurs ont compris l'utilité de pouvoir faire un lien facile entre leurs différentes données pour établir des factures aisément. Se compliquer la vie avec des exigences puériles est en revanche stérile : Une bonne facture se caractérise par sa simplicité d'utilsation et d'archivage. Sa numérotation doit suffire à la retrouver en moins de 5 secondes. Inutile de lui donner un nom à rallonge incluant l'age du capitaine et la date de naissance de ses enfants, dans un système d'archivage complexe quand une référence avec une dizaine de caractères dans un répertoire unique suffit dans la plupart des cas... A quoi bon un archivage pdf irrécupérable par Excel quand un archivage dans une BD permet de récupéer les données instantanément ? Même un archivage .xls est en général 10 fois moins volumineux et 10 fois plus pratique... Inutile de songer à programmer quoi que soit tant que tu ne possèdes pas une expérience claire du besoin réel et du process manuel. L'analyse du besoin et la facilité d'utilisation prime sur la réalisation d'un "truc" à remettre à plat tout les 15 jours... Une (ou plusieurs) bonne(s) table(s) bien organisée(s) et géreé(s) directement (avec des plages nommées dynamiques) est souvent bien plus utile que 20 macros et une demi douzaine d'Userform complexes et mal finis. Inutile de créer tout un système de gestion permettant ce retrouver toutes les commandes d'un client depuis la dernière guerre : la seule chose importante est que sa dernière commande soit (bien) traitée le jour même. (Il est rare qu'un client insatisfait refasse une commande avant que la dernière soit traitée convenablement) Dernière règle : Les bases de données c'est sacré. Pas touche. Tu peux faire toutes les extractions que tu veux, tous les calculs que tu veux, toutes les mises en forme que tu veux mais va jouer ailleurs : On ne touche pas à mes bases de données. Tu peux créer autant de feuilles (ou de classeurs) que tu veux pour en extraire des données ou calculer des tas de trucs. Mais pas de pollution interne. Diviser pour mieux régner est une règle valide en informatique. On peut sans problème regrouper toutes ses bases de données dans un même classeur, mais les petits programmes, factures, statistiques et autres extractions au long cours et par essence variables ou périodiques sont à gérer séparément... J'ai gardé pour la fin ce qui devrait être fait en premier. Toute base de données professionnelle devrait être copiée chaque jour sur un support distinct. PAS une sauvegarde hein ! Des copies numérotées selon une séquence périodique. (quotidienne, hebdomadaire, mensuelle) Pas une clef USB non plus hein ! Au prix ou est le Tera octet de disque dur externe, il est suicidaire de faire l'impasse sur cette précaution élémentaire... Moralité : 999/1000 utilisateurs d'excel sont un peu suicidaires ! Car si on ne compte plus sur les forums les sujets qui traitent de fichiers irrécupérables, j'en ai rarement vu qui traitent du problème de copies de sécurité... Cordialement...

galopin01 · Answer

Can à mon avisn ce n'est pas du ressort du débutant lambda. En tout cas je ne me lancerai pas dans cette aventure. Surtout dans une optique multi-utilisateur. ça, selon mon expérience, c'est très hypothétique ! A+...