Les processus agiles sont reconnus aujourd’hui pour assurer une meilleure adaptation aux changements requis dans l’environnement de travail. Par ailleurs, la documentation des exigences est souvent un processus plus formalisé dont l’objectif principal est de saisir le degré de complexité d’un système et d’un projet au début du processus de développement.
Est-il réaliste de penser que la définition des exigences puisse alors se faire selon un processus itératif et partiel? Voilà la question à laquelle ont tenté de répondre deux chercheurs américains (Cao et Ramesh, 2008 ) en investiguant 7 pratiques de collecte des exigences considérées agiles dans 16 organisations différentes. Nous allons d’abord tenter d’expliciter ces pratiques et ensuite d’en identifier les bénéfices potentiels et les défis qu’elles posent, prenant pour acquis que chacune de ces pratiques est fondée sur une plus grande participation des clients aux processus. 

En conclusion, les chercheurs se sont demandés dans quelle mesure ces pratiques étaient suivies. Les résultats obtenus démontrent ce qui suit : 

–

 Les pratiques d’exigences agiles

 1-Face à face Client – Ingénieur des exigences

• Leurs bénéfices

Les clients peuvent explorer des directions nouvelles au gré des changements ou de leur compréhension de la solution logicielle;
La communication informelle remplace la documentation et les processus d’approbation.

• Leurs défis

Le succès dépend grandement de la qualité des communications entre les clients et les développeurs et du degré de consensus atteints entre les groupes clients impliqués. Tout est fondé sur le niveau de confiance réciproque qui s’établit. 

2-Approches itératives initiées avec des exigences de haut niveau qui se précisent lors de chaque cycle

• Leurs bénéfices

Permet d’explorer des voies nouvelles quand le client ne sait pas trop dans quelle direction aller; permet d’arriver à mieux expliciter des exigences floues au départ en assurant une meilleure présence du client.

• Leurs défis

L’établissement d’une cédule et d’un budget de projet est impossible au début tant que l’étendue du projet n’est pas précisée; le fait de minimiser la documentation exige en environnement de travail stable client développeur sinon c’est la catastrophe; les exigences non fonctionnelles sont trop longtemps ignorées causant souvent de gros ennuis à la fin des projets. 

3-Choix des exigences priorisés à l’extrême 

• Leurs bénéfices

Une meilleure compréhension des besoins du client entraîne une réponse plus satisfaisante à leurs besoins. Le processus agile en soi encourage la révision des priorités contrairement aux approches traditionnelles.

• Leurs défis

Le fait de tout prioriser en fonction de la valeur (time to market) peut amener à négliger la sécurité, l’efficacité, le changement d’échelle et résulter en de sérieux problèmes d’opération et d’instabilité.

 4-Accommodation aux changements par une planification constante 

• Leurs bénéfices

Cette ouverture aux changements change complètement l’approche par rapport à la gestion des exigences traditionnelle.

• Leurs défis

Des problèmes d’architecture peuvent être rencontrés à la suite de changements fréquents, ce qui peut être coûteux ; peut rendre le « refactoring » ou le besoin de  réécriture du code plus fréquent. 

5-Le prototypage 

• Leurs bénéfices

Élimine les coûts associés à la préparation de la documentation; permet d’obtenir un feedback rapide des clients sur leurs exigences

•  Leurs défis

La tendance à déployer des prototypes non matures cause de lourds problèmes de sécurité, robustesse, et d’échelle; Elle laisse aussi croire aux clients qu’ils n’ont pas à prendre le risque de déliais plus longs pour une meilleure qualité.

  6-Exigences centrées tests (test-driven development) 

• Leurs bénéfices

Plus facile d’expérimenter et de tester véritablement l’exigence et le comportement du système

• Leurs défis

Exige beaucoup de discipline des développeurs puisque les tests ne sont pas toujours préparés avant le codage; exige le raffinement des exigences de bas niveaux avec lesquelles les clients sont souvent peu familiers.

 7- Revue des exigences pour validation et tests d’acceptation 

• Leurs bénéfices

Cette rencontre permet de mettre les pendules à l’heure et d’améliorer la confiance entre les clients et l’équipe de développement.

• Leurs défis

Mets l’emphase sur la validation des exigences mais néglige souvent les aspects liés à la vérification formelle parce qu’il n’y a pas de modèles détaillés disponibles; les tests d’acceptation reposent souvent sur la contribution du personnel d’AQ.

En conclusion, les chercheurs se sont demandés dans quelle mesure ces pratiques étaient suivies. Les résultats obtenus démontrent ce qui suit :

a-      toutes les organisations consultées (au nombre de 16) se sont classées dans la catégorie élevées et moyennes pour les pratiques qu’elles appliquent;

b-      cependant, ce ne sont pas toutes les organisations qui rencontrent les défis identifiés;

c-       presque toutes les organisations ont rapportées que leur principal défi est celui d’avoir accès aux clients et d’obtenir des consensus entre les différents groupes;

d-      la pratique des « exigences centrées tests » est la moins employée (seulement 6 entreprises) à cause du fait que les développeurs ne sont pas habitués à la discipline qu’elle requiert;

e-      de façon surprenante, même si le prototypage est une pratique bien établie, au moins un tiers des entreprises ne la pratique pas;

f-        enfin la pratique des revues contrairement aux attentes était courante dans les 16 organisations. 

La pratique des exigences agiles se fait principalement dans les organisations où il s’avère impossible de développer au départ des exigences claires, appropriées et complètes. En se concentrant sur le sujet à chaque itération, les participants à l’étude ont indiqué que c’est la communication intense entre le client et les développeurs qui s’avère être la pratique la plus fructueuse et la plus dynamique. En plus de se préoccuper des défis identifiés, les organisations qui s’y intéressent feraient bien de se préoccuper aussi des coûts et bénéfices que ces pratiques entraînent  

Référence : Cau Lan et B. Ramesh, 2008, IEEE Software, January/February. P. 60-67 

Définition formelle

• EN – IIBA définition
• FR – Wikipédia définition

Définition et Promotion d’un analyste d’affaire

• FR  -  L’analyste d’affaires – Un pont entre les TI et les affaires
• FR – La montée en puissance des analystes d’affaires
• FR  – Les compétences de l’analyste d’affaires

 A suivre  pour voir si cette “norme” deviendra une référence. Qui l’a déjà utilisé ?

 2 présentations :

• FR :  présentation UQAM
• EN : présentation IIBA

Référence :

• EN Définition : ref BABOK V1.6

SWEBOK

• EN – site officiel SWEBOK
• FR – Wikipédia SWEBOK

http://fabforce.net/dbdesigner4/

- Création du Modèle Conceptuel
- Génération du modèle Logique
- Génération de l’Entité Association
- Génération des bases sql
- Dictionnaires des termes

http://analysesi.free.fr

http://www.azzurri.jp/en/index.jsp

 Merci.