mobile-best-practice/chapters/MBP_002_fr.md

Quantifier précisément le besoin

Identifiants

Pratique originale : BP_002

Catégories

Cycle de vie	Tiers	Responsable
1. Spécification	Utilisateur/Terminal	PO/AMOA

Indications

Degré de priorité	Mise en oeuvre	Impact écologique
5	4	5

Ressources Economisées
Processeur / Mémoire vive / Stockage / Réseau / Requêtes

Description

Les « dimensions » de chaque fonctionnalité doivent être définies précisément et dans leur ensemble. Il peut s’agir d’un taux de compression pour les images de l’interface graphique, du temps de réponse maximum pour une requête HTTP, du nombre d’items affichés dans une liste, etc.

Plus les « dimensions » et exigences associées à chaque fonctionnalité collent au métier, plus on évite la surqualité. La logique doit donc être inversée par rapport aux habitudes actuelles. Si une information n’est pas précisée, c’est le niveau de qualité ou la quantité minimale qui est proposé. Par exemple, en l’absence de précision, le nombre d’items d’une liste est limité à 5 éléments ou au nombre maximal affichable sur le plus petit écran cible de l’application.

Les valeurs par défaut, rarement modifiées par l'utilisateur, doivent être choisies pour répondre au besoin avec un impact minimal.

Exemple

Gain potentiel : en jouant sur le nombre d’items affichés sur la page de résultats de son moteur de recherche Bing, Microsoft Research a démontré qu’il était possible de réduire jusqu’à 80 % l’infrastructure physique (nombre de serveurs) sous-jacente.

Autre exemple : en utilisant par défaut une résolution de vidéo acceptable (480p) plutôt que maximale, on réduit la bande passante utilisée pour la plupart des utilisateurs (qui ne changeront pas la valeur par défaut), tout en laissant la possibilité aux autres d'augmenter la résolution s'ils en en ont le besoin.

Principe de validation

Le nombre ...	est égal à
de fonctionnalités avec des dimensions supérieures au besoin	0