vendredi 4 septembre 2009

DE LA QUALITÉ DANS VOS ANALYSES FONCTIONNELLES

de Robin Ouellet

La phase d’analyse fonctionnelle est sans contredit l’une des phases les plus importantes dans le cycle de développement d’une application informatique. En effet, cette phase représente la conversion des besoins d’affaires de l’entreprise par des spécifications précises de navigation et d’opérations du nouveau système informatique.

Que ce soit pour éviter une mauvaise compréhension des besoins d’affaires par l’analyste ou l’amorce trop rapide de la phase de développement, voici une liste de points de vérification qui devrait toujours être considérée dans le cadre du développement d’un nouveau système informatique.

En utilisant cette liste de vérification, vous éviterez le gaspillage de temps et améliorerez ainsi la productivité de votre équipe de projet.

Cette liste doit être utilisée par:

* l’analyste lors de la rédaction d’un nouveau document d’analyse fonctionnelle et;

* le développeur avant de débuter la programmation ou la configuration d’un module donné (ex. module de gestion du dossier client, module de facturation).


Voici les différentes étapes de la liste vérification d’un document d’analyse fonctionnelle :

  1. Le document contenant la « définition des besoins d’affaires » (objectifs du module, définitions des écrans, onglets, navigation, champs obligatoires, etc.) du module :

o Est complété par l’utilisateur principal et verrouillé pour toute modification?


  1. Le document d’analyse fonctionnelle :

a. Est complété par l’analyste et verrouillé pour toute modification?

b. Adresse tous les besoins spécifiés dans le document de « définition des besoins d’affaires »?

c. Est traduit dans la ou les langues demandées par l’entreprise (ex. écrans, onglets, messages)?

d. Contiens toutes les sections obligatoires (ex. section de révision du document, présentation, description des routines externes et procédures en différé, etc.) et que pour toutes ces sections les informations sont présentes et ont un sens?


  1. Dans la section « Présentation » (interface usager) du document d’analyse fonctionnelle :
    1. Les descriptions des champs apparaissent dans le même ordre que l’ordre de présentation des champs dans les écrans : c'est-à-dire, dans l’ordre d’apparition des onglets, de la gauche vers la droite puis du haut vers le bas?
    2. Pour tous les champs « saisissables », la mention « obligatoire ou optionnel » est spécifiée?
    3. La longueur de tous les champs est spécifiée?
    4. Pour les sections contenant une « barre de défilement horizontale », les champs apparaissant en premier puis ceux apparaissant à l’aide de la barre de défilement horizontale sont spécifiés?
    5. Tous les exemples d’écrans et d’onglets sont présents?
    6. pour tous les champs provenant de systèmes externes, le nom du système source (ex. SAP R3) est spécifié?
    7. Pour tous les champs provenant de systèmes externes, les « codes de valeur » externes sont respectés?


  1. Dans la section « Routine externe / Procédure en différé :

    1. Un diagramme du modèle de données sommaire représentant les tables et les relations relatif à la routine externe ou à la procédure à développer est spécifié?
    2. Les données volumétriques (initiale et incrémentale) pour chacune des tables qui seront utilisées dans la routine externe ou la procédure à développer sont spécifiées?
    3. Une description pour chacune des étapes de la routine externe ou de la procédure à développer est spécifiée?


  1. Dans le cas de la configuration/personnalisation d’un logiciel :

    1. Les écrans, les onglets et les fonctionnalités non utilisés sont spécifiés?
    2. Les options de menu non utilisées sont spécifiées?
    3. Les écrans de dialogue de recherche non utilisés sont spécifiés?
    4. Les rapports non utilisés sont spécifiés?


Conclusion


Bref, si vous avez répondu « non » à une seule de ces questions, votre document d’analyse fonctionnelle n’est pas complété et le développement ne peut donc pas être commencé sur ce module.


En appliquant systématiquement cette liste de vérification, il est possible que le développement d’un ou de plusieurs modules ne puisse commencer. Cependant, vous pourrez identifier les étapes du cycle de développement qui n’ont pas été complétées ou effectuées correctement et ainsi concentrer les efforts de l’équipe de projet sur les activités appropriées.


Évidemment, vous pouvez ajouter d’autres points à cette liste en considérant le contexte de votre projet, votre méthodologie de développement et votre environnement technologique.


Robin Ouellet

Conseils Modello inc.

514-385-0365

ouelletrobin@aqiii.org

Aucun commentaire: