samedi 7 avril 2012

Choisir une architecture : ordonner les exigences


Le cahier des charges


L'ONU, organisation bien connue, souhaite disposer de deux services connectés sur le référentiel des pays qu'elle reconnaît:
  • à destination de ses partenaires : un service web à accès public qui donne accès en lecture au référentiel
  • à usage interne : une application à accès restreint qui gère le référentiel dédié aux agents de l'ONU.
Dans les mois ou années qui suivront la mise en production de ces services, de nouveaux services pourront être ajoutés.
Nous nous attacherons à traiter le cas du service web.

Capturer les exigences


La meilleure approche pour capturer les exigences implicites consiste à utiliser une approche reconnue et pragmatique : FURPS.
FURPS est un acronyme qui signifie :
  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability
Cette approche permet de capturer des exigences implicites qui peuvent prendre une importance considérable. Je vous renvoie à l'excellent article rédigé par un architecte senior (l'expérience des anciens !!!!) d'IBM.

Les exigences du service web


Le client ne donne pas toujours une liste claire d'exigences. Certaines sont explicites d'autres déduites.
Ainsi, si un client demande que l'architecture passe le cap des dix années de service, il apparaît très risqué voire dangereux de proposer le dernier framework à la mode développé par quelques personnes et sur lequel la visibilité ne dépasse pas 6 mois.
En étudiant le cahier des charges, on remarque que les services proposés sont à destination du monde entier. Ceci implique que ces services seront disponibles 24/24 et 7/7 pour couvrir l'ensemble des fuseaux horaires.
La durée d'exploitation de ces services est fixée à 10 ans. Dans ce cadre, seul un standard reconnu et bien établi peut garantir une telle pérennité. Les standards proposés par l'OASIS en matière de services webs semblent répondre à cette exigence même si ils sont parfois décriés. Ils apportent l'universalité souhaitée et des spécifications claires sur les formats de données et d'échanges.
On notera que le client ne demande pas de SLA en terme de performances, ce qui paraît raisonnable dans la mesure ou ce type de service web peut être extrêmement sollicité. Ceci veut dire que les clients du service web devront tenir compte de cette contrainte : le service sera disponible mais répondra quand il pourra.
Il se peut aussi que le client pense que l'exigences de performance va de soit : grave erreur ! Il convient parfois de lever ce genre d'ambiguité au plus vite.
On remarquera aussi que le client ne précise pas de taux ! A vous de lui proposer un ou plusieurs taux raisonnables. En effet, même si un taux de 99,999% est séduisant sur le papier, cela a-t'il un sens par rapport à la criticité du service ? A priori non.
Cependant, l'universalité du service implique un taux forcément élevé dans la mesure ou l'on souhaite que le monde entier puisse accéder à ce service aux heures ouvrables. Nous proposerons un taux minimal de 95% qui implique une indisponibilité maximale d'une heure en moyenne par jour.
Voici une liste d'exigences explicites et déduites :
  • EX-OASIS : le service web se conformera aux standards WS-* de l'OASIS
  • EX-COVER : la couverture de code par les tests automatisées sera proche de 100%
  • EX-AQ : le code respectera l'état de l'art de la qualité logicielle
  • EX-MAIN : les solutions retenues (services, qualité, ...) permettront de minimiser les coûts de maintenance pour la durée de vie des services estimées à 10 ans
  • EX-REU : la réutilisation du code sera maximale
  • EX-FORGE : la fabrication des livrables suivra un processus identifié et reproductible : binaires, sources, documentations, rapports, publications, ...
  • EX-DISPO : les services seront disponibles 24/24 et 7/7 à 95%.

Ordonner les exigences


Les exigences et les besoins exprimés sont de différents ordres : certains sont très structurants, d'autres bcp moins.
L'architecte doit ordonner ces éléments du cahier des charges pour s'approcher de l'architecture idéale, c'est à dire celle qui répond aux cahiers des charges et non pas celle que votre organisation à l'habitude de vendre.
Une représentation en arbre des exigences permet de visualiser les liens et les hiérarchies de ces exigences.
Voici l'arbre des exigences construit à partir du cahier des charges :


L'EX-MAIN nous indique ensuite que l'architecture cible devra tenir le choc pendant 10 ans. Tous les choix techniques qui composeront l'architecture finale devront respecter cette exigence.
Le deuxième noeud important de l'arbre des exigences est l'EX-AQ : la qualité logicielle.
Cette exigence se décline en trois sous exigences :
  • la couverture de code par les tests : un élément reconnu de la qualité logicielle que nous verrons plus tard.
  • la réutilisation du code : factoriser le code facilite la maintenance et les évolutions du logiciel.
  • la fabrication des livrables : un processus de fabrication fiable et reproductible est un élément clef de la qualité.
Enfin, l'exigence EX-OASIS implique qu'il faut choisir une solution qui supporte ces standard : probablement que le support d'une version du Basic Profile est à retenir.
La bonne compréhension des exigences et de leurs relations est fondamentale pour proposer une architecture adaptée: il est aisé de se perdre dans l'étendue des solutions techniques disponibles.
Dans le prochain article nous tenterons de proposer une solution adaptée.




Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

Aucun commentaire:

Enregistrer un commentaire