BLOG - Conseils Modello

2009-09-04T13:36:00.000-07:00

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 :

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?

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?

Dans la section « Présentation » (interface usager) du document d’analyse fonctionnelle :

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?
Pour tous les champs « saisissables », la mention « obligatoire ou optionnel » est spécifiée?
La longueur de tous les champs est spécifiée?
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?
Tous les exemples d’écrans et d’onglets sont présents?
pour tous les champs provenant de systèmes externes, le nom du système source (ex. SAP R3) est spécifié?
Pour tous les champs provenant de systèmes externes, les « codes de valeur » externes sont respectés?

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

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é?
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?
Une description pour chacune des étapes de la routine externe ou de la procédure à développer est spécifiée?

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

Les écrans, les onglets et les fonctionnalités non utilisés sont spécifiés?
Les options de menu non utilisées sont spécifiées?
Les écrans de dialogue de recherche non utilisés sont spécifiés?
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

2008-12-11T07:46:00.000-08:00

2008/12/02

DATA MODELING

“Database Reverse engineering”: a reactive documentation

Robin Ouellet

The Data Model

Have you already heard the following statement: “show me your data model and I will understand your system “? is it true that a data model speaks to us? Based on my several years of experience in system development, I noticed that the data model is the document the most used in information technologies. It is used in all stages of development cycle.

The data model is an essential tool to illustrate the comprehension of a business domain during the architecture phase, to evaluate the space capacity required by the physical database or to analyze the impact of a modification in production. Unfortunately, the data model is the most neglected project deliverable.

Delivering a functional system is more important than delivering a well documented system. There are many reasons: lack of resources, delays in one or many stages of the development cycle, the supplier did not provide the data model at the software implementation, etc.

In the situation of an application have been implemented in production and well functioning, the need to have a data model is still required by the project manager, the analysts or the developers sustaining the application. The solution is “Database Reverse Engineering” at a relatively lower cost.

The Reverse Engineering

An appropriate data modeling tool will allow to connect into the physical database and convert information into a data model representation. This diagram will show the entities, the attributes, the primary keys, the relationships as well as the relationships cardinalities.

Reverse engineering cannot convert everything. Relationships between the entities will appear only if the “foreign keys” constraints were defined in the physical database.

Assuming that the physical database contains the minimal information (definition of the tables, the attributes, the primary and the foreign keys), here are the manual operations to perform in the data modeling tool after the reverse engineering operation has been completed:

Step 1. Manually reorganized the presentation of entities by module

The reverse engineering functionality cannot gather in a logical way and by page, the entities of a same module. E.g. entities related to the file customer, entities related to the invoicing module.

If the database contains five hundred tables, then five hundred entities will be presented on the same page with all the relationships that connect those entities. The data model will be very difficult to read.

Step 2. Withdraw relationships which become redundant

Sometimes, in order to reduce and to facilitate the reading of the data model, it is necessary to remove relationships which are found at many places. E.g. the “customer number” and “product number” foreign keys can be found in the majority of the entities of the data model.

Only the graphical representation must be removed. The background information entities relationships must always remain intact.

Step 3. Seize short and long entities descriptions

Step 4. Seize short and long attributes descriptions

The efforts

Efforts of reverse engineering is not more than one or two weeks without including the documentation of the attributes (in reference to step 4 above).

Let us consider a database containing approximately 150 tables, 350 relationships and 20 columns on average per table:

· The execution of the reverse engineering in the data modeling tool (MS Visio Professionnel) will take approximately 30 minutes;

· Steps 1,2 and 3 can take from 1 to 2 weeks according to both the application and the business domain knowledge;

· Step 4 can last approximately 8 weeks. Considering that 3000 columns (attributes) in a database represent approximately 2000 attributes to be documented because the same attribute can be found in several entities. By allocating a 10 minutes of effort per attribute, step 4 could last approximately 8 weeks. Once again the duration varies according to the application and the business domain knowledge;.

