Activité :
|
Objet
|
Rôle : Analyste système |
Fréquence : Selon les besoins. Généralement une fois pour chaque itération dans les phases Création et Elaboration, puis selon les besoins lors des phases ultérieures. |
Etapes |
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : |
Détails sur l'enchaînement des activités : |
Une façon simple d'obtenir un consensus sur la définition du problème consiste à le mettre par écrit pour voir si tout le monde est d'accord.
Demandez au groupe : Quel est le problème ?
Ensuite, redemandez au groupe : Quel est le problème réel ?
N'acceptez pas la première formulation du problème. Continuez à demander "pourquoi ?" pour identifier la "véritable nature" du problème.
Parfois, le groupe est tellement convaincu de la solution à mettre en place qu'il est difficile de mettre en évidence le problème sous-jacent. Dans ce cas, il peut être intéressant de répertorier les avantages de la solution envisagée, puis de chercher à identifier les problèmes résolus par ces avantages. Vous pourrez alors déterminer si ces problèmes sont de "réels" problèmes auxquels l'organisation est confrontée.
Parmi les techniques couramment utilisées pour identifier le problème derrière le problème, nous citerons le brainstorming, les
diagrammes causes-effets et les
diagrammes de Pareto.
Selon le niveau de compétence de l'équipe de développement, l'identification des parties prenantes peut être une étape simple ou complexe. Souvent, il suffit d'interroger les décisionnaires, les utilisateurs potentiels et autres parties concernées. Les questions suivantes vous seront utiles :
Commencez à définir les profils des utilisateurs potentiels (ou réels) du système. Ils seront mis en correspondance avec les rôles des acteurs humains du système en cours de développement. Les premières informations sur les principaux utilisateurs et leur environnement doivent être incluses dans le document Vision.
Les limites du système définissent la frontière entre la solution et le monde réel autour de cette solution. En d'autres termes, les limites du système définissent une enveloppe dans laquelle se trouve la solution. Sous forme d'entrées et de sorties, des informations sont échangées entre le système et les utilisateurs qui se trouvent en dehors du système. Toutes les interactions avec le système ont lieu via des interfaces entre le système et le monde extérieur.
Souvent, les limites du système sont évidentes. Par exemple, les limites d'un gestionnaire de contacts shrink-wrap mono-utilisateur qui s'exécute sous Microsoft Windows® sont relativement claires. Il n'y a qu'un seul utilisateur et une seule plate-forme. Les interfaces entre l'utilisateur et l'application se résument aux boîtes de dialogue via lesquelles l'utilisateur peut entrer des informations dans le système, et aux rapports de sortie et chemins de communication utilisés par le système pour documenter et transmettre ses réponses.
Il est souvent efficace d'utiliser les acteurs pour définir et décrire les limites du système. Voir Activité : Identifier les acteurs et les cas d'utilisation.
Il existe un certain nombre de contraintes à prendre en compte. La plupart de ces informations sont consignées dans l'artefact Spécifications supplémentaires . Vous trouverez ci-dessous une liste des sources de contraintes potentielles et des questions à poser :
Les informations recueillies ici serviront à rédiger les contraintes de conception définies dans l'artefact Spécifications supplémentaires.
Avec l'ensemble du groupe, travaillez sur un chevalet et décrivez chaque problème identifié à l'aide du canevas suivant :
Le problème de <décrire le problème>
affecte <parties prenantes affectées par le problème>.
Les conséquences de ce problème sont : <répercussions du problème>.
Une solution adaptée permettrait de <répertorier les principales caractéristiques d'une solution adaptée>.
Ce canevas a pour but de vous aider à distinguer les solutions/réponses des problèmes/questions.
Le problème de : résolution insatisfaisante et tardive des problèmes de service après-vente
affecte : nos clients, notre personnel du service après-vente et nos techniciens de maintenance.
Les conséquences de ce problème sont : clients mécontents, niveau de qualité insuffisant, employés insatisfaits et perte de chiffre d'affaires.
Une solution adaptée permettrait de : fournir un accès en temps réel à une base de données de dépannage pour le personnel de support et de faciliter l'affectation immédiate de techniciens de maintenance sur les sites nécessitant réellement leur intervention.
A partir de la liste d'avantages établie, définissez une liste des caractéristiques souhaitées pour le système. Décrivez-les brièvement et affectez-leur des attributs afin de définir leur état général et leur niveau de priorité au sein du projet .
Vous devez évaluer votre vision à ce stade afin de vous assurer que votre travail semble correct, mais il est inutile de faire un contrôle détaillé. Voir les points de contrôle applicables à la vision dans Activité : Revoir les exigences.
RUP (Rational Unified Process)
|