Page du LIL                                                                                       Ma Page 

L’objet de mon travail de thèse a consisté en l’élaboration d’une méthode de conduite de projet et la description du processus sur lequel elle repose. Cette méthode fournie des éléments pour une solution globale de la " crise du logiciel ". Ainsi, elle est fondée sur une théorie dite "théorie des dimensions du logiciel" déduite d'une analyse approfondie de la " crise du logiciel " et de l'organisation, qui permet de prendre en compte tous les aspects du système d'information et du logiciel. Cette théorie repose sur un modèle de l'organisation améliorant le modèle de Leavitt qui a permis d’associer cinq dimensions au système d'information. A partir de ces dimensions ont été déduits cinq dimensions concernant le processus de développement logiciel et cinq dimensions concernant le produit logiciel issu de ce processus. Dans ce travail, je me suis intéressée plus particulièrement à l’incidence du prototypage dans les démarches d’informatisation en gestion. L’étude approfondie des domaines de l’architecture logicielle et la réutilisation, l’évaluation en génie logiciel ont également fait partie de ce travail. A ce jour, les travaux de recherche effectués dans le cadre de ma thèse ont fait l'objet de deux publications:

1. Tout d'abord, la théorie des dimensions a reçu un accueil favorable dans le cadre d’une conférence consacrée aux systèmes d’information [1].
2. Ensuite, la méthode de conduite de projet que j’ai élaborée sur la base de cette théorie des dimensions a également fait l’objet d’un article, présenté dans le cadre d’une conférence IEEE consacré aux systèmes complexes [2].

La poursuite des travaux effectués dans le cadre de ma thèse m’ont permis d’identifier de nouveaux thèmes et directions de recherche liés au génie logiciel dans le cadre de l’informatisation des organisations. Il s’agit tout d’abord de compléter la méthode de conduite de projet que j’ai définie notamment en ce qui concerne les processus supportant les couches architecturale et organisationnelle. Ensuite, le caractère itératif de la méthode de conduite de projet que j’ai proposée requiert la description du méta-processus du génie logiciel et la définition d’un modèle générique d’évaluation prenant en compte les différents aspects du logiciel. Enfin, il m’est apparu rapidement nécessaire de formaliser les processus composant la méthode de conduite de projet notamment pour déterminer des critères objectifs d’amélioration et d’évaluation de ses apports, et pour développer des outils pour la supporter. La formalisation permet en particulier de préciser comment la méthode de conduite de projet que je propose permet de prendre en compte les différents aspects du logiciel notamment les aspects organisationnels et humains. Ces trois thèmes s’inscrivent dans les trois axes de recherche suivants liés au domaine du génie logiciel et des systèmes d'information, et dont l’objectif est de proposer des solutions permettant de compléter le corpus méthodologique existant et de réduire les effets de la crise du logiciel:

1. Définition, formalisation et amélioration de nouveaux processus d'informatisation des organisations et intégration du prototypage dans ces processus;
2. Définition, formalisation et amélioration de méthodes d’évaluation des solutions informatiques notamment les méthodes, les outils et les architectures logicielles;
3. Définition, formalisation et amélioration des processus décisionnels en génie logiciel.

Le modèle global du logiciel prend en compte d'une part, tous les aspects du système d'information et de sa partie automatisée (le logiciel) et d'autre part, les intérêts et les points de vue des acteurs concernés par le développement et l'utilisation du logiciel au sein de l'organisation. Ce modèle repose sur la " théorie des dimensions du logiciel " et sur les théories économiques de l'agence et des coûts de transaction. La théorie des dimensions du logiciel fournit des instruments pour prendre en compte tous les aspects du logiciel notamment les aspects économiques, organisationnels et humains. Les théories de l’agence et des coûts de transaction permettent d'identifier les métiers des acteurs impliqués dans le processus d'informatisation, de modéliser leurs interactions et de prendre en compte leurs intérêts et leurs points de vue. Le modèle global du logiciel représente le domaine du génie logiciel en quatre espaces: l'espace des problèmes, l'espace des solutions, l'espace de construction et l'espace d'opération. Il distingue quatre types d'acteurs représentant les types de métiers liés au développement et à la maintenance de logiciels: le client, l'utilisateur final, l'architecte et le développeur. Ces acteurs sont liés par des contrats du type producteur consommateur. Chaque acteur joue le rôle principal dans l'espace représentant son métier mais peut jouer un rôle secondaire dans plusieurs autres espaces. Le modèle global du logiciel a été utilisé dans la plupart de mes publications relatives aux axes de recherche énumérés précédemment. Ces publications se répartissent entre ces trois axes de la manière suivante :

• Cinq publications sont liées aux processus d’informatisation des organisations : le premier article concerne la modélisation de la crise du logiciel en termes d’inconsistances et d’interactions entre les acteurs de l’organisation [3]. Le second [4] propose un modèle générique pour réduire les incertitudes dans le cadre de l’informatisation des organisations complexes. Dans le prolongement de ce travail, le troisième article propose un cadre générique d’informatisation des organisations basé sur un modèle des cinq spirales [5]. Deux autres articles ont été consacrés respectivement aux aspects organisationnels de la réutilisation d’artefacts logiciels [6] et aux liens entre architecture logicielle et réutilisation [7]. Par ailleurs, quatre documents de travail (diffusés dans le cadre du CERIA) décrivent respectivement un modèle générique d’architecture logicielle [8], un processus itératif d’ingénierie des besoins basé sur le prototypage [9], un modèle générique du processus de coordination en génie logiciel [10] et un modèle des inconsistances inhérentes au développement des systèmes informatiques centrés sur les humains [11].
• Trois publications ont été consacrés aux méthodes d’évaluation supportant le méta-processus en génie logiciel : Le premier article [12] décrit une méthode de sélection d’une solution informatique. Le second étudie l’utilisation du modèle " logit " pour l’analyse et la prévision des risques en génie logiciel [13]. Le troisième propose un modèle économique de la réutilisation [14].
• Trois publications concernent les processus décisionnels en génie logiciel : Le premier article explore les liens entre prototypage et aide à la décision [15]. Le second propose une méthode améliorant les processus décisionnels basée sur la théorie des options [16]. Le troisième applique la théorie des options pour définir le processus des décisions en génie logiciel dans le cadre du modèle des cinq spirales [17].
• Trois publications décrivent les liens entre le méta-processus et les processus décisionnels en génie logiciel : Le premier étudie le comportement des décideurs à l’aide de modèle économétriques qualitatifs et montre comment le modèle " Tobit " permet de décrire les facteurs déterminants de l’investissement dans une nouvelle technologie [18]. Les deux autres décrivent des cadres génériques orientés décision pour mettre en œuvre le méta-processus [19] [20].

Références

[1] C. Toffolon: " The Software Dimensions Theory ", Conference ICEIS’99, Setúbal, Portugal, March 27-30, 1999.

[2] C. Toffolon, S. Dakhli: " A Three Layers Software Development Method: Foundations and Definitions", Conference IEEE-ICECCS’97, Como, Italy, 8-12 Sept. 1997.

[3] C. Toffolon, S. Dakhli: "A Framework for Software Engineering Inconsistencies Analysis and Reduction", Conference IEEE-COMPSAC’98, Vienna, Austria, 19-21 August 1998.

[4] C. Toffolon, S. Dakhli : " Informatisation des processus complexes : Un modèle générique pour réduire les incertitudes ", Conférence MOSIM’99, Annecy, France, oct. 99.

[5] C. Toffolon, S. Dakhli : " Le modèle des cinq spirales : Un cadre générique d’informatisation des organisations ", Conférence MFPE’99, Tunis, Tunisie, mai 1999.

[6] C. Toffolon, S. Dakhli: " Software Artifacts Reuse and Maintenance: An Organizational Framework", Conference IEEE-CSMR’98, Florence, Italy, 9-11 March 1998.

