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.

C’est dans le cadre de ces trois axes de recherche que j’ai poursuivi mes travaux au sein du CERIA à l’université de Paris-Dauphine en collaboration avec des chercheurs appartenant également au monde industriel. Depuis la fin de ma thèse, mes travaux de recherche se sont déroulés de la manière suivante. Dans un premier temps, j’ai défini un cadre général pour mes travaux futurs. Il s’agit d’un modèle générique, dit " modèle global du génie logiciel ", qui complète et précise le cadre proposé dans ma thèse. 

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 " [1] proposee par Claudine Toffolon 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].
• Deux 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 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].
• Deux  publications décrivent les liens entre le méta-processus et les processus décisionnels en génie logiciel, c'est à dire des cadres génériques orientés décision pour mettre en œuvre le méta-processus [19] [20].

[1] C> Toffolon, "The Software  Dimensions Theory",  in 'Enterprise Information Systems", Kluwer Academic Press, J. Filippe Eds., 1999. Résumé

[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] S. Dakhli, C. Toffolon : " Requirements Elicitation Process: An Iterative Approach Based on Software Prototyping", Document de travail, CERIA, Université de Paris-Dauphine, janvier 1999.

[10] S. Dakhli, C. Toffolon: " A Framework for Studying the Coordination Process in Software Engineering ", Document de travail, CERIA, Université de Paris-Dauphine, février 1999.

[11] C. Toffolon, S. Dakhli : " Human-Centered Systems Development and Use Inconsistencies ", Document de travail, CERIA, Université de Paris-Dauphine, mars 1999.

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

