Suvi des temps DDSIM Architecture Web viewDirection des Services...

Direction des Services Partagés_x000b_Systèmes d’Informations

LOUP

Dossier d'architecture technique

Référence : 01SLIVersion : 1Document propriété SNCF – Reproduction et diffusion interdites

SNCF – Direction DSP SI LOUPDossier d'architecture technique

Table des matières

OBJET DU DOCUMENT 1

DOCUMENTATION DE RÉFÉRENCE 1

1 CONTEXTE ET ENJEUX 1

1.1 Contexte du projet 1

1.2 Présentation de l’application 21.2.1 Description d’ensemble de l’application 21.2.2 Fiche d’identification et acteurs 2

1.3 Éléments de planning 21.3.1 Planning du projet - lotissement 21.3.2 Évolutions 3

2 EXIGENCES 4

2.1 Exigences liées aux fonctionnalités de l’application (Functionality) 42.1.1 Utilisateurs de l’application 42.1.2 Volumétries 42.1.3 Authentification 52.1.4 Traitement des erreurs 52.1.5 Internationalisation et traduction de l’interface 52.1.6 Travail en mode dégradé (avec ou sans synchronisation) 52.1.7 Opérations et fonctions planifiées (batchs) 52.1.8 Graphisme (fonctions graphiques particulières) 52.1.9 Mail 62.1.10 Flux 62.1.11 Impressions 62.1.12 Reporting 62.1.13 Autres fonctionnalités de l’application 6

2.2 Exigences techniques et contraintes 62.2.1 Exigences d’utilisation de l’application (Usabillity) 62.2.2 Exigences de fiabilité (Reliability) 72.2.3 Exigences de performances (Performance) 82.2.4 Exigences de supportabilité (Supportability) 82.2.5 Contraintes de conception et d’implémentation (+) 102.2.6 Contraintes d’interfaçage (+) 112.2.7 Contraintes physiques (matériels, systèmes, parc utilisateur...) (+) 11

3 ARCHITECTURE APPLICATIVE ET LOGICIELLE 12

3.1 Description de l’architecture applicative 12

Référence : 01LOU - Version : 1 - Révision : 17 Page ii


3.1.1 Schéma d’ensemble de l’architecture 123.1.2 Description générale de l’application 13

3.2 Description de l’architecture logicielle 153.2.1 Interface utilisateur (IHM) 163.2.2 Traitements batch 163.2.3 Éditions, impressions, reporting 163.2.4 Modes de déploiement 17

3.3 Flux 173.3.1 Flux internes 183.3.2 Flux externes 18

3.4 Sécurité applicative 193.4.1 Identification, authentification 193.4.2 Habilitations - Profils 193.4.3 Confidentialité, traçabilité 20

3.5 Surveillance applicative 20

ANNEXES 21

Glossaire 21

Fiche d’évaluation du besoin fonctionnel de base de données 22

Fiche d’évaluation des directives de sécurité du SI 22

Engagements de Service 23Classification de l’application 23Engagements de services 24Périmètre des prestations X 25

Trame de description d’environnement 26Matériels utilisés 26Logiciels utilisés 26

Référence : 01LOU - Version : 1 - Révision : 17 Page iii


Objet du document

L’objet de ce document est de décrire l’architecture logique du projet LOUP. Plusieurs aspects sont précisés dans ce document comme :

Le contexte du projet,

Les exigences et contraintes,

L’architecture applicative et logicielle.

L’application s’intègre dans l’infrastructure PMM et en utilise les composants. L’architecture technique de l’application est donc décrite dans le DAT PMM.

Documentation de référence

Ce dossier d’architecture s’appuie sur les documents suivants :

Expression des besoins, réf. xxxxx, version x.x

Dossier d’architecture technique de PMM, réf. xxxxx version x.x

1 Contexte et enjeux

1.1 Contexte du projetL’application LOUP a été mise en production en Janvier 2016 (généralisation) elle s’inscrit dans la démarche d’amélioration des systèmes d’information de la Direction du Matériel, notamment en ce qui concerne les moyens et les processus de gestion. Elle permet la gestion du temps de travail de chaque collaborateur sur chaque application.

1.2 Présentation de l’application

1.2.1 Description d’ensemble de l’application

Le Client est la Direction du Matériel. La Maîtrise d’ouvrage est assurée par DDSIM.

Le projet LOUP (AppLicatiOn de sUivi des temPs passés) est un projet de la Direction du Matériel destiné à remplacer la feuille Excel utilisée actuellement.