[7] C. Toffolon, S. Dakhli : " Software Reusable Artifacts Evolution : A three level abstraction framework ", Conference INCOSE’99, Brighton, UK, 6-11 June 1999.

[8] C. Toffolon, S. Dakhli: " A Framework of Software Architecture: The ‘Ladder Model’, Document de travail, CERIA, Université de Paris-Dauphine, janvier 1998.

[9] C. Toffolon : " Requirements Elicitation Process: An Iterative Approach Based on Software Prototyping", ISCIS'99 Conference, Izmir, Turquie, octobre 1999

[10] C. Toffolon: " A Framework for Studying the Coordination Process in Software Engineering ", 14th ACM Conference on Applied Computing (SAC2000), Como, Italy,  19-21 March  2000

[11] C. Toffolon : " Human-Centered Systems Development and Use Inconsistencies ",  Conference HCP'99, Brest, France, septembre 1999.

[12] S. Dakhli, C. Toffolon: "  A Software Evaluation Approach Based on the Software Dimensions Theory ", Conference ESCOM8, Berlin, Germany, 26-28 May 1997.

[13] C. Toffolon: " Software Risks Analysis and Evaluation Using an Econometric " logit " Model ", Conference ESCOM-ENCRESS’98, Rome, Italy, 27-29 May 1998.

[14] C. Toffolon, S. Dakhli : " An Economic Model of Software Reuse ", Conference ESCOM-SCOPE’99, Herstmonceux Castle, UK, 27-29 April 1999.

[15] C. Toffolon, S. Dakhli : " Software Rapid Prototyping Evaluation ", Conference UKSMA’98, London, UK, 29-30 Oct. 1998.

[16] C. Toffolon, S. Dakhli : " Decision-Making Process Improvement : A framework based on the option pricing theory ", Conference CIMCA’99, Vienna, Austria, 17-19 Feb. 1999.

[17] C. Toffolon, S. Dakhli : " The Decision Process in Software Engineering: A Framework Based on The Real Options Theory ", Conference ICEIS’99, Setúbal, Portugal, 27-30 March, 1999.

[18] C. Toffolon: " The Decision-Making in Software Engineering: An Econometric Model to Analyze the Determining Factors ", Conference FESMA’98, Antwerpen, Belgium, 06-08 May 1998.

[19] C. Toffolon, S. Dakhli: " Software Evaluation and Control: A Framework of Software Engineering Meta-process ", Conference ESCOM/ENCRESS’98, Rome, Italy, 27-29 May 1998.

[20] C. Toffolon, S. Dakhli,: " Software Projects Evaluation and Control: A Decision-Oriented Generic Framework ", Conference FESMA’98, Antwerpen, Belgium, 06-08 May 1998.

Le génie logiciel peut être défini comme étant un ensemble de trois processus interreliés qui sont:

Dans ce contexte, nous avons d’abord identifié dix aspects majeurs des logiciels, nous parlons alors de dimensions du logiciel, sur la base desquelles on réalise un logiciel. Ces dimensions concernent le processus logiciel et les artefacts qui en résultent. Les cinq dimensions du processus de développement (coût, délai, technique, communication, organisationnelle) et les cinq dimensions du logiciel final (fonctionnelle, humaine, économique, organisationnelle, temporelle) montrent qu’un même logiciel peut refléter des réalités différentes selon les contextes organisationnel, social et économique auxquels il est destiné. La théorie des dimensions du logiciel, tout en expliquant la crise du logiciel, fournit un outil d’analyse a priori, à dominante décisionnelle, qui permet de classer les dimensions, en tenant compte de la catégorie du logiciel et du contexte organisationnel et un outil d’analyse et d’évaluation a posteriori qui permet, sur la base de la mesure des composantes logicielles relativement aux différentes dimensions, de déclencher un processus itératif d’amélioration et de rectification des choix effectués. Dans un deuxième temps, nous avons élaboré sur la base de la théorie des dimensions, une approche d’évaluation qui, en tenant compte du contexte social, organisationnel et technique de production et d’utilisation d’un logiciel, reste conforme au principe de rationalité limitée.

L’approche que nous proposons permet d’une part, de choisir entre plusieurs solutions logicielles, entre plusieurs méthodes, outils ou processus et d’autre part, d’évaluer la qualité d’un artefact logiciel, sur la base d’un classement des dimensions du logiciel et en fonction des priorités et des contraintes de l’organisation. Après une description de la technique de classement des dimensions, nous déduisons un algorithme de choix qui repose sur une fonction-score qui tient compte, en plus des caractéristiques propres de l’organisation, des aspects liés aux risques et à l’incertitude. Une étude de cas, nous a permis de valider cette approche en permettant de répondre à deux questions qui concernent :

• le choix entre les différentes approches de développement,
• les effets du prototypage sur le processus de développement et sur les produits qui en sont issus.

Une méthode de développement de logiciels en trois couches:

Fondements et Définitions [2]

Salem Dakhli Claudine Toffolon

Université Paris-IX Dauphine, CERIA, France

Conférence IEEE-ICECCS’97, Côme, Italie, 8-12 septembre 1997

Résumé

Le rôle des systèmes d’information (S.I.) dans les organisations modernes est sans cesse croissant. Les S.I. sont devenus une composante essentielle de la compétitivité des organisations dans lesquelles ils s’insèrent. Cependant, l’industrie du logiciel n’est pas encore mature et toujours en crise. Les logiciels coûtent cher, les dépassements de budgets et de délais sont quasi généralisés, tandis que nombre des logiciels réalisés ne sont pas de qualité et ne répondent pas aux besoins des utilisateurs.

Même si la démarche d’informatisation des S.I. apparaît aujourd’hui bien codée, le processus de réalisation des logiciels n’est pas encore totalement maîtrisé. Il est clair que l’ensemble des solutions, approches, méthodes, techniques et outils qui ont été proposés ces dernières années ont contribué dans une large mesure à améliorer la productivité du processus de développement des logiciels et leur qualité mais il est vite apparu qu’ils sont restés insuffisants pour résoudre complètement les problèmes liés à la crise du logiciel. En premier lieu, parce que ces solutions n’ont pas su prendre en compte tous les aspects des logiciels et en second lieu, parce qu’elles n’ont pas été fondées sur une analyse en profondeur des causes de la crise du logiciel.

L’objet de cet article est de proposer une méthode de conduite de projet qui offre une solution globale à la crise du logiciel. Cette méthode est basée sur une théorie dite " des dimensions du logiciel " selon laquelle un logiciel peut être caractérisé par dix dimensions. Nous avons identifié ces dimensions à partir de l’étude des démarches d’informatisation et de l’analyse des effets de la crise. Ces dimensions nous ont aidé à dégager les sources de risques critiques en génie logiciel et à définir les instruments pour les réduire. Elles appartiennent à deux catégories et concernent respectivement le processus de développement du logiciel et le résultat de ce processus, liées aux facteurs organisationnels, techniques, économiques et humains des logiciels et des organisations dans lesquelles ils s’insèrent.

La méthode que nous avons élaboré comporte deux parties: une partie statique et une partie dynamique. La partie dynamique est divisée en trois couches: une couche organisationnelle, une couche architecturale et une couche logicielle. La couche logicielle s’appuie sur une superstructure que constitue la couche organisationnelle et une infrastructre constituée par la couche architecturale. Chaque couche est supportée par trois processus interdépendants, évolutifs et itératifs: un processus de production, un processus de support et un méta-processus. Le processus de support qui consiste en une conjonction d’un modèle du processus de production et d’une technologie permettant de le mettre en œuvre, porte sur la description des méthodes et des techniques réalisant les activités permettant de produire les artefacts logiciel. Ce processus est basé sur une représentation du modèle en spirale dans un sous-ensemble des dix dimensions. La partie dynamique de notre méthode décrit la mise en œuvre et le contrôle de ces trois processus qui animent les trois espaces constituant le champ de déroulement d’un projet informatique: l’espace des problèmes, l’espace des solutions et l’espace de construction. La partie statique est organisée autour de référentiels qui capitalisent les ressources logicielles (architectures logicielles, modèles, techniques, outils,...) ainsi que les normes, les standards en vigueur dans l’organisation, nécessaires pour la mise en œuvre de la partie dynamique de la méthode de conduite de projet.

