Modèle de présentation du CEA de la GI/TI

Nom du client
Nom du projet
Modèle de présentation du CEA de la GI/TI

Nom de présenteur
Direction générale

Date

Table des matières

  1. Contexte
  2. Introduction
  3. Historique et sommaire
  4. Exigences fonctionnelles et sommaires des avantages
  5. Sommaire des options de la solution et des options opérationnelles
  6. Description des solutions
  7. Flux de données du système (schéma)
  8. Liste des applications
  9. Facteurs RICAF (Rapports, Interfaces, Conversions, Améliorations et Formulaires) ou utiliser un schéma de cas
  10. Lacunes
  11. Hypothèses et dépendances
  12. Conversion et transfert
  13. Plan du système
  14. Point à prendre en compte lors du déploiement
  15. Points à prendre en compte lors du soutien
  16. Questions ouvertes
  17. Sommaire du modèle d'estimation

Contexte

Le Comité d'examen de l'architecture de la GI/TI permet :

  • l'harmonisation de l'architecture d'entreprise (AE) avec les objectifs stratégiques de Services publics et Approvisionnement Canada (SPAC);
  • l'harmonisation de l'ensemble des initiatives et des activités de GI/TI avec l'AE incluse dans les plans stratégiques de SPAC et du DPI.

Les initiatives et les projets éventuels d'une valeur estimative supérieure à 1 M$ sont portés à l'attention du Comité d'examen de l'architecture de la GI/TI (CEA GI/TI) par le Bureau d'exécution des projets (BEP) ou l'organisation responsable de la relation client. L'équipe d'examen de l'architecture de la GI/TI vérifie l'énoncé des exigences et tous les documents d'appui afin d'évaluer l'incidence possible des projets proposé. Les membres du CEA de la GI/TI se réunissent ensuite afin de se pencher sur les projets qui peuvent avoir une incidence sur l'AE.

Le CEA de la GI/TI prend également en considération l'incidence relative au respect de la politique en matière de sécurité, de confidentialité et d'information. L'examen a habituellement lieu avant l'achèvement du Plan préliminaire de projet pour s'assurer que :

  • les résultats du projet sont harmonisés avec la vision relative à l'AE;
  • le projet fait appel aux éléments et aux processus existants, ce qui pourrait optimiser les résultats, réduire les coûts ou offrir des occasions d'intégration.

Introduction

  • La solution conceptuelle décrit la future solution, particulièrement l'application, la technologie, le processus et les efforts et la formation nécessaire pour le soutien.
  • La solution conceptuelle contient les décisions de conception pour l'application, le processus, la technologie, ainsi que le soutien à la formation et au rendement.
  • Créer ce produit livrable à l'étape de planification afin de :
    • déterminer les applications de la solution et les relations entre elles.
    • décrire les processus opérationnels futurs à un niveau plus élevé.
    • décrire une vision de l'environnement de travail technique qui prendra en charge les applications définies.

Historique et sommaire

  • Décrire l'historique du projet afin qu'il appuie la discussion les informations fournies dans ce document.
  • Faire un résumé du problème opérationnel auquel le client est confronté.
  • Insérer des points de discussion pertinents sur les avantages, les règles, la disponibilité des ressources et l'élément moteur et le motifs du projet.
  • Si l'initiative fait partie d'un plan de lancement multi-phases, indiquer de quelle façon le lancement de ce projet peut être lié à d'autres lancements dans la stratégie de la solution globale.

Exigences opérationnelles

Sommaire du tableau

Le tableau décrit les exigences opérationnelles de haut niveau par l'identité des exigences, par titre, par exigences et par priorité.

Entrer les exigences opérationnelles de haut niveau que cette solution conceptuelle permettra d'atteindre.
ID exig. Titre Exigence Priorité
EHN1      
EHN2      
EHN3      
EHN4      
EHN5      
EHN6      
EHN7      
EHN8      
EHN9      
EHN10      

