[PDF] cartographie de l'hydrographie de l'afrique
[PDF] cartographie des métiers
[PDF] cartographie des risques comptables
[PDF] cartographie des zones de chaleur et de fraîcheur dans paris
[PDF] cartographie fonctionnelle et applicative
[PDF] cartographie fonctionnelle système d'information
[PDF] cartographie fonds marins
[PDF] cartographie géologique cours
[PDF] cartographie métiers rh
[PDF] cartographie r
[PDF] cartographie togo
[PDF] cartographie végétation
[PDF] cartography r
[PDF] cartreize l51 aix marseille
[PDF] cartreize ligne 50 marseille aix
le " comment faire » pour les activités liées à l"architecture applicative existante et à l"architecture applicative cible de la démarche méthodologique d"urbanisation de système d"information.
LE LIEN
ENTRE
L"ARCHITECTURE APPLlCATIVE
ET
L"ARCHITECTURE FONCTIONNELLE
rappel
?une des activités fondamentales des projets d"urbanisation consiste à représenter les différentes visions du système d"information sous des formes permettant de les exploiter (une base de données ou un référentiel d"AGL par exemple).
cf, le modèle générique des concepts déjà vu.?Au niveau de ce modèle générique, le lien entre l"architecture fonctionnelle et l"architecture applicative est assuré par l"association entre la classe bloc applicatif et la classe bloc (fonctionnel). ?Idéalement, un bloc fonctionnel devrait correspondre à un bloc applicatif. ?dans la réalité, on n"a qu"exceptionnellement ce genre de correspondance bijective du fait ■
de considérations d"implémentation,
de mise en place de progiciels dont le contour ne correspond jamais aux blocs fonctionnels imaginés,
etc. ?Il faut donc gérer la correspondance entre blocs fonctionnels et blocs applicatifs. ■ Un bloc fonctionnel peut donner lieu à 1 à N blocs applicatifs, un bloc applicatif peut contribuer à l"implémentation de 1 à N blocs fonctionnels.
?Au-delà, le lien avec le bloc fonctionnel permet la traçabilité jusqu"aux objectifs stratégiques métier comme vue précédemment
LA CARTOGRAPHIE APPLlCATIVE EXISTANTE
Cette activité consiste à représenter les structures décrivant le système d"information sous une forme exploitable pour des traitements ultérieurs (exemple : pour effectuer des études d"impact lors de la conception des réaménagements du système informatique). Cette tâche est destiné à réaliser la satisfaction des besoins ou la résolution de problèmes (actuels ou à venir) => prendre en compte la situation actuelle, d"en faire un diagnostic et un pronostic. Les objectifs de la cartographie applicative de l"existant sont les suivants:■ prendre connaissance de l"architecture applicative actuelle; décrire l"architecture applicative actuelle; évaluer les performances du système d"information et faire des propositions d"axes d"amélioration.
Dans la pratique,
il faut s"appuyer sur la connaissance de l"existant par des équipes d"études et de développements de l"entreprise ou de l"organisme.
La première étape
pour l"équipe du projet d"urbanisation du système d"information,■ adapter une fiche îlot (applicatif) il faut :■ d"une part que les informations demandées soient toutes utiles pour l"étude, d"autre part ne pas demander des informations déjà disponibles par ailleurs enfin, s"assurer que les informations demandées ont une chance d"être collectées compte tenu du contexte. Plus les questions sont fermées et mieux c"est. Il faut établir la liste des valeurs possibles pour les rubriques suivantes:■ entités organisationnelles concernées; acteurs existants; classes concepts existantes; processus métier existants; types de sites existants.
La deuxième étape?
l"équipe du projet d"urbanisation du système d"information doit présenter aux équipes d"études et de développements les résultats recherchés. Cette étape permet d"obtenir l"adhésion des
équipes et de s"assurer de la bonne
compréhension de chaque rubrique de la fiche
îlot.
La troisième étape?
les équipes étude et développement sollicitées remplissent les fiches en bénéficiant du coaching de l"équipe du projet d"urbanisation du système d"information. il faut demander assez rapidement à revoir ■ la liste des fiches îlots envisagés, de manière à s"assurer que le niveau de granularité d"un
îlot a bien été compris,
les premières fiches, de manière à s"assurer que les différentes rubriques sont également bien comprises.
La quatrième étape
exploiter les fiches. des allers-retours avec les rédacteurs des fiches sont nécessaires, et les informations sont saisies dans l"outil retenu pour la cartographie. avoir une approche top-down par opposition à l"approche bottom-up suivie jusqu"à présent. Rq: déterminer les quartiers et les îlots par analyse des fiches îlots et en raisonner par les flux entre îlots est, d"une part un travail de fourmi, d"autre part ne donne pas un meilleur résultat que de déterminer a priori ( en se basant sur la connaissance des équipes étude et développement ) quelles sont les zones et les quartiers principaux et d"essayer de placer les îlots dans ces zones et dans ces quartiers applicatifs.
La cinquième étape
demander la validation de la cartographie applicative de l"existant ainsi réalisée. Les équipes étude et développement ayant rempli les fiches donnent un avis au comité de pilotage pour prononcer ou non cette validation
FinalementCette cartographie applicative montre:
■les différents applicatifs composant le système informatique actuel. Sa granularité correspond à l"identification des zones quartiers et îlots tels que définies dans le glossaire; ■les flux entre ces applicatifs ( sens, temps réel, temps différé, automatisé, manuel, description fonctionnelle du contenu de l"échange, classement selon la typologie retenue fiche descriptive pour chaque îlot
ÎLOT X
1ère partie: description métier
· 1. Contribution aux processus métier
· 2. Entités organisationnelles concernées · 3. Acteurs concernés y compris tiers (nombre, type)
2ème partie : description fonctionnelle
· 4. Objectifs
· 5. Classification (Critique, Important, Utile) · 6. Entrées
· 7. Sorties
· 8. Fonctions
· 9. Classes concepts gérées
· 10. Interfaces
3ème partie: description applicative et technique
· 11. Année de développement
· 12. Volumes traités (Max, Min, Moy)
· 13. Disponibilité
· 14. Fiabilité
· 15. Matériel(s)
· 16. Système(s) d"exploitation
· 17. SGBD ou système de gestion de fichiers · 18. Middleware
· 19 . Types de sites concernés
4ème partie: premiers éléments de diagnostic
· 20. Degré d"urbanisation
· 21. Principaux points forts
· 22. Principaux problèmes
· 23. Nouveaux besoins
LA TRANSITION
DE
L"ARCHITECTURE FONCTIONNELLE CIBLE
VERS
L"ARCHITECTURE Applicative CIBLE
l"architecture applicative est la structuration du système d"information en blocs applicatifs communicants. Le passage de l"architecture fonctionnelle à l"architecture applicative est à la fois rigoureux et artistique en ce sens qu"il y a un certain nombre d"étapes types et de règles à respecter qui balisent le chemin de l"urbaniste, mais sans toutefois constituer des algorithmes aboutissant s"ils sont appliqués correctement au seul et unique bon résultat. L"architecture applicative répond à la question: Comment? (QQOQCP) Contrairement à l"architecture fonctionnelle, elle tient compte des acteurs et de l"organisation. De nouvelles notions sont donc ajoutées :■ bus logiciels, front office, middle office, back office, copies, instances, sites et d"artères de communication. l"architecture applicative Le gestionnaire de flux (ou bus logiciel). Une fois le découpage du système d"information réalisé, il s"agit de permettre la communication entre les différents blocs. Dans un milieu urbain, ceci se traduit par la mise en place des axes de communication, la voirie, les réseaux d"égouts... Dans le système d"information, c"est le rôle du gestionnaire de flux qui assure ces échanges au moyen de composants spécialisés (messageries inter-applicatives, bus logiciels, etc.) sur la base d"un format standardisé, de façon transparente pour les applications. À ce stade, on parle du gestionnaire de flux car d"un point de vue logique, il est unique, mais cela ne préjuge en rien de l"implémentation physique pour laquelle différents bus logiciels peuvent être installés et éventuellement à partir de produits différents.
Le gestionnaire de flux
Il permet aux applications de communiquer sans se préoccuper: · de la localisation physique des applications émettrices ou destinataire(s) ; · des moyens physiques et protocoles utilisés pour communiquer;
· de la forme attendue par le destinataire.
Le système de gestion de flux assure quatre grandes fonctions: · l"acheminement des messages (flux) de l"émetteur vers le destinataire; · le stockage des messages avec gestion d"échéancier et de seuil ; · l"activation des applications à échéance (date, heure, seuil)ou au fil de l"eau; · la transformation des messages: enrichissement et mise en forme.
Le gestionnaire de flux
La prise?
La prise est le moyen mis à la disposition du monde extérieur par un bloc, pour proposer ses services.
Une prise comporte :■
des structures de données et un ou des noms d"opérations que l"on peut utiliser dans ce bloc. Les blocs fonctionnels sont ensuite implémentés par des blocs applicatifs qui communiquent par le biais de messages échangés via le logiciel gestionnaire de flux (ou plusieurs d"un point de vue physique mais un seul d"un point de vue logique).
Le message?
Le message est le mode de propagation entre blocs applicatifs d"un flux de données résultant d"un événement de gestion. Il représente un flux circulant à l"intérieur de l"entreprise ou échangé entre l"entreprise et son environnement. Il peut être transmis de manière synchrone ou asynchrone. front office / back office / middle office ?
Le front office
est l"ensemble des services orientés client activables directement par l"acteur externe en contact avec le client ou par le client lui-même.
Le back office
est l"ensemble des services orientés produit non activables directement par l"acteur externe en contact avec le client ou par le client lui-même.
Le middle office
quotesdbs_dbs4.pdfusesText_7
[PDF] La cartographie, outil de pilotage de lévolution des systèmes d