The Data modeling tools

The majority of the data modeling tools offer the reverse engineering functionality: Microsoft Visio Professional 2007, PowerDesigner by Sybase, Oracle Designer, Oracle SqlDeveloper and ERWin.

These tools detect in any time differences between the physical database and the data model. This functionality proves very useful to preserve an up to date version of the data model.

Cost of its products is approximately 700 Canadian dollars for “Microsoft Office Visio Professionnel 2007” and approximately 7500 American dollars for the PowerDesigner product.

Oracle provides a free data model tool named “SqlDeveloper”. You will find it at this address: http://www.oracle.com/technology/products/database/sql_developer/files/Modeling.html. However that is a beta version.

The standard version of Microsoft Visio does not contain the reverse engineering functionality. It is thus necessary to buy Microsoft Visio with the mention “Professional”.

Conclusion

The documentation of a data model using a reverse engineering remains a reactive response. Ideally and normally, this activity occurs in the architecture stage of the system development cycle.

Robin Ouellet

ouelletrobin@aqiii.org

Data model: A data model is an abstract and a graphic representation of information related to a business domain or to the company as a whole. It presents the entities (or tables), the attributes (or columns), the relationships between its entities as well as the cardinality which characterizes the relationships. For example: The entity “ORDERS” with the relation “CONTAINS” one to many “ORDER ITEMS”. The mention “one to many” represents the cardinality of the relationship.

La “Rétro-conception”: une documentation réactive

2008-12-05T12:30:00.000-08:00

MODÉLISATION DE DONNÉES

La “Rétro-conception”: une documentation réactive

de Robin Ouellet

Le Modèle de données

Connaissez-vous cet adage, « montrez-moi le modèle de données et je vous dirais ce que le système fait »? Et bien, n’est-il pas vrai qu’un modèle de données nous parle. Pour avoir œuvré pendant plusieurs années en développement de systèmes, le modèle de données est probablement un des documents les plus utilisés par les professionnels des technologies de l’information, et ce, à toutes les étapes du cycle de développement. En effet, que ce soit pour schématiser la compréhension du domaine d’affaires durant la phase d’architecture, pour évaluer le volume et l’espace mémoire requis par la base de données physique ou pour analyser l’impact d’une modification après l’implantation du système, le modèle de données est sans contredit un outil indispensable.

Malheureusement, à postériori, l’élaboration du modèle est souvent le grand négligé parmi tous les livrables qu’une équipe de projet doit fournir. À défaut de livrer un système bien documenté, il faut avant tout livrer un système qui fonctionne. Les raisons sont nombreuses : manque de ressources, retards importants dans l’une ou plusieurs des étapes du cycle de développement, le fournisseur n’a pas fourni le modèle de données lors de l’implantation du logiciel, etc.

Qu'à cela ne tienne, l’application a été implantée, elle est en production et elle fonctionne bien. Que vous soyez le chef de projet, l’analyste ou le développeur responsable au support de l’application, votre besoin d’avoir un modèle de données est toujours présent. Il existe une solution. Et son coût est relativement minime. Il s’agit de la « rétro-conception » de la base de données.

La Rétro-conception

Cette technique consiste, avec l’aide d’un outil de modélisation de données, à se connecter sur la base de données physique et de convertir les informations contenues, en un modèle de données. Le schéma résultant de la rétro-conception présente alors les entités, les attributs, les clés primaires, les relations ainsi que les cardinalités des relations.

Évidemment, la fonctionnalité de rétro-conception de l’outil de modélisation de données ne peut tout déduire. Aussi, les relations entre les entités seront déduites seulement si les contraintes de « clés étrangères » ont été définies au niveau de la base de données physique.

En assumant que la base de données physique contient l’information minimale : définition des tables, des attributs, des clés primaires et des clés étrangères, voici les opérations manuelles qui devront être accomplies dans l’outil de modélisation de données après la rétro-conception :