Notre méthode met en évidence les apports du prototypage, de la réutilisabilité et du paradigme objet dans une approche évolutive d’ingénierie des logiciels sans interdire l’utilisation de méthodes et de techniques conventionnelles de développement.

Après avoir décrit les aspects les plus importants de notre méthode, nous présentons une étude de cas pour la valider et nous concluons en identifiant une liste d’améliorations futures potentielles.

Afin de faire face à la globalisation croissante des marchés et aux contraintes économiques et technologiques d’un environnement en évolution permanente, les organisations utilisent les technologies de l’information comme instrument de compétitivité. Ainsi, le rôle des systèmes d’information dans les organisations ne cesse de croître et évoluer. Ils supportent les processus opérationnels et décisionnels et représentent aujourd’hui une composante essentielle des organisations. Toutefois, les bénéfices de l’investissement massif des organisations dans les technologies de l’information sont inférieurs à ceux escomptés, en partie à cause de la crise du logiciel dont les coûts élevés de maintenance et l’échec de nombreux projets informatiques sont les symptômes les plus évidents. La plupart des solutions proposées à ce jour pour sortir de la crise du logiciel ont en partie échoué d’une part, en raison de la complexité croissante des systèmes informatiques et d’autre part, parce qu’elles ne prennent pas en compte tous les aspects du logiciel. C’est ainsi que depuis la fin des années 80, de nombreux auteurs voient dans la réutilisation et l’architecture logicielle, le moyen de sortir de la crise du logiciel en améliorant la productivité du processus de développement et la qualité des logiciels qui en sont issus. Cependant plusieurs problèmes liés à la réutilisation des artefacts logiciels et à leur maintenance demeurent. Tout d’abord, de nombreuses études empiriques ont montré que la valeur ajoutée de la réutilisation de fragments de code est basse. Ensuite, les problèmes liés à l’organisation du cycle de vie des artefacts réutilisables constituent un frein à la réutilisation. Enfin, les rares méthodes de conduite de projet qui prennent en compte les aspects liés à la réutilisation d’artefacts logiciels sont encore incomplètes et doivent être validées empiriquement. Par conséquent, afin de réaliser les bénéfices potentiels de la réutilisation d’artefacts logiciels, deux problèmes doivent être résolus: d’une part, les liens entre réutilisation et architecture logicielle doivent être définis et d’autre part, les processus de développement, de maintenance et d’utilisation d’artefacts réutilisables doivent être décrits. C’est pour tenter de résoudre ces problèmes que les auteurs proposent dans cet article un modèle organisationnel de la réutilisation. Ce modèle, fondé sur la théorie économique de l’agence et sur l’architecture logicielle, permet d’une part, de comprendre les difficultés inhérentes à la réutilisation en génie logiciel et d’autre part, de répondre aux questions liées aux problèmes listés ci-dessus, notamment:

• qui gère la création et la maintenance des artefacts réutilisables?
• quels sont les liens entre réutilisation et architecture logicielle?
• qui conduit le processus de réutilisation?

Le modèle décrit dans cet article a été utilisé en pratique dans le cadre de la définition et la mise en œuvre d’une politique de réutilisation dans une compagnie française d’assurances.

Le génie logiciel est " l'établissement et l'utilisation de principes technologiques bien établis afin d'obtenir de manière économique un logiciel fiable et fonctionnant efficacement sur de vraies machines ". Ainsi, en plus du développement et de la maintenance d’artefacts logiciels, le génie logiciel comprend un ensemble d’activités, désignées par l’expression méta-processus, consistant en l’introduction d’innovations, l'évaluation et l'amélioration de la qualité des artefacts logiciels et de la structure du processus de production du logiciel. Le méta-processus en génie logiciel comporte deux aspects: l’évaluation des artefacts logiciels et l’évaluation des processus, méthodes et outils afin d’en choisir les plus appropriés pour produire ces artefacts. En effet, diverses approches, méthodes ou technologies de développement sont possibles pour réaliser un logiciel. De la même manière, divers logiciels et architectures matérielles peuvent potentiellement répondre aux mêmes besoins fonctionnels. La littérature sur le sujet de l'évaluation en génie logiciel est très riche et abondante et de nombreuses méthodes et technologies comme le paradigme "GQM" (Goal-Question-Metric), le modèle de maturité technologique (CMM) ou le modèle ISO/IEC 9126 sont proposés. Néanmoins, l'utilisation de ces modèles bien établis est à l'origine de deux types de problèmes. D'une part, il est souvent difficile de définir l'ensemble des métriques permettant de répondre aux objectifs d'évaluation. D'autre part, ces modèles donnent seulement une vue partielle et de portée limitée du logiciel, et omettent souvent d'étudier beaucoup d'autres aspects, ce qui peut biaiser les résultats et mener à des interprétations fausses. Aujourd’hui, malgré l’abondance des travaux relatifs à l’évaluation, il n’existe aucune approche globale d'évaluation et de contrôle qui tient compte de tous les aspects du logiciel. Dans cet article, nous proposons un cadre décrivant une approche globale d'évaluation prenant en compte tous les aspects du logiciel ainsi que les points de vue et les intérêts conflictuels des différents acteurs du projet. En effet, l'évaluation en génie logiciel correspond aux besoins exprimés par les différents acteurs de l’organisation qui sont des producteurs ou des consommateurs de logiciel, et implique généralement un grand nombre de facteurs réels et intangibles. Ignorer totalement ou partiellement certains de ces facteurs peut mener à des résultats d'évaluation erronés et par conséquent à une décision erronée. Ce cadre est composé de trois parties. Dans un premier temps, nous utilisons la théorie économique de l’agence pour modéliser le génie logiciel comme un nœud de contrats entre différents acteurs avec des intérêts et des points de vues qui peuvent être contradictoires. Les acteurs d’un projet logiciel appartiennent aux quatre espaces identifiés par les auteurs dans des travaux précédents: l'espace des problèmes, l'espace des solutions, l'espace de construction et l'espace d'opération. Chaque espace se caractérise par un sous-ensemble des dix dimensions du logiciel. Dans un deuxième temps, nous employons ce modèle pour expliquer les coûts, les avantages et les risques d’un projet logiciel. Par exemple, nous identifions deux sources de coûts d’un logiciel: les coûts opérationnels, et les coûts d'agence. Les coûts d'agence sont liés aux divergences entre les objectifs des acteurs concernés par le logiciel. Finalement, nous employons les dimensions du logiciel pour définir, pour chaque acteur, un ensemble de métriques qui lui permet d'évaluer les logiciels selon son propre intérêt et point de vue. Ces métriques fournissent d'une part, des instruments d’évaluation " a priori " pour contrôler le projet et aider les responsables dans la prise de décision, et d'autre part, des instruments d’évaluation " a posteriori " des logiciels.

Nous avons validé ce cadre de travail de deux manières différentes. Tout d'abord, nous avons démontré qu'il est compatible avec de nombreux de modèles d'évaluation existants. Ensuite, nous l'avons appliqué pour évaluer des artefacts logiciels réutilisables et pour comparer deux stratégies de développement: "le développement avec réutilisation " et le " développement sans réutilisation ".