Le projet LOUP est un outil de maîtrise et de suivi du temps de travail de chaque employé sur chaque application utilisé par l’entreprise.

Il permet aux employés

De leur faciliter la saisie (gain de temps, plus clair)

Il permet au responsable

Référence : 01LOU - Version : 1 - Révision : 17 Page 1 / 21


De réaliser des statistiques

De pouvoir importer et exporter les données simplement

1.2.2 Fiche d’identification et acteurs

Application

Nom de l’application LOUP

Acteurs

Nom de la Maîtrise d'ouvrage (MOA) : DDSI M Architecture et Services.

Nom du Conducteur de projet (côté MOA) : David Gensel

Nom de la Maîtrise d'œuvre (MOE Études/Développement) :

DDSI M Architecture et Services

Nom du ROP et/ou RIP : David Gensel

Nom du pilote côté architecture : David Gensel

Nom des collaborateurs réalisateurs : Kévin Varichon, Théo Degarat

1.3 Éléments de planning

1.3.1 Planning du projet - lotissement

Lot 1

Fin de conception fonctionnelle 04/01/2016

Fin de conception technique 19/02/2016

Description Fonctionnalités couvertes :Saisie des temps passés par les collaborateursExport de données format XML, CSVImport de données format CSV

Lot 2

Fin de conception fonctionnelle A définir

Fin de conception technique A définir



Description Indicateurs de répartition de la charge par collaborateur et projet, par projet tous collaborateurs, mensuel, annuel

1.3.2 Évolutions

Sans objet.



2 Exigences

2.1 Exigences liées aux fonctionnalités de l’application (Functionality)

Les exigences sont remplies par l’intégration à la PMM qui fournit les fonctionnalités requises :

- Authentification annuaire

- Portabilité tablette, phablettes, smartphone, Android, IOS, PC Windows

2.1.1 Utilisateurs de l’application

Répartition géographique et points d’accès :

Les utilisateurs sont localisés à Lyon TO2, Paris Campra, tous connectés via des PC SNCF au réseau interne.

Volumétrie des utilisateurs :

L’application comptera environ 10 utilisateurs dont 2 à 3 simultanés.

Leur répartition par profil est la suivante :

1 Administrateurs

1 Gestionnaires

10 utilisateurs standards

2.1.2 Volumétries

Données :

La volumétrie attendue par type de données fonctionnelles est décrite dans le tableau ci-dessous :

Type de donnée

Volumétrie initiale

Fréquence de MAJ

Évolution annuelle

Volumétrie cible

Roulements 1 million d’enregistrements ; 1,2 Go dans 2 tables

Quotidienne +10% 4 Go sous 10 ans

Utilisateurs 10 Mo Mensuelle Non significatif

10 Mo

…

Cela fait un total d’environ 2 Go lors du démarrage de l’application avec une évolution annuelle du volume estimée à 5%.

Flux



Les échanges de flux présentent la nécessité au minimum de garder en ligne une volumétrie journalière de 5000 fichiers environ d’une taille moyenne de 1 Mo, soit un volume total de 5 Go. Ce volume est susceptible d’évoluer en fonction des nouveaux partenaires et des nouveaux fichiers à prendre en compte. L’augmentation du volume de ces fichiers est estimée à 10 % par an.

2.1.3 Authentification

L’authentification est décrite dans le paragraphe « 2.1 Authentification » des Spécifications Fonctionnelles Générales (fiche Minidoc XXXXX).

2.1.4 Traitement des erreurs

Sans objet

2.1.5 Internationalisation et traduction de l’interface

Sans objet.

2.1.6 Travail en mode dégradé (avec ou sans synchronisation)

Sans objet.

2.1.7 Opérations et fonctions planifiées (batchs)

Sans objet.

2.1.8 Graphisme (fonctions graphiques particulières)

Sans objet

2.1.9 Mail

Sans objet

2.1.10 Flux

Sans objet

2.1.11 Impressions

Sans objet

2.1.12 Reporting

Sans objet



2.1.13 Autres fonctionnalités de l’application

2.1.13.1 Messagerie instantanéeSans objet

2.1.13.2 Autres

2.2 Exigences techniques et contraintesLes exigences techniques sont généralement complémentaires des exigences fonctionnelles et peuvent aussi provenir de ces dernières. Elles ont, le plus souvent, des impacts sur les choix d’architecture.

