Acquisition et exploitation d'éléments de processus d'ingéniérie logicielle: Cas du projet CIAO-SI

I.5.3 Ce qu'il faut pour un processus d'ingénierie logicielle

L'approche processus permet d'une part, d'identifier clairement les activités nécessaires à la réalisation des produits-clés de l'entreprise, et d'autre part, d'articuler ces activités pour atteindre de manière répétable et prévisible les objectifs des projets et de l'entreprise. Une entreprise peut se baser sur des référentiels tels que CMM ou SPICE pour définir ses processus (Renault 2004). Le CMM (Capability Maturity Modeling) est un environnement, développé par l'Institut de Processus Logiciel (SEI) de l'Université de Carnegie Melon. Cet outil définit cinq (05) niveaux de maturité (niveaux initial, répétable, défini, dirigé, optimisé) permettant la classification des entreprises par rapport aux processus qu'elles envisagent d'utiliser. Adopté par des centaines d'entreprises de par le monde, ce moyen les amène à augmenter leur degré de maturité, qui va avec la réduction des risques, l'amélioration du contrôle de la gestion dans le développement de produits logiciels. Quant à SPICE (ou ISO 15504), c'est un modèle de maturité accompagné d'une méthode d'évaluation proposés par l'ISO. Mais ces référentiels s'avèrent assez lourds à utiliser, en terme de volume d'information et de ressources nécessaires. Cela constitue souvent un frein à leur diffusion dans des petites et moyennes structures.

La Figure 3 situe le processus d'ingénierie logicielle dans l'entreprise et présente les facteurs extérieurs pouvant l'influencer.

PROCESSUS D'ENTREPRISE

PROCESSUS D'INGENIERIE LOGICIELLE

PROCESSUS DE DEVELOPPEMENT

OUTILS

ARCHITECTURE

STANDARDS

CULTURE

LEGISLATION

PROCESSUS EXTERNES

Figure 3. Situation du processus d'ingénierie logicielle dans l'entreprise.

I.5.4 Les processus d'ingénierie logicielle aujourd'hui

Nous présentons sommairement où se situe ce domaine aujourd'hui. Notre souci n'est pas de faire un état de l'art des processus, mais de nous concentrer sur l'aspect évolution de ces derniers, afin de mieux situer le contexte actuel.

Il existe en effet dans ce domaine une évolution considérable. Car il y a quelques années encore, les termes les plus couramment utilisés étaient méthode et méthodologie. C'est ainsi que l'on a distingué trois (03) générations de méthodes, depuis les années 1970, suivant qu'un système soit perçu d'un point de vue fonctionnel, systémique ou objet.

- Les méthodes cartésiennes : caractérisées par les méthodes d'analyse fonctionnelle et de décomposition hiérarchique, elles trouvent leur origine dans les langages de programmation procéduraux ; brièvement, elles proposent de fonctionner par affinage des fonctions mères en des sous-fonctions ; on peut leur compter SADT, Jackson, Yourdon, CORIG (Bouzeghoub 1997) ;

- Les méthodes systémiques : développées dans les années 80, elles s'inspirent de la théorie systémique des organisations où le système d'information est perçu comme un objet complexe dont il faut définir la structure et les objets fonctionnels ; ces méthodes ont dominé le monde du génie logiciel durant les années 80 et au début des années 90 et s'appliquent en grande partie aux systèmes d'information orientés gestion tels que les applications bancaires, d'aide à la gestion d'entreprise ; on peut leur compter Merise, Axial, Information Engineering ;

- Les méthodes objets : advenues dans les années 90, elles introduisent le concept objet dans la conception des systèmes d'information et permettent ainsi la description de la dynamique des systèmes par les opérations liées aux objets des systèmes ; l'approche objet insiste sur les aspects de modularité, réutilisabilité, extensibilité du code, maintenabilité et évolutivité du système. Elle a entraîné la distinction entre le langage de modélisation (différents diagrammes et symboles utilisés pour représenter les éléments de la modélisation), processus de modélisation (enchaînement d'activités à suivre pour la réalisation du produit) et langage d'implémentation supportant les paradigmes objets. L'approche objet s'est, depuis le milieu des années 90, imposée comme un standard de fait dans l'industrie de l'ingénierie logicielle (Jacobson 1999) ; c'est pourquoi dans la suite, nous nous étendrons sur ces méthodes.

Partant donc de cette dernière avancée, qui a définitivement rendu l'approche objet dominante dans le monde du génie logiciel, les nouvelles méthodes, plus couramment désignées processus, ont vu le jour. Parmi les processus de développement les plus utilisés au début des années 2000, se trouvent OPEN, OOSP et RUP.

OPEN est un processus unifié proposé par le consortium OPEN. Il est issu de la fusion de plusieurs méthodes : MOSES, SOMA, Firesmith, Synthesis, BON et OOram (Ambler 1999). Il supporte notamment les notations UML et OML (Object Modeling Language). C'est un processus guidé par les responsabilités. Les activités y décrivent l'architecture globale du processus, et avec les tâches, elles décrivent ce qui doit être fait au cours du processus. Quant à comment cela doit être fait, un ensemble de techniques est employé. OPEN prend en compte la gestion de programmes, un programme étant ici un ou plusieurs projets ou encore une ou plusieurs versions d'une application ou d'une suite d'applications. Ce processus a malheureusement souffert d'une politique de marketing défaillante, d'où sa faible vulgarisation.

Le processus logiciel OOSP (Object-Oriented Software Process) propose une approche par phases, étapes et tâches telles que l'assurance de la qualité, la gestion de projets, l'entraînement et l'éducation, la gestion de personnes, des risques, de la réutilisation, etc. Comme la précédente elle n'est pas assez vulgarisée.

RUP (Rational Unified Process) est le processus phare de la corporation Rational. C'est sans doute l'adaptation du célèbre processus unifié UP (Unified Process) la plus répandue dans le milieu industriel. Il s'est imposé grâce à quelques atouts. Il est basé sur des principes d'ingénierie logicielle solides tels que une approche de développement itérative, guidée par les besoins et basée sur l'architecture. De plus, Rational a largement investi dans son produit RUP, une description basée sur HTML, que nous décrirons plus loin.

Enfin, EUP (Entreprise Unified Process), une proposition de Ronin International, est l'une des toutes dernières adaptations de UP, qui se veut être l'adéquation de RUP aux besoins réels des entreprises. Car, l'un des défauts de RUP étant la prise en compte d'un unique projet, l'améliorer en gérant plusieurs projets dans les mêmes délais est plus proche des réalités industrielles. C'est principalement ce qu'apporte EUP. Nous espérons que cette méthode connaîtra un succès comparable à celui du RUP lui même.

Et c'est ainsi que s'achève cette brève revue de l'état actuel des processus d'ingénierie logicielle. Nous avons donc présenté les processus d'ingénierie logicielle et nous nous sommes situés par rapport à ces processus dans le contexte actuel de leur évolution. Le cadre de notre travail n'en est que mieux défini.