Discussion :

[ver_for]

Bonjour,

J'ai déjà réalisé plusieurs applications Access, soit pour des clients extérieurs, soit, soit en interne pour des collègues.

La difficulté que j'ai rencontrée est celle de devoir faire des modifications:
- de structure. La base est finie et l'on décide d'ajouter dre prendre en compte de nouvelles informations dans l'application, d'où modification des tables, des requetes, des procédures et des formulaires
- de fomulaires
et donc de passer beaucoup de temps à retravailler sur une base finie, d'où perte de temps et parfois de qualité du produit.

J'ai d'abord pensé que c'était la faute de l'autre et puis j'ai compris qu'en partie je m'expliquait mal

Ma grande question est donc: comment réussir a définir une application Access lorsque le client n'est pas informaticien et n'a pas forcément les idées claires?

J'imagine que beaucoup d'entre vous ont rencontré cette situation. Comment la gérer vous?

Merci pour vos réponses.

[Oleff]

Bonjour,
Personnellement, je développe toujours en deux temps.
Premier temps : cahier des charges, analyse, développement du prototype, tests fonctionnels de base.

Deuxième temps : mise en exploitation partielle (avac quelques utilisateurs), redéfinition des use cases si besoin, analyse des remarques utilisateur et modifications structurelles et fonctionnelles nécessaires.

[marabout]

Bonjour,

Première chose importante au niveau de la récolte des besoins: rencontrer un maximum d'intervenants de la futur application. J'ai eu une commande du responsable informatique mais dès qu'elle fut mise en test, levée de bouclier des utilisateurs car cela ne correspondait pas à leurs besoins, leur manière de fonctionner. Ensuite il faut faire un compromis...

Deuxième élément, bien "penser", concevoir son application pour la faire la plus modulaire possible car c'est inévitable que le client voyant que ça marche demande cela en plus puis encore cela, etc.

Troisième élément, quand tu es bien avancé, demander des données réelles et faire tes tests sur des données réelles et pas sur des données bidons que tu inventes peut-être tout à fait à côté de la plaque par rapport à la réalité du client.