[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.

[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.

Salem Dakhli                           Claudine Toffolon

Université Paris-IX Dauphine, CERIA, France

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

Ainsi, le méta-processus en génie logiciel comporte deux aspects: l’évaluation des artefacts logiciels et l’évaluation des processus, méthodes, outils afin de choisir les mieux adéquats pour produire ces artefacts. En effet, plusieurs approches, méthodes ou techniques de développement différentes peuvent potentiellement conduire à la réalisation d’un même logiciel. De même, de nombreuses architectures logicielles et matérielles peuvent potentiellement répondre aux mêmes besoins fonctionnels tout en étant différentes. A ce jour, malgré l’abondance des recherches concernant l’évaluation du logiciel, il n’existe pas d’approche globale prenant en compte tous les aspects du génie logiciel. Les tentatives d’évaluation connues ne constituent que des vues partielles de portée limitée et négligent souvent l’étude de certains aspects, pouvant causer alors des biais dans les résultats et des erreurs d’interprétation. Par conséquent, l’élaboration d’un modèle conceptuel décrivant une approche d’évaluation englobant tous les aspects du génie logiciel, est une condition préalable à toute tentative d’évaluation d’une entité constitutive de ce domaine.

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.

Salem Dakhli                                 Claudine Toffolon

Université Paris-IX Dauphine, CERIA, France

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.

Claudine Toffolon                     Salem Dakhli

Université Paris-IX Dauphine, CERIA, France

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?

Dans ce travail, les auteurs ont distingué quatre espaces, associés à chacun des acteurs du projet: l’architecte, le développeur, l’utilisateur et le client/décideur. Ils ont examiné plus particulièrement les interrelations entre l’espace d’architecture où l’architecte définit la solution informatique d’un problème organisationnel soumis par les décideurs, et l’espace de construction associé au développeur où la solution informatique est implémentée.

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.

Claudine Toffolon                         Salem Dakhli

Université Paris-IX Dauphine, CERIA, France

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 ".

Salem Dakhli                     Claudine Toffolon

Université Paris-IX Dauphine, CERIA, France

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.

Claudine Toffolon                           Salem Dakhli

Université Paris-IX Dauphine, CERIA, France

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.

Le cadre décrit dans ce papier met l’accent sur le fait que les paradigmes, les approches, les méthodes et les outils existants peuvent faciliter la réduction de ces inconsistances s’ils sont intégrés dans un processus global de développement qui:

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.

Claudine Toffolon                            Salem Dakhli

Université de Paris-IX Dauphine, CERIA, France

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?

In this paper, we propose a decision oriented framework to manage software rapid prototyping process, based on a set of metrics and decision rules. To validate this framework, we have used it to manage rapid prototyping activities of many object oriented software development processes in a French insurance company. The results of these experiences are described in this paper.

Claudine Toffolon                                               Salem Dakhli

Paris-Dauphine University, CERIA, France

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.

[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.

Claudine Toffolon                        Salem Dakhli

Université Paris-IX Dauphine, CERIA, France

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.

Claudine Toffolon                                 Salem Dakhli

Paris-Dauphine University, CERIA, France

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.

Claudine Toffolon                                   Salem Dakhli

Université Paris IX-Dauphine, CERIA, France

Le système d’information (S.I.) et sa partie automatisée jouent un rôle à la fois stratégique, tactique et opérationnel dans les organisations, contribuant fortement à leur croissance et leur pérennité. Il constitue un outil de compétitivité, un catalyseur de l’innovation, il crée les conditions favorables à l’amélioration de l’efficacité et de la réactivité de l’organisation tout en favorisant la prise de décision. Ainsi, selon certains spécialistes, les organisations qui auront les meilleurs S.I. domineront l’économie des prochaines décennies. 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. En effet, le développement et la maintenance de produits logiciels sont encore considérés comme des activités à haut risque, et la valeur ajoutée résultant des importants investissements en technologie de l’information est souvent inférieure aux prévisions. Ainsi, depuis les débuts des activités 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 se manifeste à travers les coûts élevés de maintenance logicielle, le nombre important d’échecs de projets informatiques, et les phénomènes de résistance aux changements organisationnels et sociaux déclenchés par l’introduction d’un nouveau logiciel dans l’organisation. Ces effets économiques et sociaux génèrent des coûts supplémentaires pour l’organisation qui amplifient le phénomène de " crise du logiciel ". Certes, les solutions proposées à ce jour pour sortir de la " crise du logiciel " contribuent de façon significative à l’amélioration de la productivité du processus de développement de logiciels et de la qualité des produits qui en sont issus. Néanmoins, ces solutions sont insuffisantes, en partie parce qu’elles privilégient les aspects techniques et ignorent les autres aspects du logiciel. Par ailleurs, ces solutions comportent une confusion entre plusieurs points de vue différents qui reflètent les intérêts parfois conflictuels des différents acteurs de l’organisation concernés par le développement d’un système informatique. En particulier, la confusion ou l’ignorance de ces intérêts et points de vue résultent en premier lieu de faiblesses des méthodes de spécification des besoins. Sortir de la " crise du logiciel ", suppose tout d’abord, l’identification des causes de cette crise, ensuite la définition des instruments logiciels permettant d’agir sur ces causes et d’en limiter les effets et enfin, de mettre en place un processus d’évaluation et d’amélioration continue des solutions proposées. Dans cet article, nous proposons un cadre générique d’informatisation des organisations qui permet de traiter de nombreux aspects importants de la " crise du logiciel ". Ce cadre, dit " modèle des cinq spirales " est basé sur un modèle global du génie logiciel élaboré à l’aide de la théorie économique de l’agence et la théorie des dimensions du logiciel. Le modèle global du génie logiciel que nous proposons permet de prendre en compte tous les aspects du logiciel ainsi que les points de vue et les intérêts des différents acteurs concernés par un projet informatique. Cet article est organisé de la manière suivante. Le premier paragraphe est une introduction qui définit le problème traité dans l’article sur la base d’une analyse de l’existant notamment des ramifications de la " crise du logiciel " et des insuffisances des solutions proposées. Le deuxième paragraphe présente succinctement le modèle global du génie logiciel sur lequel repose notre cadre de travail. Dans le troisième paragraphe, nous décrivons le modèle de processus de production de logiciel, dit " modèle des cinq spirales ", que nous proposons et qui améliore et complète le modèle en spirale de Boehm. Le " modèle des cinq spirales " comporte cinq processus interreliés dont les quatre premiers supportent les métiers des différents acteurs impliqués dans un projet informatique. Ce sont les processus organisationnel, architectural, logiciel, opérationnel et de coordination. Enfin nous concluons l’article dans le quatrième paragraphe en décrivant les principaux enseignements de l’expérimentation de ce processus ainsi que les futures directions de recherche.

Claudine Toffolon                                  Salem Dakhli

Université de Paris-Dauphine, CERIA, France

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.

Claudine Toffolon                               Salem Dakhli

Université de Paris-IX Dauphine, CERIA, France

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.

Seuls quelques auteurs ont mis l’accent simultanément sur ces deux hypothèses en définissant les méthodes de développement nécessaires pour sortir de la crise du logiciel. Par exemple, les auteurs ont d’une part, prouvé que la prise en compte de ces deux hypothèses conduit à distinguer les métiers du client/organisateur, de l’utilisateur final, de l’architecte et du développeur et d’autre part, défini quatre espaces associés respectivement à chacun de ces métiers: l’espace des problèmes associé au métier du client/organisateur, l’espace d’opération associé au métier de l’utilisateur final, l’espace des solutions associé au métier de l’architecte et l’espace de construction associé au métier du développeur. En particulier, le rôle de l’architecte consiste à définir, dans l’espace des solutions, la solution logicielle du problème du client/organisateur alors que le rôle du développeur est d’implémenter cette solution dans l’espace de construction.

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.

La réutilisation d’artefacts logiciels dans le cadre de la définition de l’architecture d’un produit logiciel est la source de plusieurs coûts: les coûts de recherche, les coûts de customisation, les coûts de maintenance, les coûts de gestion de configuration. Ainsi, l’élaboration efficace d’une architecture logicielle repose sur la définition et l’organisation d’un référentiel d’architecture afin de minimiser les coûts listés ci-dessus. L’objet de cet article est d’une part, de proposer une définition rigoureuse de l’architecture logicielle, d’autre part de décrire son rôle et ses motivations et enfin, de proposer un modèle global d’architecture, dit " modèle de l’échelle " qui facilite la construction et l’utilisation efficace du référentiel architectural de l’organisation. Le modèle générique décrit dans cet article fournit les éléments de base nécessaires pour la définition d’un langage d’architecture qui permet aux développeurs d’éviter les interprétations erronées et qui facilite la réutilisation d’artefacts logiciels. Ce modèle générique a été utilisé pour organiser l’ensemble des artefacts réutilisables acquis sur le marché par une compagnie française d’assurance, et pour définir une politique de réutilisation au sein de cette compagnie. En particulier, le " modèle de l’échelle " a été utilisé pour élaborer un modèle organisationnel pour la maintenance et la gestion de configuration des artefacts logiciels réutilisables nécessaire pour établir le lien entre le référentiel architectural et les projets informatiques.

Claudine Toffolon (1)                                           Salem Dakhli (2)

(1) Littoral University, LIL, France

(2) Paris-Dauphine University, CERIA, France

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.

Claudine Toffolon                                       Salem Dakhli

Paris-Dauphine University, CERIA, France

Abstract

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.

Claudine Toffolon (1)                             Salem   Dakhli (2)

(1) Littoral University, LIL France

(2)Paris-Dauphine University, CERIA, France

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.

In particular, we use the Z formal specification language to describe the typology of deviations and inconsistencies provided by this work. To be complete, the human-centered systems deviations and inconsistencies description and analysis must take into account firstly, the conflicting interests and points of views of all the organizational actors involved in human-centered systems development and use, and secondly all the aspects of software engineering. Therefore, our framework rests on a global model of software built using the economic agency theory, the transactions costs theory and the software dimensions theory.