Présentation de la méthode et exemple
La spécification des projets d'évolution du SI avec HOPEX Application Design comprend les étapes suivantes :
Décrire le périmètre du projet : cette première étape consiste à définir le périmètre applicatif du projet, ses livrables, la décomposition éventuelle en sous-projets et l'organisation des intervenants sur le projet.Décrire les objectifs et les exigences du projetConstruire les spécifications fonctionnelles du projet : cette étape consiste à définir les fonctionnalités attendues et le contexte d'utilisation des applications du projet.Décrire les données du projet : il s'agit de décrire la façon dont les données d'une organisation sont utilisées par les processus et les applications.Construire les spécifications techniques du projet : les spécifications techniques du projet visent à détailler l'architecture technique des composants du projet.Décrire les échanges de données : il s'agit de décrire les contrats d'échange entre les composants d'une l'architecture métier ou informatique.Présentation de l'exemple
Ces différents points sont illustrés par l'exemple d'une entreprise de location de bateaux qui a pris la décision d'améliorer son processus d'achats.
La disponibilité des bateaux étant un facteur essentiel à l'activité de l'entreprise, un processus spécifique doit être défini pour traiter les achats urgents du service d'entretien des véhicules.
Les processus des achats de l'entreprise se répartissent entre les processus d'achats opérationnels et les processus d'achat d'investissement. Les processus d'achats opérationnels incluent les achats de pièces détachées et de matière première destinés à l'entretien et à la réparation des bateaux.
Présentation du contexte organisationnel
Le nouveau processus organisationnel prévu pour le traitement des demandes d'achat urgentes vise à étendre les responsabilités de l'assistant achats afin d'envoyer la commande d'achat dans des délais très courts.
Processus organisationnel "Traiter les demandes d'achat urgentes".
L'assistant achat commence par analyser la demande d'achat. Si le montant est important, le processus normal de traitement des demandes d'achat est mis en oeuvre.
Si le produit est disponible, l'assistant envoie la demande de mise à disposition.
Sinon, l'assistant envoie la commande d'achat au fournisseur. Le reste du traitement est effectué dans le cadre du processus "Traiter les demandes d'achat" normal.
Pour lui permettre d'analyser la demande d'achat et de passer la commande rapidement, il est prévu de mettre à la disposition de l'assistant achat une nouvelle application lui donnant accès aux données concernant les stocks et les fournisseurs.
Décrire un projet et son environnement
Le projet est l'élément de base de l'utilisation de HOPEX Application Design.
Un projet d'Architecture d'Entreprise est une partie d'un système dont l'étude est confiée à une même équipe, qui transforme un système, ou une partie d'un système, en vue d'atteindre un objectif donné.
Pour plus de détails sur la création d'un projet, voir Créer un projet de conception d'application.Décrire le périmètre du projet implique de réaliser les tâches suivantes :
• décrire les applications du projet et leurs échanges
• décrire les livrables du projet
Avec HOPEX Application Design, vous pouvez également définir les différentes organisations concernées par le projet.
Pour plus de détails sur la gestion des organisations concernées par le projet, voir Décrire l'organisation des participants au projet.Décrire les applications du projet et leurs échanges
Un environnement d'application permet de représenter un contexte d'utilisation d'une application.
Avec HOPEX Application Design, les diagrammes de scénario de flux permettent de décrire les flux échangés par une application, un service applicatif ou un micro service dans un contexte particulier.
Pour plus de détails sur les diagrammes de scénario de flux, voir Décrire les scénarios de flux.Le diagramme ci-dessous présente les flux échangés dans le contexte de l'environnement de l'application "Système de Gestion des achats".
Les achats de matériel destinés à l'entretien des bateaux sont effectués directement par le bureau de représentation en utilisant un service applicatif "Achats de matériel". Celui-ci fait appel à une application centralisée de "Gestion des achats" au siège.
S'il s'agit d'un nouveau type de matériel ou d'un nouveau fournisseur, une demande de contrat est envoyée au fournisseur à l'aide de l'application du siège. Celui-ci renvoie en échange une proposition de contrat qui est soumise au demandeur.
Dans les autres cas, un agent du bureau de représentation envoie un ordre d'achat au fournisseur à l'aide de l'application "Achats de matériel".
La réception des achats est réalisée à l'aide de l'application "Gestion des stocks bateaux" du bureau de représentation.
La facture est traitée par l'application "Facturation" du siège.
Décrire les livrables du projet
Après analyse, les éléments applicatifs qui seront affectés par le projet sont décrits dans les livrables du projet.
Pour plus de détails sur la mise à jour des livrables d'un projet, voir Décrire les scénarios de flux.
L'application "Achat de matériel" est la principale application impactée par le projet, en particulier pour l'amélioration de son portail d'accès.
L'application "Gestion des stocks" est utilisée par l'application "Achat de matériel" pour consulter et mettre à jour les informations concernant l'état des stocks et, en particulier, celui des pièces détachées.
L'application "Gestion des achats" utilise la base de données "Catalogue" pour passer une commande d'achat.
L'application "Gestion Entretien et Réparation" et l'application "Gestion des pièces de rechange" vont également utiliser le portail de l'application "Achats de matériel".
Pour plus de détails sur la description d'un environnement de projet, voir Définir un projet AD et son périmètre applicatif.
Décrire les objectifs et les exigences d'un projet
Afin d'affiner la description du périmètre technique d'un projet, cette étape consiste à collecter les objectifs et les exigences des différentes catégories d'utilisateurs.
Un objectif est un but que l'on cherche à atteindre ou la cible visée par un processus ou une opération. Il permet de mettre en évidence les points que l'on veut améliorer pour ce processus ou cette opération.Une exigence est un besoin ou une attente formulés explicitement, imposés comme une contrainte à respecter dans le cadre d'un projet de certification, d'organisation ou de modification du système d'information d'une entreprise.Dans notre exemple, le développement d'une application supportant le traitement des demandes d'achat urgentes vise plusieurs objectifs:
D'un point de vue fonctionnel, cette application doit permettre de réduire la durée d'immobilisation des bateaux due à un défaut de pièces détachées. Le traitement des demandes d'achat doit donc être accessible 24h sur 24 parce que les bureaux de représentation de l'entreprise sont répartis dans différents continents et 7 jours sur 7 puisque l'entreprise intervient dans le métier du tourisme.
Pour limiter les délais liés à la recherche de fournisseurs de pièces détachées déjà référencées ou non, le département achat a décidé de mettre en place un catalogue de produits et une base centralisée de fournisseurs.
Enfin, ce projet répond à un objectif technique de modernisation et de sécurisation des accès entre le siège de l'entreprise et les bureaux de représentation.
Le diagramme d'objectifs et d'exigences d'un projet permet de représenter et des classer les éléments recensés.
Pour plus de détails sur la gestion des objectifs et exigences, voir "Définir les objectifs et exigences d'un projet (AD)", page 43.
Construire les spécifications fonctionnelles
Après avoir défini le périmètre, les objectifs et exigences du projet, cette étape consiste à décrire les fonctionnalités attendues du futur système par les différentes catégories d'utilisateurs.
Décrire la carte des fonctionnalités attendues du projet
Une carte de fonctionnalités est un assemblage de fonctionnalités avec leurs dépendances qui, conjointement, définissent le périmètre d'une architecture matérielle ou logicielle.
Décrire la carte de fonctionnalités permet de dresser la liste des fonctionnalités attendues du projet et d'associer chacune d'elles à un objectif ou une exigence, d'une part, et à un élément applicatif d'autre part.
Pour plus de détails sur la gestion des fonctionnalités attendues du projet, voir Décrire les fonctionnalités d'un projet.Dans notre exemple, une carte de fonctionnalités se présente sous la forme du diagramme suivant.
Les fonctionnalités attendues du projet de traitement des achats urgents sont relatives au temps de réponse et à la disponibilité de l'application depuis les agences de locations. Les fonctionnalités principales sont déclinées en sous-fonctionnalités.
Décrire les environnements d'application du projet
Un environnement d'application présente le contexte d'utilisation des applications d'un projet. Il décrit les interactions, entre les acteurs impliqués et les applications internes et externes du projets, qui permettent d'assurer les fonctionnalités attendues du projet.
Plusieurs types de diagrammes sont proposés pour décrire un environnement d'application :
• Le diagramme de scénario de flux d'environnement d'application permet de décrire les flux échangés entre une application et son environnement entre dans un contexte donné.
• Le diagramme d'environnement d'application permet de décrire les interactions entre une application et son environnement décrit : ses utilisateurs, les applications et les services externes.
• Le diagramme de cas d'utilisation d'environnement d'application permet de décrire au format UML les cas d'utilisation de l'environnement d'application.
Une même application peut être associée à plusieurs environnement d'application afin de représenter plusieurs contextes d'utilisation de l'application.Exemple de diagramme de scénario de flux
Un diagramme de scénario de flux peut être construit pour un environnement d'application, une application, un service applicatif ou un micro-service.
Pour plus de détails sur la construction d'un diagramme de scénario de flux, voir Décrire les scénarios de flux.
Ce diagramme de scénario de flux décrit l'environnement de l'application "Achat de pièces détachées".
La demande de "pièce détachée" est envoyée par l'assistant Achat local à l'application "Achat de matériel".
L'application "Achat de matériel" consulte les stocks. Si la pièce n'est pas en stock, une "demande d'achat urgent est envoyée" à l'application "Gestion des achats".
L'application "Gestion des achats" valide ou refuse la demande.
Exemple de diagramme de cas d'utilisation
Vous pouvez également utiliser un diagramme de cas d'utilisation pour décrire les interactions entre un élément applicatif et les acteurs de l'organisation dans le contexte précis.
Un cas d'utilisation est une suite d'actions qui amène un résultat observable pour un acteur particulier. Des scénarios illustrent les cas d'utilisation par l'exemple.Les diagrammes de cas d'utilisation peuvent être construits pour des environnements d'application, des applications, des services applicatifs et des micro-services.
Pour plus de détails sur la création d'un cas d'utilisation, voir Décrire un cas d'utilisation d'un projet.
Le système est utilisé pour la consultation des pièces en stock et la commande de nouvelles pièces détachées.
La consultation des pièces en stock est effectuée par l'assistant achat local. Suite à la consultation, l'assistant peut faire une demande de mise à disposition.
Deux types de commandes sont possibles; une commande de pièces déjà référencées ou une commande de pièces non référencées. Dans les deux cas, un bon de commande doit être rédigé.
Le suivi de la commande est assuré à la fois par l'assistant achat local et l'intervenant chargé de la réparation des bateaux.
Exemple de diagramme d'environnement d'application
Pour plus de détails sur la construction d'un diagramme d'environnement d'application, voir Décrire un environnement d'application.Le diagramme suivant décrit l'environnement d'application correspondant au traitement des achats de pièces détachées.
Diagramme d'environnement d'application "Achat de pièces détachées"
Les demandes d'achat de pièces détachées sont formulées par les intervenants sur les réparations de bateaux et elles sont traitées par les assistant achat locaux.
La consultation des pièces en stock est effectuée par l'assistant achat local. Suite à la consultation, l'assistant peut faire une demande de mise à disposition.
Deux types de commandes sont possibles; une commande de pièces déjà référencées ou une commande de pièces non référencées. Dans les deux cas, une demande de mise à disposition est effectuée.
Le suivi de la commande est assuré à la fois par l'assistant achat local et l'intervenant chargé de la réparation des bateaux.
Pour plus de détails sur les spécifications fonctionnelles, voir Décrire les spécifications fonctionnelles d'un projet.
Décrire les données du projet
Cette étape a pour objectif de décrire les domaines de données afin de déduire la structure des bases de données qui seront mise en oeuvre par le projet.
Pour mener à bien cette étape, nous vous proposons de réaliser les tâches suivantes.
Spécifier les paquetages
Le paquetage vous permet de classer les éléments référencés dans un projet. Vous pouvez créer des sous-paquetages dans un paquetage afin de classer plus finement les objets, par exemple les acteurs d'un projet.
Les demandes d'achat urgentes sont prévues pour traiter les achats de pièces détachées et les demandes de location de bateau. Dans ces deux cas, les utilisateurs sont des acteurs du domaine des achats.
Spécifier les domaines de données logiques
Un domaine de données logique permet de définir une structure de données logiques constituée de classes et de vue de classes.
Un domaine de données logique est détenu par un paquetage, il peut référencer des objets détenus dans d'autres paquetages.
Lors d'une intégration, une structure physique correspondante peut être définie via un domaine de données physique. Celui-ci est constitué de tables et de vues de tables.
Le diagramme de domaine de données logiques suivant représente une structure de données relative aux Commandes.
Spécifier les domaines de données relationnelles
Un domaine de données relationnelles permet de positionner les bases de données dans le modèle logique de gestion des données.
Le modèle de données relationnelles du projet "Automatisation des demandes d'achat" est présenté ci-dessous.
L'application gère les demandes d'achat, les commandes et les stocks de produits dans chacun des bureaux de représentation. Un catalogue centralisé des produits et des fournisseurs est mis en place.
Les contrats avec les fournisseurs référencés sont également accessibles depuis l'application.
Pour plus de détails sur la description des données, voir Décrire les données d'un projet.
Construire les spécifications système
Après les spécifications fonctionnelles et la description des données utilisées, les spécifications techniques du projet visent à détailler l'architecture cible du projet.
Décrire les éléments de l'architecture cible
Après les spécifications fonctionnelles et la description des données utilisées, les spécifications techniques du projet visent à décrire l'architecture technique des composants du projet : applications, services applicatifs, micro-services, bases de données.
Une application est un composant logiciel déployable qui fournit un ensemble de fonctionnalités à des utilisateurs.Un service applicatif est l'élément de découpage d'une application qui est mis à la disposition de l'utilisateur final de cette application dans le cadre de son travail.Un micro-service est un composant logiciel qui peut se déployer de manière autonome, mais qui ne fournit pas directement un service à l'utilisateur final. Il peut interagir avec d'autres services applicatifs, applications ou systèmes applicatifs. C'est un composant logiciel déployable qui utilise des technologies logicielles. Par exemple : service d'authentification, service d'impression de fichiers PDF.Pour plus de détails sur la description de l'architecture cible, voir "Décrire les services applicatifs et les micro-services", page 81. Présentation du processus applicatif
Un processus applicatif permet de décrire la séquence détaillée des tâches réalisées lors de l'exécution des services applicatifs.
Le diagramme de processus applicatif ci-après propose une première ébauche du fonctionnement attendu de la nouvelle application.
La recherche du produit est effectuée à partir de la base des produits référencés.
Si le produit est référencé, l'étude de l'état des stocks est réalisée.
Si le stock est suffisant, une demande de mise à disposition est activée et le processus prend fin.
Si le stock est inférieur au stock minimum, une commande est émise vers le fournisseur.
Si le produit est nouveau, une recherche de fournisseur et une étude comparative des prix est menée. Puis une commande est émise et le processus prend fin.
Pour plus de détails sur la description des processus applicatifs, voir "Décrire les processus applicatifs", page 84.Décrire les traitements par lot
L'enchaînement de traitements automatisés peut être décrit dans un diagramme de structure de chaîne de traitement de lot.
Pour plus de détails sur la description des traitements par lot, voir "Décrire les traitements de lot", page 91.Décrire la liste des services et des IHM
Il est possible de décrire les interfaces reliant les services ou les opérations avec l'extérieur. Cette description s'effectue dans un diagramme d'IHM.
Une diagramme d'IHM permet de décrire les IHM prévues.
Pour plus de détails sur la description des IHM, voir "Décrire les interfaces utilisateur", page 96.Pour plus de détails sur les spécifications techniques, voir "Décrire les spécifications techniques d'un projet", page 77.