En dépit de l'importance économique et fonctionnelle des systèmes informatiques dans les organisations modernes, le développement et la maintenance de logiciels sont encore considérés comme des activités à haut risque. En effet, un nombre important de projets informatiques ne fournissent pas les résultats répondant aux exigences des différents acteurs concernés par le logiciel en respectant les contraintes de coût et de délai. De nombreux auteurs ont montré que les échecs en génie logiciel résultent d’une analyse et d'une évaluation insuffisantes des risques logiciels. Par ailleurs, de nombreuses études universitaires et industrielles ont souligné l'importance du risque dans la prise efficace de décision dans les domaines du développement et de la maintenance de systèmes logiciels. Un risque logiciel est le degré de vulnérabilité d’une organisation face aux menaces liées aux activités de développement, de maintenance et de mise en œuvre de systèmes informatiques, et susceptibles de porter atteinte à ses objectifs et ses priorités. Le développement, la maintenance et l'utilisation de systèmes informatiques comportent deux sortes des risques: les risques techniques et les risques économiques. Les risques techniques sont endogènes au processus de décision et se rapportent aux facteurs inconnus impliqués dans le développement d’artefacts logiciels: les facteurs liés au temps, à l’effort et aux technologies requises... Les risques économiques sont exogènes au processus de décision et se rapportent à des événements inattendus indépendants du contrôle direct de l'organisation: les événements politiques, les changements de taux d'intérêt ... Aujourd’hui, peu de progrès ont été faits pour améliorer l'analyse et l'évaluation des risques en génie logiciel. En particulier, les méthodes existantes d'analyse et d'évaluation des risques en génie logiciel ne permettent pas de tenir compte des caractéristiques et des contraintes de l'organisation d’une manière satisfaisante. Afin d’apporter des réponses à ces déficiences, cet article décrit un cadre pour analyser, évaluer et prévoir les risques en génie logiciel. Ce cadre est basé sur un modèle économétrique qualitatif, appelé modèle " logit ", dans lequel la variable dépendante est une variable binaire prenant la valeur de 1 si le projet informatique échoue et 0 autrement. Ce modèle va permettre d’expliquer les risques en génie logiciel à l’aide de variables indépendantes reflétant les caractéristiques, les priorités et les contraintes de l'organisation. Les variables indépendantes utilisées dans ce modèle sont définies en utilisant les dimensions du logiciel décrites dans des travaux précédents¹ . Le cadre proposé dans ce travail peut être appliqué à tous les types de projets informatique et permet aux décideurs d'une part, d’identifier les facteurs de risque les plus importants en génie logiciel pour l'organisation concernée et d'autre part, de définir des plans d'action pour réduire les risques techniques. En outre, il fournit un outil de prévision des risques qui facilite le choix entre plusieurs solutions alternatives (méthodes, outils, modèles d’architecture, processus,...) pour développer les systèmes logiciels.

Les paramètres du modèle de logit ont été estimés en utilisant des données relatives à vingt logiciels supportant des processus opérationnels et décisionnels dans de nombreuses banques et compagnies d’assurance françaises de différentes tailles. Les résultats obtenus ont permis d'une part, de confirmer des résultats déjà établis au sujet de l'influence de la nature et de la taille du logiciel sur la probabilité d'échec d'un projet et d'autre part, d'identifier les risques inhérents à l’utilisation de nouvelles technologies de l'information.

Le rôle des systèmes informatiques dans les organisations ne cesse de croître, évolue constamment et consiste à supporter leurs processus opérationnels et décisionnels. Ces systèmes informatiques sont devenus aujourd'hui une composante essentielle de la compétitivité des organisations. En particulier, les systèmes informatiques facilitent l'évolution des organisations intégrées dans un environnement économique, social et technologique en évolution permanente. Le logiciel vise à satisfaire les besoins des différents acteurs de l'organisation dont les points de vue et les intérêts sont souvent divergents voire contradictoires. Ainsi, la décision de développer un logiciel ou de choisir une technologie pour le développer (méthode, outil, architecture, réutilisation) doit refléter les aspects organisationnels, humains, technologiques, fonctionnels du logiciel. Quel que soit le niveau de prise de décision dans l'organisation, la décision portant sur le développement d'un système informatique ou sur le choix d'une technologie pour l’implémenter résulte d'un comportement séquentiel d’un acteur de l’organisation: tout d’abord, il décide d'effectuer ou non les tâches correspondantes et ensuite il fixe le montant d'investissement nécessaire. Dans cet article, nous représentons ce comportement à l’aide d’un modèle économétrique qui est une extension du modèle " Tobit " de James Tobin. Ce modèle est une superposition d'un modèle qualitatif dichotomique et d'un modèle quantitatif. Le premier décrit la première phase de la décision (développer ou non le logiciel, choisir ou non une technologie donnée). Le second décrit le montant d'investissement en fonction de nombreuses variables explicatives liées aux aspects spécifiques du logiciel ou de la technologie faisant l'objet de la décision. Le modèle économétrique que nous proposons rend possible la détermination d’un ensemble de critères qui visent à expliquer d'une part, l'évolution du portefeuille d'applications de l'organisation et d'autre part, l’utilisation de diverses technologies de développement (méthodes, outils, modèles d’architecture, réutilisation...).

Dans ce travail, le modèle économétrique proposé a été utilisé pour identifier les facteurs déterminants de deux décisions majeures en génie logiciel: le choix d'une méthode de développement et la réutilisation d’artefacts logiciels. Dans les deux cas, les paramètres du modèle ont été estimés en utilisant les données relatives à vingt logiciels supportant des processus opérationnels et décisionnels dans plusieurs banques et compagnies d’assurance françaises de tailles diverses. Les résultats obtenus nous ont permis d’établir les conclusions suivantes:

• la réutilisabilité des artefacts logiciel dépend fortement de l'architecture logicielle et de la maturité technologique de l'organisation,
• le prototypage est un instrument de réduction des incertitudes inhérentes au développement du logiciel,
• aucun modèle de cycle de vie, aucune méthode de développement n'est approprié avec tous les types de logiciel,
• la réduction du délai de mise sur le marché et l’amélioration de la productivité de développement ne sont pas toujours les plus importants facteurs déterminants du développement des systèmes informatiques.

Le génie logiciel est un ensemble d’activités de conception et de réalisation destinées à rationaliser la production, le contrôle et le suivi de projets informatiques. Il est basé sur trois processus: le processus de production, le processus de support et le méta-processus. Ce dernier est l’ensemble des activités du processus de génie logiciel consistant liées à l’introduction des innovations, l’évaluation et l’amélioration de la qualité des artefacts logiciels et de la structure des processus (y compris le méta-processus lui-même).

