nouveaux regards sur les mÃ©thodologies d'analyse, de

Systèmes d'Information et Management

Volume 3 | Issue 2 Article 1

1998

Nouveaux regards sur les méthodologies d'analyse,de conception et de programmation informatiquesFrédéric AdamUniversity College Cork, Ireland, [email protected]

Brian FitzgeraldUniversity College Cork, Ireland, [email protected]

Follow this and additional works at: http://aisel.aisnet.org/sim

This material is brought to you by the Journals at AIS Electronic Library (AISeL). It has been accepted for inclusion in Systèmes d'Information etManagement by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contact [email protected].

Recommended CitationAdam, Frédéric and Fitzgerald, Brian (1998) "Nouveaux regards sur les méthodologies d'analyse, de conception et de programmationinformatiques," Systèmes d'Information et Management: Vol. 3 : Iss. 2 , Article 1.Available at: http://aisel.aisnet.org/sim/vol3/iss2/1

http://aisel.aisnet.org/sim?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss2%2F1&utm_medium=PDF&utm_campaign=PDFCoverPages

http://aisel.aisnet.org/sim/vol3?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss2%2F1&utm_medium=PDF&utm_campaign=PDFCoverPages

http://aisel.aisnet.org/sim/vol3/iss2?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss2%2F1&utm_medium=PDF&utm_campaign=PDFCoverPages

http://aisel.aisnet.org/sim/vol3/iss2/1?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss2%2F1&utm_medium=PDF&utm_campaign=PDFCoverPages

http://aisel.aisnet.org/sim?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss2%2F1&utm_medium=PDF&utm_campaign=PDFCoverPages

http://aisel.aisnet.org/sim/vol3/iss2/1?utm_source=aisel.aisnet.org%2Fsim%2Fvol3%2Fiss2%2F1&utm_medium=PDF&utm_campaign=PDFCoverPages

mailto:[email protected]%3E

ARTICLES DÉ RE^HÈR.CHE

Nouveaux regardssur les méthodologies d'analyse,

de conceptionet de programmation

informatiques

Frédéric ADAM et Brian FITZGERALDEnseignants en informatique de gestion - University College Cork, Ireland

RÉSUMÉ

Un examen critique des théories dominantes dans le domaine de la concep-tion et de la programmation des systèmes informatiques révèle que la plupartdes outils, des techniques et des méthodologies qui sont utilisés dans ce do-maine sont fondés sur des concepts qui datent de la période 1967 / 1977.Les cycles de vie de type "cascade" (System Development L fe Cycle ouSDLC), le prototypage, la décomposition algorithmique, le masquage d'informa-tion, et les techniques d'analyse structurée telles que les diagrammes de-fluxde données (Data Flow Diagrams ou DFD) et les diagrammes d'entité-relation(Entity Relationship Diagrams ou ERD) datent tous de cette période.L'approche orientée objets elle-même trouve ses origines dans cette période.

Cet article présente un certain nombre d'arguments qui militent en faveurd'une révolution dans le domaine de la réalisation de projets informatiques etde la création de nouvelles méthodologies mieux adaptées aux besoins ac-tuels. Nous basant sur une série d'interviews d'informaticiens expérimentés etsur une enquête postale, nous présentons des observations qui révèlent leprofil très différent des projets informatiques actuels par rapport à ceux quifurent caractéristiques de la période 67 / 77. Finalement, nous tentons d'ex-pliquer pourquoi tant la recherche que la pratique n'ont pas avancé aussi vitequ'elles auraient dû dans le domaine de l'informatique.

Mots-clés : Méthodes de développement de systèmes, Rapid ApplicationDesign, Profil des développements informatiques actuels.

N'2 - Vol. 3- 1998 51

Adam and Fitzgerald: Nouveaux regards sur les méthodologies d'analyse, de conception e

Published by AIS Electronic Library (AISeL), 1998

SYSTEMES D'INFORMATION ET MANAGEMENT

ABSTRACT

A critical examination of currently accepted theories in the systems analysisand design area reveals that the great majority of tools and techniques used

for the development of information systems have emerged in the 1967 / 1977decade. The numerous Systems Development Life Cycles (SDLCs) in existence,prototyping, algorithmic decomposition, data hiding and structured analysistechniques such as Data Flow Diagrams and Entity Relationship diagrams alloriginated in this period. Even the Object Oriented approach can be tracedback to this golden decade".

This article presents a number of arguments in favour of a revolution in thedevelopment of information systems and pointing to the need for the creationof new development methodologies more suited to the current needs of organi-sations. Based on a series of interviews with experienced systems developersand a postal survey of Irish organisations, we show how the profile oftoday's IS projects is now radically dWerent from the projects of the 67 / 77period. Finally, we endeavour to explain why both practice and researchhave not progressed as fast as they should have in the IS area.

Key-words : IS development methods. Rapid application design, Profile oftoday's IS projects.

62

Systèmes d'Information et Management, Vol. 3 [1998], Iss. 2, Art. 1

http://aisel.aisnet.org/sim/vol3/iss2/1

NOUVEAUX REGARDS SUR LES METHODOLOGIES D'ANALYSE

1. INTRODUCTION

