A la fin de la phase d'élaboration, on trouve le deuxième jalon majeur du projet, le Jalon de l'Architecture du Cycle de Vie. A ce niveau, vous observez les objectifs détaillés et la portée du système, le choix de l'architecture et la résolution des risques majeurs

Critères d'évaluation

  • La vision et les exigences du produit sont stables.
  • L'architecture est stable.
  • Les approches clés à utiliser dans les phases de test et d'évaluation sont sûres.
  • Les phases de test et d'évaluation des prototypes exécutables ont montré que les éléments majeurs de risque ont été traités et résolus de manière valable.
  • Les plans d'itération utilisés dans la phase de construction sont suffisamment détaillés et fidèles pour permettre un avancement des travaux.
  • Les plans d'itération utilisés dans la phase de construction sont basés sur des estimations valables.
  • Toutes les parties prenantes sont d'accord sur le fait que vision peut être réalisée si le plan en cours est exécuté pour développer le système complet, et ce dans le contexte de l'architecture actuelle.
  • Les dépenses réelles de ressources par rapport aux dépenses de ressources planifiées sont acceptables.

Le projet pourra être abandonné ou repensé dans son ensemble s'il ne parvient pas à atteindre ce jalon.

Artefacts

Artefacts essentiels (par ordre d'importance) Etat au jalon
Prototypes Au minimum un prototype d'architecture exécutable a été créé pour explorer les fonctionnalités critiques et les scénarios significatifs en terme d'architecture. Voir le commentaire ci-dessous concernant le rôle des prototypes .
Liste de risques Mise à jour et revue. Les nouveaux risques seront probablement architecturaux par nature, principalement concernant le traitement des exigences non fonctionnelles.
Processus de développement

Le processus de développement, y compris tous les principes et conseils et canevas liés au projet, a été affiné sur la base de projets antérieurs. Sa définition est actuellement suffisante pour permettre le démarrage de la phase de construction.

Infrastructure de développement

L'environnement de développement est en place pour la construction, y compris tous les outils et supports d'automatisation du processus.

Document d'architecture logicielle Créé et considéré comme base de référence, il comprend la description détaillée des cas d'utilisation les plus significatifs (vue des cas d'utilisation), l'identification des mécanismes et éléments de conception clés (vue logique), plus la définition de la vue du processus et la vue de déploiement. Si le système est réparti ou s'il doit être confronté à des questions de concurrence.
Modèle de conception (et tous les artefacts constitutifs) Défini et considéré comme référence. Des réalisations de cas d'utilisation de conception destinés aux scénarios les plus significatifs en terme d'architecture ont été définis. Le comportement exigé a été assigné aux éléments de conception appropriés. Les composants ont été identifiés et les décisions de réalisation/achat/ré-utilisation ont été suffisamment bien comprises pour garantir le coût et le calendrier de la phase de construction. Les composants d'architecture sélectionnés sont intégrés et évalués par rapport aux scénarios primaires. Les enseignements tirés de ces activités pourraient bien conduire à la re-conception de l'architecture, en prenant en considération des options de conception ou en reconsidérant les exigences.
Modèle de données Défini et considéré comme référence de base. Les éléments majeurs du modèle de données (par exemple des entités, relations, tables importantes) sont définis et revus.
Modèle d'implémentation (et tous les artefacts constitutifs, y compris les éléments d'implémentation) La structure initiale est créée et les composants majeurs bénéficient d'un prototype.
Vision Affinée sur la base d'éléments d'information nouveaux obtenus durant la phase, établissant une bonne compréhension des cas d'utilisation les plus critiques qui orientent les décisions architecturales et de planification.
Plan de développement logiciel Mis à jour et augmenté afin de permettre la réalisation des phases de construction et de transition
Plan d'itération Le plan d'itération pour la phase de construction est terminé et revu.
Modèle de cas d'utilisation (Acteurs, Cas d'utilisation) Un modèle de cas d'utilisation (achevé à environ 80%)-tous les cas d'utilisation ont été identifiés dans la présentation du modèle de cas d'utilisation, tous les acteurs ont été identifiés, et la plupart des descriptions de cas d'utilisation (saisie des exigences) a été développée.
Spécifications supplémentaires Des spécifications supplémentaires réunissant les spécifications non fonctionnelles sont décrites dans la documentation et revues.
Artefacts facultatifs Etat au jalon
Etude de rentabilité Mise à jour si les recherches architecturales révèlent des questions qui modifient les projets fondamentaux.
Modèle d'analyse Peut être développé en tant qu'artefact formel ; généralement pas maintenu de manière formelle, il évolue vers une version préliminaire du modèle de conception.

Le rôle du prototype

Le Rational Unified Process donne à l'architecte logiciel ainsi qu'au chef de projet la liberté de réaliser des prototypes de plusieurs types (voir Concepts: Prototypes) comme stratégie de réduction des risques. Certains de ces prototypes peuvent être purement exploratoires, et seront alors retirés. Il est néanmoins probable (et certain pour les systèmes les plus grands ou sans précédent) que l'architecture aura été conçue comme une série de prototypes évolutifs couvrant diverses questions tandis que la phase d'élaboration progresse et que, à la fin de cette phase d'élaboration, elle aura abouti à une base architecturale intégrée et stable. Ici, nous ne voulons absolument pas suggérer que les réalisations de prototypes durant la phase d'élaboration devraient conduire à un ensemble de fragments architecturaux ne nécessitant aucune intégration.



RUP (Rational Unified Process)   2003.06.15