La complexité, l’incertitude et les risques sont trois caractéristiques intrinsèques du processus de production du logiciel. Ces caractéristiques sont liées d’une part, aux dimensions du logiciel identifiées dans un précédent travail¹ , d’autre part aux attributs des processus métier supportées par les systèmes informatiques, et enfin à l’importance du nombre de méthodes, techniques et outils proposés pour supporter le processus de production du logiciel. Le processus de production du logiciel comporte deux types d’incertitudes: l’incertitude technique et l’incertitude économique. L’incertitude technique est endogène au processus de décision et fait référence aux facteurs inconnus inhérents au développement d’artefacts logiciels: délai, effort, technologies requises,... L’incertitude économique est exogène au processus de décision et fait référence aux événements incontrôlables directement par l’organisation: événements politiques, changements des taux d’intérêt,...Le méta-processus du génie logiciel fournit un ensemble d’approches et d’outils d’évaluation et de contrôle permettant de réduire les effets de la complexité, de l’incertitude et des risques inhérents au processus de production du logiciel. A ce jour, malgré la richesse de la littérature relative à l’évaluation, il n’existe pas d’approche globale d’évaluation et de contrôle qui prend en compte tous les aspects du génie logiciel. Par exemple, les approches d’évaluation basées sur la règle de la Valeur Actualisée Nette (VAN) ne prennent pas en compte les événements incertains susceptibles de survenir au cours du développement du logiciel. Par ailleurs, ces approches supposent que les risques et l’incertitude inhérents au processus de production du logiciel ne changent pas au fur et à mesure que les managers prennent des décisions. Dans ce papier, nous proposons un modèle générique d’évaluation orienté aide à la décision et basé sur le prototypage, la théorie de la décision économique et la théorie des options. Ce modèle concerne l’évaluation et le contrôle des projets informatiques à risques et permet aux managers de prendre des décisions intermédiaires de continuer, de différer ou d’annuler ces projets afin de réagir aux événements incertains. Ce modèle peut être utilisé pour décrire des méthodes et des outils nécessaires pour réduire l’incertitude à l’aide du prototypage, et pour évaluer le retour sur investissement des technologies du logiciel (modèles d’architecture, méthodes orientées objet,...).

Afin de valider le modèle générique proposé, nous l’avons utilisé pour évaluer le retour sur investissement du développement d’un kit d’artefacts réutilisables, et déterminer la valeur de l’information fournie par le prototypage rapide dans plusieurs banques et compagnies françaises d’assurance. Pour atteindre ce but, nous avons défini un ensemble de métriques nécessaires pour mesurer les inputs, les outputs et les bénéfices des artefacts réutilisables et du prototypage rapide. L’analyse des données collectées nous a permis de conclure notamment que:

• Les coûts organisationnels et humains et les bénéfices du logiciel sont difficiles à estimer avec une précision suffisante ;
• Les bénéfices résultant de la construction d’artefacts logiciels réutilisables dépendent du savoir faire de l’organisation, de sa maturité technologique et de ses facteurs de coûts;
• Le développement et l’utilisation d’artefacts logiciels réutilisables comporte de nombreux risques liés notamment à leurs coûts de développement et de maintenance qui peuvent être largement supérieurs aux prévisions. Ainsi, dans certains cas, il est peut être préférable de différer la décision de développer des artefacts logiciels réutilisables.

• Le prototypage rapide (informatif) est utile pour réduire l’incertitude inhérente au processus de production du logiciel. Néanmoins, l’information qu’il fournit peut accroître la complexité des systèmes informatiques. Ainsi, l’impact du prototypage informatif sur la complexité des systèmes informatiques doit être évalué et pris en compte dans la détermination du nombre optimal d’itérations.

Malgré l’importance économique et fonctionnelle des systèmes informatiques dans les organisations modernes, le développement et la maintenance du logiciel sont considérés comme des activités à haut risque. En effet, un nombre important de projets informatiques n'aboutissent pas aux logiciels répondant aux besoins des utilisateurs en respectant les contraintes de budget et de délai. Par ailleurs, selon G. Wierderhold, la part de la maintenance dans le coût global du logiciel dans l’industrie atteint environ 60 à 85%. Le nombre important de projets informatiques qui échouent et les coûts élevés de la maintenance logicielle constituent les ramifications économiques de la crise du logiciel. Les ramifications sociales de cette crise concernent la résistance des utilisateurs à la mise en œuvre des systèmes informatiques dans les organisations. La crise du logiciel apparaît comme la plus importante cause du " paradoxe de la productivité " mis en évidence par de nombreux auteurs. Les solutions proposées à ce jour pour sortir de la crise du logiciel ne sont pas appropriées, d’une part en raison de la complexité croissante des systèmes informatiques et d’autre part, parce qu’elles ne prennent pas en compte tous les aspects du logiciel. En particulier, ces solutions ne mettent pas suffisamment l’accent sur les causes réelles de la crise du logiciel. Cela ne signifie pas que les paradigmes, les méthodes, les outils et les technologies utilisés jusqu’aujourd’hui sont mauvais. Bien au contraire, nous pensons qu’ils fournissent des instruments efficients pour remédier à certains aspects de la crise du logiciel, si les vrais problèmes sont identifiés et bien connus. Par conséquent, pour élaborer une solution de la crise du logiciel, il faut tout d’abord identifier les causes réelles de cette crise et ensuite définir les processus, les méthodes et les outils les plus appropriés pour éliminer ces causes.

Cet article fournit un cadre qui d’une part, permet de comprendre les causes de la crise du logiciel et d’autre part, propose un processus de développement permettant aux développeurs d’éliminer ces causes. A la place de la vue traditionnelle du génie logiciel comme un ensemble d’activités de spécifications, de conception et de réalisation, ce cadre basé sur la théorie économique de l’agence permet de modéliser le génie logiciel en termes de contrats entre des acteurs organisationnels qui interagissent et qui ont des points de vue et des intérêts conflictuels. Ainsi, les causes réelles de la crise du logiciel sont dues aux inconsistances résultant des discrépances entre les objectifs des acteurs du projet. Ce travail fournit notamment:

1. un modèle du génie logiciel basé sur la théorie économique de l’agence,
2. une description des inconsistances en génie logiciel,
3. un modèle de processus de développement pour éliminer ces inconsistances.

1. permet aux organisations d’implémenter toute solution logicielle à l’aide de différentes approches, méthodes et outils conformément à leurs priorités, leurs contraintes et leur maturité technologique,
2. améliore l’efficacité du développement en tenant compte de tous les aspects du logiciel y compris les aspects humains et organisationnels souvent ignorés par de nombreuses méthodologies,
3. permet une meilleure adéquation entre les besoins des clients/utilisateurs et le logiciel d’une part, en distinguant quatre métiers majeurs impliqués dans chaque projet informatique et d’autre part, en prenant en compte les points de vue et les intérêts conflictuels des acteurs du projet.

Software rapid prototyping is an instrument which may be used to reduce uncertainty inherent in software engineering. In particular, it provides information needed to choose the most appropriate computer solutions, technologies, methods and tools to build the software products meeting the organization’s requirements. This information permits reducing the impacts of communications problems between the software project actors. For example, software rapid prototyping makes it possible to describe the users needs with precision and is useful to assess the impacts of an architecture model, a process or a new software technology on the universe of discourse. Nevertheless, software rapid prototyping corresponds to an irreversible investment which have two characteristics: firstly, its level depends on the quantity of information sought to reduce uncertainty and secondly, its profitability is dubious. By another way, information provided by software rapid prototyping may result in more complex software, additional development and maintenance costs, and higher risks of failure. Consequently, an a priori evaluation of software rapid prototyping costs, benefits and risks must be undertaken before building a software prototype in order to answer the following questions:

1. What is the optimal level of investment in software rapid prototyping?
2. What is the value of information provided by software rapid prototyping?
3. What is the optimal stopping criterion of the software prototype iterative improvement process?
4. What is the impact of the software rapid prototyping on the project actors behavior and perception of software engineering?