Se basant sur un certain nom-bre d'observations qui montrentque l'industrie du logiciel subitune crise (caracterisée pas lachute des prix du matériel infor-matique et l'impossiblité de ré-pondre à la demande en applica-tions), Cox (1990) a envisagé lanécessité d'une "révolution indus-trielle" dans la conception et laréalisation des systèmes informati-ques et la création de nouvellesapproches mieux adaptées auxbesoins de notre environnementen mutation permanente. Deuxarguments permettent de mieuxcibler ce débat. Premièrement, ilest remarquable que la plupartdes méthodologies et des techni-ques de développement informati-ques disponibles à l'heure actuellesont basées sur des conceptsmaintenant anciens. Deuxième-ment, il est évident que le profildes projets informatiques avec les-quels les informaticiens sont auxprises a évolué de façon particu-lièrement radicale au cours des10 dernières années et que l'envi-ronnement industriel et commer-cial dans lequel ces projets se dé-roulent a lui aussi beaucoupchangé.

Cet article retrace les originesdes concepts sur lesquels sontfondées les méthodologies ac-tuelles et les replace dans leurcontexte historique. Parce quel'approche orientée objets a étéidentifiée par plusieurs auteurscomme le prochain paradigmepour le développement des sys-tèmes informatiques (une analyseque nous ne partageons pas for-cément), une attention particulièrelui est accordée. Nous sommesainsi amenés à nous demanderdans quelle mesure l'approcheorientée objets est une révolution

ou une simple évolution des mé-thodes existantes. Dans la sectionsuivante, l'article présente une sé-rie d'observations qui illustrent leprofil des projets informatiquesd'aujourd'hui sur la base d'uneenquête postale et de 21 inter-views plus qualitatives avec desinformaticiens expérimentés con-duites par l'un des auteurs dansdix entreprises différentes. Finale-ment, l'article tente d'expliquerpourquoi, tant la théorie que lapratique sont décalées par rapportà cette réalité du développementinformatique et offre des sugges-tions pour la création de métho-dologies futures.

2. REGARDS HISTORIQUESSUR L 'ANALYSEET LA CONCEPTIONDES SYSTÈMESINFORMATIQUES

La plupart des méthodologies deconception et de programmation(Systems Development Methods ouSDM) utilisées à l'heure actuelledans la réalisation des projets in-formatiques ont leur origine dansdes concepts qui ont émergé aucours de la décennie 67 / 77. Parexemple, les cycles de vie des pro-jets de développement (SDLC) quitrouvent leur origine dans la théo-rie générale des systèmes des an-nées 30 (Enger, 1981) ont été in-troduits à cette période dans lagestion des projets informatiques(Royce, 1970). Ces SDLC furent àleur tour à la base de la plupartdes méthodes (Davis et al., 1988 ;Orr, 1989) et ont été décritscomme étant la caractéristique es-sentielle de tous les projets de dé-veloppement informatique (Ahituvet al., 1984). De même, le prototy-page fut utilisé par un nombregrandissant de développeurs de

73




systèmes pendant cette périodepour éviter les problèmes inhé-rents aux traditionnels SDLC en"cascade" (Agresti, 1986 ). Le pro-totypage fait maintenant partie in-tégrante de nombreuses méthodo-logies commerciales de développe-ment (Boehm, 1988, Downs et al.,1992).

En ce qui concerne l'approchestructurée , qui a été décritecomme étant la plus fréquemmentutilisée en Amérique du Nord eten Europe (Yourdon , 1991), leconcept de masquage d'informa-tion , qui stipule que chaque mo-dule doit représenter un proces-sus et un seul et doit révéler aus-si peu que possible les donnéesqu'il utilise (Parnas, 1972), leconcept de décomposition algo-rithmique , c'est-à -dire la divisionprogressive des fonctions pri-maires d'un logiciel en sous-fonc-tions jusqu 'au niveau le plus élé-mentaire , et les concepts de cohé-sion et de couplage ont tousémergé pendant cette période (DeMarco , 1978 ; Stevens, Myers etConstantine , 1974). La méthodeMerise qui est la plus utilisée enFrance est apparue juste à la finde la période considérée puis-qu'elle a été lancée en 1977 parle ministère de l'Industrie (Avisonet Fitzgerald , 1995 ). De plus, laplupart des techniques de repré-sentation qui se retrouvent danstoutes les méthodologies, les dia-grammes d'entité-relation (Chen,1976 ), diagrammes de flux dedonnées et les dictionnaires dedonnées (De Marco, 1978 ) datentaussi de la période 67 / 77.

SSADM (Structured SystemsAnalysis and Design Method) quiest la méthodologie la plus uti-lisée * en Grande Bretagne eten Irlande a ses antécédents dansla méthode MODUS utilisée entre1965 et 1977 , tandis que l'ap-

proche de Jackson (JSP ouJackson System Programming) estfondée sur le principe de Bohm etJacopini ( 1966).

Dans des travaux plus récents,certains auteurs ont affirmé quel'approche orientée objets repré-sente un nouveau paradigme pourle développement des systèmes(Thomann, 1994 ), et, en effet,l'approche 00 a pris une grosseimportance en informatique. Iln'en reste pas moins que le con-cept d'OO n'est pas aussi révolu-tionnaire qu'il y paraît . Il sembleque dans beaucoup de cas, lesméthodologies dites 00 ne sontque des évolutions de méthodolo-gies existantes ayant elles aussileur origine dans les années 60.Pour être tout à fait précis, l'ap-proche orientée objets a ses ori-gines dans le langage de program-mation Simula qui fut utilisé enNorvège à partir de 1967. Avantcela, certains principes orientésobjets tels que l'encapsulation ontété utilisés dans la conception dumissile Minuteman dès la fin desannées cinquante (Dyke et Kunz,1989).

Ainsi, bien que l'intérêt de laprofession informatique pour l'ap-proche orientée objets soit bienréel et que les prédictions les plusoptimistes aient été faites concer-nant la rapidité d'adoption de cesméthodes par les informaticiens(Topper , 1992 ), on peut s'interro-ger sur le caractère révolution-naire de l'approche orientée ob-jets. L'encapsulation , qui permetd'enrober des données et des pro-grammes dans un objet est trèssemblable au concept de mas-quage d'information (Parnas,1972 ). De même, la communica-tion entre objets s'effectue sousforme de messages qui passentd'un objet à un autre pour dé-clencher l'exécution d'une procé-

84




dure. Ce mécanisme rappelle leprincipe de couplage. En fait, stirla trentaine de méthodologiesorientées objets qui ont été docu-mentées (Firesmith, 1993), beau-coup sont simplement des évolu-tions d'anciennes méthodes bienconnues.

Néanmoins, certains auteurs ontaffirmé que l'approche 00 estprobablement l'approche la plusappropriée pour le développementdes systèmes informatiques futursétant donné les besoins des nou-velles formes organisationnelles(Bessagnet et al., 1994). Il semblequ'il y a des avantages certains àappliquer l'approche 00 dans cesnouveaux contextes. En particu-lier, il a été suggéré que l'ap-proche 00 s'applique naturelle-ment aux éléments du monde réelgrâce à son pouvoir de modélisa-tion et aux possibilités de réutili-sation des programmes qu'ellepermet.

La réalité de l'utilisation des ap-proches 00 est cependant loin decorrespondre au volume des pu-blications consacrées à cette ap-proche. La plupart des rechercheset développements dans le do-maine 00 ont été effectués en de-hors du cadre des développementsInformatiques commerciaux dontles entreprises ont besoin etl'application de l'approche 00 àde vrais projets informatiquescommerciaux semble bien problé-matique. L'étude de Firesmith(1992) qui portait sur 23 projetsutilisant un langage de program-mation 00 a conclu qu'aucunprojet n'avait pu bénéficier totale-ment des avantages supposésd'OO. En guise de conclusion,Firesmith (1992) propose un nom-bre de conseils pratiques pour ai-der les entreprises à appliquer lesprincipes d'OO, mais il préciseaussi que les bénéfices ne seront

visibles qu'après plusieurs projetset qu'en fin de compte, les pro-blèmes de gestion des projets sontplus importants que les problèmestechniques.

Ainsi, en dépit du potentiel desapproches 00, on peut se deman-der si les avantages procurés parl'approche 00 seront un jour à lahauteur des prédictions faitesdans les revues scientifiques.

3. LE DÉVELOPPEMENTINFORMATIQUEDANS LES ANNÉES 90

Les sections précédentes de cetarticle ont Indiqué que la plupartdes méthodes de développementutilisées à l'heure actuelle, y com-pris les méthodes 00 qui sontpourtant présentées comme nou-velles, sont fondées sur des con-cepts étant apparus entre 1967 et1977. Pour achever de montrer lanécessité de changements radi-caux dans le domaine du dévelop-pement des systèmes informati-ques, il nous reste à décrire lesprofondes différences qui existententre l'environnement dans lequelles systèmes informatiques d'au-jourd'hui sont développés et l'envi-ronnement des années 67 à 77.Nous tentons de montrer ces dif-férences en nous fondant sur despublications récentes, sur uneétude statistique et sur une séried'interviews conduites par l'un desauteurs (Fitzgerald 1994, 1996,1997). Les questions qui sontsoulevées dans les sections sui-vantes sont liées à la nature évo-lutive du monde des entreprises,la nature changeante des con-textes organisationnels dans les-quels les systèmes informatiquessont développés et à l'existence defortes pressions pour des dévelop-

95



SYSTEMES DINFORMATION ET MANAGEMENT

pements de plus en plus rapides(comme en témoigne l'apparitiondu concept de Rapid ApplicationDevelopment ou RAD).

3.1. L'Univers commercialdu développementinformatique

Les entreprises d'aujourd'huidoivent faire face à un environne-ment qui évolue de plus en plusvite ; phénomène qui a étéconstaté par de nombreux au-teurs. Rockart et De Long (1988)ont fait référence au "métabolismeaccéléré du commerce d'aujour-d'hui" qui requiert que les entre-prises réagissent plus efficacementet plus rapidement. Baskerville etal. (1992) ont aussi insisté sur lesconséquences des modificationsdu monde actuel sur le développe-ment des systèmes. Ils indiquentque les méthodes de développe-ment structurées sont tournéesvers des projets de développementde grande taille et de longue du-rée, ce qui n'aide pas les entre-prises à résoudre efficacement lesproblèmes posés par l'évolutionrapide des marchés et des pro-duits. Cela pousse les entreprisesà se tourner vers des solutions deplus en plus de court terme.Dans cette situation, il n'est plusni rentable ni même possible desuivre les étapes formelles desméthodes de développement desystèmes 'en cascade. Baskervilleet al. (1992) sont allés plus loinet ont affirmé que l'utilisation desméthodes traditionnelles est deve-nue un frein à la résolution ra-pide des problèmes informatiquesdes entreprises. Ainsi, les dévelop-peurs ne peuvent plus se permet-tre d'appliquer patiemment lesvieilles méthodes et en sont ré-duits à choisir entre ce qu'ils ont

le temps de faire et ce qui doitêtre abandonné (Brown, 1985).

3.2. Stratégies de remplaoementpour le développementde systèmes

Cette évolution de l'environne-ment commercial pousse les en-treprises à rechercher des straté-gies de remplacement pour faireface à leurs besoins en systèmesinformatiques. Bansler et Havn(1994) ont Identifié -une nouvelletendance dans l'industrie du logi-ciel. Il semble que les entreprisescomptent de moins en moins surleurs services informatiques in-ternes pour le développement desystèmes et achètent en contre-partie des logiciels clef en mainou utilisent l'outsourcing commestratégie de remplacement. Ils ontappelé cette tendance "l'industria-lisation du développement infor-matique" et ont suggéré que lamême mutation a déjà eu lieudans d'autres branches plus an-ciennes de l'ingénierie. Bansler etHavn (1994) ont aussi décrit lesconséquences pratiques de cettemutation de l'industrie du logiciel.Par exemple, de nombreux utilisa-teurs assemblent leurs systèmessur la base de modules disponi-bles sur le marché et les intègrentavec des morceaux de logiciel dé-veloppés spécialement pour res-pecter les particularités et habi-tudes de l'entreprise. Bien enten-du, les SDM traditionnelles nesont d'aucun secours pour la ges-tion et l'organisation de ces nou-veaux processus de création desystèmes et leur application à detels exercices informatiques en estainsi d'autant plus difficile etdangereuse. Dans l'état de nosconnaissances, il semble queseule l'étude de Nilsson (1990) sesoit penchée sur les problèmes

106




méthodologiques posés par ce typede projets informatiques. En l'ab-sence de méthode(s) rigoureuse(s)pour la conduite de tels projets,les entreprises désireuses d'acqué-rir des systèmes existants doiventinventer des processus de selec-tion et d'adaptation pour augmen-ter leurs chances de succès ;exercice difficile et risqué commel'ont prouvé certains exemples no-toires (cf. SNCF et son système deréservation SOCRATE décritdans Adam et Cahen, 1997).

3.3. Etude empiriquedu nouveau profildes projets informatiques

Pour confirmer les tendancesqui sont décrites dans les sections3.1 et 3.2 et en rendre compte defaçon plus précise, une approcheplus empirique est cependant né-cessaire. Dans cette section, nousprésentons donc les résultatsd'une enquête récente de l'indus-trie du logiciel qui illustrent leprofil des développements infor-matiques actuels et montrent àquel point le profil du projet typi-que s'est modifié. Un question-naire fut envoyé à 776 informati-ciens (du programmeur au direc-teur informatique) dans autantd'entreprises irlandaises. Sur letotal des 186 réponses reçues,162 purent être utilisées dansl'analyse qui suit, ce qui donneun taux de réponse global de24 %. Un tel taux de réponse estsimilaire à ceux obtenus dansd'autres enquêtes postales surl'utilisation des méthodes dedéveloppement de systèmes auRoyaume-Uni (Hardy, Thompsonet Edwards ont obtenu 20 % et29 % dans leurs études en 1995)et aux Etats-Unis (Mahmood aobtenu 18 % en 1987 et Palvia etNosek ont obtenu 22 % en 1993).

Le tableau 1 donne une indica-tion des caractéristiques des orga-nisations qui forment notreéchantillon. Il s'avère que la plu-part des organisations étudiéescomptaient entre 100 et 1 000employés (43 %) et avaient unservice informatique de petitetaille - soit de 1 à 5 persones(44 %). Ces statistiques nous per-mettent de conclure qu'unegrande proportion de ces organi-sations de taille moyenne étaientpourvues de services informati-ques restreints. En effet, ces chif-fres sont nettement en dessousde ceux rapportés par des étudesprécédentes comme celle deSumner et Sitek (1986). Ils sonten revanche en accord avecl'étude de Friedman (1989) qui aidentifié une diminution de lataille des départements informati-ques au cours des années 80.Friedman en avait conclu quecette évolution était due à une dé-centralisation des informaticiensdans les autres services et au re-cours grandissant à l'outsourcing.Il est à noter que cinquante desentreprises étudiées (31 %) étaientdes sociétés de conseil en infor-matique ou des SSII.

Le tableau 2 présente les résul-tats de l'étude qui concernent leniveau d'expertise des répondantset le profil des projets Informati-ques sur lesquels ils travaillentcouramment. Il est à noter que leniveau d'expérience des dévelop-peurs ayant accepté de participerà l'étude (plus de 15 ans enmoyenne) est assez élevé pourconférer une validité suffisanteaux résultats obtenus.

Le tableau 2 montre, entre au-tres, le haut niveau d'utilisationdes logiciels clef en main (environ40 %) et le niveau significatifdooutsourcing (environ 13 %). Surla base de ces chiffres, on peut

117



SYSTEMES D INFORMATION ET MANAGEMENT

Industrie% (n)

Nombre totald'employés % (n)

Nombre d'employésService info. % (n)

Consultant / SSII 31 % (50) 1 à 10 12% (19) 1 à 5 44% (71)

Secteur public / 7% (11) 10 à 100 29% (47) 5 à 20 30% (49)Education

Ent. industrielle / 36 % (58) 100 à 1000 43% (70) 20 à 100 19% (31)Distribution

Grossiste / 4% (7) 1 000 à 5000 9 % (15) > 100 7% (10)Détaillant

Finance / 12 % (19) > 5 000 7% (11)Assurance

Service / 6% (10)Communication

Autres 4% (7)

Tableau 1 : Profil démographique des organisations étudiées

Experience des répondants (en nombre d'années)

Profil des développements :% développements internes% développement "outsourcé"% utilisation de logiciels "clef en main"

Profil des projets informatiques :Nombre de développeursDurée (en mois)

Hardware utiliséMainframeMiniPCCombinaison / Autres

Pourcentage ou Moyenne

15,07

471340

3,55,7

%20%26%33%21 %

Tableau 2 : Profil des développements informatiques actuels

conclure que le développement in-terne n'est plus aussi importantque par le passé pour un grandnombre d'entreprises. De même, lefait qu'un projet Informatique ty-pique rassemble une équipe detrois ou quatre développeurs etdure moins de six mois montre leprofil très différent des projets

actuels - plus courts et plus ra-pides - qui contraste avec les ré-sultats d'études précédentescomme celle de Jenkins et al.(1984) par exemple. Les diffé-rences que nous avons relevéesavec l'étude de Jenkins sont im-portantes parce que cette étudedate du début des années 80

128




(c'est l'une des plus anciennes dece type) et parce qu'elle est recon-nue comme l'une des plus cou-ramment citée par les auteursdans ce domaine.

On peut s'interroger sur les rai-sons de cette rapide évolution etse demander si cette fragmenta-tion des projets ne reflète pas uneadhérence plus stricte aux prin-cipes de base des méthodologiestraditionnelles, en l'occurrence "di-viser pour mieux régner" ("divideand conquer"). Cela semble entout cas indiquer une approcheplus réaliste de la part des chefsde projet qui sont conscients queles gros investissements et laprise de risques inconsidérés nesont plus de mise. Un autre ré-sultat notable de cette étudeconcerne la plate-forme la plusutilisée pour les développementsinformatiques : la plupart desprojets étudiés étaient des appli-cations destinées à opérer sur desPC ; plate-forme réservée jusqu'icià de petits logiciels génériques

(feuille de calcul, traitement detexte, etc.).

L'étude indique également que60 % des participants n'utilisentpas de méthode de développementidentifiable. La raison la plus fré-quente de cette non-utilisation desméthodes existantes vient de laperception des développeurs del'inadéquation de ces méthodes autype de développement informati-que dont leurs entreprises ont be-soin.

Le tableau 3 indique le détaildes résultats de notre étude quiconcernent le degré d'utilisationréel des méthodologies tradition-nelles dans les entreprises étu-diées. La colonne de gauche con-firme que 60 % des répondantsn'utilisent aucune SDM. Les 40 %restants appliquent une SDM à lalettre (14 %) ou sous une formemodifiée en fonction de leurs be-soins (12 %) ou encore utilisentune méthode tout à fait person-nelle (14 %).

Totaln'utilisantaucune SDM

Totalutilisantune SDM

Parmi ceux qui utilisent une SDM

60%(97) 40%(65) Utilisent Utilisent Utilisentune SDM une SDM basée une SDMcommerciale ) sur une SDM personnelle

commerciale

14%(23) 12%(20) 14%(22)

SSADM (8) SSADM (9)IE (6) IE (3)Oracle (4) etc.Method 1 (3)OMT (2)LSDM (1)STEP (1)STRADIS (1)Progen (1)

1 (n = 23, mais certains répondants ont donné plus d'une réponse).

Tableau 3 : Degré d'utilisation réel des méthodologiestraditionnelles

13

9




Ces résultats indiquent que rela-tivement peu d'entreprises irlan-daises utilisent les méthodologiescommerciales habituelles. Les chif-fres que nous avons obtenus(14 % des entreprises appliquentà la lettre une méthode connue)sont en effet très inférieurs àceux rapportés dans des étudesprécédentes. Par exemple, l'étudede Jenkins et al. (1984) qui sertsouvent de référence en la matièrementionne des taux d'utilisationde SDM de l'ordre de 85 %, maisune étude Irlandaise qui date de1992 avait déjà mesuré un tauxde 38 % (O'Duffy, 1992). On peutdonc se demander s'il existe unedifférence fondamentale entre lestaux d'utilisation des SDM auxEtats-Unis (étude de Jenkins), enEurope et plus particulièrementen Irlande. Notre étude ne permetpas de conclure sur ce point et ilserait intéressant d'étendre l'étudedes taux d'utilisation à d'autrespays d'Europe afin de mesurer leseffets d'éventuelles "préférencesnationales".

L'une des nouveautés de notreétude consistait donc à s'intéres-ser plus spécialement aux entre-prises qui utilisent des SDM mo-difiées. Parmi celles-ci nous avonsrelevé une certaine confusion dela part des répondants qui ontavancé des noms de méthodes quinous étaient totalement inconnusou qui ne pouvaient être considé-rés comme des SDM à propre-ment parler. Un certain nombrede répondants ont même cité ISO9000 comme la base de leur mé-thode interne, ce qui laisse à pen-ser qu'un petit nombre d'informa-ticiens ne sont pas très sûrs dece qu'une méthodologie de déve-loppement représente.

Nous avons utilisé les résultatsprésentés dans le tableau 3 pour

contraster le degré d'usage queles entreprises étudiées font desoutils et des techniques normale-ment associés avec les méthodolo-gies traditionnelles. Les répon-dants devaient ainsi indiquer s'ilsutilisaient couramment le prototy-page, les diagrammes de flux dedonnées ou d'autres techniquestrès connues (voir tableau 4). Par-mi ces derniers, le prototypage,les diagrammes de flux de don-nées, les dictionnnaires de don-nées et les diagrammes d'entité-relation sont les plus populaires àla fois dans les entreprises utili-sant une SDM et dans celles quin'en utilisent pas. Le résultat leplus remarquable réside dans lefait que les entreprises qui sui-vent une SDM s'avèrent faire unusage bien plus important detous les outils et techniques pro-posés. Cela semble confirmer queles SDM aident effectivement lesinformaticiens à coordonner leurutilisation des outils et techniquestraditionnels.

Ces résultats sont à compareravec ceux du tableau 5 qui indi-que la proportion de l'effort de dé-veloppement que les développeursallouent à chacune des phases etactivités qui composent les projetsInformatiques. Comme dans le ta-bleau précédent, ces résultatssont contrastés en fonction del'utilisation (ou non) d'une SDM.

Les résultats présentés dans letableau 5 indiquent clairementque l'apport des SDM n'apparaîtpas être aussi marqué que pourl'utilisation des outils et techni-ques traditionnels (résultats dutableau 4). En fait, c'est plutot lecontraire : la différence entre lesentreprises utilisant une SDM etcelles qui n'en utilisent pas n'estpas significative statistiquementparlant. Même s'il semble que,

1410




Entreprises utilisantune SDM

Entreprises n'utilisantpas de SDM

OutilsITechniquesJoint Application Design (JAD) 31 % 20 %

Prototypage 75 % 57 %Diagramme de flux de données 71 % 37 %

Diagramme d'entité -relation 63% 19 %Diagramme de changement d'état 19 % 6%

Ordinogramme 55 % 35 %Dictionnaire de données 74 % 34 %

Process Mini-Specifications 40 % 25 %Structured Walkthrough 48 % 23 %

Autre 9% 5%

Tableau 4 : Usage des outils et techniques traditionnelsen fonction de l'utilisation (ou non) d'une SDM

Temps de développementmoyen alloué

dans les entreprisesutilisant une SDM

Temps de développementmoyen alloué

dans les entreprisesn'utilisant pas de SDM

ActivitéPlanification 10% 10%

Analyse 17% 14%Design 15 % 12 %

Programmation 28% 31 %Test 17% 17%

Installation 8% 10 %Evaluation 3% 4%

Autre 2% 1 %

Note : Ces résultats ont été obtenus en faisant la moyenne des pourcentages queles participants à l'étude ont eux-mêmes déclaré avoir alloué à chaque activité.

Tableau 5 : Allocation de l'effort de développemententre les différentes phases dans les entreprises

utilisant (ou non) une SDM

dans les entreprises qui utilisentune SDM, plus de temps est al-loué aux phases d'analyse et dedesign, les variations sont mi-nimes. Cela nous conduit à nousdemander si les méthodologiestraditionnelles aident vraiment lesdéveloppeurs à se concentrer surles phases importantes commecela a été suggéré (Ahituv et al.,1984, Baskerville et al., 1992).

Certains auteurs ont affirmé quel'ignorance relative des informati-ciens en entreprise était l'obstaclele plus important à une utilisationplus complète des SDM (Ward,1991). Cette hypothèse n'a cepen-dant pas été vérifiée dans le voletde cette étude réalisée par l'undes auteurs sur la base d'inter-views avec des informaticiens ex-périmentés dans plusieurs entre-

1511




prises (Fitzgerald, 1994). En fait,même les participants qui n'utili-saient pas formellement de SDMavaient une connaissance utilisa-ble de plusieurs méthodes etavaient une certaine expérience del'utilisation des méthodes commer-ciales les plus connues. C'étaitdonc par choix qu'ils n'utilisaientaucune méthode, choix motivé parla nécessité de rester flexible etde développer leurs systèmes rapi-dement. Ainsi, les SDM sont per-çues comme potentiellement béné-fiques pour la documentation etl'application des règles et desstandards, mais ces avantages nesuffisent pas à contrebalancer lesproblèmes (et les coûts) liés à l'al-longement de la durée des projets.

Un des participants à l'étude asuggéré qu'une approche contin-gente était plus efficace pour ledéveloppement de systèmes infor-matiques. Selon lui, la majoritédu travail de développements'effectue "dans la tête des ana-lystes programmeurs" où émergenttoutes les solutions aux problèmesqui se posent. La tâche la plusimportante consiste donc à com-muniquer ces solutions entre col-lègues. -Ce participant ajouta qu'ilexiste de telles différences decompétence et de créativité entreles programmeurs qu'il est néces-saire de distribuer les tâches ausein de l'équipe en fonction despossibilités de chacun et d'adapterla communication des spéci-fications du système aux diffé-rents individus (le degré de forma-lisation des spécifications parexemple).

Ce type d'approche a été appelé"quick-and-dirty" (à la va vite)par certains auteurs (Guimaraes,1985), mais cela ne correspondpas nécessairement à la réalité deces méthodes spontanées et non-formulées qui s'avèrent parfois

très efficaces comme nous l'avonsconstaté au cours d'interviewsavec des développeurs. Dans unedes entreprises étudiée, nousavons trouvé un excellent travaild'équipe fondé sur l'utilisation detechnologies de communicationtelles qu'E-mail et Lotus Notes. Ceprocessus était très dynamique etdifférents programmeurs assu-maient le rôle de leader à diffé-rents stades du projet. Il seraitdonc intéressant d'étudier com-ment les développeurs de sys-tèmes pourraient bénéficier del'application des nouvelles techno-logies de communication. Cette di-rection de recherche a déjà étéidentifiée par Larrasquet et Clare(1996). En conclusion, il faut in-sister sur le fait que, dans la plu-part des cas, les informaticiensont rejeté les méthodes existantespour des raisons basées sur leurexpérience et non par ignorance.Il s'avère donc que leur expérienceet leur connaissance des réalitésdu développement informatiquesont des atouts aussi importantspour le succès des projets Infor-matiques que la bonne utilisationd'une méthode quelconque.

3.4. Comment accélérerle processusde développementdes applications ?

On peut donc en conclure queles développeurs de systèmes in-formatiques en entreprises sonten permanence à la recherche desolutions à même d'augmenter laproductivité des activités de déve-loppement, qu'il s'agisse de laphase d'analyse, de la phase dedesign ou de l'implantation. Cetterecherche est partagée par les au-teurs qui s'intéressent au dévelop-pement rapide des systèmes (Ra-

1612




pid Application Development ouRAD). Folkes et Stubenvoll (1992)affirment que les besoins des en-treprises nécessitent une accéléra-tion des processus de développe-ment . D'autres auteurs ont mêmeestimé que la productivité des dé-veloppeurs de systèmes informati-ques devrait être multipliée par10 pour véritablement servir lesbesoins des entreprises (Verity,1987). Hough ( 1993 ) s'est joint àceux qui dénoncent la faiblesse dela philosophie des approches mo-nolithiques de longue haleine :

Dans le passé, cette philosophiea engendré des processus de dé-veloppement informatique trèslongs et rigides qui se sont tra-duits par du software qui étaittout sauf "soft". La plupart desapplications sont développéessous la conduite d'approchesmonolithiques alors que les be-soins des entreprises sont évolu-tifs et changent rapidement(').

Hough (1993) cite les résultatsd'une étude menée par IBM qui aétudié les problèmes qui seposent quand des méthodologies"monolithiques" sont utilisées.Ceux-ci incluent : un ralentisse-ment du processus de développe-ment, pour les programmeurs unetendance à faire durer les projetspendant des années et à en faireune carrière, un certain degréd'ignorance des problèmes organi-sationnels qui doivent être réso-lus, une perte d'intérêt de la partdes développeurs et une perte demotivation générale des partici-pants au projet. Hough (1993)soutient qu'une méthode axée surune livraison rapide des systèmesdéveloppés pourrait résoudre tous

ces problèmes. Son modèle, inspi-ré d'un modèle de production ja-ponais, a aussi été utilisé par DeGrâce et Stahl (1990) dans leurdiscussion des alternatives quis'offrent aux développeurs de sys-tèmes (cf. Takeuchi & Nonaka,1986). L'objectif principal de cettelivraison rapide est de produiredes résultats à intervalles régu-liers, par exemple en livrant uneou plusieurs fonctions tous lesmois. Ce concept de livraisonrégulière est aussi à la basede l'approche de Gilb (1988), ap-pelée "incremental engineering ap-proach". D'après Hough, les avan-tages d'une livraison rapide dessystèmes Informatiques sont nom-breux et importants dans le con-texte d'une entreprise commer-ciale. Ces avantages pourraientinclure :

• l'harmonisation de la contribu-tion de l'équipe de développeurs ;

• une amélioration de la planifi-cation ; surtout des dates limiteset des durées ;

• une réduction du risque dedépassement des budgets et desrisques d'échec ;

• une réduction du risqued'omission d'un besoin utilisa-teur ;

• l'amélioration de la crédibilitéet du prestige du département in-formatique ;

• la possibilité de démarrer laformation des utilisateurs plustôt ;

• un encouragement à lacréation de systèmes faciles àinstaller.

(1) Traduit de l'anglais par les auteurs.

17 13



SYSPEMES D'INFORMATION ET MANAGEMENT

4. SYNTHÈSE ET DISCUSSION

Dans cette section, nous pro-posons une synthèse des difficul-tés résultant de l'écart évident en-tre les besoins des développe-ments informatiques et les mé-thodes disponibles. Une analogieavec la blague du fêtard et dulampadaire(2) a été utilisée parplusieurs auteurs pour mettre enévidence les problèmes qui exis-tent en termes de méthodologies(Angell & Smithson, 1991 ;Baskerville et al., 1992 ; Boehm,1988 ; Fitzgerald, 1994). Cettehistoire permet d'illustrer certainsdes problèmes essentiels qui seposent dans l'utilisation des SDMtraditionnelles. Finalement, nousprésentons des arguments en fa-veur d'un nouveau paradigme quiretourne aux sources des problèmes du développement infor-matique et qui tient compte desnouvelles technologies et des nou-velles formes organisationnellesémergentes.

4.1. Regards théoriquessur la méthodologie

Etant donné le caractère peuconcluant des recherches qui ontessayé de comparer et d'évaluerles méthodologies de développe-ment informatique, il est peut-êtrejuste de se demander si nous,chercheurs dans ce domaine,n'avons pas imité le fêtard del'histoire : avons-nous cherché àconduire des recherches sur lesméthodologies existantes parceque cela semblait plus facile, aulieu de réfléchir sur les problèmes

réels du développement informati-que ? L'étude de ces problèmesest, bien sûr, bien plus complexecar elle touche à des aspects poli-tiques et organisationnels bienplus difficiles à cerner qu'unesimple analyse des activités desacteurs impliqués dans le dévelop-pement de systèmes sur la basede méthodologies précises et biendéfinies. Il n'en reste pas moinsque de telles études, même diffi-ciles à mettre en oeuvre, pour-raient apporter des solutions bienplus crédibles et efficaces auxproblèmes bien réels que de nom-breuses études ont révelés.

4.2. Regards pratiquessur la méthodologie

En ce qui concerne la pratiquedu développement des systèmes,on peut légitimement se demandersi les développeurs en entreprisesn'utilisent pas les méthodologiesplutot comme support moral quecomme guide. Ainsi, les entre-prises continuent à utiliser desméthodes peu efficaces et peuutiles pour donner l'impressionque tout est fait dans le respectdes règles. Dans certains cas, cesméthodes sont utilisées par desentreprises de conseil en informa-tique et des entreprises de déve-loppement de logiciels pour im-pressionner leurs clients et leurprouver qu'ils ont vraiment affaireà des professionnels. Dans d'au-tres cas, l'adoption d'une SDMcommerciale est justifiée par lanécessité d'obtenir la certificationISO. Quand les méthodes tradi-tionnelles sont utilisées dans ces

(2) Cette blague raconte l'histoire d'un homme qui, rentrant chez lui tard et pris deboisson, avait perdu sa montre. Il la cherchait à la lumière d'un lampadaire quandun passant lui proposa son aide. Voulant savoir exactement où la montre avait étéperdue, il demanda au fêtard qui lui expliqua qu'il l'avait perdue plus loin dans larue, mais qu'il était plus facile de chercher là où la lumière était la meilleure.

18 14




contextes, les entreprises courentle risque de voir certains pro-grammeurs, surtout les moins ex-périmentés, suivre aveuglémentles étapes de leur méthode au dé-triment de l'avancement du projet.Dans ce cas, l'importante flexi-bilité et l'intelligence naturelle desdéveloppeurs sont perdues auprofit de l'application automatiquede la méthode.

L'importance de la question desperformances des informaticiensreste une question vitale pour no-tre discipline. De nombreux au-teurs ont identifié des problèmestrès fréquents qui se traduisentpar une "crise du logiciel" dont onperçoit les effets dans certainsexemples d'échecs informatiquesnotoires qui ont des échos jusquedans la presse grand public. Nouspensons que ces difficultés sont leproduit du retard des méthodesdisponibles à l'heure actuelle parrapport aux besoins des entre-prises. La création de nouvellesméthodologies plus adaptées auxnouvelles formes organisation-nelles et à la complexité crois-sante des applications qui doiventêtre developpées pourrait apporterdes solutions pour résoudre cettecrise. Ce point de vue a déjà étémis en avant par Larrasquet etClare (1996) qui ont souligné àquel point il était importantd'essayer d'exploiter le potentieldes technologies nouvelles (par-ticulièrement en termes decommunication) pour le bénéficedu développement des systèmesinformatiques.

Le nouvel environnement écono-mique exige que les entreprisesagissent plus vite et à plus courtterme. Le développement doit de-venir plus rapide et la livraisondes systèmes doit être accéléréepar rapport à ce qui est possibleavec les méthodes traditionnelles.

En fait, il est même possible queces dernières soient en partie res-ponsables des problèmes identifiésdans l'étude présentée dans cetarticle. Ce qui est certain, c'estque l'application automatique deméthodologies génériques ne suffi-ra pas à atteindre les objectifsd'informatisation des entrepriseset d'accroissement de l'autonomiedes employés.

5. CONCLUSIONS

Plus de recherches sont doncnécessaires pour établir la naturede l'environnement dans lequel lessystèmes sont aujourd'hui déve-loppés et les besoins réels des en-treprises à travers l'étude de casréels. Dans la plupart des cas, lesinformaticiens ont développé destechniques personnelles qui cor-respondent à leurs besoins et ilsrefusent d'utiliser les méthodestraditionnelles pour d'excellentesraisons basées sur leur expérienceet non par ignorance comme onl'a parfois écrit. L'étude de cespratiques personnelles dans ungrand nombre de projets de tailleet de complexité différentes pourralivrer les fondations des méthodo-logies nouvelles. Ces méthodolo-gies devront non pas révolution-ner la pratique du développementinformatique, mais fourniront unebase conceptuelle plus adaptée àla réalité des projets informatiquesdu vingt et unième siècle.

Avec l'aide de ces nouvelles mé-thodes, le développeur des tempsmodernes devra utiliser une com-binaison de technologies an-ciennes et nouvelles de façoninnovatrice pour l'aider à structu-rer ses connaissances, travaillermieux en groupe et développerplus vite. En particulier, la mes-sagerie électronique et le group-

1915




ware devront être exploités pourun meilleur partage des connais-sances et pour faciliter l'évolutionrapide de la structure et de lacomposition des équipes de déve-loppement. Ainsi, les développeursles plus expérimentés pourront se"relayer" à la tête des équipes dedéveloppement en fonction desétapes du projet concerné et deleur compétence spécifique. Fina-lement, il faudra trouver le moyend'améliorer l'apprentissage (le"learning") à tous les stades duprojet au lieu de le cantonner àla fin du projet dans une hypo-thétique phase d'audit ou de re-vue nécessairement plus ou moinsbâclée ou le plus souvent rempla-cée par une phase intense de "do-cumentation". Ces initiatives de-vront contribuer à une accéléra-tion du processus de développe-ment, accélération qui est vitalepour la satisfaction des besoinsactuels des entreprises.

BIBLIOGRAPHIE

Adam, F. et Cahen , F.D. (1997),« Socrate, or when organisations tryto purchase new systems instead ofdeveloping them », ESRC Researchand Discussion Papers, ref. 97/10,December 1997.

Agresti , W. (1986), New Paradigmsfor Software Development . IEEE Com-puter Society Press, Washington DC.

Ahituv, N., Hadass, M. et Neumann,S. (1984), « A flexible approach to in-formation system development ». MISQuarterly , Vol. 8, n° 2, p . 69-78.

Angell , I. et Smithson , S. (1991), In-formation Systems Management : Op-portunities and Risks, MacMillan, Lon-don.

Avison , David and Fitzgerald, Guy(1995 ), Information Systems Develop-ment : Methodologies , Techniques andTools , Information Systems Series,McGraw Hill , London.

Bansler , J. et Havn , E. (1994), « In-formation 'systems development withgeneric systems », in Baets, W. (Ed),Proceedings of Second EuropeanConference on Information Systems,Nijenrode University Press, Breukelen,p. 707-718.

Baskerville , R., Travis, J . et Truex,D. (1992), « Systems without me-thod : the impact of new technologieson information systems developmentprojects ». In Kendall , K., DeGross, J.and Lyytinen, K. (eds .) The Impact ofComputer Supported Technologies onInformation Systems Development, El-sevier Science Publishers B.V., 'NorthHolland Press, p . 241-269.

Bessagnet , M.N., Larrasquet , J.M. etJayaratna , N. (1994), « Object Orien-ted approaches in the analysis anddesign of information systems to sup-port modern organisational forms »,In Lissoni , Richardson , Miles, Wood-Harper and Jayaratna (eds) Procee-dings of 2nd Annual Conference on ISMethodologies , Heriot-Watt University,p. 177-184.

Boehm , B. (1988), « A spiral modelof software development and mainte-nance ». IEEE Computer , Vol. 21,n° 5, p. 61-72.

Bohm , C. et Jacopini, G. (1966),« Flow diagrams , Turing machinesand languages with only two forma-tion rules » . Communications of theACM, May , p. 366-371.

Brown, P. (1985), « Managing soft-ware development ». Datamation, April15, p. 133-136.

Chen , P. (1976), « The entity rela-tionship model -towards a unified viewof data », ACM Transactions on Data-base Systems . Vol. 1, n° 1, p. 9-36.

Cox, B. (1990), « Planning the soft-ware industrial revolution ». IEEESoftware , November , p. 25-33.

Davis, A., Bersoff, E. et Comer, E.(1988), « A strategy for comparingalternative software development lifecycle models » . IEEE Transactionson Software Engineering , October,p. 1453-1460.

DeGrace, P. et Stahl, L. (1990),Wicked Problems , Righteous Solutions :A Catalogue of Modern Software Engi-neering Paradigms . Yourdon Press,

20 16




Prentice Hall, Englewood Cliffs, NewJersey.

DeMarco, T . ( 1978), Structured Ana-lysis and System Specification, Your-don Press , New Jersey.

Downs , E., Clare, P. et Coe, I.(1992), Structured Systems Analysisand Design Method : Application andContext . Prentice-Hall International(UK), Hertfordshire.

Dyke , R. et Kunz , J. (1989), « Ob-ject -oriented programming ». IBM Sys-tems Journal , Vol. 28, no 3.

Enger , N. (1981 ), « Classical andstructured system life -cycle phasesand documentation », in Cotterman,W., Couger , J., Enger , N. and Harold,F. (Eds) ( 1981 ) Systems Analysis andDesign : A Foundation for the 1980s,Elsevier, New York, p. 1-24.

Firesmith , D. (1993), Object-OrientedRequirements Analysis and LogicalDesign, Wiley and Sons, New York.

Firesmith , D. (1992 ), « Take a flyingleap : the plunge into object-orientedtechnology ». American Programmer,Vol. 5, no 8, p. 17-27.

Fitzgerald , Brian ( 1997), « The useof systems development methodologiesin practice : a field study », Informa-tion Systems Journal , Vol. 7, p. 201-212.

Fitzgerald , Brian (1996), « An inves-tigation of the use of systems deve-lopment methodologies in practice »,in Coelho , J. et al . (Eds) Proceedingsof the 4th European Conference on In-formation Systems , Lisbon , p. 143-162.

Fitzgerald , Brian ( 1994), « Whithersystems development : time to movethe lamppost ? », in Lissoni et al.,(eds), Proceedings of Second Confe-rence on Information Systems Metho-dologies , p. 371-380.

Folkes , S. et Stubenvoll , S. (1992),Accelerated Systems Development,Prentice Hall, London.

Friedman , A. (1989), Computer Sys-tems Development : History , Organisa-tion and Implementation , Wiley &Sons , Chichester.

Gilb, T. ( 1988), Principles of Soft-ware Engineering Management, Addi-son Wesley, UK.

Guimaraes, T. (1985). « A studyof application program developmenttechniques ». Communications of theACM, May, p. 494-499.

Hardy, C., Thompson, B. andEdwards, H. (1995), « Problems asso-ciated with the customisation ofstructured methods », in Jayaratna,Miles, Merali and Probert (Eds.) Pro-ceedings of the Third Conference onInformation Systems Methodologies,p. 211-220.

Hough, D. (1993), « Rapid delivery :an evolutionary approach for applica-tion development », IBM Systems Jour-nal, Vol. 32, no 3, p. 397-419.

Jenkins, A., Naumann, J. et We-therbe, J. (1984), « Empirical investi-gation of systems development prac-tices and results ». Information & Ma-nagement, Vol. 7, p. 73-82.

Larrasquet, J.M. et Clare, P. (1996),« The implication of new organisatio-nal forms and emerging technologyfor IS methodologies ». In Jayaratna,N. and Fitzgerald, B. (eds) Proceedingsof 4th Annual Conference on IS Metho-dologies, University College Cork,p. 407-413.

Mahmood, M. (1987), « Systems de-velopment methods a comparative in-vestigation », MIS Quarterly, p. 293-311.

Nilsson, A. (1990), « IS developmentin an application package environ-ment » , In Wrycza, S (Ed) Proceedingsof Second International Conference onIS Developers Workbench, Universityof Gdansk, p. 444-466.

O'Duffy, M. (1992), Centre for Soft-ware Engineering Newsletter, p. 2-3.

Orr, K. (1989), *(Methodology: theexperts speak ». BYTE, April, p. 221-233.

Palvia, P. and Nosek, J. (1993), « Afield examination of system life cycletechniques and methodologies »,Information and Management, no 25,p. 73-84.

Parnas, D. (1972), « On the criteriato be used in decomposing systemsinto modules ». Communications of theACM, Vol. 15, no 12, p. 1053-1058.

Rockart, J. et De Long, D. (1988),Executive Support Systems, DowJones-Irwin, Homewood, Illinois.

2117




Royce, W. (1970), « Managing thedevelopment of large software sys-tems » . Proceedings of IEEE Wescon.

Stevens, W., Myers, G. et Constan-tine, L . (1974), « Structured design ».IBM Systems Journal, Vol. 13, no 2,p. 115-139.

Sumner, M. et Sitek , J. (1986),« Are structured methods for systemsanalysis and design being used ? »Journal of Systems Management,June, p. 18-23.

Takeuchi, T. et Nonaka, I. (1986).« The new product developmentgame », Harvard Business Review,January-February.

Thomann, J. (1994), « Data model-ling in an 00 world » . American Pro-grammer , Vol. 7, no 10, p. 44-53.

Topper, A. (1992 ), « Building a casefor object-oriented development »,American Programmer, Vol. 5, no 8,p. 36-47.

Verity, J. ( 1987), « The OOPS revo-lution ». Datamation , May 1, p. 73-78.

Ward, P. (1991 ), « The evolution ofstructured analysis Part I : the earlyyears » . American Programmer , Vol. 4,no 11, p. 4-16.

Your-don, E . (1991 ), « Sayonara, onceagain, structured stuff ». American Pro-grammer, Vol . 4, no 8, p . 31-38.

2218



nouveaux regards sur les mÃ©thodologies d'analyse, de

Documents