Étape 1: Réorganisation manuelle des entités par module

L’outil de rétro-conception ne peut regrouper de façon logique et par page les entités d’un même module. Ex. les entités relatives au dossier client, les entités relatives au module de facturation.

Si la base de données contient cinq cents tables, alors cinq cents entités seront affichées dans le modèle sur une même page, et ce, avec toutes les relations qui les relient entre elles. Le modèle sera donc illisible.

Étape 2: Retirer des relations qui deviennent redondantes

Parfois, afin d’alléger et de faciliter la lecture du modèle de données, il est nécessaire d’enlever des relations (représentation graphique seulement) qui se retrouvent à plusieurs endroits. Ex. les clés étrangères «numéro de client » et « numéro de produit » peuvent se retrouver dans la plupart des entités du modèle.

Noter que seulement la représentation graphique doit être enlevée, car en arrière-plan l’information sur la relation entre les deux entités doit demeurer intacte.

Étape 3: Saisir les descriptions brèves et longues des entités

Étape 4: Saisir les descriptions brèves et longues des attributs

Les efforts

Bref, l’effort de rétro-conception n’est pas si grand soit d’une à deux semaines si on ne considère pas la documentation des attributs (voir étape 4 ci-dessus).

Considérons une base de données contenant environ 150 tables, 350 relations et 20 colonnes en moyenne par table :

· L’exécution de la rétro-conception dans l’outil de modélisation prendra environ 30 minutes (MS Visio Professionnel).

· Les étapes 1, 2 et 3 peuvent prendre de 1 à 2 semaines selon le niveau de connaissance de l’application et du domaine d’affaires.

· L’étape 4 peut durer environ 8 semaines. 3000 colonnes (attributs) dans une base de données représentent environ 2000 attributs à documenter étant donné que le même attribut peut se retrouver dans plusieurs entités. En accordant un temps de 10 minutes par attribut, l’étape 4 pourrait durer environ 8 semaines. Encore une fois la durée varie selon le niveau de connaissance de l’application et du domaine d’affaires.

Les outils de modélisation de données

La plupart des outils de modélisation de données possèdent les fonctionnalités relatives à la rétro-conception : Microsoft Visio Professionnel 2007, PowerDesigner de Sybase, Oracle Designer, Oracle SqlDeveloper, ERWin.

Ces outils permettent également de détecter en tout temps les différences entre la base de données physique et le modèle de données. Cette fonctionnalité s’avère très utile pour conserver une version à jour du modèle de données.

Le coût de ses produits est d’environ 700 dollars canadiens pour « Microsoft Office Visio Professionnel 2007 » et peut aller jusqu'à environ 7500 dollars américains pour l’outil PowerDesigner de Sybase.

Oracle fournit gratuitement l’outil de modélisation de donnée SqlDeveloper à cette adresse : http://www.oracle.com/technology/products/database/sql_developer/files/Modeling.html. Cependant prenez note qu’il s’agit d’une version « béta ».

La version Microsoft Visio de base ne contient pas la fonctionnalité qui permet la rétro-conception. Il faut donc acheter Microsoft Visio avec la mention « Professionnelle ».

Conclusion

La documentation d’un modèle de données par rétro-conception est une mesure réactive. Idéalement et normalement, cette activité s’effectue dans la phase d’« Architecture » du cycle de développement d’un système informatique.

Robin Ouellet

Conseils Modello

ouelletrobin@aqiii.org

Modèle de données: Un modèle de données est une représentation abstraite et graphique des données relatives à un domaine d’affaires ou à une entreprise dans son ensemble. Il présente les entités (ou tables), les attributs (ou colonnes), les relations entre ses entités ainsi que la cardinalité qui caractérise les relations. Par exemple : L’entité « COMMANDE » avec la relation « INCLUT » une à plusieurs « LIGNE DE COMMANDE ». La mention « un à plusieurs » représente la cardinalité de la relation.

Exemple d’un modèle de données :