Decision-making plays a central role in determining the shape of modern organizations and helping them to take into account their internal and environmental constraints. Many authors have proposed paradigms to cope with the difficulties inherent in the decision-making process. For example, [Marshak et al. 72] proposed an information economics view to study the impacts of the information structure and the information value on the decision-making process. By another way, the relationships between this process and the organizations environmental forces (increased speed, complexity, turbulence,...) have been analyzed by [Huber et al. 86]. More recently, [Stohr at al. 92] stressed the role of information technology in the support of the organizations decision-making processes. Nowadays, in spite of the richness of literature on the subject of decision-making, many problems and difficulties related to the ability of organizations to make effective and timely decisions, are still unsolved. Firstly, almost all decisions problems involve the simultaneous consideration of several different objectives and conflicting interests and points of view. Indeed, according to the economic agency theory [Alchian et al. 72], an organization is a nexus of contracts among self-interested individuals. Each agency contract links a principal (entrepreneur) and agents (employees) in order to perform some service. The economic agency theory is based on the following assumption: each agent maximizes its proper utility and pays no regard to the welfare of the principal or non-pecuniary virtues. The discrepancies between the objectives of the principal and those of agents result in conflicting objectives that must be taken into account in the decision-making process. Secondly, complexity, uncertainty and risks are three intrinsic characteristics of the decision-making process. These characteristics are related, on the one hand to the attributes of the organizations business processes and on the other hand, to the organizations environmental constraints. In particular, in each organization, the decision-making process must cope with two kinds of uncertainty: technical uncertainty and economic uncertainty. Technical uncertainty is endogenous to the decision process and refers to the unknowns involved in the organizations operational and decision-making processes: time, effort and technologies required,... Economic uncertainty is exogenous to the decision process and refers to unexpected events beyond the direct control of the organization: political events, changes in interest rates,... Many methods and tools proposed to cope with the uncertainty inherent in the decision-making process are based on the economic decision theory. These methods present many problems: for example, they assume that the organizations business processes uncertainty and risks don’t change as managers make decisions. By another way, the proposed methods are based on only one time period and don’t consider that a decision-maker may make intermediary decisions to continue, postpone or alter some actions in order to respond to uncertain events. In this paper, we use the option-pricing theory to improve the decision-making process especially when decisions are irreversible. We assume that an irreversible decision corresponds to a capital investment opportunity comparable with a call option. Therefore, the decision-making process we propose in this work is based on an investment tree and considers uncertainty over many time periods. In particular, this process stresses that complexity reduction and uncertainty reduction are conflicting objectives. Indeed, information resulting from uncertainty reduction increases the complexity of the decision-making process. So, the decision-making process description includes an algorithm to compute the value of information. In order to validate the proposed framework, we use it to understand the software development process and to evaluate the return on investment of many tasks composing this process.

References

[Alchian et al. 72] Alchian A.A., Demsetz H.: " Production, Information Costs and Economic Organization ", American Economic Review, Vol. 62, No. 5 (Dec. 1972), pp. 777-795.

[Huber et al. 86] Huber G.P., McDaniel R.R.: " The Decision-Making Paradigm of Organizational Design ", Management Science, Vol. 32, No. 5, 1986, pp. 572-589.

[Marshak et al. 72] Marshak J., Radnor R.: " Economic Theory of Teams ", Yale University Press, New Haven, Connecticut, 1972.

[Stohr et al. 92] Stohr E.A., Konsynski B.R.: " Information Systems and Decision Processes ", IEEE Computer Society Press, Los Alamitos, California, 1992.

The role of Information Systems (I.S.) in modern organizations is always increasing and constantly evolving. They become an essential component of competitiveness and constitute an efficient tool and an innovation catalyst. By another way, I.S. create favourable conditions to increase effectiveness and reactivity of organizations by improving their decision-making and production processes. Information technology provides two kinds of resources to automate I.S.: hardware resources and software resources. Hardware resources are composed of computers and networks. Software resources permit using and managing hardware resources and provide methods, techniques and tools to develop software products required to support organizations business processes. Nevertheless, the software industry isn’t mature and still in crisis since the early times. This crisis, called " software crisis " is going on but is nowadays more critical as organizations can not exist without operational software. Solutions proposed to date in order to deal with the software crisis have partly failed, on the one hand because of the increasing complexity of software systems and on the other hand, because they don’t take into account all the aspects of software engineering. We think that all these solutions are not bad, each one present many benefits but they don’t take into account all the aspects of the software. In many cases, their use can be even worse than expected and create new difficulties. Consequently, any solution to the software crisis must be global and take into account all the aspects of the software, that means economic, technical, functional, structural as well as human and organizational aspects.

This paper proposes a theory, the " software dimensions theory " which permits analyzing deeply the software crisis. In particular, this theory may be used to elaborate software development methodologies which permits coping with the effects of the software crisis. Our paper is composed of four parts. In a first part, we propose a model of the organization which improve the Leavitt’s model by taking into account the behavioral aspects and the impact of information technology on the organization. This model uses the economic agency theory and the transaction costs theory to describe the information flows sent and received by the organizational entities. In the second part, we use the model of the organization described in the first part to derive the dimensions of I.S. There are five I.S. dimensions which constitute the basis of our software dimensions theory (functional, social, structural, economic, temporal).

The third part of our paper describes the software dimensions. Since software systems are parts of computer-based I.S., they must integrate the five I.S. dimensions we mention earlier and include the specific constraints of information technology. In that way, the software development activity can be assimilated to a projection of I.S. on the information technology constraints space. This projection results in evolution of the I.S. dimensions and is characterized by two aspects: dynamic and static. The dynamic aspect is related to the software development and maintenance processes while the static aspect concerns the software artifacts produced by these processes. These remarks as well as the analysis of the impacts of information technology on the organization business processes, permit identifying ten software dimensions. Five software dimensions concern the software development process and five other software dimensions concern the software product itself. The software process dimensions are cost dimension, delay dimension, technical dimension, communication dimension and organizational dimension. The software product dimensions are functional dimension, human dimension, economic dimension, organizational dimension and temporal dimension. The software dimensions theory provides at the same time:

• An a priori decision-oriented analysis tool which permits classifying the process and product dimensions and selecting the most important among them according to the nature of the software project and the characteristics of the context where it is used.
• An a posteriori analysis and evaluation tool which permits defining an iterative improvement process of software artifacts, methods, architectures and tools.

Software engineering is " the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines ". Therefore, software engineering is a set of design and implementing activities intended to rationalize production, control and monitoring of software projects. It comprises four processes: a production process, a support process, a meta-process and a decision process. The production process is a partially orderly set of interrelated development and maintenance activities of software artifacts. The support process is a conjunction of a production process model and a technology implementing this model. The meta-process is a set of activities related to software engineering process which consist in introducing innovations, evaluating and improving the quality of software artifacts and process structure (including the meta-process itself). The decision process uses information provided by the meta-process to make decisions related either to a stimulus or to the performance of the organization’s business and management processes. These four processes are interrelated and may be considered as meta-activities belonging to an iterative process which takes place according to the Boehm’s spiral model. Indeed, the software production process rests on the software support process, the software support process activities are selected and undertaken according to the decision process results, the decision process is based on the evaluation results of the meta-process, the meta-process is applied to the outputs of the three other processes. Existing software development processes, approaches and methods used in software engineering have many weaknesses. In particular, the decision process inherent in software engineering has been ignored by the majority of methods and tools suggested to date. Many authors have tried to take into account some aspects related to the decision-making process during software development and maintenance lifecycles. Their work, which rests on the economic decision theory, presents some disadvantages. In particular, it is based on the Net Present Value technique which is not compliant with the Simon’s Bounded Rationality Principle, and lead to " now or never " decisions.

We think that without describing the decision process inherent in software engineering, the ability of software developers and project managers to accommodate all risks and accurately schedule complex projects in changing environments, is seriously challenged. In this paper, we propose a framework to formalize the decision process inherent in software engineering. This framework, based on the call option theory, rests on the following assumption: each software project is a succession of irreversible investment decisions corresponding to the activities needed to develop software artifacts. The real options theory is applicable to evaluate design decisions made during the software development process since these decisions are, in general, irreversible and uncertain. So, the evaluation of a design decision can lead to four strategies: make follow-on the investment corresponding to this activity, postpone the activity, abandon the activity, invest to get more information about this activity. The real options theory provides instruments to manage software iterative lifecycles, in particular software rapid prototyping. Indeed, since software rapid prototyping requires an irreversible and uncertain investment in limited resources whose level depends on the quantity of required information, it corresponds to a call option that can be exercised by the software developer.

