Gestion de projet – Vers les méthodes agiles
62
techniques de modélisation. Tout comme UML (Unified Modeling Language), le
Processus unifié (Unified Process) ambitionnait de standardiser des bonnes pratiques
expérimentées ici ou là dans l’ingénierie logicielle. Il faut également reconnaître à
Philippe Kruchten d’avoir considérablement enrichi le Processus unifié.
UP met en avant six bonnes pratiques pour favoriser le succès des projets ; elles sont
présentées dans le tableau 2-3, ci-après :
Tableau 2-3 Les six bonnes pratiques du Processus unifié
Bonne pratique
Description
Un pilotage itératif et incrémental, piloté par les risques et les cas d’utilisation
Comme toutes les méthodes agiles, UP adopte le principe de découpage du projet
en itérations et du développement incrémental pour les avantages cités ci-dessus.
UP est attaché à la technique des cas d’utilisation (voir chapitre 3), pour représenter textuellement et graphiquement les scénarios d’usage du système à développer. À chaque cas d’utilisation sont associés des r isques d’implémentation. Grâce
au pilotage par les risques, on choisira d’implémenter en priorité les cas d’utilisation qui permettent de réduire ou supprimer le maximum de risques.
Une gestion rigoureuse
des exigences
UP préconise de constituer un référentiel d’exigences, facilitant ainsi l’organisation,
l’analyse et l’évolution des exigences fonctionnelles ou non fonctionnelles ; ce référentiel, en outre, garantit la traçabilité des exigences, dans leur évolution et dans les
différentes étapes du cycle de transformations qu’elles vont subir.
Un développement centré
sur l’architecture
L’architecture et les problématiques techniques sont souvent les plus critiques sur un
projet (nouvelle technologie, intégration, complexité). Il est impératif, par conséquent, de
valider les principes et les choix architecturaux au travers d’un prototype architectural
(« un squelette épaissi de quelques muscles » a ) afin de lever les principaux risques. Elle
ne doit pas être validée « sur le papier », mais au travers de composants réels.
La modélisation graphique
des exigences
« Un schéma vaut parfois mieux que de longs discours. »
La représentation graphique, schématique et visuelle sert à mieux décrire les systèmes, d’autant mieux s’ils sont complexes.
C’est ainsi que recourir à un langage standard comme UML pour modéliser le système sous forme de diagrammes ne peut que faciliter la communication au sein du
projet (avec le client, selon les diagrammes, ou entre les différents corps de métier
au sein de l’équipe).
Le contrôle permanent
de la qualité
Parce qu’il est plus coûteux de détecter et de corriger un défaut logiciel tardivement, la
qualité d’un produit doit être évaluée en continu le plus tôt possible dans le cycle de vie.
Chaque jalon majeur ou intermédiaire du projet donne l’opportunité de contrôler la
qualité, et de revoir et d’adapter la méthodologie de travail à l’origine des défauts, en
complément des activités de tests permanentes.
Le contrôle des changements
Si l’on accepte le changement, ce n’est pas n’impor te comment, n’importe quand, ni
n’importe quoi !
Un processus rigoureux outillé doit supporter le changement, inhérent au développement itératif. Chaque changement fait l’objet d’une demande de changement (change
request) qui sera analysée en termes d’impacts et dont le statut sera décidé par un
comité des changements (change control board). On ne peut accepter qu’un changement soit introduit de façon informelle par un utilisateur qui contacterait directement un
développeur, sans mesure d’impact ni traçabilité de la demande.
a. In Ivar Jacobson, Grady Booch, James Rumbaugh, Le Processus unifié de développement logiciel, Eyrolles, 2003.
GestProjInform Livre Page 62 Vendredi, 3. avril 2009 12:07 12
62
techniques de modélisation. Tout comme UML (Unified Modeling Language), le
Processus unifié (Unified Process) ambitionnait de standardiser des bonnes pratiques
expérimentées ici ou là dans l’ingénierie logicielle. Il faut également reconnaître à
Philippe Kruchten d’avoir considérablement enrichi le Processus unifié.
UP met en avant six bonnes pratiques pour favoriser le succès des projets ; elles sont
présentées dans le tableau 2-3, ci-après :
Tableau 2-3 Les six bonnes pratiques du Processus unifié
Bonne pratique
Description
Un pilotage itératif et incrémental, piloté par les risques et les cas d’utilisation
Comme toutes les méthodes agiles, UP adopte le principe de découpage du projet
en itérations et du développement incrémental pour les avantages cités ci-dessus.
UP est attaché à la technique des cas d’utilisation (voir chapitre 3), pour représenter textuellement et graphiquement les scénarios d’usage du système à développer. À chaque cas d’utilisation sont associés des r isques d’implémentation. Grâce
au pilotage par les risques, on choisira d’implémenter en priorité les cas d’utilisation qui permettent de réduire ou supprimer le maximum de risques.
Une gestion rigoureuse
des exigences
UP préconise de constituer un référentiel d’exigences, facilitant ainsi l’organisation,
l’analyse et l’évolution des exigences fonctionnelles ou non fonctionnelles ; ce référentiel, en outre, garantit la traçabilité des exigences, dans leur évolution et dans les
différentes étapes du cycle de transformations qu’elles vont subir.
Un développement centré
sur l’architecture
L’architecture et les problématiques techniques sont souvent les plus critiques sur un
projet (nouvelle technologie, intégration, complexité). Il est impératif, par conséquent, de
valider les principes et les choix architecturaux au travers d’un prototype architectural
(« un squelette épaissi de quelques muscles » a ) afin de lever les principaux risques. Elle
ne doit pas être validée « sur le papier », mais au travers de composants réels.
La modélisation graphique
des exigences
« Un schéma vaut parfois mieux que de longs discours. »
La représentation graphique, schématique et visuelle sert à mieux décrire les systèmes, d’autant mieux s’ils sont complexes.
C’est ainsi que recourir à un langage standard comme UML pour modéliser le système sous forme de diagrammes ne peut que faciliter la communication au sein du
projet (avec le client, selon les diagrammes, ou entre les différents corps de métier
au sein de l’équipe).
Le contrôle permanent
de la qualité
Parce qu’il est plus coûteux de détecter et de corriger un défaut logiciel tardivement, la
qualité d’un produit doit être évaluée en continu le plus tôt possible dans le cycle de vie.
Chaque jalon majeur ou intermédiaire du projet donne l’opportunité de contrôler la
qualité, et de revoir et d’adapter la méthodologie de travail à l’origine des défauts, en
complément des activités de tests permanentes.
Le contrôle des changements
Si l’on accepte le changement, ce n’est pas n’impor te comment, n’importe quand, ni
n’importe quoi !
Un processus rigoureux outillé doit supporter le changement, inhérent au développement itératif. Chaque changement fait l’objet d’une demande de changement (change
request) qui sera analysée en termes d’impacts et dont le statut sera décidé par un
comité des changements (change control board). On ne peut accepter qu’un changement soit introduit de façon informelle par un utilisateur qui contacterait directement un
développeur, sans mesure d’impact ni traçabilité de la demande.
a. In Ivar Jacobson, Grady Booch, James Rumbaugh, Le Processus unifié de développement logiciel, Eyrolles, 2003.
GestProjInform Livre Page 62 Vendredi, 3. avril 2009 12:07 12