4.4 Les besoins en acquisition
4.4.1 Les éléments à renseigner
L'acquisition consistera à renseigner les
éléments du Process State, à savoir : - Discipline
WorkDefinition
- ProcessRole
- Activity
- Iteration
- Phase
Representation
- WorkProduct
Une seconde étape consistera à renseigner pour
chaque interface :
- La méthode associée à cette interface
(créer,modifier,consulter,supprimer), elle permet de différencier
les interfaces associées à un WorkProduct,
~ Le WorkProduct concerné choisi dans l'ensemble des
WorkProduct préalablement renseignés,
- La description sommaire de l'interface.
Et pour chacun des champs ou attributs d'une interface, on
renseignera :
- Le nom du champ,
- Le libellé du champ correspondant au label qui sera
affiché,
~ Le type du champ (numérique, texte, image, ...),
- Le renseignement du champ qui représente ici la plage de
valeurs (source) par exemple un champ peut être une liste de choix entre
les différents WorkProduct.
4.4.2 Tâches à réaliser
Il s'agira donc de :
1. Fournir des interfaces permettant de renseigner les
éléments ci-dessus cités dans un ordre efficient,
2. Proposer quatre (04) modèles d'interface adaptable
(ajout, consultation, modification et suppression),
3. Spécifier les différentes
représentations dans un fichier. Nom, description de la
représentation et nom de l'icône associée (au format PNG
16x16) qui doit être copié dans un répertoire
précis. Par défaut, on proposera les représentations UML
pour les work-Product et RUP pour les autres éléments du
processus, et on laissera l'utilisateur choisir,
4. Enregistrer les interfaces dans des fichiers XUL
codifiés,
5. Renseigner les dépendances
~ Précédence : gérée par la
définition des WorkDefinition,
- Import : gérée par une Activity qui importe des
WorkProduct en entrée/sortie, Refers To : gérée par la
définition des Discipline,
~ Impact : gérée dans la définition des
WorkProduct de regroupement,
- Catégorizes : gérée par la
définition des Discipline, WorkProduct, ProcessRole et Activity.
6. Pour chacun des WorkProduct, permettre de spécifier
les règles de validation en proposant un modèle de projet
adaptable sous QuickRules.
7. Bien évidemment, s'assurer que les fichiers .xul
produits sont valides pour l'interpréteur utilisé au niveau de
l'exploitation. Idem pour les règles de validation sous QuickRules.
Les dépendances en terme de précédence entre
les différentes tâches spécifiques à l'acquisition
sont présentées à la figure 4.3.
| 