Our paper is organized as follows. Section 1 is an introduction which synthesizes the problems encountered in software engineering, in particular those related to the decision process, and describes the purpose of the paper. Section 2 describes the real option theory and proves how this approach is suited to cope with software project management and decision-making. In section 3, we apply the real options theory to define an evaluation approach which views design decisions as irreversible investments under uncertainty. Section 4 presents a spiral model, which shows the relationships between the four processes related to software engineering activities. In section 5, we present a case study and conclude this paper by listing lessons learned and research directions.

Since the late 80's, many studies dedicated to the analysis of the payoffs resulting from the investments in information technology, have focused on the " productivity paradox ". This paradox is related to the little contribution of information technology to organization productivity. Many authors lay stress the critical role of software products in modern organizations competitiveness and conclude that the productivity paradox is one aspect of the so-called " software crisis ". This crisis is going on but is nowadays more critical as organizations can not exist without operational software.

In that context, software reuse is a key technology which permits organizations to cope with many aspects of the software crisis (maintenance costs and development cycle times reduction, software systems quality increase). Software reuse consists in the utilization of existing software artifacts in an environment different from that it was originally intended, to build software systems by assembly with other artifacts. Although software reusable artifacts may be plugged into a new project without modification (black-box reuse), software reuse usually implies changing some aspects of reusable artifacts (white-box reuse).

However, despite the potential benefits of software reuse, current reuse methods, techniques and tools fail to improve the software development process productivity and the software products quality. Indeed, software reuse is, on the one hand, limited in most cases to fragments of source code programs with low added value while, on the other hand, problems related to the organizing of reusable artifacts lifecycle put a brake on its progress. Furthermore, the few software development methodologies which take these topics into account are not complete and need to be validated empirically. By another way, the complexity of the software reuse process has been highlighted by numerous studies which demonstrate notably that the cost-effectiveness of this paradigm is still an open question. In addition of the technical difficulties, we think that the complexity of the software reuse process results from two factors. Firstly, the software reuse process is strongly dependent of three types of activities: reusable artifacts development, maintenance and configuration management. Secondly, the software reuse process is based on two strategies, the " development with reuse " strategy and the " development for reuse strategy " which have conflicting goals.

Consequently, to realize all the potential benefits of software reuse in terms of software engineering productivity and software product’s quality improvements, many organizational and technical problems must be solved. In this paper, we propose a three-levels of abstraction (conceptual, organizational, technical) framework to describe the reusable artifacts evolution activity. The conceptual level lists the main tasks of the evolution activity and the data flows they exchange. The organizational level describes the actors contributing to the evolution activity and the evolution tasks carried out by each actor. The technical level emphasizes the version control problems resulting from reusable artifacts evolution and defines a set of basic rules to cope with these problems. This framework is based on the software engineering model we have defined in a previous work. This paper is organized as follows. In section 2, we present the software engineering model. Section 3 describes the structural aspects of the " software reuse environment " proposed in this work. Section 4 defines and discusses the conceptual and organizational models of our framework. In section 5, we offer a short insight into the version control aspects of reusable artifacts evolution activity. Section 6 concludes this paper by presenting research directions and lessons learned from using the proposed framework in many real cases.
 
 

Le contexte économique de cette fin du vingtième siècle a profondément changé, certains auteurs parlent de nouvelle révolution industrielle pour expliquer la rupture avec l’environnement économique passé de production de masse, de stabilité et de croissance, et l’émergence d’une " ère informationnelle ", une société post-industrielle à haute teneur en information où les changements sont incessants, souvent inattendus et l’environnement incertain. Cela signifie pour les organisations de chercher sans cesse à s’adapter à un monde en évolution, en " révolution " permanente où plus rien n’est constant ni prévisible. Dans ce contexte, le bon fonctionnement voire la survie d’une organisation moderne est conditionné par la mise en place d'une communication cohérente et fluide aussi bien entre ses différentes composantes qu'avec son environnement externe. L'essence de cette communication est l'information qui n'a donc d'utilité que si elle est exploitée et mise à disposition de façon optimale. L'augmentation du volume d'informations à traiter et la complexité croissante de la communication dans les organisations ont amené ces dernières à se doter de systèmes d'information afin de gérer efficacement la ressource stratégique qu'est devenue l'information. L’automatisation du système d’information grâce à l’emploi des technologies de l’information devant permettre à cet égard, de faciliter et améliorer le traitement de l'information en privilégiant sa circulation et sa mise à disposition auprès de l'utilisateur final, notamment pour l’aider dans ses décisions. Cependant, le processus d’informatisation des systèmes d’information demeure dans les années 90 la préoccupation majeure des organisations, sa maîtrise n’étant pas encore acquise. Ainsi, depuis les débuts de l’activité de réalisation de logiciels, constituant ce que l’on appelle désormais le génie logiciel, parle-t-on de crise du logiciel. Cette crise est d’autant plus préoccupante que le coût du logiciel représente une part importante dans l’économie des pays.

La crise du logiciel découle en grande partie du fait que le processus de développement de systèmes informatiques n’est pas encore bien maîtrisé. En effet, les tâches composant ce processus sont à la fois complexes et incertaines. Par conséquent, le succès de l'informatisation des organisations passe nécessairement par la réduction de la complexité et des incertitudes inhérentes à ce processus. Notons que la réduction des incertitudes et la réduction de la complexité ont souvent des effets contradictoires. En particulier, l'information obtenue lors de la réduction des incertitudes rend le développement d'un logiciel plus complexe.

Dans cet article, nous étudions le rôle du prototypage rapide ou informatif dans la réduction de l'incertitude inhérente à l'informatisation des processus organisationnels complexes. Afin de mieux maîtriser le prototypage dans le cadre de l’informatisaton des processus organisationnels, nous proposons une démarche en trois étapes. Tout d’abord, il est nécessaire de définir un modèle d’informatisation qui prend en compte d’une part, tous les aspects du logiciel notamment économiques, organisationnels et humains; d’autre part, tous les acteurs concernés par le logiciel au sein de l'organisation, acteurs qui ont des intérêts et des points de vue contradictoires voire conflictuels; et enfin tous les métiers impliqués dans le processus d'informatisation.

La deuxième étape de notre démarche consiste à définir une classification des prototypes basée sur le modèle d’informatisation issu de la première étape. Selon cette classification, un prototype comporte quatre facettes : la portée (processus ou produit), la dimension, l’espace et l’acteur. Ainsi, le prototypage informatif est un instrument de réduction de toutes les incertitudes inhérentes à l’informatisation qu’elles soient liées à la technologie de l’information, au contexte organisationnel ou encore aux acteurs impliqués dans l’informatisation.

La troisième étape de notre démarche propose un cadre générique pour évaluer le prototypage informatif. D’une part, ce cadre permet de déterminer le nombre optimal d’itérations. D’autre part, il assimile le prototypage à une option que les acteurs organisationnels peuvent lever ou non. La levée de l’option d’investir dans le développement d’un prototype informatif est associée à un coût dit "d’opportunité " qui traduit la perte de l’opportunité de choisir le moment d’investir. Ainsi, le cadre d’évaluation du prototypage permet de corriger les faiblesses des approches d'évaluation existantes basées sur la technique de la valeur actualisée nette (VAN).

Pour valider notre démarche, nous l’avons utilisée dans le cadre de l’informatisation du service international d’une compagnie d’assurances. Les leçons de cette expérience et les futurs axes de recherche sont décrits succinctement dans cet article.

Les méthodes, approches, technologies et outils de génie logiciel existants ont contribué jusqu’à un certain degré à l’amélioration de la productivité du développement de logiciels ainsi qu’à la qualité des artefacts logiciels qui en sont issus. Néanmoins, ces améliorations sont insuffisantes pour sortir complètement de la crise du logiciel et minimiser ses impacts négatifs d’ordre économiques et sociaux.