2.2.1 Exigences d’utilisation de l’application (Usabillity)

Sans objet

2.2.1.1 AccessibilitéSans objet

2.2.1.2 Ergonomie et confort d’utilisationL’application présente les contraintes d’ergonomie suivantes :

Utilisable sur écran PC (12 pouces et plus), tablette (8 à 10 pouces), phabettes et smartphone (inférieur à 6 pouces)

Possibilités de faire du « glisser-déposer » (pour les postes disposant d’une souris).

Utilisable avec clavier (PC) ou écran tactile (terminaux mobiles).

2.2.1.3 Interactions avec les utilisateurs Permettre à l’utilisateur de visualiser la progression des traitements, de les

interrompre, de les reprendre, dans le cas des traitements longs.

Possibilité d’annuler des actions utilisateurs (en garantissant le retour à un état antérieur cohérent et en préservant l’intégrité des données).

Lorsque la saisie des données est validée l’agent ne peut plus le modifier. Néanmoins les personnes habilitées pourront le faire en cas d’erreur de saisie identifiée après validation.

2.2.1.4 Autres exigences d’utilisation

2.2.2 Exigences de fiabilité (Reliability)

Sans objet



2.2.2.1 Disponibilité de l’applicationL’application souhaite bénéficier d’une exploitation standard :

Plage d’ouverture du Service aux utilisateurs : 5j/7 durant les horaires d’ouverture des bureaux (08h à 18h du lundi au vendredi).

Les informations ci-dessus concernent la plate-forme de production. Précisez si besoin pour chaque type de plate-forme (développement, intégration, recette/pré-production) les besoins de disponibilité.

Taux de disponibilité du Service : taux de disponibilité mensuel de XX% (soit x heures par mois) (la durée globale théorique du service correspond à la durée de la plage d’ouverture du service).

ATTENTION !! Ce taux de disponibilité ne peut s’appliquer que pour les prestations dont DSIT-X a effectivement la charge. Ceci signifie qu’on ne comptabilisera pas les périodes de non fonctionnement causées par la défaillance d’une prestation non maîtrisée par DSIT-X.

Les informations ci-dessus concernent la plate-forme de production.

Arrêts négociés avec la MOA/MOE : Indiquer le nombre (préciser par mois ou semaine…) et la durée des périodes où il sera possible de négocier un arrêt de l’application pour effectuer des opérations de maintenances, des mises en production, etc…

16 heures ouvrées d’interruption de service sont acceptées, ce qui correspond à 2 jours de Temps de Remise en Service (TRS).

Si possible, quantifier les pertes financières engendrées par un dysfonctionnement ou un arrêt prolongé de l’application.

La perte de données autorisée est de 24h.

Amplitude d’ouverture de l’Assistance aux utilisateurs : 5J/7 8h00/18h00.

Lorsque la prestation d’assistance est prise à DSIT-X, la plage d’ouverture de l’assistance est de 5J/7 8h00/18h00.

L’accès en consultation est souhaité en dehors des plages d’ouverture des bureaux.

2.2.2.2 Maintien du système en conditions opérationnellesSans objet

2.2.2.3 Intégrité et confidentialitéSans objet

2.2.2.4 Conservation des donnéesSans objet

2.2.2.5 Tolérance aux pannesSans objet

2.2.2.6 Autres exigences de fiabilitéSans objet



2.2.3 Exigences de performances (Performance)

2.2.3.1 Temps de réponse nominauxSans objet

2.2.3.2 Temps de réponse en situation de chargeSans objet

Autres exigences de performancesSans objet

2.2.4 Exigences de supportabilité (Supportability)

Cette catégorie d’exigences porte généralement sur les domaines suivants :

Evolutivité et adaptabilité : aptitude de l’application à prendre en compte à un coût raisonnable des modifications fonctionnelles et techniques.

Maintenabilité : possibilité de comprendre sans efforts excessifs l’organisation interne et le fonctionnement de l’application et d’y apporter des modifications sans régression sur les autres composants.

Configurabilité : capacité d’installer et de mettre à jour facilement l’application, de modifier sa configuration.

Exploitabilité : Faculté à superviser, analyser et exploiter le bon / mauvais fonctionnement de l’application.

Scalabilité (extensibilité) : capacité à supporter la montée en charge. Cette aptitude est directement impactée par les utilisateurs et les données du système.

