Styles

mercredi 2 juillet 2008

Prévision de changement de besoin

La seule et unique constante dans l'univers c'est le changement. Il en va de même avec les besoins des utilisateurs, clients, maîtrise d'ouvrage d'une application. Comment faire pour suivre cette évolution à moindre frais. Bien que certains proposent de multiples techniques de "refactoring", l'objectif est de ne pas avoir du tout à refactorer.

On peut y arriver si on envisage comment l'application va évoluer au cours du temps. Oui, mais ... qui peut prédire l'avenir ? personne, en tout cas, pas moi. Pour essayer de limiter les dégâts et prévoir au maximum les changements à venir, la gestion des exigences a été pour moi ce qui m'a le plus permis d'avoir une approche rationnelle de la gestion et de la prévision du changement.

L'article de Wikipedia est clair sur le sujet :
En ingénierie, et plus particulièrement dans les procédures d'appel d'offres publiques et privées, les exigences sont l'expression d'un besoin documenté sur ce qu'un produit ou un service particuliers devraient être ou faire. Elles sont le plus souvent utilisées dans un sens formel dans l'ingénierie des systèmes et dans l'ingénierie logicielle.
et notamment, sur les différents types d'exigence :
- Les exigences métier qui décrivent le quoi dans les termes du métier. Elles décrivent ce qui doit être fourni ou réalisé pour produire de la valeur.

- Les exigences produit qui décrivent le produit ou le système à un haut niveau. Elles répondent aux exigences métier et sont couramment formulées comme les fonctionnalités que le système doit réaliser. On les appelle également exigences fonctionnellles ou spécifications fonctionnelles.

- Les exigences de processus qui décrivent le comment. Ces exigences prescrivent les processus que l'on doit suivre et les contraintes auxquelles on doit se conformer pour la réalisation du système. Dans ce cas, on trouve par exemple des exigences de sécurité, d'assurance qualité, ou de management.
Le découpage en exigences des besoins permet de mettre un nom (un identifiant) sur chaque besoin élémentaire, le but étant d'avoir une liste exhaustive.

Au delà de permettre dans un projet, un suivi de bout en bout des exigences, l'intérêt principal c'est de ne pas perdre le besoin client dans une foule de détails plus ou moins techniques. Cela permet notamment au client d'être plus confiant et de lui permettre de valider l'expression écrite de son besoin.

Une fois la liste d'exigences rédigée, apparaît alors la phase qui permet de se protéger contre les changements du besoin. C'est une phase d'assurance qualité qui vise à s'assurer que toutes les exigences respectent les propriétés suivantes:
- Nécessaires – Elles doivent porter sur des éléments nécessaires, c'est-à-dire des éléments importants du système que d'autres composants du système ne pourraient pas compenser.

- Non ambiguës – Elles doivent être susceptibles de n'avoir qu'une seule interprétation.

- Concises – Elles doivent être énoncées dans un langage qui soit précis, bref et agréable à lire, et qui de plus communique l'essence de ce qui est exigé.

- Cohérentes – Elles ne doivent pas contredire d'autres exigences établies, ni être contredites par d'autres exigences. De plus, elle doit, d'un énoncé d'exigence au suivant, utiliser des termes et un langage qui signifie la même chose.

- Complètes – Elles doivent être énoncées entièrement en un endroit et d'une façon qui ne force pas le lecteur à regarder un texte supplémentaire pour savoir ce que l'exigence signifie.

- Accessibles – Elles doivent être réalistes quant à aux moyens mis en œuvre en termes d'argent disponible, avec les ressources disponibles, dans le temps disponible.

- Vérifiables – Elles doivent permettre de déterminer si elles ont été atteintes ou non selon l'une de quatre méthodes possibles : inspection, analyse, démonstration, ou test.
Mais on peut aller plus loin pour se protéger des futurs changements : imaginer au moins 3 possibilités d'évolution pour chaque exigence.

L'important est d'identifier ces évolutions comme de nouvelles exigences internes. Selon l'état d'esprit de votre client ou donneur d'ordre, vous pouvez faire apparaître ces nouvelles exigences ou pas.

Lors de la phase de définition de l'architecture, il est donc alors possible de faire des choix informés qui permettent à moindre coût l'évolution de chaque exigence métier, et d'en faire un véritable suivi.

Il existe beaucoup de techniques permettant l'extensibilité et la personnalisation d'une architecture. Savoir à l'avance ce qui va changer permet de ne pas oublier de mettre en place ces techniques aux bons endroits et de renforcer la solution face à l'avenir.

Ce travail implique bien sur un surcoût, mais beaucoup moins important que de répondre à un changement d'exigence non anticipé. Dans le cas de société de service, le surcoût est inutile dans le cas de développement au forfait, mais devient beaucoup plus justifiable dans le cas de TMA où la rentabilité des contrats s'avère dépendant de la qualité de l'application.

Ce processus de prévision des changements du besoin peut être pondéré par la prioritisation de ceux-ci. Il peut être bien sur être plus qu'intéressant d'interroger le client sur chacune de ces évolutions possibles. Car finalement, c'est quand même lui le mieux placé pour répondre.

Aucun commentaire: