suvi des temps ddsim architecture web viewl’annuaire des utilisateurs (annuaire des ressources...
Post on 02-Feb-2018
219 Views
Preview:
TRANSCRIPT
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 : 18 Page ii
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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 : 18 Page iii
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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.
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
De réaliser des statistiques
De pouvoir importer et exporter les données simplement
1.2.2 Fiche d’identification et acteurs
Référence : 01LOU - Version : 1 - Révision : 18 Page 1 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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 A définir
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.
Référence : 01LOU - Version : 1 - Révision : 18 Page 2 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 3 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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.
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 4 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 5 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 6 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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.
Référence : 01LOU - Version : 1 - Révision : 18 Page 7 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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.
Référence : 01LOU - Version : 1 - Révision : 18 Page 8 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 9 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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.
Référence : 01LOU - Version : 1 - Révision : 18 Page 10 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 11 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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.
Référence : 01LOU - Version : 1 - Révision : 18 Page 12 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 13 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 14 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 15 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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.
Référence : 01LOU - Version : 1 - Révision : 18 Page 16 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 17 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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.
Référence : 01LOU - Version : 1 - Révision : 18 Page 18 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 19 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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
Référence : 01LOU - Version : 1 - Révision : 18 Page 20 / 20
SNCF – Direction DSP SI LOUPDossier d'architecture technique
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 : 18
top related