2.2.4.1 Evolutivité, adaptabilité et maintenabilitéCompte tenu des évolutions fonctionnelles exprimées précédemment (§ 1.3.2 Evolutions), l’ouverture de l’application à l’extérieur de l’entreprise, d’ici 5 ans, entraînera des contraintes de compatibilité avec les nouveaux systèmes qui vont interagir avec elle, à savoir :

L’application BETA qui imposera l’utilisation de fichiers dont le format est prédéfinie.

L’application GAMMA qui remettra en cause la gestion des barèmes.

…

De plus, l’application doit être conçue pour intégrer facilement de nouveaux flux d’informations.

2.2.4.2 ConfigurabilitéLes postes de travail des utilisateurs de l’application sont installés à partir de masters qui imposent l’utilisation de Windows XP SP2 et Internet Explorer 6.

L’application doit être capable de prendre en charge les thèmes Windows utilisés localement par les utilisateurs.



2.2.4.3 ExploitabilitéTous les traitements batch doivent renvoyer des codes retours pour signaler une bonne fin ou un incident survenu lors du traitement.

En cas d’incident sur l’intégration d’un fichier de données, c’est toute l’opération qui sera annulée. Après correction, tout le fichier devra être repris.

2.2.5 Contraintes de conception et d’implémentation (+)

2.2.5.1 DonnéesOn rappelle les données gérées par l’application (bases de données, entrepôts, fichiers, référentiels externes…), cf. 2.1.2 (volumétries)

