Soutenance mémoire
Définition des PME
L’entreprise est un lieu de création de valeurs, liées au développement et à la commercialisation de produits et/ou de services destinés à un marché donné et dont une clientèle solvable reconnaît l’utilité, dans un ou plusieurs domaines d’activité et en interagissant avec des partenaires externes. L’entreprise évolue suivant une politique et des objectifs stratégiques qui favorisent l’obtention d’un avantage compétitif. En comparaison avec les grandes entreprises ou encore les grands groupes, les petites et moyennes entreprises (PME) ont généralement une structure plus simple avec un ensemble plus limité de ressources. Ce sont, selon les textes (Figure 1), des entreprises qui emploient moins de 250 salariés et dont le chiffre d’affaires annuel n’excède pas 50 millions d’euros et/ou le total annuel de bilan n’excède pas 43 millions d’euros. Parmi elles, les microentreprises (MIC) occupent moins de 10 personnes et ont un chiffre d’affaires annuel ou un total de bilan n’excédant pas 2 millions d’euros (OSEO 2012). Les PME jouent un rôle central dans l’économie de la plupart des pays et leur poids économique est décisif. Pour la Commission Européenne, elles sont le moteur de l’économie puisqu’elles sont une source majeure de compétences entrepreneuriales, d’innovation et d’emplois. En France, durant l’année 2013, les PME représentaient plus de 98% de la totalité des entreprises (dont 94% sont des microentreprises) et emploient 42% des salariés (Planson et al. 2013). Nous remarquons donc que la quasi-totalité des PME sont des microentreprises. En outre, sur 129 000 PME étudiées, le profil type des PME françaises est de 20 salariés avec un chiffre d’affaires de 4,6 millions d’euros assorti d’une valeur ajoutée de 1,3 million d’euros (OSEO 2012). De fait, leurs ressources humaines sont limitées et centrées principalement sur le cœur de métier de l’entreprise. Les différentes expériences de RESULIS lui ont permis de constater que les PME, et surtout les microentreprises, évoluent en suivant des procédures simples et évolutives au gré des situations. Leurs processus métiers impliquent des ressources humaines qui collaborent, généralement polyvalentes, sans liens nécessairement clairs entre leurs rôles ou entre les responsabilités exercées. Elles ont aussi une structure organisationnelle qualifiable de simple en raison de leur petite taille, avec peu de profondeur dans la hiérarchie des postes.
Ingénierie des besoins et des exigences : concepts et définitions
L’ingénierie des besoins et des exigences (IBE) est une discipline commune à toutes les ingénierie1 métiers (génie logiciel, mécanique, électronique, etc.) comme à l’Ingénierie Système (BKCASE Editorial Board 2015) qui la reconnaît comme la phase décisive la plus en amont dans tout projet d’ingénierie d’un système i.e. de produits et/ou de services satisfaisant les besoins de différentes parties prenantes. Le processus regroupant toutes les activités d’IBE est défini par (Loucopoulos & Champion 1989) comme étant “the systematic process of developing requirements through an iterative process of analyzing a problem, documenting the resulting observations, and checking the accuracy of the understanding gained”. Il suppose donc l’application systématique et répétitive de techniques d’analyse, de documentation et de vérification et de validation des exigences. Dans le domaine du Génie Logiciel, selon (Rolland 2003) « l’ingénierie des besoins est concernée par l’identification de buts assignés au système envisagé et l’opérationnalisation de ces buts en contraintes et exigences imposées au système et aux agents qui en assureront le fonctionnement. L’ingénierie des besoins peut être vue comme le processus qui permet de transformer une idée floue en spécification précise des besoins servant de support à la spécification du système et de ses interfaces avec l’environnement ». Notons enfin que l’Ingénierie Système (BKCASE Editorial Board 2015) propose deux processus distincts d’ingénierie des besoins et d’ingénierie des exigences qui se positionnent en amont des processus de conception architecturale de la solution. L’IBE guide et accompagne le passage d’une description initiale, souvent peu claire voire contradictoire que nous appelons besoin, à une spécification plus formelle et plus contractuelle de ce besoin, appelée exigence. Ceci se fait au moyen d’activités, entre autres, d’expression, de documentation et d’évaluation continue des besoins et de construction d’un référentiel d’exigences. Dans la littérature anglo-saxonne, les auteurs ne différencient pas réellement les concepts de besoin et d’exigence. En effet, selon (Chemuturi 2012) «Une exigence est un besoin, une attente, une contrainte ou une interface de toutes les parties prenantes, qui doit être satisfaite par le système logiciel proposé». Le besoin est alors plutôt vu comme une attente basique voire vitale, le minimum absolu sans lequel le système ne sera pas utilisable. Nous préférons la stratification proposée par (Jackson 1997) « Une exigence est le produit intermédiaire entre le besoin et le programme ». Nous considérons dans la suite deux phases de maturité qui distinguent les besoins des exigences :
Besoin : « stakeholder requirement » ou « user requirement » en anglais, représente l’expression initiale de la MOA, considérée alors comme la représentante des parties prenantes commanditaires. Il exprime et décrit une situation, un vœu, un but ou une contrainte vis-à-vis du système à réaliser. Les besoins sont le plus souvent définis de façon informelle, dans le langage de la maîtrise d’ouvrage, afin de simplifier la communication avec ces parties prenantes. Ils reflètent le monde du problème.
Exigence : « system requirement », une exigence est définie comme « un énoncé qui prescrit une fonction, une aptitude ou une caractéristique à la quelle doit satisfaire un produit ou un système dans un contexte donné » (Scukanec & Gaasbeek 2007). Les exigences traduisent donc les besoins, elles sont établies de fait dans le langage de la maîtrise d’œuvre. Elles représentent les propriétés attendues du système qui vont ainsi contraindre la conception de la solution. Une collaboration MOE / MOA est ainsi nécessaire pour analyser les besoins et déduire les exigences. Ces exigences sont organisées dans un référentiel, i.e. l’ensemble des exigences qui reflète les consensus et décisions prises par les parties prenantes et est à la base d’un document contractuel définissant les rôles et responsabilités des commanditaires et prestataires. En ce qui concerne les projets de développement d’applications logicielles, la distinction entre besoin et exigence est d’autant plus importante qu’elle permet de mettre l’accent sur le problème à solutionner en considérant le point de vue de chaque partie prenante pour éviter que les seules descriptions du système à réaliser soient exprimées en termes de solution (Hull et al. 2010). Il existe deux catégories d’exigences (ISO15288 2008) à savoir : les exigences fonctionnelles et les exigences non-fonctionnelles. Les exigences fonctionnelles font référence aux fonctionnalités et aux services que le système doit fournir. Lorsqu’il s’agit par exemple d’une application de gestion, elles traduisent les opérations à automatiser et sont fortement liées au fonctionnement de l’entreprise. Les exigences non-fonctionnelles contraignent et précisent comment le système doit satisfaire les exigences fonctionnelles en termes de performance, sécurité, fiabilité, ergonomie, niveau de maintenabilité, portabilité, réutilisabilité, etc. Elles peuvent concerner également certains aspects liés à la gestion du projet de développement comme le coût et les délais de réalisation. Leur identification est importante puisqu’elles servent de critères de sélection permettant à l’équipe de développement de faire des choix en termes de conception et d’implémentation. La première référence à la nécessité d’actions d’ingénierie des besoins et des exigences était faite au milieu des années 70 : « the requirements for a system do not arise naturally; instead, they need to be engineered and have continuing review and revision » (Bell & Thayer 1976) et l’IBE a été alors reconnue comme discipline au milieu des années 80 (Lamsweerde 2000). Depuis, un grand nombre de méthodes et de langages ont été proposés, suivants différentes orientations (buts, scénarios, etc.) qui sont repris au chapitre II. Cependant, quelle que soit la méthode proposée, l’objectif des travaux en IBE est d’améliorer la qualité des exigences en atténuant les défauts, omissions ou erreurs souvent rencontrés dans la phase d’expression des besoins et inhérents à la nature informelle de ces derniers, tels que :
• L’ambiguïté : informations données au niveau des besoins ayant différentes interprétations possibles;
• L’imprécision : besoins flous ou insuffisamment définis, structurés ou détaillés suite à des reformulations par exemple ambiguës;
• L’omission : besoins omis par oubli objectif ou subjectif, menant ici aussi à des incohérences ou des imprécisions;
• La redite : besoins exprimés plus d’une fois ou reformulés en d’autres termes induisant encore des incohérences ou de l’ambiguïté;
• L’incohérence : besoin en contradiction avec un ou plusieurs besoins.
Nous pouvons aussi citer le bruit, la non-mesurabilité, la non intelligibilité ou la nontraçabilité (Lamsweerde 2009). Certains de ces défauts pourraient être levés ou limités par l’emploi de méthodes éprouvées, de bonnes pratiques, le respect de normes et de standards tels que ceux proposés par (INCOSE 2012) et (ITU-T 2008) dont une analyse est faite au chapitre II, analyse qui nous permettra d’argumenter les contributions attendues de ces travaux. La présence de ces défauts peut avoir des conséquences désastreuses dans les phases suivantes du projet d’informatisation ou pendant l’exploitation du système. En effet, dès le milieu des années 70, les auteurs de (Bell & Thayer 1976) ont remarqué que des exigences inadéquates, incohérentes ou ambiguës ont un impact critique sur la qualité des applications qui en résultent. C’est aujourd’hui un des problèmes reconnu dans le domaine du Génie Logiciel, comme le montrent des études telles que celles proposées par (Ibanez & Rempp 1996; The Standish Group 2009). Par exemple, (The Standish Group 2009) souligne que 44% des projets de développement logiciel ont dépassé leur délai et budget sans nécessairement arriver, d’une part, à décrire et, d’autre part, à respecter toutes les exigences attendues. Ceci est lié principalement à une gestion inadéquate des exigences. Il est donc proposé par les praticiens de l’IBE de systématiser un processus d’expression puis de passage des besoins aux exigences. Ce processus est composé généralement les activités suivantes :
1 – L’identification des parties prenantes. Il est important d’identifier toute personne, groupe de personnes ou organisation pouvant influencer ou être affecté par le système ou son élaboration, de façon directe ou indirecte (Sharp et al. 1999). Le processus d’ingénierie des besoins et des exigences concerne ainsi un grand nombre de parties prenantes en relation avec les parties prenantes principales du projet d’informatisation, à savoir la maîtrise d’ouvrage et la maîtrise d’œuvre : les clients, les fournisseurs, le législateur, les soustraitants, etc. La liste des parties prenantes peut également évoluer durant le processus d’IBE. Aussi, dans la plupart des projets d’informatisation, les entreprises font appel à une assistance à maîtrise d’ouvrage pour la représenter, jouer le rôle de coordinateur avec la MOE et l’aider à élaborer le cahier des charges. La MOE exprime des contraintes qui sont vues ici comme un type d’exigences nonfonctionnelles, par exemple en termes de gestion de projet, de disponibilité des acteurs ou de techniques utilisées lors du développement. Elle apporte son expertise et doit proposer à la MOA des solutions fonctionnelles.
2 – Compréhension du domaine et expression des besoins. C’est ici que le problème à résoudre est décrit. Après l’identification des parties prenantes, il est nécessaire de les impliquer pour qu’elles puissent décrire, partager et faire comprendre :
les objectifs stratégiques et la politique de l’entreprise, ses partenaires essentiels concernés a priori par le futur système,
le contexte dans lequel le système devra être exploité, le fonctionnement, l’organisation et les interactions de l’entreprise avec son environnement,
les besoins fonctionnels, non fonctionnels et les contraintes liées à l’organisation et aux ressources internes à l’entreprise auxquels le système doit répondre et les informations qu’il doit gérer.
3 – Analyse, vérification et négociation. Le processus d’IBE implique plusieurs des parties prenantes identifiées. C’est pourquoi les besoins qu’elles expriment peuvent être contradictoires voire conflictuels de par les rôles détenus par ces parties prenantes dans le processus d’IBE ou dans l’entreprise, mais aussi de par les points de vue de chacun sur le système souhaité. Ces conflits doivent être détectés et résolus. Une phase d’explication, de vérification, de justification et de négociation est requise pour parvenir à un consensus.
4 – Passage des besoins aux exigences, vérification et documentation des exigences. Le passage des besoins aux exigences doit être systématique et rigoureux en s’appuyant sur différentes méthodes (raffinement, choix, revue, etc.). Durant cette phase, sur la base des besoins établis et vérifiés, la MOA (ou son assistance) en collaboration avec la MOE décident de ce qui peut être conservé ou mis à jour dans le SI actuel de la PME (système « as-is ») si celui-ci existe partiellement, de ce qui doit être prévu pour former le système attendu (système « to-be ») et de ce qui sera effectivement développé en tenant compte des contraintes projet (système « to-implement »). Ces choix conduisent à l’élaboration du référentiel des exigences qui sont écrites, typées, documentées et structurées. En parallèle, la vérification continue de la qualité attendue de ces exigences est nécessaire pour garantir qu’elles sont bien formées, bien écrites, et éliminer les possibles défauts cités précédemment (ambiguïtés, omissions ou autres défauts inhérents aux besoins).
5 – Validation des exigences. Il s’agit alors de valider les exigences par rapport aux besoins des parties prenantes. Il est nécessaire ici de se référer au métier de l’entreprise et aux domaines évoqués dans les besoins pour déterminer la pertinence des exigences vis-à-vis du monde réel tel que perçu par chacune des parties prenantes, dont la MOA et la MOE. Ce processus n’est pas séquentiel. Des retours en arrière et des itérations apparaissent, par exemple, lorsque la résolution d’un conflit implique des modifications ou que la vérification des exigences implique des corrections. La Figure 2 met en évidence ces itérations et montre l’intervention des différentes parties prenantes (cas où la MOA est assistée) dans le processus d’IBE. Il est également important de garder une trace de « qui a dit quoi » et des modifications qui ont été apportées afin de pouvoir justifier et argumenter de la qualité résiduelle du référentiel des exigences. Ce référentiel est ensuite utilisé comme entrée pour les phases suivantes du projet.
Principes de la Modélisation d’Entreprise
Les méthodes, cadres d’architecture et outils de modélisation d’entreprise ont été développés comme support au cycle d’ingénierie et de modélisation des entités de l’entreprise. La maîtrise de la complexité apparente ou inhérente de l’entreprise a été traitée, dans la plupart des méthodes, par une décomposition selon des points de vue structurels (organisation, ressource, information) et fonctionnels. Plusieurs approches basées sur la mise en avant des processus de l’entreprise sont effectivement aujourd’hui reconnues pour permettre de comprendre, d’améliorer et de piloter les activités entre collaborateurs et partenaires pour aboutir à un résultat correspondant aux objectifs de l’entreprise. De nombreux auteurs arguent de fait que la maîtrise du système d’information d’une entreprise passe par la maîtrise ses processus. Ces derniers sont perçus traditionnellement comme la source principale des besoins fonctionnels, lorsqu’il s’agit de développer des applications supports au SI de l’entreprise (Brocke & Rosemann 2010). Cependant, cette vision fonctionnelle (vision processus) n’est pas suffisante pour saisir la totalité du système d’information de l’entreprise. En effet, pour pouvoir représenter les autres points de vue de l’entreprise au moyen de modèles, d’autres langages de modélisation sont nécessaires. Selon (Vernadat 2001), les concepts que ces langages permettent de manipuler doivent être définis en prenant en compte les principes suivants :
Les concepts du langage sont en nombre fini, et leur syntaxe et sémantique sont fixées, figeant ainsi tout problème d’interprétation.
Séparation entre les processus et les ressources : l’entreprise est perçue comme un entrelacs de processus interdépendants mais séparés et non couplés avec un ensemble de ressources.
Séparation entre le comportement et le fonctionnement de l’entreprise : il faut pouvoir séparer ce qui est fait (le fonctionnement) de l’ordre selon lequel c’est fait (le comportement).
Séparation entre les ressources et les unités organisationnelles : les unités organisationnelles (services, départements…) sont définies dans le but de représenter la structure de l’organisation. Les ressources (humaines et matérielles) doivent être définies séparément puisqu’elles peuvent être allouées à différentes unités organisationnelles.
Ces principes ont été définis dans un souci d’interopérabilité entre les langages proposés en modélisation d’entreprise dans le cadre du projet UEML (Vernadat 2001). Ils garantissent l’évolution et la maintenabilité des modèles produits lors des projets concernés par la modélisation d’entreprise, puisque des éléments du modèle peuvent être mis à jour sans pour autant modifier tout le modèle.
SBVR
SBVR (Semantics of Business Vocabulary and Business Rules) (OMG 2008) est un métamodèle dédié à la définition des connaissances métiers en CNL d’une manière non ambiguë et compréhensible par l’homme et la machine. Ce n’est pas un langage mais plutôt une syntaxe abstraite qui standardise la définition de modèles sémantiques du vocabulaire et des règles métiers d’une organisation (Hall, 2006). SBVR supporte la construction d’un vocabulaire constitué de l’ensemble des termes, définitions et relations qu’une organisation utilise lors de l’exercice de son métier. Ce dernier est construit à partir de :
– Concepts, qui représentent : (i) des concepts individuels correspondant à un seul objet, (ii) des types d’objet, qui sont des concepts génériques classifiant des objets selon leurs propriétés communes, (iii) des rôles, joués par les concepts pour définir leur fonction ou leur utilisation dans des situations particulières.
– “Fact types” (faits) : les faits représentent une relation entre des concepts ou une caractéristique d’un concept. Les faits sont construits à l’aide de verbes et peuvent être associatifs, de catégorisation, partitifs, etc.
– Règles métiers : elles sont construites à partir de faits, eux-mêmes construis à partir de concepts. Les règles métiers et les conseils (bonnes pratiques) pris en considération au niveau d’une organisation représentent la politique de gestion de cette dernière.
o Les règles métiers peuvent être opératives (régissent le fonctionnement de l’organisation – elles expriment l’obligation, l’interdiction et la permission restreinte) ou structurelles (vraies par définition – elles expriment la nécessité, l’impossibilité et la possibilité restreinte)
o Les conseils expriment la permission ou la possibilité.
Des langages ont été définis sur la base de SBVR et permettent son utilisation comme SBVR Structured English et RuleSpeak (OMG 2008). Formulés en langage naturel, ces langages sont utilisés par les experts et décideurs métiers formés sur les règles d’écritures et les formulations à respecter.
|
Table des matières
Introduction générale
Chapitre I : L’informatisation des PME Contexte et problématique
1.1 Introduction
1.2 Contexte : ingénierie des besoins et des exigences pour l’informatisation des PME
1.2.1 Caractéristiques des Petites et Moyennes Entreprises (PME)
1.2.2 Ingénierie des besoins et des exigences : concepts et définitions
1.3 Conclusion : problématique RESULIS et objectifs des travaux
Chapitre II : État de l’art
2.1 Introduction
2.2 Comprendre la PME : apports de la Modélisation d’Entreprise
2.2.1 Modèle d’entreprise
2.2.2 Principes de la Modélisation d’Entreprise
2.2.3 Cadres et méthodes en Modélisation d’Entreprise
2.2.4 Efforts d’unification et de normalisation
2.2.5 Synthèse : verrous constatés
2.3 L’IBE pour comprendre et formaliser le projet d’évolution de la PME
2.3.1 Analyse comparative de langages de modélisation en IBE
2.3.2 Vers des notations plus accessibles en IBE
2.3.3 Synthèse : verrous constatés
2.4 Progresser en confiance durant le processus d’IBE : vérification et validation
2.4.1 Définitions : vérification et validation des exigences
2.4.2 Qualités attendues d’une exigence et d’un référentiel d’exigences
2.4.3 Techniques de vérification et de validation
2.4.4 Synthèse
2.5 Conclusions et contribution des travaux
2.5.1 Positionnement
2.5.2 Hypothèse de travail : l’organisation avant l’informatisation
2.5.3 Contribution attendue
2.5.4 Exemple illustratif
Chapitre III : Concepts supports à la Méthode d’IBE
3.1 Introduction
3.2 Cadre normatif pour la construction du modèle de l’entreprise
3.3 Syntaxe abstraite pour l’expression des besoins et le passage des besoins aux exigences
3.3.1 Vue du contexte de l’étude
3.3.2 Vue organisationnelle
3.3.3 Vue des ressources
3.3.4 Vue fonctionnelle
3.3.5 Vue informationnelle
3.3.6 Vue des exigences
3.4 Règles de modélisation
3.4.1 Règles favorisant la complétude
3.4.2 Règles favorisant la non-reformulation
3.4.3 Règles favorisant la cohérence
3.5 Conclusion
Chapitre IV : Langages supports à la Méthode d’IBE
4.1 Introduction
4.2 Les DSL supports de la méthode d’IBE
4.2.1 Le DSL textuel
4.2.2 Les DSL graphiques
4.3 Conclusion
Chapitre V : Démarche illustrée et outillages
5.1 Introduction
5.2 Description de la démarche
5.2.1 Identification des parties prenantes
5.2.2 Elicitation des besoins
5.2.3 Vérification des besoins
5.2.4 Validation des restitutions
5.2.5 Validation des exigences
5.3 Conclusion
Conclusion générale, limites et perspectives
Références
Télécharger le rapport complet
