Réussir un projet - Documenter

Note utilisateur:  / 6
MauvaisTrès bien 

Première partie de notre dossier sur la réussite d'un projet : Nous abordons l'intérêt de la documentation d'un projet.

Documenter

La documentation projet au service du développement WinDev

La réalisation d’un projet est souvent assimilée aux seules tâches de développement. C’est malheureusement omettre l’importance de la réalisation de la documentation. L’intérêt de la documentation est de faciliter la communication non seulement au sein de l’équipe de développement mais aussi entre cette équipe et son environnement. Il s’agit alors généralement des autres services de l’entreprise. Ils pourront utiliser cette documentation pour consulter les détails du projet. Elle sert aussi de départ à la réalisation des manuels d’utilisation des fonctionnalités. La documentation d’un projet peut être répartie en trois parties.

La documentation d’analyse

La documentation d’analyse regroupe l’analyse fonctionnelle qui peut être réalisée au moyen de méthodes diverses (APTE, UML…). Elle traite de l’étude du besoin qui est alors modélisée jusqu’à proposer des solutions fonctionnelles. La méthode APTE place dans un premier temps la solution dans son environnement pour étudier ses relations avec ce dernier et énoncer les fonctions de service et fonctions contraintes : C’est l’analyse fonctionnelle externe. La reprise de chacune d’elle cette fois-ci au sein du projet permet d’énoncer les fonctions techniques et de déterminer les solutions techniques : c’est l’analyse fonctionnelle interne. Il est possible de modéliser détail de cette analyse par des diagrammes FAST, SADT, ou des matrices RACI pour une approche d’analyse par la répartition des tâches.

Pour la réalisation d’un projet de gestion informatique les solutions technique sont des traitements, les solutions techniques regroupent alors les données saisies et produites. Chacune des fonctions créées au cours de ces étapes d’analyse est validée dans la durée de vie du projet. Il s’agit d’indiquer les raisons de leur existence et pour chaque raison de déterminer ce qui est susceptible de les faire disparaitre afin de vérifier qu’elles satisfassent le besoin pour toute cette durée.

De même chacune de ces fonctions est caractérisée. On apprécie alors la manière donc la fonction est remplie ou la contrainte respectée. Concrètement on trouvera ici les valeurs limites acceptées. La documentation d’analyse sert de base de travail pour analyser un besoin et préparer le travail du développeur. Elle permet aussi d’assurer la présentation du projet sous forme de cahier des charges dont le chiffrement permet la réalisation des devis et la planification la production.

Dans un projet WinDev, on trouvera cette gestion dans le Centre de Suivi de projet. Chaque fonction technique donnant alors lieu à une « Exigence ». Il est alors possible de décrire l’exigence et surtout de faire référence au document qui la décrit. Les exigences sont alors découpées en « tâches » de développement, documentation et tests. Les solutions techniques étant alors mises en place dans le modèle de donnée du projet ou « analyse ». La gestion de la production consiste alors à affecter les tâches aux membres de l’équipe en donnant des estimations de durée. Cela permet de remplir leur planning et d’assurer leur suivi. Il est possible de hiérarchiser les tâches et donc de produire un diagramme de GUANT.

On l’aura compris la documentation d’analyse est réalisée par le chef de projet et permet de partir d’un besoin exprimé par le client pour arriver aux tâches de développement.

La documentation de développement

Rédigée par les développeurs, la documentation de développement indique la manière dont la fonction d’analyse est réalisée. Elle organise les éléments de projet mis en œuvre et indique leurs rôles respectifs. Elle description et donne les résultats des tests produits.

Elle peut aussi indiquer les solutions envisagées mais abandonnées en précisant la raison de ces décisions. Ainsi, lors d’une évolution de la solution, il sera possible de tenir compte de ces études selon la validité des raisons invoquées.

La documentation de développement est le moyen pour le développeur de communiquer sur sa réalisation à tout autre interlocuteur qui n’a accès au code tels que : chef de projet, service qualité ou marketing… C’est un outil de communication interne souvent laissé de côté par manque de temps. Cependant, si sur une durée plus longue, le développeur du code n’est plus présent, cette documentation est nettement plus efficace qu’une rétro-analyse de son travail.

La documentation du code

Rédigée par les développeurs au sein des programmes, la documentation du code décrit son prototypage paramétrique et le fonctionnement.

L’éditeur de code WinDev permet de formater les commentaires d’entête des procédures et fonctions. Accès : Menu > Outils > Options > Options de l’éditeur de code, volet « Doc. ». Cocher les zones que vous souhaitez que le développeur remplisse.

Ces paramètres seront alors utilisés pour la construction du squelette de commentaire à chaque modification de la déclaration de procédure. En cochant, « Synchroniser les commentaires avec la syntaxe des procédures », les modifications du commentaire suivront la réalité de la syntaxe.

L’avantage de cette documentation est que l’éditeur de code propose lors de la saisie d’un appel à la procédure, en plus de la complétion des paramètres, l’affichage en barre de message de leur description saisie dans ces commentaires.

Ensuite, il est recommandé, même si on utilise les règles de nommage, de préciser le rôle des variables déclarées en début de procédure.

Enfin, au sein des procédures, il est utile de commenter les blocs de codes enroulables afin de conserver une lisibilité de l’algorithme même avec le code enroulé.

Il est possible de fixer un quota de commentaire aux développeurs dans les règles de gestion du projet via la politique de réintégration dans le GDS.

La documentation de code est à destination de son lecteur et doit l’aider à comprendre le cheminement de l’exécution.