Certaines données de l’application sont mutualisées (référentiel commun avec les applications… Les échanges de flux se font avec les fréquences et les volumes suivant le schéma : …

Les traitements transactionnels (traitement en tout ou rien afin de garantir l’intégrité des traitements et des données) sont…

Le démarrage de l’application nécessite une initialisation de données à partir de l’application BADEM qui représente un référentiel existant comportant xx utilisateurs, est implémentée de la façon suivante :…

Par conséquent, cette initialisation de données nécessitera le mode de reprise choisi (batch, lots DTS, etc.), les tests prévus (test à blanc, contrôle d’imports, validation des règles, etc.) et le planning envisagé pour cette opération…

Sont impactées les entités suivantes (tables de base de données par exemple) du référentiel de données.

Les décrire en précisant leur nombre d’enregistrements, leur volume, leur croissance, leur fréquence de mise à jour…

L’application prévoit-elle des mécanismes implémentés d’archivage suivants : …

Et/ou de purge : … (volume, fréquence…).

L’ensemble des traitements transactionnels représente 10% par rapport au reste des traitements de l’application.

2.2.5.2 Autres contraintes Langages et outils de développement,

Bases de données,

Frameworks, plateformes imposées (StarterKit .Net, par exemple),

Filière technologique souhaitée (Java, .Net…)

Etc.

Compte tenu des objectifs de convergence au niveau de la division, il est souhaitable d’utiliser la technologie Java / JEE pour l’application en se basant sur le StarterKit Java comme socle de départ pour les développements.



2.2.6 Contraintes d’interfaçage (+)

Données : Décrire les partages de données avec d’autres applications existantes ou à venir. Indiquer les interfaces de données qui seront mises en place ou l’existence de référentiels communs.

Services : Préciser si l’application s’appuie sur des services et modules logiciels, existants.

Applications : Indiquer comment d’autres applications sont impactées par la mise en place où l’utilisation de ce système.

Fournisseurs : Au niveau de la technologie et de l’entreprise la fournissant, indiquer si la solution d’architecture doit correspondre à une norme suivie par plusieurs fabricants, où à une technique propriétaire. Dans ce cas, détailler si possible les différents points de vue : matériel, logiciels, technologies et prestataires.

Pour une meilleure lisibilité, utiliser un sous paragraphe pour chacune des interfaces.

L’application sera intégrée à un système d’information existant. Elle doit donc s’adapter aux différents systèmes avec lesquels elle va interagir à savoir le service d’optimisation des calculs de roulements, des éléments de l’infrastructure de l’entreprise (annuaires et serveurs de messagerie) ainsi que ses cinq partenaires.

Service d’optimisation des calculs de roulements :

L’application ALPHA met à disposition d’autres applications son service d’optimisation des calculs de roulements. Celui-ci sera appelé par la future application.

La communication se fera à travers l’échange de fichiers. En effet, l’application émettra une demande d’optimisation par le dépôt d’un fichier de calculs. Le service d’optimisation y répondra par la mise à disposition d’un fichier ‘solution’ avec un roulement optimisé.

Annuaire des utilisateurs :

L’annuaire des utilisateurs (Annuaire des Ressources Windows – ARW) sera utilisé pour l’authentification des utilisateurs de l’application. Il sera sollicité par le biais de requêtes directes provenant de l’application.

L’application utilisera le mécanisme déjà implémenté sur PMM..

2.2.7 Contraintes physiques (matériels, systèmes, parc utilisateur...) (+)

Pour la partie centrale (partie serveur), l’application utilisera une plateforme existante, celle de l’application BETA.

Par ailleurs, les postes de travail des utilisateurs dont le profil est ‘Administrateur’ doivent respecter les contraintes suivantes :

La taille du boitier de l'UC du poste est limitée par la place prévue. Les dimensions maximum sont : (LxHxP) 460x200x450 mm

Les dimensions maximum de l’assise de l’écran doivent être : (Lxl) 280x230 mm



3 Architecture applicative et logicielle

3.1 Description de l’architecture applicative

3.1.1 Schéma d’ensemble de l’architecture

Figure 1 : Architecture applicative retenue

3.1.2 Description générale de l’application

3.1.2.1 Description de l’organisation de l’architecture L’application repose sur une architecture Web Intranet. Elle sera constituée d’un frontal web, d’un générateur de rapports, d’un serveur de données et d’un entrepôt de fichiers.

De plus, elle possède des interactions avec l’Annuaire de Ressources Windows, l’Annuaire des Applications Tierces et le serveur de messagerie de l’entreprise.

La structure sera un client léger accessible via l’intranet sur PC, et sur navigateur sur smartphone et tablette.

3.1.2.2 Description des modules et composantsLe choix d’une architecture Web permet de s’affranchir de tout déploiement logiciel, spécifique à l’application, sur les postes des utilisateurs.



Par ailleurs, la partie « serveur » est constituée :

D’un serveur Web (IIS 6.0) pour publier les écrans de l’application et garantir les différentes interactions avec les utilisateurs et les autres briques applicatives (serveur de données, serveur de rapports…).

D’un serveur de données (SQL Server 2005) pour gérer les données de l’application.

D’un serveur de rapports (SQL Server Reporting Services 2005) pour générer les rapports de l’application aux formats pdf et excel.

D’un entrepôt de fichiers pour stocker :

- les fichiers en provenance des établissements et qui serviront à alimenter la base de données lors du démarrage de l’application,

- les rapports générés par l’application ou importés à partir des applications partenaires.

Les parties de l’infrastructure de l’entreprise qui sont nécessaires aux besoins du projet sont les suivantes :

L’Annuaire des Ressources Windows (ARW) qui permettra d’authentifier les utilisateurs de l’application.

L’Annuaire des Applications Tierces (AAT) qui permet de fournir des informations sur les personnes (noms, prénoms, n° de téléphones…).

L’application fait appel aussi à d’autres briques applicatives :

Un middleware d’intégration de type ETL pour réaliser les échanges de données entre la base de données de l’application et celle…

3.1.2.3 Mécanismes évolués mis en œuvreVoir DAT PMM.

3.2 Description de l’architecture logicielle

Figure 2 : Architecture logicielle retenue



L’application s’appuie sur le StarterKit .Net 2005 qui définit une structure logicielle en 5 couches (Présentation (orange), Services (bleu), Accès aux données DAL (vert), Domaine (jaune) et Commun (gris)).

L’objectif d’une telle organisation est d’offrir une plus grande évolutivité de l’application tout en améliorant sa maintenabilité et sa compréhensibilité. Il devient alors plus facile de repérer les fonctionnalités à manipuler dans le code source lors d'une correction ou d’une évolution.

Remarque : Il est certain qu'une architecture en couches demande plus de discipline et de rigueur au concepteur / développeur. Et même s'il semble parfois inutile ou pénalisant de suivre strictement les règles de programmation définies, il est impératif de les respecter car la complexité du projet augmentera avec sa taille et il est donc nécessaire de disposer d’un code maintenable et cohérent.

Appels entre couches dans le cas du StarterKit .Net 2005

Les deux couches transverses que sont la couche Domaine et la couche Commun sont accessibles par l’ensemble des autres couches.

Concernant les appels sur les couches de l’axe vertical, ces derniers ne peuvent s’effectuer que de manière descendante, une couche ne pouvant appeler que la couche se situant immédiatement au dessous d’elle.

Les objets de la couche Service peuvent s’appeler entre eux. Idem pour la couche Présentation. Ce n'est pas le cas pour la couche DAL.

Les appels intra couche, pour la couche Service, sont uniquement autorisés pour les traitements transactionnels (portant des transactions) car les transactions de base de données ne doivent pas être utilisées au sein de la couche Présentation.

Les appels d'une même classe de la couche Présentation à plusieurs classes de la couche Service sont uniquement autorisés dans le cas de traitements non transactionnels (pour la même raison que celle du point précédent).

3.2.1 Interface utilisateur (IHM)

L’IHM de l’application est de type client léger. Le navigateur préconisé sur les postes de travail est Internet Explorer 6.0 et Mozilla Firefox 38.2.0.5696.

L’application comporte environ une trentaine d’écrans qui respectent une résolution de 1024x768.

3.2.2 Traitements batch

Sans objet.

3.2.3 Éditions, impressions, reporting

Voir DAT PMM.

3.2.4 Modes de déploiement

Lors des déploiements de nouvelles versions de l’application sur les postes clients, les mises à jour se feront depuis le serveur de déploiement par l’intermédiaire de la technologie Microsoft ClickOnce.



Un site IIS 6.0 sera présent sur le serveur de déploiement pour la mise à disposition des packages de mise à jour.

3.3 Flux L’application comptera au total une dizaine de flux : huit flux seront externes (trois émis par l’application et cinq reçus) et deux seront internes.

3.3.1 Flux internes

Sans objet.

3.3.2 Flux externes

Sans objet.

3.4 Sécurité applicative

3.4.1 Identification, authentification

Un seul mode d’authentification sera appliqué à tous les utilisateurs qu’ils soient internes ou externes à l’entreprise. Tout utilisateur sera au préalable être identifiés sur le reverse proxy, avec une authentification par login et mot de passe qui sera soumise à un annuaire LDAP. Ces échanges entre les postes clients et le reverse proxy se feront en HTTPS.

Une fois authentifié, sur le Reverse proxy, un serveur SSO (Single Sign-On) permettra d’authentifier l’utilisateur au niveau de l’application sans lui redemander son mot de passe.

Remarque : La délégation de l’authentification à l’annuaire LDAP permet de respecter les règles de gestion des mots de passe décrites au sein de la fiche des directives de sécurité des SI (fiche Minidoc 11503).

3.4.2 Habilitations - Profils

Pour répondre aux exigences exprimées par l’application (cf. § 2.1.3Authentification et § 2.1.1 Utilisateurs de l’application), on utilisera le Membership Provider du framework .Net sur la base de ce qui est fourni dans le StarterKit .Net 2005…

3.4.3 Confidentialité, traçabilité

La confidentialité des données est principalement assurée par trois moyens :

un cloisonnement des fonctions « administrateur » et « utilisateur »

le chiffrement (cryptage) des données sensibles stockées en base de données et ce, en utilisant la fonctionnalité fournie par SQL Server 2005.

l’utilisation du protocole HTTPS pour les échanges de données entre les clients et le serveur



Toute opération sur le système d’habilitation est enregistrée et tracée de manière automatique (inscription d’une trace explicite dans un journal des connexions). Une alarme est d’ailleurs émise au-delà de trois tentatives infructueuses de connexion.

3.5 Surveillance applicativeSans objet



ANNEXES

GlossaireMOA : Maîtrise d’Ouvrage du projet. De manière générale dans ce document, on entendra par MOA, les personnes assumant la responsabilité fonctionnelle (complète ou partielle) sur le projet, depuis la phase d’expression du besoin jusqu’aux phases de recette et de mise en production.

MOE : Maîtrise d’œuvre du projet. Ce terme est associé dans ce document aux représentants de l’équipe projet chargés de la réalisation informatique du système en liaison avec la MOA. Le maître d’œuvre est généralement le chef de projet, le directeur de projet, ou toute instance de pilotage opérationnel du projet.

Architecture logique : elle réunit l’architecture applicative et logicielle.

Architecture applicative : elle permet de définir les blocs applicatifs qui constituent le système (frontal Web, service de Reporting…) et de déterminer les flux techniques qui les relient. Dans ce cadre, on peut mentionner, par exemple, l’architecture client-serveur, l’architecture Web…

Architecture logicielle : elle s’intéresse à la décomposition en couches de l’application, à l’utilisation de design patterns, de frameworks…

Architecte applicatif et logiciel (MOE - EX) : Le domaine de prédilection de l’architecte applicatif et logiciel est celui de la structure logique de l’application, des communications inter-applicatives et de l’intégration des applications entre elles pour répondre aux besoins fonctionnels. C’est donc lui qui traite par exemple tous les flux de données entre un site web et le système d’information. L’architecte applicatif et logiciel est un spécialiste du développement, de la structuration du code et de la modélisation (architectures en couches, client-serveur, etc.). Il étudie le positionnement des référentiels et des interfaces qui permettent de les alimenter. Sur la base de ces réflexions, l’architecte applicatif conçoit des composants logiciels (réutilisables ou non) ou les services logiciels de l’application.

Architecture technique

Plus généralement, l’intégrateur applicatif s’intéresse au point de vue technologique de l'architecture technique qui concrétise le passage des composants et services logiciels vers des choix techniques précis. Initiateur d’un DAT, il réunit les informations qui permettent, selon l’avancement du projet, soit d’analyser les choix possibles au préalable, soit de détailler les technologies matérielles et logicielles permettant de réaliser le système et l'organisation physique (machine, topologie, réseau). Il est donc à la fois rassembleur des informations issues de l’architecture applicative et logicielle et fédérateur des points de vue matériel, déploiement, configuration physique et enfin exploitation. Lors de l’étude qui amène au choix, il peut consulter :

un architecte technique, qui veillera à la cohésion entre ses différents éléments : matériels, applicatifs, systèmes d’exploitation, réseaux…, en respect des préconisations entreprise (SDT, normes de sécurité en vigueur, PRA/PRI, études et qualification de nouvelles solutions,…)

un ingénieur système, qui veillera au respect des normes, notamment issues des points de vue physique et exploitation, considérant principalement les besoins



infrastructures et la mise en application des référentiels des « socles technologiques » par domaine technique (OS, bases de données, middlewares)

un exploitant, qui, en tant que responsable de production, veillera aux engagements contractuels à proposer pour garantir les services nécessaires aux choix architecturaux, en polarisant l’attention sur la qualité de service par la conception et la mise en place des mécanismes de surveillance adaptés, la coordination des moyens d’intervention et la gestion de crise en dernier recours

Fiche d’évaluation du besoin fonctionnel de base de données

Sans objet

Fiche d’évaluation des directives de sécurité du SISans objet.



Engagements de ServiceCe paragraphe a pour but de rappeler les règles de classification des applications selon les critères du niveau de service souhaité par le client en production, pour définir au mieux l’architecture technique permettant de respecter l’engagement de service de DSIT-X.

Il est important de noter que les besoins exprimés auront une incidence directe sur les moyens mis en œuvre par DSIT-X et, par conséquent, sur les coûts de facturation. A titre d’exemple, on peut mentionner :

Une disponibilité de l’application en 24H/24 et/ou 7j/7 pourra nécessiter la mise en place d’une astreinte spécifique et une extension des conditions d’intervention dans les contrats de maintenance souscrits auprès de nos fournisseurs.

Un taux de disponibilité important (par exemple 99%) pourra nécessiter une redondance des équipements. Cela pourra également rendre obligatoire la réservation d’un site de secours et l’organisation de tests sur ce même site.

Il faut enfin noter que DSIT-X ne pourra s’engager à garantir la disponibilité que sur les prestations dont elle a la maîtrise. La conception de l’application elle même doit être compatible avec le niveau de disponibilité souhaité.

Classification de l’application

Rattaché au choix de la classification, sont proposées par DSIT X des valeurs de référence pour la plage d’ouverture, la disponibilité, la garantie de remise en service et la perte de données.

La classification d’une application se définit par le niveau de préjudice ou de conséquence qu’un incident sur cette application va engendrer. Ce niveau de préjudice peut apparaître dans plusieurs domaines : Sécurité des personnes, retard des trains, pertes financières, perte de productivité, préjudice sur l’image de la SNCF.

Les classifications proposées sont standard, sensible et critique. On trouvera les critères d’évaluation dans le tableau qui suit (extrait du modèle de convention de services).

Préjudice :/Classification :

Sécurité des pers(oui /non)

Retard des trains minutes)

