Objet
|
Choisir les cas d'utilisation ou les scénarios à utiliser dans le cadre de l'itération.
Choisir les exigences non fonctionnelles à traiter dans le cadre de l'itération.
|
Instructions : Plan d'itération
|
La portée d'une itération dépend de quatre facteurs :
-
Les principaux risques liés au projet
-
Les fonctionnalités souhaitées pour le système
-
Le temps alloué à l'itération dans le plan de projet
-
La phase et ses objectifs spécifiques (voir Concept :
Phase)
Lors de la planification initiale d'une itération, le travail est sélectionné en quantité suffisante par rapport au
temps planifié pour l'itération - bien que le responsable de projet dispose d'une certaine marge de manoeuvre pour
prendre en compte les contraintes liées aux ressources et d'autres considérations techniques lors du développement du
plan d'itération. Bien évidemment, les tâches planifiées pour l'itération précédente et qui n'ont pas été effectuées
(par exemple parce que la portée de l'itération précédente a été réduite pour des raisons de délai) bénéficient d'une
priorité élevée.
La portée du travail planifié doit également tenir compte du personnel qu'il est possible d'affecter pendant la durée
de l'itération. Par exemple, il n'est généralement pas possible de doubler le travail réalisé dans le cadre d'une
itération en doublant le personnel affecté, même si ces ressources sont disponibles. Le nombre de ressources qu'il est
possible d'affecter tout en restant efficace est déterminé par l'envergure et l'architecture du logiciel. Des modèles
d'estimation comme COCOMO II (voir [BOE00]) peuvent vous
aider à déterminer ce nombre de ressources.
L'exécution d'une itération est ensuite gérée par jalonnement :
il s'agit de gérer la portée et la qualité (en termes de défauts identifiés et non résolus) tout en respectant le délai
final.
Vous devez prendre en compte trois éléments essentiels lors de la définition des objectifs d'une itération de la phase
d'élaboration :
-
Risque
-
Importance
-
Couverture
Les risques constituent l'aspect le plus important. Vous devez limiter ou éliminer les risques aussi tôt que
possible. Cela concerne principalement la phase d'élaboration, à l'issue de laquelle la plupart des risques doivent
être limités, mais cela peut se poursuivre dans la phase de construction, car certains risques peuvent rester élevés et
de nouveaux risques peuvent être identifiés. Toutefois, l'objectif de la phase d'élaboration étant de fournir une
architecture de référence, d'autres considérations doivent également être prises en compte : vous devez par exemple
vous assurer que l'architecture choisie répond bien à tous les critères du logiciel à développer (couverture).
Cet aspect est primordial car cette architecture sera utilisée pour les planifications à venir : organisation de
l'équipe, estimation du code à développer, etc.
Tout en vous concentrant sur l'importance des risques, vous devez garder à l'esprit quelles sont les missions
principales du système ; c'est très bien de résoudre les questions difficiles mais cela ne doit pas être fait au
détriment de la fonctionnalité centrale : assurez-vous que les fonctions critiques ou les services du système sont en
effet couverts (criticité), même si aucun risque associé n'est perçu.
Pour les risques les plus lourds de la liste de risques, identifiez un scénario au sein d'un cas d'utilisation au cours
duquel l'équipe de développement se trouvera "confrontée" au risque en question.
Exemples
-
Si vous avez un risque d'intégration de type "base de données D fonctionnant correctement avec le système
d'exploitation Y", vous devez inclure un scénario qui implique une interaction avec la base de données, même si
elle est limitée.
-
Si vous avez un risque de performance de type "temps nécessaire au calcul de la trajectoire de l'avion",
assurez-vous d'avoir au moins un scénario qui inclut ce calcul, au moins pour le cas le plus évident et
fréquent.
Du point de vue de l'importance, assurez-vous que les fonctions et services principaux fournis par le système
sont inclus. Sélectionnez un scénario issu du cas d'utilisation qui représente la forme la plus courante et fréquente
du service ou de la fonctionnalité offert par le système. Le Document d'architecture logicielle sert à mener ces efforts,
fournissant un ensemble prioritaire de cas d'utilisation ou de sous-flux de cas d'utilisation sélectionnés par l'architecte du logiciel pour refléter les cas d'utilisation ou les
scénarios importants du point de vue de l'architecture.
Exemple
-
Pour un commutateur téléphonique, l'appel classique de poste à poste est un élément incontournable pour une
itération de début de projet. Il est beaucoup plus important de réussir ce point, plutôt que de chercher des
modes d'échec compliqués dans le sous-système de gestion des erreurs.
Concernant la couverture, vers la fin de la phase d'élaboration, pensez à inclure des scénarios qui touchent
certains domaines qui seront à développer, bien qu'ils ne soient ni cruciaux ni risqués.
Il est souvent plus judicieux de créer des scénarios longs et complets qui traitent plusieurs problèmes en même temps.
Le danger est souvent de développer des scénarios trop touffus, qui essaient de couvrir trop d'aspects, de variantes et
de cas d'erreur différents (voir Plan
d'itération)
En outre, lors de la phase d'élaboration, n'oubliez pas que certains risques sont surtout liés à l'homme ou au
programme : culture, formation, choix des outils, nouvelles techniques, etc. Dans ce cas, un examen minutieux de
l'itération suffit à limiter les risques.
Exemples
-
Créer un enregistrement abonné sur une station de travail cliente, à stocker dans la base de données du
serveur (comprenant les interactions avec l'utilisateur, mais ne comprenant pas tous les champs, et en
supposant qu'aucune erreur n'a été détectée).
Combine un certain nombre de fonctions critiques, avec des risques d'intégration (base de données et
logiciel de communication) et des problèmes d'intégration (utilisation de 2 plates-formes différentes). Les
concepteurs doivent se familiariser avec de nouveaux outils de conception d'interfaces utilisateur. Permet
finalement d'obtenir un prototype qui peut être présenté aux utilisateurs finaux afin de recueillir leurs
commentaires.
-
S'assurer qu'il est possible de créer jusqu'à 20 000 abonnés et que l'accès à un abonné se fait en moins de
200 millisecondes.
Traite quelques problèmes clés de performance (volume ou données et temps de réponse) susceptibles d'avoir
des conséquences significatives sur l'architecture s'ils ne sont pas résolus.
-
Annuler le changement d'adresse d'un abonné.
Fonctionnalité simple qui force les concepteurs à élaborer une conception pour toutes les fonctions
d'annulation. Cela peut permettre de signaler aux utilisateurs finaux les fonctions qui peuvent être annulées
moyennant un coût raisonnable.
-
Effectuer tous les cas d'utilisation liés à la gestion de la chaîne logistique.
La phase d'élaboration a également pour objectif de terminer le recueil des exigences, éventuellement
ensemble par ensemble.
Lorsque le projet entre dans la phase de construction, les risques restent un élément important, car de nouveaux
risques peuvent être identifiés. Toutefois, le degré d'achèvement du cas d'utilisation commence également à revêtir une
certaine importance. Les itérations peuvent être planifiées fonctionnalité par fonctionnalité, en achevant les plus
importantes aussi tôt que possible, afin qu'elles puissent être testées de manière approfondie dans le cadre de
plusieurs itérations. Vers la fin de la construction, on cherche à obtenir des cas d'utilisation terminés et robustes.
Exemple
-
Implémenter toutes les variantes du transfert d'appel, y compris celles qui sont erronées.
Il s'agit d'un ensemble de fonctionnalités associées. Une d'entre elles peut avoir été implémentée lors de
la phase d'élaboration, auquel cas elle servira de prototype pour le reste du développement.
-
Assurer toutes les fonctionnalités de l'opérateur, sauf le service de nuit.
Il s'agit d'un autre ensemble de fonctionnalités.
-
Assurer 5 000 transactions par heure avec 2 ordinateurs.
Cela peut impliquer une augmentation des performances requises par rapport à ce qui avait été réalisé lors
de l'itération précédente (seulement 2 357/heure)
-
Intégrer une nouvelle version du Système d'information géographique.
Cela constitue un changement architectural mineur, qui peut être nécessaire suite à certains problèmes
identifiés plus tôt.
-
Eliminer tous les défauts de niveau 1 et de niveau 2
Il s'agit de résoudre les défauts identifiés lors des tests exécutés dans le cadre de l'itération
précédente, qui n'ont pas été résolus immédiatement et ont été différés..
L'objectif principal est de finaliser cette génération du produit. Les objectifs d'une itération sont exprimés en
termes de problèmes à résoudre, d'améliorations à apporter ou de niveau de convivialité à atteindre. Si certaines
fonctionnalités ont été laissées de côté (ou désactivées) pour terminer la phase de construction dans les temps (jalon
IOC ou version bêta), elles peuvent maintenant être finalisées, ou activées, à condition qu'elles ne mettent pas en
péril ce qui a été construit jusqu'à présent.
Exemples
-
Résoudre tous les problèmes de niveau 1 identifiés sur les sites client bêta.
Il s'agit d'un objectif de qualité, qui peut avoir une incidence sur la crédibilité sur le marché.
-
Eliminer tous les plantages au démarrage dus à des données incorrectes.
Il s'agit également d'un objectif de qualité.
-
Assurer 2 000 transactions par minute.
Il s'agit d'un ajustement des performances qui implique une certaine optimisation : changement de la
structure des données, mise en mémoire cache et algorithme plus performant.
-
Réduire de 30 % le nombre de boîtes de dialogue.
Il s'agit d'améliorer la convivialité en limitant la surcharge visuelle.
-
Produire des versions en allemand et en japonais.
La version bêta a été produite uniquement en anglais, par manque de temps et pour limiter la quantité de
remaniements.
|