Activité: Définition d'une architecture potentielle
Cette activité crée une esquisse initiale de l'architecture logicielle.
Etend: Définition d'une architecture potentielle
DescriptionStructure de répartition du travailAffectation d'équipeUtilisation du produit
Relations
Activités parentes
Description

Cette activité vise les objectifs suivants :

  • Création d'une esquisse initiale de l'architecture du système
    • Définition d'un ensemble initial d'éléments significatifs du point de vue architectural à utiliser comme base d'analyse
    • Définition d'un ensemble initial de mécanismes d'analyse
    • Définition des différentes couches et de l'organisation initiales du système
    • Définition des réalisations de cas d'utilisation à adresser dans l'itération en cours
  • Identification des classes d'analyse à partir des cas d'utilisation significatifs du point de vue architectural
  • Mise à jour des réalisations de cas d'utilisation avec les interactions de classe d'analyse
Propriétés
Commandé par les événements
Plusieurs occurrences
En cours
Facultatif
PlanifiéYes
Réitérable
Affectation du personnel

Comme dans le cas de l'Activité : Définition d'une architecture candidate, il est préférable que ces activités soient exécutées au sein d'une petite équipe, formée de personnes dont les compétences couvrent tous les champs d'action nécessaires. Les problèmes typiquement significatifs du point de vue architectural concernent les performances, l'échelonnement, la synchronisation des processus et des unités d'exécution et la distribution. L'équipe doit également accueillir des personnes possédant assez d'expérience dans leur spécialité pour identifier les abstractions clés. L'équipe doit également avoir des connaissances en organisation de modèles et en organisation en couches. A partir de ces entrées, l'équipe devra être capable de synthétiser le modèle, voire le prototype, d'une solution.

Utilisation
Conseils d'utilisation

Il est préférable de réaliser ce travail en plusieurs sessions, peut-être en plusieurs jours (ou en plusieurs semaines ou plusieurs mois pour les très grands systèmes), avec une itération entre l'analyse architecturale et l'analyse de cas d'itération. Définissez une architecture initiale dans le cadre de l'analyse architecturale, puis choisissez des cas d'utilisation architecturalement significatifs et exécutez une analyse de cas d'utilisation pour chacun d'entre eux. Pendant ou après l'analyse de chaque cas d'utilisation, mettez à jour l'architecture pour refléter les adaptations nécessaires à la prise en compte du nouveau comportement du système ou à la résolution des problèmes potentiels que vous aurez identifiés.

Si l'architecture a déjà été définie (lors d'une itération ou d'un projet antérieur), il sera peut-être nécessaire de créer des demandes de changement pour que le système puisse prendre en charge le nouveau comportement requis. Ces changements peuvent concerner n'importe quel artefact du processus, en fonction de l'ampleur de la modification.