Sommaire des avantages

  • Fournir un sommaire des avantages attendus (lorsque disponibles).

Sommaire des options de la solution et des options opérationnelles

Sommaire du tableau

Le tableau décrit le sommaires des options de la solution et des options opérationnelles par option opérationnelle, par option de la solution et par commentaires/recommendations.

Option opérationnelle Option de la solution Commentaires/
Recommandations
Option opérationnelle 1 option de la solution 1
option de la solution n
 

Description des solutions

  • Déterminer les applications de la solution, de chacune des options de la solution tel qu'appropriées, et les relations entre elles.
  • Considérer toutes les applications planifiées et existantes pour appuyer la solution. L'étendue de l'intégration avec les autres applications devra être prise en considération, car cela aura des répercussions lors de la définition de l'architecture d'application et les répercussions possibles sur la solution de reprise après sinistre.
  • Élaborer ce produit livrable durant l'étape du plan afin de :
    • Schématiser les applications nécessaires pour appuyer la solution, qui montre les diverses couches techniques et fonctionnelles de l'application.
    • Fournir une base pour la conception détaillée de la technologie.
    • Démontrer les dépendances entre les applications.
    • Accroître la prévisibilité du rendement de l'application (car le comportement d'exécution des composants communs est familier et constant)
    • Fournir un plan de construction et assurer une continuité sur les systèmes.
    • Dresser la liste des exigences fonctionnelles.

Schéma du flux de données du système

  • Documenter :
    • les sources d'information et bases de données utilisées.
    • l'interface entre les systèmes et les utilisateurs finals.
    • les exigences en matière d'information et flux.
    • l'intégration à d'autres applications.
    • les exigences et l'intégration à la reprise après sinistre.

Liste des applications

Dressez la liste des différentes applications qui font parties de la solution et de quelle façon elles communiquent entre elles.

Utilisateurs

En tirant parti de l'information sur les styles de travail des utilisateurs, des exigences relatives à la géographie et à l'interface, nous pouvons déterminer les voies d'accès nécessaires pour les applications cibles.

Applications commerciales

Les applications commerciales ciblées sont ces suites de solutions que l'architecture est conçue pour prendre en charge.

Services d'intégration

Les services d'intégration sont la technologie qui permet de fournir une capacité d'intégration des systèmes d'applications incompatibles. La couche des services d'intégration est constituée d'objets opérationnels, de collaborateurs et d'adaptateurs. Les objets opérationnels fournissent un enveloppeur pour les transactions regroupées logiquement. Cela permet aux applications commerciales ayant une interface générique de cacher la complexité de l'interaction avec les systèmes dorsaux. Les collaborateurs rassemblent les données de multiples systèmes dorsaux en utilisant les adaptateurs, qui fournissent un accès simplifié à chacun des systèmes dorsaux. Certains adaptateurs peuvent être développés sur place alors que d'autres peuvent fournis par un tiers.

Systèmes opérationnels

Les systèmes opérationnels sont constitués de toutes les applications d'arrière-guichet existantes et nouvelles et de bases de données dont tireront parti les applications commerciales pour leurs fonctions et les données. Cela comprend les applications personnalisées et les progiciels ainsi que les bases de données, les entrepôts de données et les magasins de données.

Services technologiques

Les services technologiques sont un ensemble complet de services d'exécution nécessaires pour prendre en charge les applications et les styles de traitement ciblés.

Facteurs RICAF

  • Les facteurs RICAF sont une liste d'objets requis pour la solution.
  • RICAF signifie Rapports, Interfaces, Conversions, Améliorations et Formulaires.
  • Les objets RICAF devraient être présentés dans un format tableau. Le tableau doit contenir les renseignements qui suivent :
    • le système source
    • la complexité (simple, moyen ou complexe)
    • si l'objet est nouveau ou une modification d'un objet existant
    • le nom de l'objet
    • une description de l'objet à modifier ou à ajouter

