Table des matières








télécharger 126.48 Kb.
titreTable des matières
page4/8
date de publication02.04.2017
taille126.48 Kb.
typeDocumentos
ar.21-bal.com > loi > Documentos
1   2   3   4   5   6   7   8

2.2Exigences techniques et contraintes


Les 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.1Exigences d’utilisation de l’application (Usabillity)


Sans objet

2.2.1.1Accessibilité


Sans objet

2.2.1.2Ergonomie et confort d’utilisation


L’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.3Interactions 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.4Autres exigences d’utilisation




2.2.2Exigences de fiabilité (Reliability)


Sans objet

2.2.2.1Disponibilité de l’application


L’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.2Maintien du système en conditions opérationnelles


Sans objet

2.2.2.3Intégrité et confidentialité


Sans objet

2.2.2.4Conservation des données


Sans objet

2.2.2.5Tolérance aux pannes


Sans objet

2.2.2.6Autres exigences de fiabilité


Sans objet

2.2.3Exigences de performances (Performance)

2.2.3.1Temps de réponse nominaux


Sans objet

2.2.3.2Temps de réponse en situation de charge


Sans objet

3Autres exigences de performances


Sans objet

3.1.1Exigences 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.

3.1.1.1Evolutivité, 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.

3.1.1.2Configurabilité


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.

3.1.1.3Exploitabilité


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.

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

3.1.2.1Données


On 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.

3.1.2.2Autres 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.

3.1.3Contraintes 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..

3.1.4Contraintes 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
1   2   3   4   5   6   7   8

similaire:

Table des matières iconTable des matières

Table des matières iconTable des matières

Table des matières iconTable des matières

Table des matières iconTable des matières

Table des matières iconTable des matières

Table des matières iconTable des matières

Table des matières iconTable des matières

Table des matières iconTable des matières

Table des matières iconTable des matières

Table des matières iconTable des matières








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com