Discussion :

[PALMIER82]

Bonjour

Je lance une bouteille à la mer car nous cherchons des compétences ACCESS

J'arrive sur votre forum et je suis seulement utilisateur ACCESS. Depuis 15 ans nous utilisons une application de gestion avec un gros développement d'un module logistique sous Access.

Notre développeur à 78 ans et il souhaite prendre sa retraite bien méritée. Nous devons envisager le transfert de l'application vers de nouvelle compétence pour la maintenance des 10 prochaines années

Nous cherchons des outils et surtout une méthodologie pour documenter l'application avant de la transférer.

Avez-vous des expériences similaires?
Méthode pour documenter un développement Access?
Avez-vous utilisé des outils ?
Connaissez-vous des outils de versionning pour Access? Peut- on faire un export .TXT de toute la base?
Connaissez-vous des outils de recherche de texte dans les objets et code dans Access 2019? car nous n'avons pas réussi à faire fonctionner DEPENDANCE PLUS.

Comment faire pour trouver des nouvelles compétences qui souhaitent reprendre la suite d'un autre développeur ?

Toutes vos expériences sont les bienvenues.
Merci d'avance pour votre collaboration

PATRICK

[ONTAYG]

Bonjour,

Déjà à 78 ans c'est une retraite qui aurait du être prise depuis longtemps.

A ma connaissance il n'y a pas d'outils, mais est-ce que la base a été documenté dans le code (commentaires pour expliquer ce que fait tel ou tel routine)

J'imagine que l'application a été améliorée au fur et à mesure des besoins, est-ce que toutes les évolutions ont été notés quelque parts.

Car pour moi il n'existe aucun outils à part les dépendances objets, et de plus cela ne fonctionne qu'avec les requêtes faites dans Access, pas avec celles dans le code VBA.

ONTAYG

[User]

Bonjour,

En effet, mais est-ce indispensable ?

Pourquoi ne pas simplement utilisez Word, libreOffice, ou un éditeur XML qui permet de décrire la structure de l'application avec une table des matières.

Est-ce que cela ne suffirait pas ? :

I. Présenter d'abord les fonctions principales et la structure générale de votre application.

Eventuellement ajouter une vue sur le formulaire d'accueil avec les différents menus...et un schéma montrant les liens entre les différents formulaires.


II. Puis détailler la structure des différents objets de votre application :


II.A Décrire le rôle et la structure des différentes tables, accompagné du schéma des relations entre les tables (menu outils de base de données -> relations).

II.A.1 Table T_Client
...

Utiliser des tableaux pour décrire les différents champs de chaque table : nom du champ, type de données, description..


II.B Décrire le rôle et la structure des différentes requêtes

II.B.1 Requête R_Client...
...

(ex. : ajouter des copies d'écran de vos requêtes en mode création)


II.C Décrire le rôle et la structure des formulaires.

II.C.1 Formulaire F_Client...
...
(ex. : ajouter des copies d'écran de vos formulaire en mode création et en mode formulaire, décrire également les contrôles des formulaires et commenter le code dans les modules des formulaires)


II.D Décrire et bien commenter le code VBA dans vos modules.

Avec cette documentation proposer bien sûr de télécharger une version locale de votre application, avec quelques données,
pour qu'on puisse mieux tester et se familiariser avec ses différentes fonctions.

Voilà, tout cela est assez évident au final, mais je pense que ça facilitera pas mal la compréhension des choses..

Cdlt,

[Pierre Fauconnier]

Bonjour Patrick,

Si l'application n'est pas documentée "au fur et à mesure", je pense qu'il est plus simple et moins coûteux en temps de ne pas la documenter et de voir avec le professionnel que vous choisirez pour sa maintenance comment la faire évoluer. Vous risquez de perdre un temps et une énergie considérables à vouloir produire "après coup" une documentation qui ne sera que peu exploitable, voire pas du tout.

[ONTAYG]

De plus, il est vrai que si l'application a été bien documenté lors de la conception c'est le top.

J'ai repris récemment une application faite par un de mes collègues (parti malheureusement dans un autre service et sur d'autres développement )

Celle-ci était accompagnée d'un descriptif comme écrit plus haut, et le code était commenté, et les objets correctement nommés de manière explicites. C'était un bonheur de reprendre son code (sans lui lancer des fleurs car il était très fort).

En résumant, c'est des le départ qu'il faut bien le faire.

ONTAYG

[User]

J'avais cru comprendre que l'application actuelle donnait satisfaction et que son auteur etait en mesure de fournir les éléments pour assurer sa maintenance.

Si ce n'est pas le cas, alors oui il faudra envisager de revoir sa conception et donc de produire les schémas et documents necessaires au futur développement.

Si par contre elle donne satisfaction, s'agit-il d'ajouter de nouvelles fonctions ou bien d'en améliorer certaines, et d'envisager une maintenance "évolutive" ?

Dans tous les cas il faudra bien produire de la documentation

Cdlt,

[PALMIER82]

Bonjour

Nous vous remercions pour vos réponses et vos différents points de vues. L'échange avec des professionnels d'Access nous permet de appréhende les solutions possibles:

A la lectures de vos réponses il ce dégage deux possibilités :

1. Ne pas faire de documentation et trouver un développeur Accces pour le suivi de la maintenance pour les 10 prochaines années. Pour avoir déjà pris des contacts et fait des essais avec 3 développeurs, ce n'est pas facile aujourd'hui de trouver des compétences Access. Je comprend aussi que repartir sur un développement existant cela ne doit pas être facile ni gratifiant. C'est vraie que les premiers contacts que nous avons eu n'était pas des développeurs "Pro-Access" et ils parait que nous avons vraiment exploiter au maximum les possibilités du logiciel.
   C'est pour cela que je suis venu sur votre forum pour trouver des compétences ACCESS. Nous sommes donc un l'écoute des intervenants qui cherche des missions de quelques heures par semaines sur le long terme
   
2. Ce lancer dans la réalisation d'une documentation même si c'est difficile de reprendre du code après réalisation.
   Merci à User pour sa méthode, cela nous permet d'avoir un canevas .

L'avantage c'est qu'Access offre déjà en mode création des informations faciles à documenter. Connaissez-vous un moyen d'imprimer les requêtes ou les tables sans passé par les recopies d'écrans?

Est il possible d'exporter toute le code au format TXT?

Merci pour votre suivi et bonne soirée

Patrick