Lacunes

  • Déterminer et décrire toute exigence opérationnelle qui ne peut être intégrée à la solution. Dire pourquoi ce n'est pas possible.
  • Voici la définition d'une lacune :
    1. Pour le progiciel, les lacunes sont les domaines de fonctionnalité qui ne sont pas pris en charge par la configuration standard du progiciel.
    2. Une exigence opérationnelle qui ne peut être respectée dans un système ou une application.

Hypothèses et dépendances

  • Dresser la liste de toutes les hypothèses faites sur la solution. L'intention n'est pas de répéter les hypothèses du projet, mais celles qui portent davantage sur ce qui doit être en place pour que la solution soit mise en œuvre de la façon décrite.
  • Voici des exemples des hypothèses à considérer :
    • les changements qui doivent être apportés aux applications existantes.
    • l'infrastructure nécessaire.
    • les compétences que le client doit avoir, c.-à-d. EAU à un moment précis.
    • une solution de reprise après sinistre existante dont on tirera parti.

Conversion et transfert

  • Décrivez les processus de conversion et de transfert qui sont nécessaires pour cette solution.
    • Est-ce que les conversions sont manuelles ou automatiques?
    • Quel sera le processus à suivre pour convertir les données et quel est le délai?
  • Définition
    • La conversion de données du format actuel à la structure requise par la nouvelle application. Une conversion peut être effectuée à l'aide d'un programme automatisé ou manuellement.

Plan du système

  • L'architecte technique définit le plan des environnements de développement, d'exécution et d'exploitation.
  • À plus grande échelle, l'architecture technique se réfère aux composantes de l'infrastructure dans l'entreprise.
  • Au niveau de la mise en œuvre, l'architecture technique est l'infrastructure physique (dédiée ou conjointement) et les composantes de l'application qui décrivent aux concepteurs et développeurs les environnements qui doivent être mis sur pied et à jour durant le cycle de développement.

Point à prendre en compte lors du déploiement

  • Dresser la liste de toutes les exigences importantes liées aux activités de déploiement de cette solution.
    • Y'aura-t'il de nouveaux processus et une nouvelle technologie déployée en région.
    • Combien d'utilisateurs et de sites seront touchés?
    • Est-ce qu'une nouvelle solution est recommandée pour faire partie de l'essai annuel de reprise après sinistre?
  • Définition
    • Étape qui présente les nouvelles capacités opérationnelles dans l'environnement d'exploitation. Les tâches de cette étape effectuent une transition du personnel, déploient de nouveaux processus et une nouvelle technologie et stabilisent des activités. Ces tâches sont répétées pour chaque unité de déploiement.

Points à prendre en compte lors du soutien

  • Quels sont les impacts à l'ANS en place?
  • Quels sont les impacts à la solution de reprise après sinistre?
    • La gestion des applications doit prendre part à l'évaluation.
  • Quelles sont les nouvelles applications?
  • Quelles sont les nouvelles composantes de la reprise après sinistre?
    • 1 AP - programmeur qualifié pour installer les correctifs des applications en continu.
    • ½ Expert Linux pour le soutien du SE.
    • Soutien téléphonique 24 h sur 24, 7 jours sur 7.

Questions ouvertes

  • Dresser la liste des questions qui doivent être réglées concernant la solution conceptuelle.
  • La liste peut être dressée sous forme de tableau - voir l'exemple ci-dessous.
Sommaire du tableau

Le tableau décrit une liste de questions ouvertes qui doivent être réglées concernant la solution conceptuelle par numéro d'identité, la question, la gravité, la mesure et le status.

ID Question Gravité Mesure Statut
1        
2        
3        

Sommaire du modèle d'estimation

  • Insérer un sommaire du modèle d'estimation approuvé comme service direct au client.
  • Coûts uniques :
    • développement personnalisé
    • configuration
    • formation
    • progiciel
    • matériel et logiciel
  • Coûts continus :
    • soutien à l'application et au service
    • services de données
    • gestion des licences
    • Maintien du matériel