L’analyse des échecs dans la conduite de projets informatiques qui sont intervenus dans les quatre premières ères identifiées par V. Basili and J. Musa, montrent que l’amélioration des processus de développement et de maintenance du logiciel reposent sur deux hypothèses majeures:

1. d’une part, chaque méthode de développement doit intégrer les caractéristiques et les contraintes de l’organisation ainsi que les aspects sociaux et humains des produits logiciels,
1. d’autre part, la réutilisation d’artefacts logiciels est un instrument puissant pour améliorer la productivité du développement.

Ainsi, l’architecture logicielle joue le rôle d’infrastructure du processus de développement puisqu’elle fournit un ensemble d’artefacts logiciels (modèles, composants,...) qui capitalisent l’expérience et le savoir-faire de l’organisation. Par conséquent, le génie logiciel est entré aujourd’hui dans une nouvelle ère, l’ère de l’architecture, caractérisée par la définition d’un produit logiciel comme un assemblage d’artefacts logiciels, en grande partie réutilisables, qui fournissent les services nécessaires à l’organisation et qui peuvent être acquis sur le marché ou développés au sein même de l’organisation. L’architecture logicielle est la condition préalable pour développer des logiciels ouverts, évolutifs et de grande qualité compatibles avec les besoins et les contraintes de l’organisation. De ce fait, l’architecture logicielle doit être prise en compte par les méthodes de développement de logiciels:

• d’une part, en définissant le rôle de l’architecte,
• d’autre part, en décrivant le processus d’élaboration d’une architecture logicielle.

The value obtained from organizations vast investment in information technology is often less than expected, due in large measure to the software crisis. The software crisis has two main ramifications: social and economic. Social ramification of the software crisis is characterized by users resistance, stress and productivity loss. Economic ramification of the software crisis is characterized by software development costs and schedule slippages and maintenance burden. In particular, many software projects are two or three times over their schedule and budget. By another way, delivered systems often fail to meet users needs and are difficult and expensive to change. Many authors stress the fact that requirements deficiencies are among the most important contributors to the software crisis. They point out that approaches and techniques provided by existing software development methods to carry out requirements elicitation and management process are often insufficient. Too often, software systems don’t adequately meet all the stakeholders true requirements. This paper provides an iterative approach based on software prototyping to improve the software requirements elicitation process. This approach is based on a framework which models the stakeholders points of view and interactions.

Despite the economic and functional importance of software systems in modern organizations, activities related to software engineering are still regarded as complex and high-risk activities. The complexity inherent in the software engineering discipline originates from three aspects. On the one hand, the organizations business processes supported by software are complex and continuously evolving. On the other hand, software engineering exists in a larger environment of entire systems involving various technical, economic, human and organizational factors. Finally, software engineering is based on many interdependent processes involving many interacting stakeholders with conflicting interests and points of view. The management of dependencies between stakeholders activities corresponds to the coordination process. This process plays a key role in software engineering notably because of the large use of networks, distributed computing and groupware technology. Nevertheless, coordination activities are neglected by well established methods and tools in software engineering, which stress in particular the technical aspects related to development and maintenance of software systems. In this paper, we propose a framework for studying the foundations and the basic activities of the coordination process. Since the coordination process consists in managing dependencies between software engineering activities, our framework has two major objectives. The first objective consists in identifying the different categories of stakeholders and characterizing their interactions and the dependencies between their activities resulting from these interactions. The second objective is the description of the appropriate coordination activities that can be used to manage these dependencies. This framework is based on the software model proposed by the author. This model rests on three paradigms: the economic agency theory, the transaction costs theory and the software dimension theory. According to the software model, software systems development, maintenance and use take place in four spaces: the operation space associated with the end user business, the problem space associated with the customer business, the solution space associated with the architect business and the construction space associated with the developer business. The software model is used to determine the dependencies between the stakeholders. So, we distinguish two kinds of dependencies: intra-space (vertical) dependencies and inter-spaces (horizontal) dependencies. To manage vertical and horizontal dependencies, we propose a coordination process composed of two layers. The first layer relates to the informal coordination activities while the second layer corresponds to the formal coordination activities which are supported by formal organizational procedures stored in a repository, called the coordination repository. The ISO9001 norm provides examples of procedures that can be used to support formal coordination activities. In our framework, the first layer of the coordination process is supported by a negotiation process. The Win-Win process is an example of such process. The negotiation process consists in eliminating conflicts and discrepancies between producers and consumers of artifacts needed to build a software system. It may use various approaches and techniques like, for example, rapid prototyping, interviews and cost/benefit analyzis. Informal coordination activities constitute generally a preliminary step before formal coordination activities. So, the negotiation process may lead to three possible actions: the use of an existing formal procedure stored in the coordination repository, the customization of an existing formal procedure stored in the coordination repository, or the definition of a new formal procedure.

Consequently, the coordination repository is continuously and repeatedly improved and enriched. In this paper, in addition to the description of the two layers of the coordination process and the structure of the coordination repository, we provide examples of formal coordination procedures. To validate this framework, we use it in a French insurance company to build a workflow system which implements the horizontal (inter-spaces) coordination activities as well as the vertical (intra-space) coordination activities within the solution and construction spaces. This workflow system and the lessons learned from this experience are described in this paper.

A human-centered system is one in which humans, supported by information technology, play a key role. Development and use of human-centered system involve actors, organizational structures, rule, procedures and computerized tools. Actors are humans who perform tasks in order to accomplish various categories of goals related to the business process supported by the human-centered system. Their role is characterized by three types of cooperation. On the one hand, they interact and cooperate among themselves (actor/actor cooperation). On the other hand, they interact and cooperate with the computerized tools (software, hardware, networks) which compose the human-centered system (actor/computerized tool cooperation). Finally, they interact with the organizational context composed of organization's internal and external constraints and priorities. Organizational structures, rules, procedures are instruments which permit actors either to interact among themselves or to cooperate with computerized tools and organizational context. Interactions and cooperation inherent in human-centered processes are either formal or informal. In recent years, many methods, techniques and tools have been proposed to support formal interactions. For example, workflow technology provides instruments to automate well defined sequences of actions performed by humans or machines. In particular, it automates formal procedures associated with actor/actor and actor/computerized tool cooperation. Informal interactions and cooperation either among actors or between actors and computerized tools are sources of various unexpected deviations and inconsistencies. Indeed, most processes governing these informal interactions cannot be completely specified in advance and once for all. A human-centered system inconsistency reflects a state of the software development or use process or a state of a software artifact resulting from this process, and originates from a set of deviations. A wide range of deviations and inconsistencies arise during the development of human-centered systems. Many researchers and practitioners have proven that deviations and inconsistencies are inevitable in particular in complex human-centered systems. Moreover, in such systems, removal of certain inconsistencies can cause others to pop up. By another way, inconsistencies may be useful for focusing on aspects of human-centered systems which need particular attention. Consequently, management of human-centered systems inconsistencies must be integrated in the human-centered systems development and use. We think that to be managed, deviations and inconsistencies must be identified and the issues related to understanding why they occur must be addressed. In this paper, we propose a framework which:

1. describes a typology of deviations and inconsistencies occurring during the human-centered systems development and use,
2. permits understanding the causes of human-centered systems deviations and inconsistencies.

The framework we describe in this paper provides basic instruments to cope with inconsistencies of human-centered systems. In particular, it permits defining methods and tools to manage inconsistencies in compliance with the organization’s constraints, priorities and technical maturity. So, it is compliant with the Simon’s Bounded Rationality Principle. Besides, it is compliant with new software engineering paradigms like distributed software, computer supported cooperative work (CSCW) and software agents.