Conclusions élargies sur un objet métier

Ce texte ci dessous est extrait du blog de ea-is.blogspot.com article concernant l'Anatomie d’un Objet métier.

Conclusions élargies sur un objet métier.

1- Les objets métiers (OM) sont une abstraction de la réalité. La photographie métaphorique doit laisser la place à la modélisation. La modélisation sémantique doit tenir compte de la posture des métiers à leur égard, leurs intérêts et leurs objectifs.
2- Les objets métier sont résumés à l’aide d’une abstraction, nommée « classe d’objet ». Cette classe d’objet doit être typée plus finement. Dans le cas de nos objets métiers, on pourrait par exemple choisir les termes de « Concept », « Entité », ou encore « OM ». C’est une excellente idée d’utiliser un formalisme d’abstraction simple, évolutif, standard et ouvert, comme UML.
3- Le terme « modèle d’objet métier » (MOM) n’est pas un terme très propice, car il peut prêter à confusion, entre un modèle de classe et un modèle d’instance. Les anciens parlaient de « Modèle Conceptuel de Donnée », qui cette fois opposait, le terme de concept et de donnée. Dans notre affaire, « Modèle des Concepts Métier » met tout le monde d’accord.
4- 90% des soi-disant experts en modélisation confondent « Modèle » et représentations graphiques du modèle. Pour ne plus jamais subir ce genre d’amalgame, rappelons gentiment que si un modèle est assimilable à un hyper cube, les vues ou « Diagrammes » en sont les faces de projection. Ainsi, retenons qu’un modèle se conjugue plutôt au singulier alors que les diagrammes sont les vues plurielles du modèle. La confusion a été entretenue pour la raison suivante : Cette sacro-sainte mauvaise habitude de vouloir absolument représenter tous les concepts d’un modèle sur une seule vue. Du coup le modèle était le diagramme. Cette mauvaise habitude persiste encore dans certains outils d’urbanisation qui affirme : « les vues sont le modèle ». Ce type de pratique est néfaste à 2 titres :
-Manque d’agilité de l’outil dans la gouvernance de la donnée: Dans le processus d’acquisition de l’information, des architectes, tout concept n’est pas forcement représentable intelligiblement sur une vue, immédiatement.
-Les éléments du modèle peuvent et doivent le plus souvent être exploité par transformations, générations successives, et ne pas sans tenir à refaire la tapisserie du mur de son bureau.
5- Un modèle n’est jamais complet ou exacte du premier coup. Il est donc important d’itérer sur sa mise à jour et d’automatiser les conséquences de cette itération, que cela occasionne sur le reste du système (c’est un premier principe d’agilité des données en EA)
6- Les objets métiers doivent avoir une définition métier précise, permettant d’être identifié naturellement par leurs bénéficiaires. L’architecte « sémantique » gère la synonymie, et l’homonymie des noms des OM.
7- L’architecte sémantique est l’une des casquettes de l’architecte d’entreprise.
8- Dès la conception, L’architecte « sémantique » doit toujours garder à l’esprit qu’un objet métier deviendra très probablement (du moins on l’espère) une donnée informatique.

Qualité logicielle avec la norme ISO 9126 et SquaRE

En situation d'utilisation de logiciel ou de production de logiciel, il convient de prendre en compte certain règles pour une meilleure qualité d'utilisation ou de production. Nous parlerons très succinctement des normes ISO 9126 et/ou SquaRE.

La norme ISO 9126, « Technologies de l’Information : Qualités des produits logiciels », définit et décrit une série de caractéristiques qualité d’un produit logiciel.
Voir ci dessous le classement défini par cette norme en 2001.

Les caractéristiques qualité définies par cette norme sont :

La capacité fonctionnelle,
La fiabilité,
La facilité d'usage,
L'efficacité,
La maintenabilité,
La portabilité.

Les sous caractéristiques sont rangées de la manière suivante :

La capacité fonctionnelle :

L'aptitude
L'exactitude
L'interopérabilité
La conformité réglementaire
La sécurité

La fiabilité :

La maturité
La tolérance aux fautes
La capacité de récupération

La facilité d'usage :

L'exploitabilité
La facilité d'apprentissage
La facilité de compréhension

L'efficacité :

L'efficacité des ressources employées
L'efficacité des temps de réalisation

La maintenabilité :

La stabilité
La facilité de modification
La facilité d'analyse
La facilité à être testé

La portabilité :

La facilité d'installation,
La facilité de migration,
L'adaptabilité
L'interchangeabilité

Pour ce qui concerne la norme SquaRE (Software product quality Requirement and Evaluation) elle est issue de la norme ISO 9126. Elle est constitué de huit caractéristiques principales qui ne sont pas très distinct de l'ISO 9126, ce sont:

L’Adéquation fonctionnelle
La Performance
La Compatibilité
La Facilité d'Utilisation
La Fiabilité
La Sécurité
La Maintenabilité
La Portabilité


Le respect de ces principes et normes dans la conception et la réalisation d'un produit logiciel assure une meilleure qualité du produit final.