- Exigences d'architecture technique
-
Une architecture physique ou architecture technique est conçue de manière à répondre à des exigences.
Ces exigences sont de plusieurs natures:
Sommaire
Exigences fonctionnelles
Il s'agit des fonctionnalités de l'application.
Disponibilité / Fiabilité / plage d’ouverture
La plage d’ouverture du service précise les périodes de temps durant lesquelles l’application doit être active.
Par exemple :
- 7/7j, H24
- 7/7j, H24, hors plage de maintenance le 15 de chaque mois entre 20H et 6H
- 5/7j, 9H-20H
La disponibilité indique le taux de disponibilité cible de l’application durant les plages d’ouverture.
Par exemple :
- disponibilité de 99,9%
Des fortes exigences de disponibilité demandent la mise en œuvre d'architecture de Haute disponibilité.
Reprise de service en cas d'incident
On distingue l'incident local et le désastre site : l'incident est par exemple la perte d'un serveur, tandis que le désastre site est par exemple l'incendie du centre d'exploitation.
Les exigences doivent s'exprimer en RTO et RPO. Le RTO (Recovery Time Objective) est le temps maximum admissible pour reprendre le service. Le RPO (Recovery Point Objective) est la perte maximale de données acceptable après redémarrage. Les objectifs de RPO et le RTO peuvent être différents selon qu'il s'agit d'un incident ou d'un désastre.
Sécurité
Les exigences de sécurité couvrent plusieurs domaines:
Performances
Exigences liées aux éléments suivants
- nombres d'utilisateurs,
- temps de traitement souhaités pour les transactions, les traitements "batchs" (traitement par lots),
- fréquence des traitements, débit transactionnel, pics de charge,
- filtres,
- temps de réponse.
Scalabilité
Article détaillé : scalabilité.La scalabilité est la capacité qu’a l’architecture pour évoluer en cas de montée en charge si nécessaire.
- Scalabilité horizontale : possibilité d’ajouter des serveurs d’un type donné. Par exemple : ajout possible de serveurs WebSphere avec répartition de charge Alteon.
- Scalabilité verticale : possibilité d’upgrader un serveur (ajout de processeurs, RAM, disques…).
Conservation des données
Une application ne peut pas accumuler des données sans limite. Il faut obligatoirement prévoir des mécanismes de purge ou d’archivage. Fixer la durée de l’historique conservé en ligne. Quand les anciennes données ne doivent plus être conservées en ligne, quelles sont les exigences ? Purge des données ? Transfert des données dans un système d’archivage ? Archivage sur bande magnétique ? Si les données sont archivées sur bande, quel est le temps souhaité maximal pour pouvoir accéder à ces données ? Prendre en compte les exigences légales :
- durée de conservation minimale à observer pour certaines données comme les factures.
- droit à l’oubli : en droit français, on ne peut conserver certaines données nominatives que pendant un temps donné (fixé lors de la demande d'autorisation à la CNIL)[1].
- autres exigences.
Modifiabilité
Pour les applications sensibles, on traitera le cas des demandes (installation de version correctives, reparamétrage) qui peuvent devoir être faite sans interruption de service (installation et reparamétrage « à chaud »).
Utilisabilité
Exigences concernant des fonctions destinées à améliorer les interactions avec les utilisateurs. Exemples :
- Cas de traitements longs pour lesquels il est nécessaire de permettre à l’utilisation de visualiser la progression des traitements, de l’interrompre, de le reprendre.
- Cas d’action utilisateur qui est nécessaire de pouvoir annuler (nécessité de pouvoir revenir à un état antérieur cohérent).
- Exploitabilité
Faculté de pouvoir exploiter et superviser le bon fonctionnement de l'application, d'analyser le bon fonctionnement (et le mauvais).
Liens externes
Notes
Wikimedia Foundation. 2010.