Pertes financières (euros)

Perte de productivité (homme/jour)

Préjudice sur l’image de la SNCF (échelle)

Réponses possibles :

Standard Non Inférieur à 5 minutes.

Inférieur à plusieurs centaines d’Euros

Perte de productivité inférieure à 1 J/H

Faible Ni sensible, ni critique, donc Standard

Sensible Non Retard supérieur à ½ heure

Quelques dizaines de milliers d’Euros

Perte de productivité de l’ordre d’une Semaine/H

Moyen, ressenti faible

Une seule case remplie suffit pour être classée Sensible



Préjudice :/Classification :

Sécurité des pers(oui /non)

Retard des trains minutes)

Pertes financières (euros)

Perte de productivité (homme/jour)

Préjudice sur l’image de la SNCF (échelle)

Réponses possibles :

Critique Oui Fortes perturbations

Autour du million d’Euros

Perte de productivité très importante (plusieurs Mois/H)

Fort, ressenti négatif

Une seule case remplie suffit pour être classée Critique

DSIT-X classe les applications selon 3 niveaux, à savoir :

0 – Standard

1 – Sensible

2 – Critique

Engagements de services

Moyens quantifiables mis en œuvre par DSIT pour maintenir l’application en état de marche en rapport avec son niveau de criticité.

