Le 25 février 2003, à Gosselies, un groupe de discussion a débattu de la pertinence des méthodes orientées objectifs pour concevoir des cahiers de charges de logiciels. Constat : les objectifs semblent plus parlants pour les managers et les analystes business et laissent aux développeurs la responsabilité de concevoir la solution qui satisfasse aux mieux les objectifs.
Selon Michaël Petit, chercheur aux FUNDP de Namur, et Christophe Ponsard, chercheur au CETIC, les techniques actuelles de modélisation utilisées en génie logiciel, comme UML, conviennent bien pour décrire des solutions logicielles (architectures, designs) mais sont mal adaptées pour décrire le problème à résoudre -l’objet même du cahier des charges. Tout d’abord, ces techniques sont trop opérationnelles. Une diagramme UML de séquence, par exemple, décrit un enchaînement d’événements concrets menant à la réalisation d’un service souhaité mais ne permet pas d’exprimer des solutions alternatives, de les comparer et de les évaluer. Ensuite, le " pourquoi " n’est pas explicité : on ne sait pas exprimer pourquoi telle séquence est appropriée et quels sont les objectifs fondamentaux qui sont poursuivis.
Par conséquent, souligne Robert Darimont du CEDITI, les chefs d’entreprise et les managers délèguent souvent les aspects informatiques des projets et s’y impliquent peu car le jargon utilisé ne leur parle pas. Une approche par objectifs, au contraire, leur permet de comprendre les cahiers des charges et les liens existant entre les objectifs qui y sont décrits et leurs objectifs statégiques. Il s’agit donc du bon niveau de description, qui de plus impose moins de contraintes au niveau de la solution et permet donc de ne pas déresponsabiliser l’équipe de développement.
Un objectif décrit une intention, une raison pour laquelle on veut construire un système. On peut décrire des objectifs à différents niveaux d’abstraction : des objectifs stratégiques, de haut niveau, ou des objectifs plus précis, opérationnels. On distingue également les objectifs fonctionnels, qui portent sur la fonction même que le système va remplir, et les objectifs non fonctionnels, qui expriment des qualités attendues du système en terme de performance, de sécurité, de coût ou d’adaptabilité, par exemple. Ces objectifs sont poursuivis ou satisfaits par des " agents " -le logiciel à développer (on parle alors d’exigences du cahier des charges), mais aussi d’autres logiciels existants, des êtres humains ou des machines. Une approche orientée " buts " permet donc non seulement de décrire les objectifs / exigences d’un système, mais également sont environnement, ce qui est indispensable car c’est dans celui-ci que le système s’incrit et va apporter une plus-value.
L’utilisation de ces concepts permet d’élaborer le cahier des charges d’un système de manière intuitive. En effet, à partir d’un objectif donné, en se posant la question du " pourquoi ", on peut identifier des objectifs de plus haut niveau à satisfaire ; en se posant la question du " comment ", on peut identifier l’ensemble des sous-objectifs qui vont permettre d’atteindre l’objectif en question. L’élaboration du cahier des charges se fait donc " naturellement " par une combinaison d’approches " top-down " et " bottom-up ". Par ailleurs, les objectifs fournissent un mécanisme de structuration du cahier des charges (un modèle) qui en facilite la compréhension, la cohérence et la mise à jour. L’examen d’alternatives devient possible car on peut identifier plusieurs sous-ensembles distincts d’objectifs qui sont autant de manières différentes de satisfaire un même objectif de plus haut niveau. Cette technique permet également de "rétro-analyser" un système existant afin de découvrir les objectifs sous-jacents, puis, à partir de ceux-ci, de redéfinir des sous-objectifs différents qui correspondent au nouveau système à développer. Notons enfin que l’identification d’alternatives permet aussi d’explorer diverses frontières possibles entre le système à développer et son environnement.
KAOS et i* sont les deux principales approches orientées objectifs. La première a été développée à l’Université Catholique de Louvain par le professeur Axel van Lamsweerde et son équipe ; la seconde a été conçue par Eric Yu de l’université de Toronto. Dans le cadre du groupe de travail, Christophe Ponsard et Michaël Petit ont présenté ces deux notations via un exemple : l’analyse de l’organisation d’un service d’urgence hospitalier.
Quatre modèles sont proposés dans KAOS : le modèle des objectifs (modèle principal), le modèle objet, similaire aux diagrammes de classe d’UML et permettant de décrire le vocabulaire du domaine, le modèle des responsabilités et le modèle des opérations.
Un objectif peut être raffiné en sous-objectifs, selon plusieurs principes de décomposition. Le jalonnage temporel, par exemple, identifie les sous-objectifs comme des étapes successives dans le temps permettant de satisfaire l’objectif de haut niveau. Un objectif peut donner lieu à des alternatives permettant de représenter différentes possibilités de satisfaire un objectif. Une distinction est faite entre objectifs " softs " (de haut niveau, flous) et objectifs " hard " dotés d’une définition précise. Les objectifs peuvent être " à réaliser " (un jour), à " assurer " (toujours) ou à " éviter " (jamais). Les buts " feuilles " (qui ne sont pas raffinés plus avant) sont assignés à des agents. Un principe de la méthode KAOS est d’arrêter le raffinement des objectifs en sous-objectifs lorsqu’il est possible de les assigner à un agent particulier. KAOS permet également de représenter les obstacles qui empêchent la réalisation d’objectifs ainsi que les moyens de les contourner ou d’amoindrir leur effet.
i* met l’accent sur les agents poursuivant les objectifs et les liens stratégiques existant entre ces agents. Ainsi, contrairement à KAOS, chaque objectif " appartient " à un agent donné. Différents types d’éléments sont identifiés : des objectifs " softs ", des tâches (effectuées par des agents pour atteindre un objectif) et des ressources (nécessaires à un agent pour effectuer une tâche ou attendre un objectif). Les liens entre ces éléments sont de types divers : tâches et objectifs peuvent être décomposés, un objectif peut être considéré comme un moyen pour atteindre une fin (un autre objectif, une tâche), un acteur peut dépendre d’un autre pour atteindre ses objectifs.
Objectiver : un outil de support à KAOS
Le CEDITI a développé Objectiver (précédemment nommé "Grail"), un outil de support à KAOS. Il est actuellement en phase de finalisation et de commercialisation. Robert Darimont insiste particulièrement sur la fonctionnalité de génération de la documentation, qui permet d’obtenir un cahier des charges dans un format traditionnel (Word, RTF, HTML ou PDF) tout en étant cohérent même après de multiples mises à jour, puisqu’il découle d’un modèle. Cette cohérence est impossible à obtenir en gérant un document de manière traditionnelle.
OME : un environnement pour la modélisation organisationnelle
L’environnement OME a été développé à l’Université de Toronto et offre un support à l’activité de modélisation en i*. L’outil est générique (supporte plusieurs notations) et extensible. Il offre des fonctionnalités intéressantes telles qu’une procédure permettant d’évaluer les objectifs du modèle en propageant des valeurs de satisfaction le long des différents liens existant entre les objectifs. Bien qu’il s’agisse d’un prototype universitaire, il offre une très bonne stabilité. Une version beta est disponible.