Pour certaines applications, il ne faut pas minimiser les moyens mis en œuvre, pour d’autres, il ne faut pas faire de la « sur qualité ».

Les engagements définis dans les conventions de service concernent 5 critères

Plage d’ouverture du Service aux utilisateurs Plage horaire pendant laquelle le Fournisseur doit maintenir l’application ou le service disponible pour les utilisateurs.

Taux de disponibilité du ServiceLe taux de disponibilité est égal à la durée mensuelle réelle de fonctionnement du service divisé par la durée globale théorique du service, hors arrêts programmés, concertés et sinistres majeurs. Il est exprimé en pourcentage.

Garantie de Temps de Remise en Service (GTRS)Temps maximal pour remettre en service une application après un incident bloquant de production. Les heures d’arrêts en dehors de la plage d’ouverture du service (Utilisateur et Back Office) ne sont pas prises en compte.

Cela correspond à la Durée maximale d’un arrêt accidentel.

Pertes de données toléréesDurée max entre la dernière sauvegarde et le crash contenu dans la plage d’ouverture de l’utilisateur.

Amplitude d’ouverture de l’Assistance aux utilisateursPlage horaire pendant laquelle le Fournisseur dispose de ressources humaines et techniques qui permettent d’assurer une surveillance du bon fonctionnement du service et les interventions afférentes.



Le tableau suivant indique les valeurs de ces critères en fonction de la classification de l’application. Il s’agit là de valeurs de référence proposées :

Classification de l’application :/Critères d’Engagements

Standard Sensible Critique

De la Prestation de Surveillance

Plage d’ouverture du Service aux utilisateurs

5J/7 - 8h/18h 5J/7 - 7h/20h 7j/7 – 0/24h

Taux de disponibilité du Service

95% 97% 99 %

Garantie de Temps de Remise en Service (GTRS)

20 heures 13 heures 12 heures

De la prestation de Sauvegarde

Pertes de données tolérées

1 jour 4 heures 1 heure

De la prestation Assistance aux Utilisateurs

Amplitude d’ouverture de l’Assistance aux utilisateurs

5J/7 - 8h/18h 5J/7 - 8h/18h 5J/7 - 8h/18h

Périmètre des prestations X

Voir « Catalogue des prestations pour l’exploitation de l’application X ».

http://wwwx.dsit.sncf.fr/EspaceClients/serv.html



Trame de description d’environnement

Matériels utilisés

Voir DAT PMM.

Logiciels utilisés

Type de matériel Logiciel (nom et version)

Editeur

Système d’exploitation

Windows NT… MICROSOFT

Outils de gestion

Configuration CVS, PVCS MÉRANT

Outils de documentation

MinidocWord

Outils de codage

SGBD SQL Server 8.0 MICROSOFT

Outils d’installation WARTHIC DSIT-XA



Fiche d’identification du document

Titre LOUP

Sous-titre Dossier d'architecture technique

Sous-titre

Type DSI

Émetteur SNCF – Direction DSP SI

Référence 01LOU

Version 1

Date d’application

Cycle éditorialRédacteur VARICHON Kévin 13/01/2016

Vérificateur Vérificateur(s)

Approbateur Approbateur

Texte(s) de référence

Historique des versionsVersion Date d’application Date de retrait

DiffusionDestinataires

Référence : 01LOU - Version : 1 - Révision : 17

Suvi des temps DDSIM Architecture Web viewDirection des Services...

Documents

Transcript of Suvi des temps DDSIM Architecture Web viewDirection des Services...