Home

UNIVERSITÉ DE MONTRÉAL ÉCOLE

1. Evolution compar e des cotts du changement au fil du cycle de d veloppement selon les id es de Beck 1999 Modele simplifi du cycle de d veloppement et de maintenance en programmation extr me aL oa be a ee Se eee Rs Screenshot from a completed product Software development schedule in working days Effort distribution by activity by team 40 4 we a ui Aggregate effort distribution by cognitive activity Aggregate effort by cognitive activity by process Weight index by cognitive activity Weight index by category pia Go See he te Dont Distribution of effort among team projects XIX 13 14 16 21 4 2 4 3 4 4 4 5 4 6 4 7 4 8 4 9 4 10 4 11 4 12 4 13 4 14 Relative effort distribution by category for all team projects sorted by increasing total effort ae M NN Oe A 2D plot of total team project effort ratios relative to the three poles 2D plot of effort mix progression for team project 2001A 2D plot of effort mix progression for team project 2001C 2D plot of effort mix progression for team project 2002B 2D plot of effort mix progression for team project 2003A 2D plot of effort mix progression for team project 2001B 2D plot of effort mix progression for team project 2003B 2D plot of effort mix progression for team project 20
2. Page consult e le 21 mars 2004 119 Annexe I Calculation of the 2D plots of effort Consider x y and z to represent relative effort expended on coding V amp V and engineering activities respectively Let B 7 7 k be a base for R Since the sum of relative effort at a given time is 100 we obtain for each vector x E y z r y z 1 0 1 1 which represents the equation of a plane in a three dimensional space Such a plane can be represented in a two dimensional space if rotated properly We may define the following vectors 2 7 and k as follows 1 V2 la 1 v3 12 120 V6 o 1 3 2 V6 Since 7 1k 1 and x k we can conclude that 7 7 and k form three linearly independent unit vectors and that therefore it is possible to express E in terms of the new base B T kh Let 1 42 1 V6 1 V3 P 1 2 1 46 1 V3 1 5 0 2 v6 1 V3 be the change of coordinate matrix from B to B Therefore 121 x y V2 x y V2 1 y 22 V6 x y 22 V6 1 6 z y 2 Vv3 1 43 We used equation 1 6 to draw each 2D plot diagram dropping z which is constant Any other relative effort mix can be represented in the same way in a similar diagram 122 Annexe II Contenu du support CD fourni Le disque compact qui accompagne ce m moire contient trois articles de conf rence auquel l auteur a contribu Les trois article
3. Transition phases are not included in any of the projects under study so we do not consider these here The 40 of project completion point seems to constitute the first major milestone Before that point the focus is on engineering activities which is typical of an Elaboration phase evolving rapidly towards this first milestone After 40 of project completion the process seems to become much more stable with an average of only 14 engineering work in the second half of the software development cycle The whole time period from the first milestone to the end of the project is typical of a Construction phase The 80 completion stage seems to represent a second milestone with a great deal of emphasis being transferred mostly from coding activities to V amp V activities This milestone is less important than the first one in that a shift from coding to V amp V activities has to be expected at the end of a typical construction phase with the timing of the shift being theoretically dependent on iteration granularity We call the part of the Construction phase that occurs before the 80 milestone the building up stage This period reflects a steady state which is in theory typical of iterative and incremental processes during the time period when components are built and basic system integration is performed Finalization by contrast is the part of the phase that occurs beyond the 80 milestone At that point so
4. consid rer les aspects qualitatifs d une d marche de recherche Toutefois l tude bien qu exploratoire a t r alis e dans le contexte de m thodo logies et mod les existants et bien d finis Elle a pour theme central l effort d ploy par les d veloppeurs entit qui s analyse le plus souvent de mani re quantitative Pour ces raisons et de la m me mani re que Seaman et Basili nous optons pour l utilisation d une approche hybride qualitative quantitative Selon Robillard Kruchten et d Astous 2003 chap 12 deux facteurs font de la mesure de l effort une entreprise ardue et susceptible d engendrer des donn es 30 difficiles interpr ter D abord la mesure de l effort n cessite un minimum d in teractions avec les individus ce qui oblige la prise en compte de nombreux aspects sociaux et psychologiques Ensuite les syst mes courants de mesure de l effort pr supposent l existence d une relation un un entre les activit s mesur es et les t ches selon lesquelles l effort est enregistr En pratique rien n assure une telle ad quation Les auteurs num rent quatre menaces distinctes la validit des don n es d effort soit la validit des mesures proprement dites la non uniformit des intervalles de temps la non uniformit de l utilisation des jetons et l ambigu t des jetons Germain Dulipovici et Robillard 2002a ont montr que m me en utilisant un syst me de me
5. limination des effets d coulant de la substitution mutuelle possible des activit s enregistr es par les participants De telles substitutions peuvent survenir notamment pour des raisons d ambiguit de la classification de bas niveau des activit s ou encore pour des raisons de choix de m thodes de travail non couvertes par la classification de bas niveau des activit s Elle doit comporter un nombre suffisant de cat gories afin d offrir une pers pective fine lors de l analyse des patrons d effort Un nombre lev de pa trons significatifs est suceptible d engendrer une meilleure pr cision d ana lyse Le principal avantage de la classification par tat employ e au chapitre 3 re lativement a la g n ration de patrons d effort est la stabilit montr e par rapport au mod le de processus utilis En pratique toutefois l utilit de cette caract ris tique peut varier consid rablement selon le contexte Une organisation d sireuse de pratiquer le contr le de processus et disposant d un mod le g n rique de processus qu elle r ussit appliquer avec peu de modifications la plupart de ses projets risque peu d en b n ficier De fa on g n rale une classification sera plus utile si elle r ussit soutenir des conditions de projets diversifi es plut t que des processus tr s diff rents De toute mani re des conditions de projets variables devraient nor malement entra ner des variations cor
6. 40 gt SRG if 05 _ a 520 10 Pure Engineering 0 5 0 0 0 5 X Figure 4 9 2D plot of effort mix progression for team project 2003B Figure 4 10 2D plot of effort mix progression for team project 2002A Pure V amp V Pure Coding l a 0 0 o AS a Ne A 100 gt PS a o 60 0 5 _ 40 N xe Pure Engineerin 40 _ g g 0 5 0 0 0 5 x Figure 4 11 Pure V amp V Pure Coding e A IA A GE gt e 80 No a O 0 0 _ Pa 40 N lt 100 EN 20 gt Ne je 0 5 S a ee Pure Engineering 1 0 _ 0 5 0 0 0 5 X 2D plot of effort mix progression for team project 2003C 82 83 effort was added about equally in the coding and V amp V disciplines Finally at the 80 and 100 stages projects end almost in the middle of the diagram which means that total effort has been invested almost equally among the disciplines Since the 20 stage is mainly at the engineering marker we can conclude that the engineering effort was very important for these team projects For these first four team projects all progressions head north assuming that north is at the top of each diagram meaning that the emphasis is put on en gineering activities at the beginning of a project that their relative importance diminishes as the project progresses and that from there on the coding and V amp V activities increase about equally Team project 2003A shown on Figure 4 7 is
7. En pratique le mod le de processus d finit exactement les r les activit s et art facts propos s ainsi que les relations entre ceux cl 14 Disciplines Requis me mm Analyse et cat ct conception Implantation _ SSC Test im pi a Gestion cont et 1 changement E Gestion de projet he ee se LL Figure 1 2 Mod le bidimensionnel de processus et de cycle de vie du UPEDU traduit de Ecole Polytechnique de Montr al 2002 1 1 2 2 Le Unified Process for Education UPEDU Le UPEDU Ecole Polytechnique de Montr al 2002 est un mod le de processus d riv du Rational Unified Process I a t mis sur pied par l cole Polytechnique en collaboration avec Rational Software Corporation Il a t d crit en d tail dans Robillard Kruchten et d Astous 2001 2003 Les caract ristiques du RUP telles que mentionn es la section pr c dente s appliquent galement au UPEDU sauf mention contraire La figure 1 2 illustre le mod le bidimensionnel de processus et de cycle de vie du UPEDU qui constitue un sous ensemble du mod le correspondant 15 l int rieur du Rational Software Process En abscisse figurent les quatre phases qui composent le cycle de vie ces phases sont les m mes que pour le RUP Chacune des phases peut tre subdivis e en un certain nombre d it rations suivant le d tail du processus retenu ou a la discr tion du gestionnaire de projet La phase de com
8. es La r alisation de classifications pertinentes est essentielle pour l obtention de patrons significatifs et partant pour le d veloppement de m canismes viables en mati re de contr le de processus et d estimation en cours de projet Les principales caract ristiques de qualit d une classification en disciplines sont les suivantes La classification doit pouvoir s arrimer naturellement avec la ou les classifi cations de bas niveau des activit s cognitives ou de processus utilis es dans le cadre de la prise de mesures Id alement chaque activit doit pouvoir tre rattach e clairement l une ou l autre des disciplines sans qu il soit n ces saire d tudier le contexte du jeton avant de pouvoir prendre une d cision cet effet La classification doit permettre une discrimination claire entre les courbes d effort issues de chaque discipline Elle doit pouvoir absorber des variations raisonnables sur le plan de facteurs tels que le processus utilis la nature ou la taille des projets ou encore la taille des quipes sans que ces variations ne se refl tent de mani re significative dans les courbes d effort Le caract re raisonnable des variations accept es d pend du contexte de la mesure et de l utilisation pr vue des r sultats La classification doit comporter un nombre optimal de disciplines et ce afin d quilibrer les deux contraintes suivantes 100 Elle doit permettre l
9. r certains mod les de co ts et d effort comme c est le cas du COCOMO II Boehm Clark Horowitz West land Madachy et Selby 1995 tiennent compte des m thodes de d veloppement en place de la maturit du processus logiciel ou de l influence de facteurs purement locaux Toutefois l absence de lien direct entre le mod le de co ts et le mod le de processus constitue un inconv nient notable dans le contexte de la bo te outils du gestionnaire de projets ou de l ing nieur de processus logiciel Morisio 1999 29 constate que m me si une attention croissante est port e la mod lisation des processus logiciels l tablissement d un couplage strict entre celle ci et la mesure de processus en est ses premiers balbutiements 1 3 2 La mesure de l effort Dans le cadre d un travail d analyse des discussions lors de r unions d inspection Seaman et Basili 1998 exposent la distinction entre les m thodes de recherche qua litatives et quantitatives Selon ces auteurs les m thodes qualitatives permettent d analyser des donn es comme des mots ou des images et sont surtout utilis es afin de g n rer des hypoth ses plut t que les mettre l essai Les m thodes quantita tives touchent l analyse de donn es num riques et sont souvent utilis es aux fins de confirmation ou de tests d hypoth ses d j mises Dans le cas de la pr sente tude la nature exploratoire des travaux am ne naturellement
10. 1997 98 suivant g n ralement une courbe de la forme D aE o a et b sont des constantes et 0 lt b lt 1 Dans University of Southern California 1998 il est mentionn que Accelerated schedules tend to produce more effort in the later phases of development because more issues are left to be determined due to lack of time to resolve them earlier A stretch out of a schedule produces more effort in the earlier phases of development where there is more time for thorough planning specification and validation En pratique la convergence remarquable des patrons d effort pr sent s au cha pitre 4 peut porter croire que la pr sence ventuelle de tels ph nom nes a eu peu d impact sur la qualit des observations Incidemment la mesure de l avancement des projets a t r alis e en utilisant la proportion de l effort total r alis un instant donn plut t que les dates indiqu es sur les jetons d effort Ce choix avait justement pour but de minimiser l impact de ces ph nom nes 5 2 La classification en disciplines La classification des activit s cognitives ou de processus en cat gories ou dis ciplines a t r alis e en fonction des contraintes inh rentes aux processus et aux 99 approches de mesure de l effort utilis s Bien qu ayant permis la r alisation d obser vations int ressantes les classifications r alis es sont exploratoires et devront tre raffin
11. 9 V amp V activities increase little over the course of the project relative to other activities and actually decrease between 60 and 100 of completion 4 5 3 Incoherent progressions Figures 4 10 and 4 11 show two incoherent progressions of the effort mix In Figure 4 10 the progression shown for team project 2002A has a U shape which starts almost in the middle of the diagram comes down towards the Engineering pole and then after a pause moves towards the Coding pole The incoherence is mostly due to the data point at 20 of completion which includes too few engineer ing activities However were that point to be located closer to the Engineering pole then the overall pattern would be tilted towards the Coding pole and thus 85 still be considered irregular In Figure 4 11 we can see that the progression of the effort mix for team project 2003E evolved in a chaotic fashion along the axis between the Engineering and Coding poles Not only is there no real progression but the proportion of V amp V activities through the entire project remains remarkably low 4 6 Non cumulative perspective on regular coherent progressions Figure 4 12 shows the non cumulative effort patterns for the four team projects which have exhibited regular coherent effort progressions The curves are shown on different floors The x axis represents ranges of project advancement as defined previously The s
12. Total person hours 300 200 100 2003C 2002B 2003B 2002A 2003A 2001B 2001C 2001A Team edition Figure 4 1 Distribution of effort among team projects of the deliverable products The seven team projects excluded had suffered major drawbacks such as failure to meet the requirements unreliable effort slip values in sufficient overall effort lack of relevant team activities and major misunderstanding of the software engineering process disciplines All selected team projects involved a minimum of 350 person hours The projects selected for the study generated software system products that met the specified requirements Figure 4 1 shows the distribution of total effort for each team project Project duration varied from 9 to 14 weeks depending on the studio edition For instance the first column shows that project C in year 2003 required a total effort of 350 hours 75 4 4 Overview of disciplines The first step is to define the three disciplines to be used as a comparative basis for all the projects These disciplines must be general enough to fit each of the projects and specific enough to provide a meaningful description of the various activities composing the discipline The following three disciplines meet these criteria e The Coding discipline includes all activities related mainly to programming e The Validation and Verification V amp V discipline includes all activities re lated to deb
13. a slight exception as progression heads north west rather than north which means that most of the engineering effort is transferred to V amp V activities as the project progresses The 20 stage is also very interesting as it includes a very small V amp V component as well as a 50 50 mixture of coding and engineering ac tivities It is interesting to note that at least one team project from each edition is represented in this subgroup 4 5 2 Coherent progressions with tilt towards coding Figures 4 8 and 4 9 show a special case of coherent progression where little or no increase in V amp V activities occurs This transitioning from mostly engineering activities to mostly coding activities is remarkable because it tends to represent a 84 break from the accepted practices in iterative and incremental software develop ment Determining whether a progression is regular or not can be made only on a case by case basis since there is no obvious demarcation between what constitutes a sufficient increase in V amp V activities and what does not We selected team projects 2001B and 2003B because they exhibit at least one clear measurable characteristic of inclination towards coding activities In the case of team project 2001B see Figure 4 8 there is virtually no increase in V amp V activities until after the 60 completion point After that point the increase is sharp but limited In the case of team project 2003B see Figure 4
14. analysis approach for extracting relevant informa tion on effort at the process discipline level and for identifying patterns which are followed in a substantial number of the projects under study We have been able 95 to provide quantitative measures of effort progression for projects that are in our opinion quite similar to many other small scale software development initiatives Such quantification is necessary if we wish to be able to use detailed process infor mation for planning purposes instead of aggregated information alone We have also defined a technique which permits the online detection of irregular project progressions using measurements of the effort mix at various times In order to establish whether or not our proposed progression is ideal for that purpose it will have to be validated using additional empirical data similar as that presented here The main contribution of the paper is to show that an opportunity currently exists for the useful utilization of effort progression data for project planning monitoring and control purposes Acknowledgments We are grateful to S bastien Cherry Alexandre Moise Christian Robidoux Martin Robillard and Houcine Skalli who were involved at various steps in the three Software Engineering Studio editions and especially to Mihaela Dulipovici who acted as teaching assistant for editions 2002 and 2003 and was deeply involved in artifact and effort slip evaluation in all three editio
15. bullet Essence and accidents of software engineering IEEE Computer 20 4 10 19 BROOKS Jr Frederick P 1995 The Mythical Man Month Essays on Software Engineering Anniversary ed Boston Addison Wesley Longman 322 p COCKBURN Alistair 2002 Agile Software Development Boston Addison Wesley 278 p COCKBURN Alistair WILLIAMS Laurie 2001 The costs and benefits of pair programming Extreme Programming Examined Sous la direction de Giancarlo Succi et Michele Marchesi Boston Addison Wesley P 223 247 CUGOLA Gianpaolo GHEZZI Carlo 1998 Software processes A retrospec tive and a path to the future Software Process Improvement and Practice New York Wiley InterScience P 101 123 110 D ASTOUS Patrick 1999 Approche de mesure et d analyse des activit s coop ratives lors de r unions de r vision technique du processus de g nie logiciel 219 p Th se de doctorat en g nie lectrique cole Polytechnique de Montr al DAVIS Noopur MULLANEY Julia 2003 The Team Software Process TSP in Practice A Summary of Recent Results Pittsburgh Carnegie Mellon Software Engineering Institute 88 p CMU SEI 2003 TR 014 COLE POLYTECHNIQUE DE MONTR AL 2001 Annuaire de l Ecole Poly technique Baccalaur at en Ing nierie Montr al cole Polytechnique COLE POLYTECHNIQUE DE MONTREAL 2002 UPEDU En ligne http www yoopeedoo org Page consult e le 21 mars 2004 E
16. com plete and acceptable software system The study defines a new categorization of process activities in three disciplines The analysis shows that we can define relative effort paths in the discipline space These paths have well defined characteristics which may be used to monitor project progression 4 1 Introduction Model based effort estimation rests on the principle that total software project effort should be an approximate function of a set of predictors Lines of code func tion points programming language rate of reuse requirements volatility software 69 change rates product complexity database sizes non functional requirements and platform difficulty are representative of the kinds of predictors found in models such as those of the COCOMO family Boehm Clark Horowitz Westland Madachy and Selby 1995 These predictors refer to product characteristics or sometimes to key factors of process capability such as personnel experience and schedule tightness These approaches assume that the software process generates similar outputs under similar quality and cost conditions when provided with similar inputs Although that view may be correct for organizations in control of their software processes it should not be assumed to be so for others Software processes need to be mon itored and controlled just like any manufacturing and business processes Failure to follow the prescribed activities may lead to the execution of a
17. data point upward At the 60 stage major Pure V amp V 79 Pure Coding 00 _ Y _ 40 920 Nal 0 5 bs N N Pure Engineering 1 0 0 5 0 0 x 0 5 Figure 4 4 2D plot of effort mix progression for team project 2001A Pure V amp V Pure Coding SR ee ee ES 4 0 0 e 100 ES K 800 ke AT 60 Le gt 40 eS N 20 40 Pure Engineering 05 0 0 0 5 x Figure 4 5 2D plot of effort mix progression for team project 2001C 80 Pure V amp V Pure Coding ee 4 E Lo 100 0 0 eo se 80 A gt 20 N t 410 _ Pure Engineering 60 40 0 5 0 0 x 0 5 Figure 4 6 2D plot of effort mix progression for team project 2002B Pure V amp V Pure Coding o A o A A A A ne p ad En e 2100 i 80 Ke a 7 60 gt ES 40 05 pa 20 10 _ Pure Engineering 0 5 0 0 0 5 X Figure 4 7 2D plot of effort mix progression for team project 2003A 81 Pure V amp V Pure Coding Re EN H 100 0 0 E s es es 80 de ra 60 gt de 4 of ES 40 0 5 _ a ES ye N 720 LS Pure Engineering 1 0 _ 0 5 0 0 0 5 x Figure 4 8 2D plot of effort mix progression for team project 2001B Pure V amp V Pure Coding RN A A NN a 4 N A 00 7 en 80 N 7 60 ES gt
18. des projets de d veloppement de logiciels et le comportement des individus qui participent ces projets Au del de la rh torique ambiante sur la valeur compar e des multiples approches de d ve loppement il ressort que le choix d une approche particuli re a un impact limit sur les activit s cognitives r alis es par les quipes tudi es Cet impact mesur en termes relatifs se manifeste surtout au niveau des activit s d inspection et de r vision des travaux r alis s L analyse des activit s r alis es par chaque quipe tudi e montre une conver gence mod r e des proportions d activit s r alis es sur l ensemble du cycle de d veloppement Toutefois l observation la plus notable demeure que la majorit des projets soumis affichent une volution tr s similaire du type d activit s r alis es au fil du temps Ainsi l effort r alis suit une progression qui d bute par une pre mi re phase o les activit s li es l ing nierie sont pr dominantes Le poids de ces activit s diminue progressivement ce qui am ne une seconde phase d quilibre entre les activit s de programmation et celles de validation et de v rification Cet quilibre est rompu peu avant la fin du projet en faveur des activit s de valida tion et de v rification quoique de mani re peu marqu e Bien que l ensemble de ces observations soit en accord avec notre compr hension th orique des cycles de 104 d veloppement
19. findings and provide a few general conclusions 4 2 The Software Engineering Studio The Software Engineering Studio is an optional project oriented course offered during the winter term to senior year students in computer engineering Its purpose is to allow students to gain practical experience in software development by par ticipating in a small scale software development project Teams of students must develop a complete implementation based on software requirements specifications provided by the instructors Also they must follow a specific software engineering process the UPEDU Participants thus acquire experience in building a complete operational software product through the disciplines of analysis design implemen tation testing and management This project course teaches them the realities of teamwork milestones and time constraints As a secondary objective students become more familiar with a specific application domain or set of technologies Earlier versions of the Studio are presented in detail in Germain Dulipovici and Robillard 2002a Germain Robillard and Dulipovici 2002b Germain and Robil lard 2003 2004 Robillard 1998 The Unified Process for Education UPEDU which has been used for most of the projects performed in the Studio since 2001 73 is extensively described in Robillard Kruchten and d Astous 2001 2003 and is readily available online Ecole Polytechnique de Montr al 2002 The case study
20. for team projects with incoherent progressions as function of project advancement 90 4 7 Analysis 4 7 1 Coherence and regularity Six of the eight team projects studied show coherent effort patterns along the three disciplines which constitute the basis of our classification The focus is placed on engineering activities first and is gradually transferred to coding and V amp V ac tivities For four of them the increase in V amp V activities is at least as great as it is for coding activities These observations tend to show the presence of fundamen tal behavior characteristics The fact that two team projects exhibit incoherent progressions of effort patterns should not be a surprise since the participants in them were mostly inexperienced and while the software process gave clear indica tions of the kinds of activities to perform and artifacts to generate it did not as implemented tell the developers when to perform those activities Timing issues are tightly coupled to the development cycle implemented and were except for delivery dates mostly under the control of the teams 4 7 2 Development cycle and key milestones for regular and coherent progressions The progression of the curves shown in Figure 4 12 offers a picture of a frac tured software development cycle These fractures match the Elaboration and Construction phases of the UPEDU Note that the contents of the Inception 91 and
21. impact beaucoup moindre sur la profitabilit du projet Il s ensuit que selon la th orie de la programmation extr me Beck 1999 le gestionnaire de projet doit se rabattre 22 dans sa qu te d une plus grande conomie dans la r alisation du projet sur les m thodes classiques de la maximisation de la valeur conomique des projets Lutz 1992 Une telle approche passe par l application de la m thodologie de planification des travaux suivante Il s agit d abord de percevoir le projet non pas comme une entit unique mais plutot comme une succession de mini projets appel s livraisons fond s successivement les uns sur les autres Ainsi la version la plus r cente du syst me logiciel est livr e au client la fin de chaque mini projet Il faut ensuite proc der l ordonnancement des travaux au niveau macrosco pique ainsi qu la planification de la premi re livraison afin de maximiser la valeur de celle ci dans la perspective du client Les caract ristiques qui ne contribuent pas cet objectif sont exclues de la livraison Une fois la livraison effectu e il s agit d en facturer imm diatement le contenu et de passer la livraison suivante Cette approche par livraisons fr quentes doit permettre de maximiser la valeur du projet par l application des trois tactiques suivantes Les d penses surviennent plus tard car l implantation des caract ristiques non essentielles la qual
22. l tude r alis e permet la fois de confirmer la forte convergence des patrons d effort affich s et de les quantifier en termes relatifs a l effort total d ploy pour chaque projet Un des apports principaux de ce travail de recherche est une m thode permet tant de pallier la probl matique soulev e par MacDonell et Shepperd 2003 qui n ont pu relever clairement de proportions normalis es d effort pour chacune des phases du cycle de d veloppement Notre approche montre que de telles pro portions peuvent appara tre condition de consid rer deux dimensions d analyse les disciplines ainsi que l avancement des projets plut t qu une seule la notion de phase Les observations effectu es montrent galement que l utilisation de condi tions multiples de projets peut permettre de cerner des patrons d effort pertinents Selon Tichy 2000 The reality of even the most rigorous approach to em pirical work is that experiments normally constitute only a small step forward Cette d claration s applique tout a fait au pr sent travail d autant plus qu il s agit ici d une recherche exploratoire et non d une exp rimentation En ce sens seule la recherche future fond e sur ce travail permettra de le faire fructifier Ainsi nous d celons un certain nombre de voies suivre pour valider nos observations dans le cadre d une d marche exp rimentale formelle et v rifier leur applicabilit a
23. l application d un cycle incr mental de d veloppement suivant des it rations extr mement courtes ponctu es de livraisons interm diaires obligatoires se veut le mode d emploi vers l obtention d une courbe croissante mais plafonn e des co ts de modification du logiciel en fonction du moment o elles sont amen es voir figure 1 4 La relation entre les courbes de co ts pour chaque cas peut s ex primer math matiquement comme suit Soient t le temps coul depuis le d but de la r alisation d un projet c le co t d un changement r alis au temps t et n une constante quelconque Pour n t c Rin gt 1 t2 gt 0 Processus conventionnel an e 1 1 Programmation extr me c t t 1 2 21 Co t en c 4 Processus conventionnel XP Temps 1 Figure 1 4 Evolution compar e des co ts du changement au fil du cycle de d ve loppement selon les id es de Beck 1999 Les cons quences sur la strat gie de d veloppement d coulant de l utilisation de l une ou l autre de ces courbes sont cruciales L quation 1 1 m ne directement une strat gie visant minimiser les co ts du changement par la prise des d cisions de fond le plus tot possible dans le projet notamment sur les volets des requis et de l architecture et par le gel de celles ci De mani re contrast e dans le contexte de P quation 1 2 le retardement de la prise des d cisions de fond comporte un
24. performing their tasks correctly and efficiently However some variations did exist among individuals A small num ber of students were not yet familiarized with the UPEDU Also a small number of students had been exposed to the Java language and to related technologies Nev 50 ertheless we feel that these differences did not create any significant asymmetry among the teams 3 3 Cognitive activity classification In previous Studios students had been asked to record effort expended under each process activity That approach has the benefit of allowing a direct measure ment of the process itself However it can only be used on the assumption that the list of activities defined in the process covers every possible work situation without generating excessive overlap Such an assumption has not been confirmed Indeed an analysis performed using data from the 2001 Studio Germain Dulipovici and Robillard 2002a showed the possible presence of ambiguity and confusion among participants in relation to the process activities as defined by the instructors Another problem with the approach was that the presence of two separate software processes prevented the utilisation of a single process based scheme that would allow comparison of the effort expended by all the teams An alternative approach was to use a process independent classification which would lead to the implicit assignment of effort to the proper activity A classification based
25. research opens the way to the implementation of effort pattern analysis in industrial settings From a theoretical perspective such analyses may help improve our understanding of the behavior of software develop XIV ment professionals From a more practical perspective they may also constitute powerful tools for software project managers and process engineers XV TABLE DES MATIERES TIC AC Baten Re de de iv REMERCIEMENTS mae di Oa eg Bog eee da aa a hed v RESUMES AE E S arenas tee eae ale E EEE vii ABSTRACT ye siria AA Gee DA ara ls Pa a ii xi TABLE DES MATIBRE NS bi a ee xv LISTE DES FIGURES go e o A LA RE xix LISTE DES SIGLES ET ABBREVIATIONS xxi LISTE DES TA BLEU a dos A ee ane dunes REA xxiii LISTE DES ANNEXES suite Lie ste ah e Ae ks xxiv INTRODUCTION gira mt AE SS 1 CHAPITRE 1 REVUE CRITIQUE DE LA LITTERATURE 6 1 1 Processus logiciels eds a ds ls ir a AE 6 1 1 1 Evolution du domaine T7 1 1 2 Revue des principaux mod les de processus 11 1 2 M thodologies agiles de d veloppement de logiciels 18 xvl 1 2 1 Survol des m thodologies agiles 18 1 2 2 La programmation extr me sie die ne A 20 1 2 3 Les processus d ing nierie par opposition aux m thodologies NE SE her s dS ag hes de evs as are hes dt tae hey a eek 25 1 3 La mesure des processus logiciels 26 Mga estimation de l effort v
26. some methods which have 67 emerged in the light of XP such as pair programming see for instance Williams and Upchurch 2001 can be considered for teaching purposes independently of the process involved Acknowledgments We are grateful to Mihaela Dulipovici who participated in the preparation of the project course acted as teaching assistant for the course and was deeply involved in artifact and effort slip quality evaluation Also this project would not have been possible without the participation of all the students enrolled in the Software Engineering Studio course during the Winter 2002 semester We would also like to thank Alexandre Moise and Martin Robillard for their insightful comments while we were building the requirements specifications for the semester project This work was partly supported by the Natural Sciences and Engineering Re search Council of Canada NSERC under grant A0141 68 CHAPITRE 4 MEASURING RELATIVE EFFORT PROGRESSION PATHS IN THE DISCIPLINE SPACE OF THE SOFTWARE ENGINEERING PROCESS Abstract This paper presents the analysis of relevant effort patterns in the work per formed in the context of a capstone project course in software engineering at the Ecole Polytechnique de Montr al Eight teams of students from three annual edi tions of the Software Engineering Studio were given the task of providing a detailed record by activity of their work while each team was engaged in developing a
27. 0 28 des projets sont termin s temps et l int rieur des estimations ini tiales 49 des projets sont annul s avant leur ach vement ou ne sont jamais mis en uvre Les d passements de co ts quivalent en moyenne 45 des estimations initiales 28 En moyenne les logiciels livr s r pondent 67 des besoins sp cifi s Les statistiques laissent entrevoir non seulement une difficult g n ralis e maitri ser les param tres qui contr lent l envergure d un projet de d veloppement mais galement un manque g n ralis de contr le du processus logiciel C est pourtant le processus logiciel qui permet de transformer les besoins des usagers en produits logiciels Standards Coordinating Committee of the Computer Society of the IEEE 1990 L incapacit de combler l ensemble des besoins formels exprim s dans le cadre d un projet de d veloppement constitue clairement un chec du processus logiciel l inverse l application ad quate d un processus logiciel appropri doit permettre non seulement de livrer les caract ristiques fonctionnelles et non fonc tionnelles pr vues mais d y parvenir sous des conditions pr visibles de co ts et de d lai de livraison et de r duire ainsi la fr quence des probl mes mentionn es pr c demment Notons que les mod les de co t et d effort les plus courants n integrent pas les caract ristiques du mod le de processus utilis Bien s
28. 02A 2D plot of effort mix progression for team project 2003C Non cumulative effort for team projects with regular and coherent progressions as a function of project advancement Non cumulative effort for team projects with irregular but coherent progressions as a function of project advancement Non cumulative effort for team projects with incoherent progressions as a function of project advancement TT 2D Cn CMM COCOMO En EQ EQM EQn IEEE It NSERC OPEN PAI PSEE PSP RUP SLIM SPCC xxl LISTE DES SIGLES ET ABBREVIATIONS Bi dimensional It ration de construction n Capability Maturity Model Constructive Cost Model It ration d laboration n Modele quivalent Modele quivalent it ration de maintenance Modele quivalent it ration n Institute of Electrical and Electronics Engineers It ration Natural Sciences and Engineering Research Council of Canada Object oriented Process Environment and Notation Process Activity Index Process centered Software Engineering Environment Personal Software Process Rational Unified Process Software Lifecycle Management Software Project Control Center Tn TSP UP UPM UPn UPEDU V amp V XP XPM XPn xxii It ration de transition n Team Software Process Unified Process for Education Unified Process for Education it ration de maintenance Unified Process for Education q
29. L EMAM Khaled 2001 Software engineering process Guide to the Software Engineering Body of Knowledge Trial Version Version 1 00 Sous la direction de Pierre Bourque et Robert Dupuis Los Alamitos IEEE Computer Society P 137 154 FENTON Norman E PFLEEGER Shari Lawrence 1997 Software metrics a rigorous and practical approach London PWS Publishing 638 p FLORAC William A CARLETON Anita D 1999 Measuring the software process statistical process control for software process improvement Reading Addison Wesley 250 p FUGETTA Alfonso 2000 Software process A roadmap The Future of Soft 111 ware Engineering 2000 22nd International Conference on Software Engineering Sous la direction de Anthony Finkelstein New York Association for Computing Machinery P 25 34 GERMAIN ric DULIPOVICI Mihaela ROBILLARD Pierre N 2002a Mea suring software process activities in student settings Proceedings of the 2nd ASERC Workshop on Quantitative and Soft Computing Based Software Enginee ring Edmonton Alberta Software Engineering Research Consortium P 44 49 GERMAIN Eric ROBILLARD Pierre N 2003 What cognitive activities are performed in student projects Proceedings of the 16th Conference on Software Engineering Education and Training CSEET 03 Los Alamitos IEEE Computer Society P 224 231 GERMAIN ric ROBILLARD Pierre N 2004 Engineering based processes and agile
30. P Kruchten 2000 is an example of a process that fits this approach The Unified Process for Education UPEDU is a RUP based process designed for teaching the software processes in software engineering and computer science programs The process is built on a set of focused activities with significant 40 cognitive content and on a set of essential artifacts that should be needed for small projects The process also defines basic roles such as Designer Implementer Tester Project Manager and Reviewer which are easily understandable by developers who are inexperienced Roles activities and artifacts are grouped into disciplines which are categorized as either engineering or management The UP EDU has been extensively described in Robillard Kruchten and d Astous 2001 2003 and is readily available online cole Polytechnique de Montr al 2002 The other approach called Agile Software Development Agile Alliance 2003 Cockburn 2002 promotes quick response to changes in requirements as well as extensive and ongoing collaboration between the development team and the cus tomer The approach specifically downplays the importance of formal processes and comprehensive documentation Agile Alliance 2003 It is based on the assumption that one cannot truly anticipate project requirements right at the beginning of a software development project and that the proper way to deliver timely quality software in
31. These observations tend to show that irregular progressions do not simply constitute a special case of coherent progres sions but rather should be considered as an independent category characterized by its emphasis on coding activities Figure 4 14 shows the same information for the team projects with incoherent progressions Average values have been omitted as patterns do not converge except a little for V amp V activities Both team projects exhibit major deviations from pat terns previously shown For team project 2002A the peak in engineering activities is located in the second fifth of project execution instead of the first Also V amp V activities actually decrease over the course of the project Finally the increase in coding activities from 40 to 80 of completion is unusually high For team project 2003C coding and engineering effort patterns show the inverse of what is shown by other team projects 89 1009 80 60 40 20 Coding 100 80 60 V amp V 40 i E A PEST 20 o A RA gt Ro _ a 100 A A One 80 60 Dae Tsn Engineering a EE a 40 we x h Res Ai dd j y Weer 20 Sig ee y er e A o 0 gt 20 20 gt 40 40 gt 60 60 gt 80 80 gt 100 1 Coding 2002A Coding 2003C V amp V 2002A 4 V amp V 2003C Engineering 2002A Engineering 2003C Figure 4 14 Non cumulative effort
32. UNIVERSITE DE MONTREAL ECOLE POLYTECHNIQUE DE MONTREAL Ce m moire intitul ANALYSE COMPARATIVE DE LA R PARTITION DE L EFFORT DANS LE CADRE DE PROCESSUS LOGICIELS pr sent par GERMAIN ric en vue de l obtention du dipl me de Ma trise s sciences appliqu es a t d ment accept par le jury d examen constitu de M BOUDREAULT Yves M Sc pr sident M ROBILLARD Pierre N Ph D membre et directeur de recherche M DESMARAIS Michel Ph D membre UNIVERSITE DE MONTREAL ANALYSE COMPARATIVE DE LA REPARTITION DE L EFFORT DANS LE CADRE DE PROCESSUS LOGICIELS ERIC GERMAIN DEPARTEMENT DE GENIE INFORMATIQUE ECOLE POLYTECHNIQUE DE MONTREAL MEMOIRE PRESENTE EN VUE DE L OBTENTION DU DIPLOME DE MAITRISE ES SCIENCES APPLIQUEES GENIE INFORMATIQUE AVRIL 2004 Eric Germain 2004 lv Aux deux femmes de ma vie Hughette ma m re Marie ma douce REMERCIEMENTS J aimerais d abord remercier mon directeur de recherche Pierre N Robillard dont la vision les conseils les critiques et les encouragements ont fortement teint l ensemble de ma d marche de recherche et de production de ce m moire Je tiens remercier tout particuli rement Mihaela Dulipovici pour son soutien dans le contexte du cours projet Atelier de g nie logiciel et notamment pour son travail m ticuleux de validation des jetons d effort J aimerais galement remer cier S bastien Cherry Alexandre Moise Christia
33. a cost effective manner is instead to build flexibility within the devel opment activities The Manifesto for Agile Software Development Agile Alliance 2003 provides the basic values for agile development in detail Some methodolo gies inspired by this approach include Adaptive Software Development Highsmith 2000 Scrum Rising and Janoff 2000 the Crystal family Cockburn 2002 High smith 2002 Feature Driven Development Palmer and Felsing 2002 Dynamic System Development Method Stapleton 1997 and Extreme Programming XP 41 see Beck 1999 There is no such thing as a universal process or methodology Organisations will typically develop their own process or methodology based on the approaches described and often on an existing process model For example an organization may use tools provided with the RUP package to build a custom process containing a chosen subset of the proposed activities and artifacts Alternatively an organiza tion may simply take the generally recognized set of XP practices and adapt them to its particular context Meanwhile students enrolled in a software engineering program who have re ceived training on software processes are expected to be at the end of the program more sensitive to issues affecting software quality cost and life cycle This does not mean however that those individuals will actually apply everything they have learned Previous studies Germain Dulipovici and Robillard 2002a Ge
34. al conclusions can be drawn although these conclusions need more experimentation in order to be validated The effort expended on core activities within each development project is more or less independent of the software engineering process used Rather one process will emphasise a particular type of activity over another This shifted emphasis does not have a spectacular effect on the overall distribution of the cognitive activities performed One possible interpretation is that some cognitive activities will require a minimal effort investment regardless of the software process used We observe that a well defined software process such as the UPEDU will put more emphasis on the engineering aspects of the software implementation by stress ing the pre coding activities while the XP based process will put more emphasis on ad hoc communications While these observations are totally in line with the definition of the processes involved what is most interesting is that these differ ences between processes are simply not as great as one may have expected and have no impact on the effort intensive coding related activities We did not observe any significant relationship between the requirement for explicit artifacts for the UPEDU teams and the productivity of those teams Infor mal discussions with the participants who used the UPEDU revealed that most of 66 them did not feel the benefit of having produced those artifacts One possible ex plan
35. analysis Figure 3 4 illustrates the aggregate effort distribution by activity as a percentage of total effort expended for all teams The diagram also shows the relative amounts of effort for each state oriented category The Code and Code amp Test activities have aggregate relative weights of 29 and 21 respectively All other activities have weights in the 3 to 11 range Activities in the Active category include almost 75 of total effort Figure 3 5 shows the aggregate information for each process model The sep 57 100 Interactive 90 80 Inspect Review Discuss 70 Browse Search 60 amp Read Think 50 z Draw Write O 40 El Integrate 8 Test 30 a Test Code amp Test 20 1 Code 10 0 XP UPEDU Figure 3 5 Aggregate effort by cognitive activity by process aration between state oriented categories is shown with bold dotted lines while the separation between the Draw and Write activities and the other activities in the Active category is shown with thinner dotted lines Coding and testing activities are less intensive under the UPEDU However the Draw and Write activities include more effort under this process model bringing total effort under the Active category to almost identical
36. and quantitative under standing of the behavior of software engineers Since the theoretical foundations required to achieve this understanding are not currently well defined maturity re mains a utopian vision A symptom of the paucity of general knowledge on the process is the lack of a consensus with respect to the newly emerging approaches to software development as they represent a major break from what we may refer to as the classical school of software development The reason for this lack of consensus is that very few studies have been carried out comparing the various proposed approaches from a global perspective One challenge which the researcher may face in the search for a way to usefully compare software development approaches is to find a suitable context in which to make such a comparison It is extremely difficult for example to apply a number of software processes to a single set of specifications and avoid interference in the analysis from project related factors Obstacles like these must be removed if comparative studies in industry are to be executed on a large scale One way to solve this problem is to identify characteristics of the behavior of software engineers which do not vary with project conditions as this would permit valid analysis in a multi project context xii This research is aimed at improving the state of knowledge on the relationship between software development process and project characteristics theo
37. applicable to estimation techniques Boehm Clark Horowitz Westland Madachy and Selby 1995 apply here too First estimation will always become more accurate as the project advances whatever techniques are 93 used Second databases of historical data will continue to be required in order to adapt to local project and team conditions The main contribution of this paper is to show that process monitoring and control based on effort patterns and on a categorization by discipline is likely to be a practical approach and that the proposed discipline scheme has very good potential to achieve that goal This is not a trivial issue as other categorization schemes may not necessarily lead to converging patterns Germain and Robillard 2004 tested two different categorizations while analyzing patterns of cognitive activities performed in the 2002 edition and found that one of them was much more sensitive to the process used Other potentially interfering factors include individual team development style which remains extremely difficult if not impossible to control without implementing a software process that is very restrictive 4 7 4 Study limitations Limitations applicable to this kind of study and already mentioned in Germain and Robillard 2004 apply here too Thus as discussed earlier student developers behavior could be substantially different from professionals behavior This shows that our observations should be general
38. ata related to the maintenance phase which was initially set up to measure the relative maintainability of each software system We suspect that the various design choices made by the individual teams may have had a significant impact on the effort patterns deployed and therefore on their convergence Potential sources of team productivity variations are many for instance pro ductivity gaps between individual developers are often very important see for Fonte Active 30 20 10 0 Preparation e Implementation O Inspect Review A Discuss Browse Search El Read E Think E Draw Write Integrate amp Test Test E Code amp Test O Code Figure 3 3 Effort distribution by activity by team 94 59 instance Brooks 1995 chapter 3 and may generate even wider gaps at the team level Cockburn 2002 chapter 4 In order to eliminate the influence of such vari ations all effort data has been normalized relative to total effort for a given team Figure 3 3 clearly shows wide variations in intensity among teams for each cognitive activity taken individually This result shows that effort convergence at the cognitive activity level is low However relative effort expended on active cognitive activities see left side of Figure 3 3 falls into the 71 to 76 range which is narrow This suggests a very strong inherent behaviour characteristic which is i
39. ation is that since the project was very small most relevant information could be mastered easily by the participants and communicated verbally with greater efficiency than through the time consuming production of documents Of course it is possible that such an explanation may represent more of an impression than a concrete reflection of the true characteristics of developer behaviour 3 5 4 Teaching software development The main advantage of a well defined software engineering process is that stu dents are aware of the various activities that are likely to be needed for the proper development of a software product They may thus decide to put more emphasis on a particular activity while at the same time being able to anticipate the impacts of their decisions It is not clear whether XP as a whole is suitable for teaching at the undergraduate level or not It is already recognized that XP is aimed at teams of talented and experienced individuals Indeed experience often comes from using a more structured approach from which one can pick the valuable aspects and throw away the rest XP is often learned through the pairing of an experienced program mer with a junior one Academic environments at least in their usual form do not fit in well with such an approach However it may be important to familiarise students with the nature of XP or another agile methodology once they have been trained in a more classical process approach Of course
40. cs Engineers 83 p STANDISH GROUP 2001 Chaos chronicles version 2 0 316 p STAPLETON Jennifer 1997 DSDM Dynamic Systems Development Method The Method in Practice Harlow Addison Wesley 192 p TICHY Walter F 2000 Hints for reviewing empirical work in software engi neering Empirical Software Engineering 5 4 309 312 UMPHRESS David A HAMILTON Jr John A 2002 Software process as a foundation for teaching learning and accrediting Proceedings of the 15th Conference on Software Engineering Education and Training CSEET 02 Los Alamitos IEEE Computer Society P 160 169 UNIVERSITY OF SOUTHERN CALIFORNIA 1998 COCOMO II model definition manual En ligne ftp ftp usc edu pub soft_engineering COCO MOIT cocomo97docs modelman ps WELLS Don 2003 Don t solve a problem before you get to it IEEE Software 20 3 44 47 118 WILLIAMS Laurie KESSLER Robert R CUNNINGHAM Ward JEFFRIES Ron 2000 Strengthening the case for pair programming IEEE Software 17 4 19 25 WILLIAMS Laurie UPCHURCH Richard L 2001 In support of student pair programming Technical Symposium on Computer Science Education Pro ceedings of the Thirty Second SIGCSE Technical Symposium on Computer Science Education New York ACM Press P 327 331 WILLIAMS Sam 2002 A unified theory of software evolution En ligne http www salon com tech feature 2002 04 08 lehman index html
41. ctors 4 5 1 Regular and coherent project progressions 4 5 2 Coherent progressions with tilt towards coding 4 5 3 Incoherent progressions 2 44 Lu LAN Se RE RE Non cumulative perspective on regular coherent progressions AAN SS ma Ui a gees aa eG EPS Es EG ete eo eves 4 7 1 Coh rence and regularity stos des Maes dre ak du os 4 7 2 Development cycle and key milestones for regular and coher Clit PFOETESSIONS e seal ax a oe See ee vk ee ee eee 4 7 3 Impacts on effort estimation and process control xvii xviii ATA Study imitations adds Sy fet da he et As 93 4 7 5 Effort distribution does it make sense 94 AS CONCISO tt Ge ihe Ge Nao hes Gg Aih 94 CHAPITRE 5 DISCUSSION G N RALE 97 5 1 Calibration des charges de travail 97 5 2 La classification en disciplines 98 CONCLUSION 25 2 sms Lam A RS eg SA Re 103 BIBLIOGRAPHIE gt si image die PM ae AN EL 108 1 1 1 2 1 3 1 4 1 5 3 1 3 2 3 3 3 4 3 9 3 6 3 7 4 1 LISTE DES FIGURES Mod le conceptuel fondamental du RUP traduit de Robillard Kruch ten et d Astous 2003 arcoiris Mod le bidimensionnel de processus et de cycle de vie du UPEDU traduit de cole Polytechnique de Montr al 2002 D finition des jalons au cours du cycle de d veloppement traduit de cole Polytechnique de Montr al 2002
42. d coherent 20 gt 40 progressions as a function of project advancement 87 60 40 Coding 20 A 1 Coding 2001B 100 Coding 2003B 80 Coding Avg 60 vey E VEv 20018 40 SAAT ee VaV 20038 seo SF a gs pee A Po A A 5 e ee ee sae Vevey 100 Engineering 2001B 80 Engineering 2003B a n 60 OS Engineering Avg as E ES ss Engineering 0 40 US ta N 5 Ma Y O oa Ni 20 O Wii PS 25 Fe mn i 0 gt 20 20 gt 40 40 gt 60 60 gt 80 80 gt 100 Figure 4 13 Non cumulative effort for team projects with irregular but coherent progressions as a function of project advancement 88 low increase in V amp V activities However the diagram also shows that while the patterns of engineering activities are quite similar to those of the team projects with regular progressions coding effort curves have much higher peak values whether on average 79 vs 47 or for extrema the peak for the lower curve in Figure 4 13 is indeed at 79 while the lowest of the four peaks in Figure 4 12 is at 61 This particular behavior seems totally independent of project absolute effort values We can also see that there is indeed some increase in V amp V activities in Figure 4 13 but that as opposed to the increase in Figure 4 12 it does not take place until after 80 of the projects have been completed
43. demeure utopique pour l instant car la fondation th orique n cessaire son accomplissement n est pas bien ancr e l heure actuelle Ainsi les connaissances sur les d terminants des caract ristiques d un processus logiciel r el c est dire tel qu appliqu sont limit es Or le d veloppement de mod les valables qu ils soient simples ou complexes ne peut tre r alis avec assurance qu avec une fondation th orique minimale Un des sympt mes de la pauvret relative des connaissances g n rales dans le domaine est l absence de consensus face l mergence d approches qui tranchent radicalement avec les enseignements de ce que nous appellerons l cole classique du d veloppement de logiciels Ainsi les derni res ann es ont t marqu es par l mergence de m thodologies dites agiles Cockburn 2002 et notamment de la programmation extr me Extreme Programming ou XP Beck 1999 Cette der ni re pr ne essentiellement le rel chement des efforts sp cifiques en mati re de planification d analyse et de conception la faveur d une strat gie de r duction des co ts du changement et de retardement des d cisions principales en mati re de requis et de conception Les processus traditionnels voir par exemple Kruchten 2000 au contraire pr conisent l application rigoureuse de pratiques d ing nierie et de gestion ainsi que la production de plusieurs art facts Il est int ressant de note
44. described in this paper covers the three following Studio edi tions 2001 2002 and 2003 Although some general principles apply to the design of all three editions substantial differences do exist Projects technologies processes specific pedagogical objectives coaching style guidelines to students instructor at titude team sizes and effort recording schemes and tools all varied to some extent from one edition to another The 2001 edition for example featured the develop ment using Java related technologies of a Web based effort recording tool similar to the one that was used by the participants to carry out their own effort logging activity The 2002 edition which is described in detail in Germain and Robillard 2003 featured the development of a Web based meeting scheduling system The implementation had to be performed using Java related technologies and Oracle databases In 2003 the project would involve performing major maintenance oper ations on one of the systems developed during the previous year The technological base remained essentially the same except for the fact that students were required to make the system work with the latest releases of the Java Runtime Environment 4 3 Team projects under study A total of 15 teams participated in all three editions under study Only eight team projects were selected for this comparative analysis because of the quality 74 800 700 600 500 400
45. e a key measure of project success or failure using it as an indicator of process control makes a great deal of sense Third using effort data to confirm that a software process is under control implies that the same data can theoretically be reused to feed an estimation model MacDonell and Shepperd 2003 have studied the effort expended in sixteen software development projects undertaken by a single organization in order to de termine the viability of prior phase effort analysis for re estimation in the course of a project They found little support for the idea of standard proportions of effort distributed between phases However their approach involved comparing the effort expended during successive phases of a project The notion of distinct engineering disciplines applied concurrently towards a succession of phases as im plemented for instance in the Rational Unified Process Kruchten 2000 was not used in that study Including the notion of engineering disciplines adds a potentially 71 useful level of refinement to the problem at hand An academic platform has been used for several years for the purpose of record ing the effort expended in software development projects The Software Engineer ing Studio is both a project oriented course aimed at senior students in software engineering at the Ecole Polytechnique de Montr al and a research setting which permits the observation of actual software process activities in the contex
46. e costs of change become too high assuming these costs will rise exponentially as generally assumed in the traditional software engineering community Pressman 2000 Second the value of the various artifacts that are developed through the project will be felt the most when another development team tries to maintain the software product particularly if the original team members are not available for consultation Unfortunately our study neither confirms nor denies those statements The benefits of mandatory design activities and artifacts are most evident in large projects while the setting featured a small project Measuring those benefits would require the realization of a similar study using a much larger project Also the impact of the methodology on product maintainability could only be measured through the realization of maintenance activities on software products developed using different methodologies The Studio class as established can constitute a very suitable environment for such maintenance projects 63 The validity of the study rests heavily on the level of confidence that exists in the effort slips entered by the participants Difficult experiences from earlier editions of the Studio show that the instructors cannot wait until the end of the semester to validate the data as recorded Such validation must occur in a continuous manner and be enforced through weekly meetings with participants All irregular situations for ins
47. eetings for this period List Active Meetings General Calendar Es a TT 0 internet Ad marrer 14 D i EPX Gestion des r uni AAA 18 02 Figure 3 1 Screenshot from a completed product 45 46 UP UP1 U P2 U P3 UPM EQ EQ1 EQQ EQ3 EQM XP RP xs RP xs XP 10 15 T 25 i 30 35 40 ae 50 55 60 Figure 3 2 Software development schedule in working days each team would follow one of the two proposed software development approaches One of the goals of the study was to determine the influence of the software process on the participants behaviour Thus three of the teams were assigned a process based on the UPEDU The other three teams were assigned a process built around the Extreme Programming methodology Figure 3 2 illustrates the prescribed software development schedule The top row shows the timeline of iterations for UPEDU while the bottom row shows the same information for XP The lower scale represents the nominal number of academic calendar days since the beginning of the project For example iterations UP3 and XP5 both finished on the 45th day of the project The middle row illustrates the timing of the equivalent iterations that had been defined for data analysis purposes and which are explained below A common release level framework was used to define the development schedule 47 for both processes Thus for all the teams an initial specifications document was provided at the beginn
48. ementation of our cognitive activity classification to the comparative analysis of two process models one based on the UPEDU the other based on XP These observations should not be readily generalized to industrial practices because of the academic nature of the setting and the impact of the particular project life cycle and technology chosen Besides repeating such an experiment in an industrial setting would be quite difficult because of the need to record indi vidual cognitive activities at the developer level However we think that the study presented in this paper provides clues which may be useful when evaluating the importance of a specific software engineering process 43 3 2 The Software Engineering Studio The Software Engineering Studio is an optional project oriented course offered to senior year students in computer engineering at the Ecole Polytechnique de Mon tr al Its purpose is to allow students to gain practical experience in software devel opment by participating in a small scale software development project Teams of students must develop a complete implementation based on software requirements specifications provided by the instructors Also they must use a well defined soft ware engineering process Participants thus acquire experience early on in building an entire operational software project through design implementation testing and management activities This project course teaches them the realities of teamw
49. es langages de mod lisation associ s Les auteurs pr tendent notamment que cette situation d favorable d coule du peu de flexibilit des environnements d velopp s jusqu ici et non de probl mes structurels Ainsi les environnements d velopp s dans le futur auront un bien meilleur impact s ils tol rent par exemple la d viation explicite du processus par les d veloppeurs A l inverse Lehman 1987 pr tend que la programmation de processus telle que d finie par Osterweil ne peut que d tourner la collectivit du g nie logiciel des probl mes r els auxquels la discipline est confront e plut t que de contribuer a la r solution de ceux ci Pis encore au lieu de contribuer a clarifier la nature des processus r els elle cr e plut t Villusion du progr s Ainsi quoique les programmes de processus soient th oriquement utiles pour l expression formelle des processus ils ne sont d aucune utilit pour l am lioration de notre compr hension des dynamiques obscures qui composent encore aujourd hui la plus grande partie de la discipline Du m me souffle Lehman mentionne For applications commonly termed programming in the large which provide the real challenge for software engineering as distinct from pro gramming methodology models of the application as a whole or of many of its parts do not in general exist there is no theory of program de velopment there is no global and formalisable developme
50. essus au sens large 1 3 1 L estimation de l effort La mesure des processus logiciels a traditionnellement t r gie par le besoin d obtenir des estimations pr cises de l effort d ploy L valuation des co ts d un 2 projet d ing nierie est requise afin de permettre la prise de diverses d cisions ou l valuation de certaines informations accord pour le d marrage ou la poursuite du projet construction ou achat d termination du prix de vente calcul du rende ment des investissements allocations budg taires Ostwald 1992 Le g nie logiciel discipline qui constitue ni plus ni moins que l application de l ing nierie au logiciel Standards Coordinating Committee of the Computer Society of the IEEE 1990 ne fait pas exception la r gle Il faut noter toutefois que comme les co ts de main d uvre constituent g n ralement une tr s forte proportion des co ts glo baux de d veloppement et de maintenance d un logiciel Fenton et Pfleeger 1997 Florac et Carleton 1999 l valuation de l effort requis dans le cadre d un projet s av re souvent le d terminant le plus important du co t pr visible de celui ci Or la qualit g n rale des estimations de co ts et d ch anciers en g nie logiciel est d une faiblesse notoire Fenton et Pfleeger 1997 Le Standish Group 2001 dif fuse les statistiques suivantes portant sur l tat de l industrie am ricaine du logiciel au cours de l ann e 200
51. esult of restructuring the underlying activity classifi cation Ultimately a useful target would be to define a cognitive activity set that is powerful enough to provide invariance at a very fine granularity level This is far from being achieved as yet since variability between teams at the individual cognitive activity level is very considerable In the meantime there might be some important benefits to testing the hypothesis of invariance of the Active category in a few industrial settings under various processes or methodologies in order to establish its validity and usability in practice We applied the principle of effort normalization relative to total effort by teams throughout this study and thus did not analyse in detail the relation between overall effort and its distribution by cognitive activity Such an analysis would be useful but would require a better understanding of the factors that influence total effort output for a given team such as team size and schedule compression This in turn would be best achieved using a larger number of teams as well as multiple studio editions Such a strategy would allow the identification of factors of influence coming from particular conditions 65 3 5 3 Participants behaviour This study illustrates among other things a basic observation of team software development based on two different software engineering processes In spite of the limited scope of the study a few gener
52. eu industriel Par ailleurs l tude visait galement tablir le degr appropri de granularit des disciplines utilis es aux fins de l analyse de la r partition de l effort En ce sens le premier article a permis d ouvrir la voie l approfondissement de la question des patrons d effort dans la perspective du degr d avancement d un projet Quant au second article il vise ouvrir une fen tre permettant de sortir du carcan de l analyse en mode mono dition en montrant que certains patrons d effort transcendent les caract ristiques de projet et d quipe Cette d marche est cruciale pour l application ventuelle des analyses de patrons vers le milieu industriel o la pr sence de projets similaires r alis s en parall le par des quipes de d veloppement 37 distinctes constitue l exception plut t que la r gle En somme le choix et la s quence des articles int gr s dans ce m moire re fl tent une progression s quentielle naturelle des travaux vers la r alisation future d analyses de patrons d effort en milieu industriel Par ailleurs trois articles de conf rence auxquels l auteur a contribu ont t inclus sur un disque compact qui accompagne ce m moire Le contenu du disque est pr sent bri vement l annexe II Les deux premiers articles Germain Du lipovici et Robillard 2002a Germain Robillard et Dulipovici 2002b portent sur l dition 2001 de l Atelier et ill
53. few key external components by more than one team Total absence of knowledge transfer would have been very difficult to achieve in practice Effort performed in the context of this analysis made up the entire contribution to the realization of a frozen software requirements specifications document Using evolving requirements in the course of a project would bring a very interesting di mension to such a study in the future Requirements evolution is a usual part of software development and constitutes a strong basis for the justification of the XP approach by its promoters However we predict that the impact of such a change on the effort mix would be quite limited unless some other major changes are im plemented in the setting such as making teams swap their respective projects after 62 a delivery milestone In any case it is important to understand that responsiveness to change is highly influenced by the previous design choices made by a team which in any case suffers from lack of experience Measuring effort expended in such a context would therefore include the additional challenge of trying to exclude the influence of that factor which may prove very difficult in practice Two important objectives are at the centre of the case for engineering oriented processes First well defined design activities and artifacts are meant to ensure that important design decisions especially at the architectural level are made properly and before th
54. fins de contr le d un projet soit l analyse par arbre de classification les variables dynamiques l analyse par grappe Cluster analysis la d tection des changements de tendance L une de ces approches l analyse par grappe peut s av rer particuli rement utile pour l analyse des patrons d effort d ploy s au cours d un projet Les m triques de projet recueillies touchant l effort ou toute autre variable de processus sont repr sent es par un vecteur multidimensionnel compos de valeurs mesur es au tant de p riodes distinctes La technique d analyse par grappe permet de cerner des ensembles de donn es qui affichent le m me comportement et ce afin de r per torier des groupes de patrons similaires Le calcul de la distance euclidienne entre les vecteurs permet la cat gorisation des grappes Li et Zelkowitz 1993 ont utilis des vecteurs 15 dimensions ainsi qu un chantillon de 24 projets afin de relever les patrons mergeant de huit indicateurs distincts dont l effort total employ La seg 33 mentation de l chelle temporelle a t r alis e en subdivisant chacune des quatre phases des projets en un nombre variable de portions L application de la technique sur les projets existants a permis d illustrer selon les auteurs le pouvoir pr dictif d une telle approche Ce constat am ne naturellement envisager l utilisation des donn es empiriques recueillies e
55. ftware system construction focuses on integration and validation issues 92 4 7 3 Impacts on effort estimation and process control These observations open the way to substantial improvement in the way we perform process monitoring in software engineering Thus it should be possible to determine the appropriate effort mix at any given time Major discrepancies from accepted patterns may signal a process which is out of control This subject is discussed extensively in M nch and Heidrich 2004 Selby Porter Schmidt and Berney 1991 In particular identifying such situations and applying countermea sures are tasks which are likely to be much more effective using an approach by discipline than using a single indicator of cost overrun as problematic situations may be identified earlier in the course of the project One key aspect of such an approach is determining the actual state of project advancement at a given time A few distinct approaches may be used depending on the variables that have generated the most confidence For instance under some circumstances project advancement may be estimated by artifacts such as architecture documents which can then be used to compare actual and theoretical curves for that completion level Conversely project advancement at a given time could possibly be calculated by analyzing effort patterns as drawn up to that point leading to re estimation of total project effort Of course the limitations
56. h discipline involved in the 78 software engineering process This can be misleading as the relative weights of disciplines are likely to vary over time Germain Robillard and Dulipovici 2002b We have therefore taken snapshots of the cumulative relative effort at 20 40 60 80 and 100 of project completion The next eight figures show 2D plots of the evolution of the position for each team project in terms of the relative discipline ratios for each 20 of the project s duration The sequence of point positions represents the evolution of the relative effort by discipline throughout the project It is important to note that by nature these diagrams are cumulative and therefore that the effort slip sample is much lower at say 20 than at 100 Project advancement steps for a given team project have been defined as the ratio of cumulative effort expended at a given position to the total effort expended in the whole project 4 5 1 Regular and coherent project progressions Figures 4 4 4 5 4 6 and 4 7 show progression of the discipline ratios for a first group of four similar team project patterns The four progression patterns shown are clear smooth and coherent although pattern details differ from one team project to another These diagrams show that at the 20 stage in project advancement the effort was mostly invested in the engineering discipline At the 40 stage some V amp V and coding effort was added pushing the
57. ii similar to UPEDU The objective of the study was to identify the patterns that emerged throughout the entire software development cycle in the effort distribution diagrams associated with the disciplines involved The requirement specifications submitted the lengths of the development cycles the technologies used and the effort recording methods and tools employed all varied to some extent from one edition to another The number of participants also varied from team to team The activities were classified into three disciplines in order to permit substantial segregation of the activities while at the same time minimizing the effect of factors related to the edition used or the size of the team The results revealed a ten dency towards moderate convergence of the relative proportions of the activities performed by the teams Moreover these proportions evolved in a similar way over time for a majority of the teams The effort expended progressed from an initial phase in which the focus was engineering activities their weight decreasing gradu ally over the duration of the phase to a second phase characterized by a balance between coding and validation and verification V amp V activities which endured to the end of the project This balance shifts shortly before the end however where there is a stronger emphasis on V amp V activities By showing the independence of the behavior of software engineers from pro cess and project conditions this
58. ing New York IEEE Computer Society Press P 2 13 OSTWALD Philip F 1992 Cost estimating Handbook of Industrial En gineering Sous la direction de Gavriel Salvendy 2nd ed New York Wiley P 1263 1288 PALMER Stephen R FELSING John M 2002 A Practical Guide to Feature Driven Development Upper Saddle River Prentice Hall PTR 271 p PAULK Mark C CURTIS Bill CHRISSIS Mary Beth WEBER Charles W 1993 Capability Maturity Model version 1 1 IEEE Software 10 4 18 27 PRESSMAN Roger S 2000 Software Engineering A Practitioner s Approach 6th ed Boston McGraw Hill 860 p RISING Linda JANOFF Norman S 2000 The Scrum software development process for small teams IEEE Software 17 4 26 32 ROBILLARD Pierre N 1996 Teaching software engineering through a project oriented course Proceedings of the 9th Conference on Software Engineering Education CSEE 96 Los Alamitos IEEE Computer Society P 85 94 ROBILLARD Pierre N 1998 Measuring team activities in a process oriented software engineering course Proceedings of the 11th Conference on Software 116 Engineering Education and Training CSEET 98 Los Alamitos IEEE Computer Society P 90 101 ROBILLARD Pierre N KRUCHTEN Philippe D ASTOUS Patrick 2001 YOOPEEDOO UPEDU A process for teaching software process Procee dings of the 14th Conference on Software Engineering Education and Training CSEET 01 Lo
59. ing of the semester A complete implementation of that specification was due after 45 days Thereafter a second specifications document was issued which requested modest architectural changes to the system Imple mentation of those changes was due following a further 15 day period Iterations XP1 through XP5 and UP1 through UP3 belong to the initial development cycle while iterations XPM and UPM belong to the maintenance phase An important element to mention is that no specific constraints were imposed for specific inter ations other than the requirement to deliver specification compliant end products and linked artifacts at the end of the development cycle In other words all ac tivities could be performed at various levels within all iterations Thus teams had complete freedom to schedule development work throughout the development cy cle Evaluating workload and risks as well as scheduling development work are part of the tasks that a software engineer must be able to perform on an autonomous basis The concept of iteration applied here complies with the definition found in Robillard Kruchten and d Astous 2003 An iteration is a mechanism that enables the interaction between the software life cycle and the software process by defining milestones that are often associated with the phases of the product Sets of iterations are also used to define the software process 48 Iterations are common to both traditional and agile proces
60. ing ou XP Selon les observations effectu es le choix d une approche particuli re a un impact limit sur les activit s cognitives r alis es par les quipes tudi es Cet impact mesur en termes relatifs se manifeste surtout l gard des activit s d inspection et de r vision des travaux r alis s Une seconde tude qui a port sur les ditions 2001 2002 et 2003 a permis d analyser les caract ristiques de l effort d ploy par les membres de huit quipes ayant travaill a partir de trois ensembles de sp cifications diff rents mais suivant des mod les de processus tr s fortement inspir s du UPEDU L objectif vis par cette tude consistait rep rer des patrons au sein des diagrammes de r partition de l effort relatif en disciplines travers le cycle complet de d veloppement d un syst me logiciel Les sp cifications soumises les dur es de cycle de d veloppement les technologies utilis es et les m canismes de cueillette de l effort d ploy variaient divers degr s d une dition l autre Le nombre de participants diff rait galement d une quipe l autre Une cat gorisation en trois disciplines des activit s r alis es a t d finie de mani re permettre une s gr gation substantielle des activit s tout en minimisant l influence des facteurs li s l dition ou la taille de l quipe L analyse r alis e montre une convergence mod r e des proporti
61. it d une livraison est constamment retard e Ce retardement contribue r duire le co t net du projet Pour cette m me raison les caract ristiques initialement souhait es mais pour lesquelles l int r t du client diminue au fil du projet finissent par ne jamais tre implant es ce qui 23 D veloppement Maintenance m It rations El S 2 S y 3 ES gt o 5 S S S 3 x SN Figure 1 5 Mod le simplifi du cycle de d veloppement et de maintenance en programmation extr me a des effets directs sur le co t du projet L obtention de revenus est plus rapide tant donn la facturation chaque livraison ce qui diminue le risque financier associ au projet all ge les besoins en liquidit s et augmente la valeur nette du projet Le risque d chec est r duit gr ce la validation constante de la valeur du projet par le client La figure 1 5 illustre un mod le simplifi du cycle de d veloppement et de mainte nance en programmation extr me bas sur Ambler 2002 Beck 2000 Le cycle de d veloppement ou de maintenance constitue le c ur du mod le Il englobe les phases de planification de d veloppement it ratif et de d ploiement Chaque ex cu 24 tion du cycle m ne une livraison du logiciel Le cycle assurant la livraison initiale est appel cycle de d veloppement alors que ceux d bouchant sur les livrai
62. ized with great care Also the validity of the study rests heavily on the level of confidence that exists in the effort slips entered by the participants However the larger number of projects analyzed in the present study as well as the remarkable convergence of effort mix patterns between 94 team projects contributes to attenuating but not eliminating that factor 4 7 5 Effort distribution does it make sense This study shows that the coding discipline covers on average 45 of total effort and that direct component implementation activities account for approxi mately two thirds of that percentage Do these figures make sense A study per formed by the Bangalore SPIN 2001 on projects averaging 30 000 lines of code has shown that coding and unit testing activities amounted to approximately 42 of the effort devoted to non management tasks Meanwhile a technical report by the Davis and Mullaney 2003 shows that for a sample of projects in which the Team Software Process TSP was used Humphrey 2000 effort devoted to coding compiling performing test set ups and unit testing amounts to 40 of the total or 42 if we exclude planning and post mortem work These comparisons allow us to have some confidence albeit in a limited way in the relationship between the behavior of software engineering students in small projects and that of more experienced developers in larger projects 4 8 Conclusion This paper has presented an
63. levels for the two process models 58 2 1 5 1 XP E gt i m UPEDU 0 i a ai TO i T 0 5 1 S c Y gt P xe e a x SE e Ko a w ANA e s e Ae SI O se SF Figure 3 6 Weight index by cognitive activity 3 4 3 Inter process analysis Figure 3 6 illustrates the relative weight of each cognitive activity in the two process models The Process Activity Index PAI for a given activity is defined as PAI In Eyp Exp where Eyp and Eyp represent the amount of relative effort performed by the UPEDU and XP teams respectively for that activity Thus an index value of zero indicates identical effort for a given activity Negative index values mean that the effort is greater for the XP teams while positive index values mean a greater effort for the UPEDU teams Activities are ordered by increasing index value 59 Figure 3 6 illustrates the essence of the cognitive activities of the two processes Positive indices shown for the Draw and Inspect Review activities were to be expected since those cognitive activities while required under a UPEDU like process are not covered at all by the XP methodology Under XP production of diagrams is not recommended by some of the principal gurus see for instance Jeffries Anderson and Hendrickson 2001 Ch 16 while inspection and revision are theoretically perf
64. m me probable des capacit s de design d une quipe de d veloppement dans le contexte de l absence de compr hension des facteurs qui justement font qu un concepteur sera meilleur qu un autre Le pr sent travail repose explicitement sur l hypoth se selon laquelle la recherche sur les processus du g nie logiciel doit viser un objectif d laboration de mod les permettant de mieux comprendre les facteurs qui les r gissent notamment les fac teurs humains Nous croyons que cette recherche contribue faire progresser l tat des connaissances dans les domaines d crits par Lehman lEn italique dans le texte 11 1 1 2 Revue des principaux mod les de processus En l absence de mod les quantitatifs formels du d veloppement de logiciels mod les qui auraient permis de d velopper un ou plusieurs mod les quantitatifs g n riques de processus logiciels certains intervenants des milieux acad miques et industriels ont tabli divers mod les de processus qui reposent la fois sur certains principes issus de la recherche actuelle ou pass e et sur des heuristiques d cou lant d ann es d exp rience individuelle ou collective en mati re de d veloppement de logiciels Nous survolerons ici de mani re non exhaustive quelques uns de ces mod les Il incombe cependant avant de r aliser ce survol de faire la distinction entre les types de mod les de processus suivants les mod les pr dictifs qui ont pour fo
65. mati re de processus logiciels il n en demeure pas moins que la nomenclature processus et m thodologies agiles ne constitue pas une dichotomie comme telle Ainsi Glass 2001 num re les forces et les faiblesses respectives des deux approches et plaide pour la combinaison pure et simple des meilleures id es Kruchten 2001 quant lui pr tend que la structure du RUP permet l int gration des caract ristiques de flexibilit recherch es Les m thodologies agiles sont avant tout des m thodologies ind pendantes qui existaient d j pour la plupart au moment de la r daction du Manifeste plut t qu une famille de m thodologies d riv es d une philosophie originelle Pour cette raison nous consid rons qu il convient de passer directement l tude de la m thodologie dont il est question dans ce travail de recherche soit la m thodologie de programmation extr me 20 1 2 2 La programmation extr me La programmation extr me ne constitue pas un mod le de processus pro prement parler mais plut t une m thodologie reposant sur un ensemble de treize pratiques Cette m thodologie d crite en d tail dans Beck 1999 2000 repose sur le rejet du postulat de l augmentation exponentielle du co t des modifications un logiciel au fur et mesure qu elles se d roulent tard dans le cycle de d veloppe ment Pressman 2000 L application des pratiques de la programmation extr me et en particulier
66. mencement inception a pour but de permettre a tous les intervenants de s entendre sur les objectifs du cycle de vie du logiciel Elle est plus importante pour les projets de d veloppement de nouveaux logiciels que pour les projets de maintenance La phase d laboration vise tablir les requis du syst me d velopper et a tablir en d tail l architecture de celui ci La phase de construction vise revoir les aspects perfectibles des requis et produire le syst me selon l architecture retenue La phase de transition comprend la r alisation des tests de validation et des derniers ajustements ainsi que la mise en disponibilit du logiciel aux usagers En ordonn e de la figure 1 2 figurent les six disciplines qui composent le mo d le Chaque discipline constitue un regroupement des activit s susceptibles d tre r alis es afin de produire un ensemble sp cifique d art facts cole Polytechnique de Montr al 2002 Une activit constitue la plus petite unit de travail mesurable effectu e par un membre de l quipe de d veloppement alors qu un art fact est d fini comme tant un l ment d information produit dans le cadre de l ex cution du processus logiciel Robillard Kruchten et d Astous 2003 Les six courbes de la 16 Jalon d objectifs Jalon initial de du cycle de capacit d veloppement op rationnelle Livraison Jalon du produit d architecture du cycle de d veloppe
67. ment Figure 1 3 D finition des jalons au cours du cycle de d veloppement traduit de Ecole Polytechnique de Montr al 2002 figure 1 2 illustrent l effort d ploy au sein de chaque discipline au fil d un projet La distribution de l effort telle qu illustr e est purement arbitraire et ne pr suppose aucunement de l allure des efforts d ploy s au cours d un projet r el La figure 1 3 illustre les jalons associ s chacune des phases du cycle de d veloppement L atteinte d un jalon entra ne l valuation de l atteinte des objectifs de la phase correspondante La phase subs quente peut tre entreprise uniquement dans le cas o ces objectifs sont atteints Le jalon d objectifs du cycle de d veloppement vise valuer les objectifs du projet entrepris Le jalon d architecture du cycle de d veloppement touche l valuation de la port e et des objectifs d taill s du syst me de l architecture choisie et des risques principaux 17 Le jalon initial de capacit op rationnelle vise s assurer que toutes les fonc tionnalit s ont t d velopp es que tous les tests alpha ont t r alis s qu un manuel d utilisation a t pr par et qu une description de la livraison sous tude a t r dig e Le jalon de livraison du produit correspond a la r alisation r ussie de la revue d acceptation de projet Le Object oriented Process Environment and Notation OPEN Open C
68. ment provided and minimally comfortable with the language and technologies The initial iteration has therefore been kept 49 identical in length for both processes Also the maintenance cycle has been limited to a single iteration following general agreement by the students that this would be sufficient considering the limited scope of the changes requested The remaining iterations were set out such that the ratio of XP iterations to UPEDU iterations would be 2 1 Correspondence of UPEDU iteration end dates to XP iteration end dates was required to facilitate analysis of the resulting data in terms of effort expended A set of equivalent iterations EQ1 EQ2 EQ3 and EQM was defined for that purpose Students were free to team up with whomever they wished to and to register for the process model they wanted to use provided that the following three conditions were fulfilled We had to have five teams of four students each and one team of three students Three of the teams had to use the UPEDU and the other three had to use the XP based process The three student team had to use the UPEDU since three people cannot all be pair programming at the same time The only problem we ran into was that two students were competing for the fourth seat on one UPEDU team We chose to break the tie by drawing a winner s name There was no preliminary assessment of the participants skills as it was as sumed that all the students were equally capable of
69. methodologies for software development A comparative case study The Journal of Systems and Software Accept pour publication GERMAIN ric ROBILLARD Pierre N DULIPOVICI Mihaela 2002b Process activities in a project based course in software engineering 32nd ASEE IEEE Frontiers in Education Conference Piscataway Institute of Elec trical and Electronics Engineers P S3G 7 53G 12 GLASS Robert L 2001 Agile versus traditional Make love not war Cutter IT Journal 14 12 12 18 112 HALLING Michael ZUSER Wolfgang KOHLE Monika BIFFL Stefan 2002 Teaching the Unified Process to undergraduate students Proceedings of the 15th Conference on Software Engineering Education and Training CSEET 02 Los Alamitos IEEE Computer Society P 148 159 HENDERSON SELLERS Brian 2000 The OPEN framework for enhancing productivity IEEE Software 17 2 53 58 HIGHSMITH James A 2000 Adaptive Software Development A Collaborative Approach to Managing Complex Systems New York Dorset House Pub 358 p HIGHSMITH James A 2002 Agile Software Development Ecosystems Boston Addison Wesley 404 p HOST Martin 2002 Introducing empirical software engineering methods in education Proceedings of the 15th Conference on Software Engineering Edu cation and Training CSEET 02 Los Alamitos IEEE Computer Society P 170 179 HUMPHREY Watts S 1997 Introduction to the Personal Software P
70. n Robidoux Martin Robillard et Houcine Skalli pour leurs contributions respectives au succ s des Ateliers Aussi ce travail de recherche n aurait pu tre possible sans la collaboration des tudiants qui ont particip aux Ateliers J aimerais galement remercier Les membres du jury pour leurs commentaires constructifs suite au d p t initial de ce m moire Les r viseurs anonymes pour leurs commentaires pertinents lors de la soumis sion du premier des deux articles qui constituent le m moire Th r se Gauthier Shannon Miko et Cynthia Orman pour leurs pr cieux conseils lors de la r vision du m moire Sylvie Nadeau pour ses pr cieux conseils sur le m tier d tudiant aux cycles sup rieurs vi Robert Roy pour m avoir incit me d passer et pour avoir mis XIX sur ma route mes beaux parents et mes amis pour leurs encouragements et les membres de ma famille ainsi que Marc Rochette pour leurs encouragements et leur soutien tout au long de mes tudes universitaires Finalement un merci tout sp cial ma douce moiti Marie Brassard pour ses encouragements ses conseils sa patience sa patience encore son soutien de tous les jours et pour avoir r vis le document final Je t aime vil R SUM Le domaine des processus de d veloppement de logiciels ne saura tre consid r comme mature que lorsque l laboration de tels processus pourra tre fond e sur une c
71. n cours de projet pour la r estimation en ligne du dit projet Le chapitre 4 d crit bri vement les travaux de MacDonell et Shepperd 2003 sur une telle approche 34 CHAPITRE 2 ORGANISATION GENERALE DU TRAVAIL Ce m moire pr sente le fruit d un travail de recherche approfondi qui a port sur trois ditions successives du cours Atelier de g nie logiciel voir Robillard 1996 ainsi que sur deux approches distinctes de d veloppement de syst mes logiciels Les travaux r alis s ainsi que leurs conclusions sont rapport es dans les trois chapitres qui suivent Le chapitre 3 introduit le premier des deux articles qui constituent le corps du pr sent travail L article intitul Engineering Based Processes and Agile Me thodologies for Software Development A Comparative Case Study par Eric Germain et Pierre N Robillard a t accept pour publication par la revue The Journal of Systems and Software L tude de cas pr sent e couvre l application de deux approches distinctes de d veloppement de logiciels dans le cadre de l im plantation de versions multiples d une m me sp cification de requis logiciels Elle a n cessit la d finition d une cat gorisation originale des activit s cognitives r alis es par les sujets de l tude qui taient des tudiants inscrits l dition 2002 de l Ate lier Trois des quipes ont utilis un mod le de processus tr s fortement inspir du Unified Pr
72. nction de soutenir une d marche de pr diction ou d estimation les mod les explicatifs qui ont pour fonction d expliquer le comportement r el des participants au processus et les mod les prescriptifs qui l inverse des mod les explicatifs notamment visent indiquer aux participants les activit s qui doivent tre r alis es dans le cadre de leurs fonctions La pr sente recherche s int resse avant tout aux mod les utilis s g n ralement en milieu industriel qui sont g n ralement prescriptifs Par cons quent nous ne tien drons pas compte ici des autres types de mod les 12 1 1 2 1 Le Rational Unified Process Le Rational Unified Process RUP Kruchten 2000 a t con u par Rational Software Corporation acquise depuis par IBM Il s agit d un mod le de processus it ratif et incr mental centr sur l architecture du logiciel plut t que sur le code Kruchten 2000 Kruchten d finit le RUP comme tant un produit processus process product Le RUP se pr sente sous la forme d un syst me logiciel com prenant essentiellement un site Web interactif ainsi que divers outils comme des mentors des gabarits et des exemples d art facts La figure 1 1 illustre le mod le conceptuel fondamental du RUP Le RUP est constitu de trois l ments fondamen taux le r le l art fact et l activit Un r le constitue une d finition des diverses responsabilit s pouvant tre att
73. ndependent of the process model used By contrast effort distribution between the Reflexive and Interactive categories varies widely from team to team and likewise shows no relation to the process model Implementation activities see right side of Figure 3 3 represent between 49 and 73 of total effort for each team This clearly shows that beyond the central analysis design and testing skills that are rightly promoted within the software engineering community this discipline remains a coding intensive one even when performed by students aware of the importance of software process activities This finding might provide a part of the answer to the question raised in McConnell 2002 How important is software construction Software construction is very important indeed at least in terms of its intensity relative to other categories of activities The only category showing any apparent influence of the process model is the 56 Interactive 6 ET Reflexive 3 AS Code Code amp Test S Test Integrate 8 Test i Write Draw El Think E Read Browse Search El Discuss Ea Inspect Review Active Figure 3 4 Aggregate effort distribution by cognitive activity Control category where all UPEDU teams expended more effort average of 8 than XP teams average of 3 3 4 2 Aggregate
74. ng software is an open problem There can be as many solutions as there are individuals or teams In this study all the teams provided acceptable software products in relation to the requirements specifications issued All were also constrained by a development schedule and met all deadlines Even though the software process used seemed to have an impact on the im portance of some cognitive activities we did not observe any significant relation between the process used and the magnitude of the overall effort Effort expended by the XP teams as a whole indeed exceeded effort expended by the UPEDU 61 teams by a whopping 29 However the external factors that may have affected this figure are numerous and make this result highly questionable The only three participant team was a UPEDU team which showed the least total effort of the six Also the project required quick learning of the Java Servlet technology by the par ticipants Since the XP teams had to start coding almost immediately they faced technological difficulties earlier than the UPEDU teams We observed significant technology related knowledge transfers from the XP teams to the UPEDU teams at the time when the latter started producing code It must be noted that other kinds of knowledge transfers for instance those related to architectural decisions seem not to have occurred Traces of such transfers have not been found in the resulting artifacts except in the form of reuse of a
75. ns Also this study would not have been possible without the participation of all the students enrolled in the three editions This work was partly supported by the Natural Sciences and Engineering Re search Council of Canada NSERC under grant A0141 96 97 CHAPITRE 5 DISCUSSION GENERALE De nombreux l ments de discussion ont t pr sent s l int rieur des deux chapitres pr c dents La pr sente section vient enrichir ces l ments par quelques consid rations d ordre g n ral 5 1 Calibration des charges de travail Le contenu des sp cifications mises a t calibr de mani re refl ter une charge de travail compatible avec un cours de trois cr dits soit l quivalent de 135 heures par tudiant En absence de donn es long terme qui auraient pu alimenter un mod le d estimation en bonne et due forme cette calibration a t effectu e sur la base du jugement des enseignants Selon la recherche effectu e on pose l hypoth se que la charge de travail attribu e aux quipes tait raisonnable compte tenu des ressources et du temps allou s pour la r alisation des projets A titre d illustration deux mod les souvent utilis s pour fins d estimation soit le COCOMO II et le mod le SLIM de Putnam tiennent pour acquis que la relation entre la dur e optimale de r alisation D typiquement en mois et l effort requis E typiquement en personnes mois n est pas lin aire Fenton et Pfleeger
76. nt davantage ex cut es en mode UPEDU qu en mode XP ce qui a t confirm dans un seul des deux cas Bien que cet objectif s appliquait dans une moindre mesure la classification du chapitre 4 la pr occupation de base dans ce dernier cas tait plutot de cerner trois poles d ac tivit s repr sentant des modes de fonctionnement enclench s successivement dans Pex cution d un projet typique Nonobstant ces diff rences la structure commune 102 TAB 5 1 Un exemple de classification en disciplines bas e sur les disciplines originales du UPEDU Requis Implantation Revues analyse planif technique Requis Ing nierie et conception de l int gration analyse et et de implantation conception sauf les revues Programmation Revues Programmation de programmation Implantation d bogage tests unitaires et int gration Validation et v rification VEV Tests aux deux classifications rend possible l tude d une classification plus fine bas e sur la juxtaposition des deux classifications pr sent es Le tableau 5 1 montre un exemple de classification en sept cat gories suivant ce mod le bas e sur les dis ciplines du UPEDU Bien entendu une telle classification reste valider dans le cadre d une d marche empirique tel que discut ci apr s 103 CONCLUSION Ce travail de recherche a permis d approfondir notre compr hension des rela tions entre les caract ristiques des processus et
77. nt procedure at best there is only an abstract process model Dix ans plus tard il d clare Eventually it may be possible to develop generic models but that lies in the distant future Lehman 1997 Les vues de Lehman trouvent cho dans le d veloppement r cent de la pratique du g nie logiciel Ainsi Robillard Kruchten et d Astous 2003 p 41 mentionnent que le d veloppement de logiciels comporte une forte composante opportuniste 10 c est dire qu une d marche exploratoire non planifi e est tr s souvent utilis e afin d identifier les l ments d information manquants qui auraient permis d appliquer une d marche plus syst matique De plus une progression d un mode de d veloppe ment syst matique vers un mode opportuniste est g n ralement observ e au fil de l volution d un projet La pr sence d activit s opportunistes semble difficilement compatible avec le concept de programmation de processus d Osterweil D une ma ni re similaire Brooks trouve dans le processus de construction de logiciels une dimension cr ative cruciale Great designs come from great designers Software construction is a creative process Sound methodology can empower and liberate the creative mind it cannot inflame or inspire the drudge Brooks 1987 Dans un tel contexte nous sommes en droit de nous demander comment la programmation de processus r ussirait compenser pour la faiblesse possible voire
78. o send availability requests to a set of individuals so that each of them can specify personal availability peri ods The set of availability periods would then be graphically represented using a special calendar tool to enable a coordinator to visualise the relevant informa tion at a glance making the scheduling decisions easier The decisions can then be transmitted electronically to all participants The software system would be responsible among other things for ensuring proper data storage and updates as well as for communications among all participants All communications would be performed using standard e mail All the students had to use identical software requirements specifications and were instructed not to add any additional features not explicitly requested Figure 3 1 shows a screenshot from one of the software products delivered The main feature of the Winter 2002 Studio was the use of two different software engineering processes Although all the teams were competing on the same project estion des r unions Microsoft Internet Explorer lex Fichier Edition Affichage Favoris Outils lt Pr c dente gt 2 A Gpechercher Favors Emde A B 3 http faww ral polymtl ca 8080 XPx servlet Main usemame simon polymtl caBpassword 5432108action Connexion K Liens gt Weicome Participant APA REPLAN Meeting Management Simon Smith simonepolymtl ca Availability Calendar for All Meetings M
79. ocess for Education UPEDU mod le de processus d riv du Rational Unified Process RUP Les trois autres quipes ont utilis un processus construit 39 autour de la m thodologie de programmation extr me Extreme Programming ou XP Le chapitre 4 constitue le second des deux articles qui forment le corps de ce travail L article intitul Measuring Relative Effort Progression Paths in the Discipline Space of the Software Engineering Process galement par Eric Germain et Pierre N Robillard a t soumis pour publication la revue IEEE Transactions on Software Engineering L analyse pr sent e vise a cerner des patrons au sein des diagrammes de r partition de l effort relatif en disciplines travers le cycle complet de d veloppement d un syst me logiciel Huit quipes d tudiants issues de trois ditions diff rentes de l Atelier 2001 2002 et 2003 ont utilis un mod le de processus tr s fortement inspir du UPEDU afin de d velopper des syst mes logiciels distincts Les sp cifications soumises les dur es de cycle de d veloppement les technologies utilis es et les m canismes de cueillette de l effort d ploy variaient divers degr s d une dition l autre Le nombre de participants diff rait galement d une quipe l autre Une cat gorisation en trois disciplines des activit s r alis es a t d finie de mani re permettre une s gr gation substantielle des ac
80. ompr hension d taill e et quantitative du comportement des ing nieurs du lo giciel Or cette vision demeure utopique pour l instant car la fondation th orique n cessaire son accomplissement n est pas bien ancr e l heure actuelle et beau coup de travail sera n cessaire avant d y parvenir Un des sympt mes de la pauvret relative des connaissances g n rales dans le domaine est l absence de consensus face l mergence d approches qui tranchent radicalement avec les enseignements de ce que nous appellerons l cole classique du d veloppement de logiciels Cette situa tion d coule largement du faible nombre d tudes comparant dans leur globalit les diff rentes approches propos es Une des difficult s auxquelles le chercheur risque de faire face dans sa qu te d une vue comparative valable a trait la mise en place d un contexte permettant d effectuer des comparaisons valides Il est tr s difficile d appliquer des processus logiciels divers sur un m me ensemble de sp cifications sans que des facteurs li s aux projets ne risquent d interf rer avec l analyse Cette situation constitue un carcan duquel il faut sortir si l on veut ventuellement proc der des tudes comparatives grande chelle en milieu industriel Une fa on possible de rem dier ce probl me est de cerner les caract ristiques invariables du comportement des ing nieurs du viii logiciel par rapport aux conditions de p
81. on the evaluation of explicit mutually exclusive cognitive activities constituted an interesting path to this target Table 3 1 illustrates the classification that was used for the the study Partici pants were presented a total of 14 cognitive activities and asked to tag each effort 51 Table 3 1 Cognitive activity classification Implementation Draw Code joe Write Code amp Test Integrate amp Test Test Browse Search Reflexive Read Think Tateractie Discuss Inspect J Review slip to be recorded with one and only one of these activities Three of these ac tivities dealt mostly with tasks that we wished to exclude from our study such as training and systems administration These activities are not included in Table 3 1 and all effort slips recorded under them have been excluded from this study Although most activity names are self explanatory we provide a short descrip tion of them below Two distinct groupings of cognitive activities were defined for analysis purposes These groupings were not revealed to the participants Each represents one dimension in Table 3 1 The grouping along the horizontal axis called step oriented represents the sequence of steps typically performed in the development of a software product The grouping along the vertical axis called state oriented illustrates the cognitive states likely to be taken during software development The Active state occurs when a devel
82. ons d activit s r alis es par chaque quipe sur l ensemble du cycle de d veloppement La majorit des projets soumis affichent toutefois une volution tr s similaire du type d activit s r alis es au fil du temps Ainsi l effort r alis suit une progression qui d bute par une premi re phase o les activit s li es l ing nierie sont pr dominantes Le poids de ces activit s diminue progressivement ce qui am ne une seconde phase d quilibre entre les activit s de programmation et celles de validation et de v rification Cet quilibre est rompu peu avant la fin du projet en faveur des activit s de validation et de v rification quoique de mani re peu marqu e En montrant l ind pendance relative du comportement des ing nieurs du logi ciel par rapport aux conditions de processus et de projet le travail de recherche ouvre la voie pour l application ventuelle des analyses de patrons d effort vers le milieu industriel Sur le plan th orique de telles analyses pourront permettre d approfondir davantage notre compr hension du comportement des praticiens du d veloppement de logiciels Sur le plan pratique elles pourraient constituer un outil puissant d estimation et de contr le la disposition des gestionnaires de projets et des ing nieurs de processus xl ABSTRACT The software development process field will be considered mature only when the elaboration of such processes can be based on a detailed
83. onsor tium 2002 Henderson Sellers 2000 est un mod le de processus du domaine public qui comme le RUP est it ratif incr mental et bas sur le paradigme orient objet Ce mod le de processus a t con u de mani re pouvoir soutenir de multiples mod les de cycles de d veloppement comme le mod le en cascade ou encore le mod le en spirale Boehm 1988 Le concept de phase n a pas t inclus dans ce mod le On y d finit plut t les termes suivants Une activit est un ensemble de t ches qui se succ dent au moyen de tran sitions formelles pr conditions et post conditions et qui collectivement m nent la r alisation d un objectif long terme et d bouchent sur un en semble de produits de travail Une t che constitue la plus petite unit de travail pouvant tre valu e Une technique englobe l ensemble du savoir faire requis pour la r alisation des t ches la relation entre t ches et techniques tant d finie par le biais d une matrice d adaptation 18 La notion de produit de travail work product correspond approximativement a la notion d art fact du RUP Henderson Sellers 2000 pr tend que The beauty of the OPEN framework is that it does not lay down the law on what you shall and shan t do et qu il peut et doit tre adapt aux organismes et projets vis s Quant au RUP meme s il a t con u de mani re pouvoir tre appliqu int gralement on p
84. oper is performing any activity the pur pose of which is to generate or modify an artifact It includes the cognitive activities Draw and Write which refer to the production of diagrams and text of all kinds 52 respectively It also includes a set of activities which collectively cover everything related to coding integration and testing Code Code amp Test Integrate amp Test and Test This redundant labelling of activities was necessary because under XP these activities are often intertwined in practice Thus all plausible combinations of coding and testing are taken into account Also the Integrate amp Test activity reflects the fact that integration is presumably a short duration activity which immediately leads to testing The Reflexive state occurs when a stand alone developer is performing any activity which does not generate or modify any artifact The Browse Search activity refers to the action of reading documents or Web pages in a non specific order as when searching for documents that will eventually be read while the Read activity refers to the action of reading a specific document such as a textbook or article for the purpose of assimilating a chunk of information The Think activity refers to the process of self reflection and thus encompasses every effort expended by a stand alone participant for which no input or output exists The Interactive
85. ork milestones and time constraints As a secondary objective students become more familiar with a specific application domain or set of technologies An earlier version of the Studio is presented in detail in Robillard 1996 The Studio has also served as a test bed for the study of development effort and artifact quality Some indi vidual studies performed using data generated in a Studio have been documented in Germain Dulipovici and Robillard 2002a Germain Robillard and Dulipovici 2002b and Robillard 1998 Several other software engineering programs imple ment other paradigms of the concept of a Studio For instance Blake and Cornett s Software Engineering II class Blake and Cornett 2002 implemented a setting that was aimed at teaching every step of a typical software development cycle to stu dents split into specialised teams in the context of a single class wide project By 44 contrast in our approach students work in small teams each developing their own version from common specifications Also in our setting students are free to or ganize their work however they wish as long as they deliver the required artifacts at each defined milestone The Winter 2002 Studio featured the development of a Web based meeting management system aimed at organisers of meetings where the number and geo graphic dispersion of participants make scheduling difficult The software system to be developed would allow meeting coordinators t
86. ormed on line in the course of regular pair programming tasks At the other end of the axis the explicit role emphasis on the Integrate amp Test activity reflects the intertwined nature of integration and testing under XP That the activity is performed mainly by XP based teams should not be considered a surprise The presence of the Discuss activity at the very left end of the axis posed more of a question since the XP methodology promotes several teamwork practices such as pair programming It is interesting to observe that each activity in the Interactive category is dominant in one of the process models This suggests a real influence of the process model on the relative intensity of these activities The framed activities in the middle of Figure 3 6 are considered to be equivalent for the two process models since their index values are close to zero Figure 3 7 illustrates calculation of the PAT using the state and step oriented categories The Control category which encompasses little total effort is overex posed here because the index calculation is based on a simple logarithmic function The other five categories are considered to be equivalent for the two process models 60 0 8 State oriented Step oriented 0 6 0 4 l XP m UPEDU 0 2 Figure 3 7 Weight index by category 3 5 Concluding remarks 3 5 1 Study limitations Developi
87. os a E Rues Fos Een 26 1 3 2 La mesure de l effort ta nel ia pels pet 29 1 4 Le contr le des processus eb bea ge oo Sas SEES ES as 31 CHAPITRE 2 ORGANISATION GENERALE DU TRAVAIL 34 CHAPITRE 3 ENGINEERING BASED PROCESSES AND AGILE 3 1 3 2 3 3 3 4 3 9 METHODOLOGIES FOR SOFTWARE DEVELOPMENT A COMPARATIVE CASE STUDY 38 Introduction eE eh a a ee asa eee A ee Sak 39 The Software Engineering Studio 43 Cognitive activity classification kr sd y ee es ee ne 50 Analysis of cognitive activities performed 53 3 4 1 Raw data analysis Sodan ed de nr te de nt de dre ne 53 3 4 2 Aggregate analysis e ees Ae ees aw ees Sale es As 56 3 4 3 nter process analysis a 2 dota tee we ee dite set ve 58 Concluding remarks danita Aa a 60 dl Study imitations Lis LA da its eh Aa YR Awe 3 5 2 Observations on the methodology 3 5 3 Participants behaviour is 3 5 4 Teaching software development CHAPITRE 4 MEASURING RELATIVE EFFORT PROGRESSION 4 1 4 2 4 3 4 4 4 5 4 6 4 7 PATHS IN THE DISCIPLINE SPACE OF THE SOFT WARE ENGINEERING PROCESS IniPOdUCHOl Ss 2 RE eA pe oie eee A ae ee Oy ae ee ase The Software Engineering Studio Team projects under study Overview of disciplines 24 415 4 24 oa M Rs Bs Study of effort distribution invariance relative to project fa
88. oughout the XP lifecycle En ligne http www agilemodeling com essays agileModelingX PLifecycle htm Page consult e le 21 mars 2004 ANTON Annie I 2003 Successful software projects need requirements plan ning IEEE Software 20 3 44 47 BANGALORE SPIN 2001 Benchmarking of software engineering prac tices at high maturity organizations En ligne http www bangaloreit com html itscbng Softengcon2001 B2SIG pdf Page consult e le 21 mars 2004 BECK Kent 1999 Embracing change with Extreme Programming IEEE Computer 32 10 70 77 BECK Kent 2000 Extreme Programming Explained Embrace Change Boston Addison Wesley 190 p BECK Kent BOEHM Barry 2003 Agility through discipline A debate IEEE Computer 36 6 44 46 BLAKE M Brian CORNETT Todd 2002 Teaching an object oriented soft ware development lifecycle in undergraduate software engineering education 109 Proceedings of the 15th Conference on Software Engineering Education and Trai ning CSEET 02 Los Alamitos IEEE Computer Society P 234 240 BOEHM Barry CLARK Bradford HOROWITZ Ellis WESTLAND Chris MADACHY Ray SELBY Richard 1995 Cost models for future life cycle processes Cocomo 2 0 Annals of Software Engineering 1 57 94 BOEHM Barry W 1988 A spiral model of software development and enhan cement IEEE Computer 21 5 61 72 BROOKS Jr Frederick P 1987 No silver
89. ourrait l adapter galement Kruchten 2000 Il est par cons quent difficile d tablir une comparaison entre les deux mod les en pr sence sur cette base comparaison qui d borde du cadre de cet ouvrage 1 2 M thodologies agiles de d veloppement de logiciels L un des deux articles int gr s dans le pr sent ouvrage touche directement luti lisation de la m thodologie de programmation extr me extreme programming ou XP Cette m thodologie fait partie de la grande famille dite des m thodologies agiles Nous pr senterons d abord les caract ristiques g n rales de cette famille puis nous pr senterons plus en d tail la m thodologie elle m me 1 2 1 Survol des m thodologies agiles Les m thodologies dites agiles ont pour but de soutenir le d veloppement de logiciels d une mani re moins rigide que par l utilisation de processus formels Le Manifeste du d veloppement agile Agile Alliance 2003 mentionne les valeurs v 19 hicul es par cette philosophie du d veloppement de logiciels priorit des individus et des interactions sur les processus et les outils priorit du logiciel fonctionnel sur l exhaustivit de la documentation priorit de la collaboration client fournisseur sur la n gociation contractuelle priorit de la r ponse au changement sur le suivi de plans bien d finis Bien que le Manifeste ait t r dig principalement en r action aux tendances contemporaines en
90. peut tre trouv dans M nch et Heidrich 2004 Bien que ces concepts ne se situent pas dans l axe de la recherche effectu e et sont somme toute encore peu utilis s en milieu industriel ils pourraient redevenir d actualit suite aux travaux pr sent s dans le cadre de ce m moire ou dans le cadre de recherches similaires Un centre de contr le de projet logiciel Software Project Control Center ou SPCC tel que d fini par M nch et Heidrich 2004 est un outil assimilable un syst me de contr le de trafic a rien servant de colonne vert brale la d marche de mesure d interpr tation et de visualisation des m triques issues d un processus logiciel Le SPCC utilise un ensemble de m triques recueillies dans le cadre d un projet en cours ainsi qu une banque de m triques issues de projets ant rieurs et g n re une vue contextualis e de ces donn es aux fins de leur utilisation par no tamment les gestionnaires de projets ainsi que le personnel d assurance qualit Un SPCC est form des l ments suivants 32 un ensemble de techniques et de m thodes de contr le de projet un ensemble de r gles touchant l utilisation des techniques et m thodes une architecture logique permettant l interfa age du SPCC avec son environ nement un outil mettant en uvre l architecture logique M nch et Heidrich pr sentent galement quatre techniques et m thodes pouvant tre utilis es aux
91. que le second article est pr sent au chapitre 4 Enfin le chapitre 5 pr sente une discussion globale de la recherche compl mentaire aux conclusions nonc es l int rieur des articles CHAPITRE 1 REVUE CRITIQUE DE LA LITTERATURE 1 1 Processus logiciels Le pr sent chapitre constitue une revue critique de la litt rature pertinente aux nombreux aspects touch s par ce travail de recherche Les deux premi res sections du chapitre traiteront de l objet d tude principal de ce travail soit les processus et m thodologies de d veloppement de logiciels Dans la premi re section l tat du domaine des processus logiciels sera d abord d crit puis trois mod les de processus courants seront pr sent s La seconde section traitera des m thodologies de d ve loppement de logiciels et en particulier de la m thodologie dite de programmation extreme Par la suite la mesure des processus logiciels et de l effort sera abord e dans la perspective o tout travail d analyse empirique comme celui ci doit tenir compte du contexte de mesure Finalement le domaine du controle des processus et de l estimation en cours de projet sera effleur Bien que ces derniers concepts ne soient pas couverts dans le cadre des travaux r alis s ils constituent une avenue de choix pour l exploration des conclusions de la recherche effectu e 1 1 1 Evolution du domaine Fugetta 2000 offre une perspective historique de l volu
92. quite different process from the prescribed one Florac and Carleton 1999 p 9 mention that software processes can perform poorly or be unstable non compliant or incapable of delivering products that meet requirements Unstable processes can sometimes be stabilized by identifying the possible causes of the instability and taking steps to prevent them from recurring Processes lacking in capability will require modification and then stabilization since modification alone is enough to make a process unstable Florac and Carleton 1999 chap 7 Predicting the effort consumed by a process that is out of control is like trying to estimate the total duration of a hitchhiking trip Since hitchhikers do not control the time of pick up where drivers are going or how fast they drive their estimates 70 will be fuzzy at best If time is critical it would be wise to use one s own car or any other more reliable means of transportation In the same way if software needs to be developed in a predictable way then the software process will need to be monitored and controlled to support the desired predictability level The use of effort measurement as a basis for process monitoring can bring with it certain advantages First effort data are likely to be collected for estimation purposes so using an effort based monitoring and control system might reduce or eliminate any additional data collection burden Second since effort will ultimately constitut
93. r que malgr le d bat sur la question voir par exemple Ant n 2003 Wells 2003 les arguments soulev s des deux c t s ram nent souvent soit des aspects th o riques non v rifi s soit des exp riences personnelles difficilement g n ralisables En outre les tudes comparatives document es entre les deux approches sont rares Par ailleurs le chercheur d sireux de comparer deux ou plusieurs approches doit mettre en place un contexte permettant de rendre de telles comparaisons valides Or il est tr s difficile d appliquer des processus logiciels distincts sur un m me ensemble de sp cifications sans que des facteurs li s aux projets ne risquent d in terf rer avec l analyse Cette situation constitue un carcan duquel il faut sortir si l on veut ventuellement proc der des tudes comparatives grande chelle en milieu industriel Une fa on possible de rem dier ce probl me est de cerner les caract ristiques invariables du comportement des ing nieurs du logiciel par rapport aux conditions de projet ce qui permettrait ventuellement de proc der a certaines analyses valides dans le contexte de projets variables Le d partement de g nie informatique de l cole Polytechnique de Montr al uti lise depuis plusieurs ann es une plate forme acad mique afin d approfondir l tat des connaissances sur les processus logiciels Le cours projet Atelier de g nie lo giciel offert principalement aux
94. r la pr sence de tendances non d tect es par notre approche principalement observationnelle Une telle analyse n cessiterait l utilisation d un chantillonnage beaucoup plus important que celui pr sent ici Finalement les derni res recommandations ont trait la m thodologie de me sure proprement dite D abord le contexte de saisie de l effort outil modalit s d utilisation subdivision des activit s approche par activit s cognitives ou par activit s de processus etc peut avoir une influence significative sur les donn es d effort enregistr es par les participants Une avenue de recherche pertinente consis terait a d terminer le niveau d objectivit d une approche de mesure donn e et a 107 relever les alt rations potentielles apport es aux informations enregistr es ainsi que leurs causes Le processus de validation des jetons d effort devrait galement consti tuer l objet d une recherche approfondie Bien que des crit res objectifs existants permettent de guider le travail de la personne responsable de la validation il existe un besoin pour l tablissement d un processus de validation formel assujetti aux m mes crit res de qualit que les processus de d veloppement de logiciels dont nous avons trait 108 BIBLIOGRAPHIE AGILE ALLIANCE 2003 Agile alliance web site En ligne http www agilealliance org Page consult e le 21 mars 2004 AMBLER Scott W 2002 AM thr
95. re conclue 25 Notons que l it ration initiale d un cycle de d veloppement ou de maintenance doit permettre de statuer sur les caract ristiques de l architecture du logiciel construire ou modifier Les principes de croissance du logiciel sur son squelette pr conis s par Beck 2000 sont semblables ceux propos s par Robillard Kruch ten et d Astous 2003 dans le cadre du UPEDU La phase de d ploiement productionizing Ambler 2002 constitue une exten sion de la phase de d veloppement incr mental au cours de laquelle on proc de aux divers tests fonctionnels sur le syst me et effectue les modifications d coulant de ceux ci 1 2 3 Les processus d ing nierie par opposition aux m thodologies agiles La guerre de clochers que se livrent avec plus ou moins de passion les partisans des processus d ing nierie et ceux des m thodes agiles repose sur fort peu de mat riel empirique pertinent Bien que de nombreuses tudes portent sur la comparaison de certains aspects pr cis des m thodologies agiles par rapport leur conception traditionnelle voir par exemple Williams Kessler Cunningham et Jeffries 2000 qui traite de la programmation par paires les tudes comparatives entre les deux approches prises globalement voir par exemple Noll et Atkinson 2003 sont encore rares Une analyse appropri e du comportement r el des ing nieurs du logiciel per mettrait d clairer grandement notre compr hension de
96. respondantes dans les mod les de processus utilis s La classification par tat comporte par ailleurs l inconv nient d tre diffici 101 lement utilisable l ext rieur d un contexte o les donn es d effort sont recueillies selon les activit s cognitives r alis es En effet une activit de processus est suscep tible d incorporer la fois des activit s cognitives li es la r flexion l action et l interaction Ces l ments ne doivent toutefois pas occulter l utilit remarquable de cette classification des fins d analyse empirique ainsi que les conclusions du chapitre 3 le laissent entrevoir La classification par tape poss de une structure similaire a la classification en trois disciplines pr sent e au chapitre 4 Les deux classifications s parent gale ment les activit s r alis es selon leur position par rapport un noyau central savoir l implantation des composants logiciels Les activit s en aval de ce noyau sont plac es dans une cat gorie celles en aval sont plac es dans une autre et les activit s d implantation sont plac es dans une troisi me Les diff rences dans la r partition des activit s au sein de chacune des cat gories tiennent avant tout au role des classifications dans leur tude respective La classification originale par tape avait notamment t con ue avec l id e d isoler sp cifiquement les activit s de pr paration et de contr le suppos me
97. retical or physical and the effort expended by the developers of software systems Our study was conducted using three successive editions of the Software Engineering Studio a project course offered once a year to senior students in the Bachelor of Computer Engineering program Software Engineering Option at the cole Polytechnique de Montr al Two separate studies performed in this context are presented One of the studies using the 2002 edition of the Studio compared the cogni tive activities performed by students who were developing software systems based on a single set of specifications but using two different approaches This study involved defining a new classification for these activities Three of the teams used a process very strongly based on the Unified Process for Education UPEDU a teaching oriented process derived from the Rational Unified Process The other three teams used a process built around the principles of the Extreme Program ming XP methodology The results revealed that the approach used has limited impact on the cognitive activities performed by the teams What impact there was measured in relative terms was associated mainly with artifact inspection and review The second study using the 2001 2002 and 2003 editions of the Studio evalu ated the effort expended by the members of eight teams developing software systems based on three distinct sets of specifications but using a single process model very xi
98. ribu es un membre d une quipe de d veloppe ment Robillard Kruchten et d Astous 2003 Ainsi chacune des activit s peut tre r alis e par un et un seul r le et chacun des art facts est sous la responsabilit d un seul r le Une activit consomme un certain nombre d art facts intrants et produit galement un certain nombre d art facts extrants Un art fact peut tre consomm ou produit par un nombre ind termin d activit s Le mod le conceptuel fondamental constitue en r alit un composant du m tamod le d ing nierie de processus logiciel du Object Management Group 2002 et se situe ainsi au niveau M2 de la hi rarchie des niveaux de mod lisation de 2L volution du concept de d veloppement it ratif et incr mental est d crite dans Larman et Basili 2003 13 EstResponsableDe E 1 0 z R le Art fact 1 0 intrant O 3 Mm 3 R alise 3 oO 0 E Activit 0 E Figure 1 1 Mod le conceptuel fondamental du RUP traduit de Robillard Kruch ten et d Astous 2003 cette organisation Il peut s appliquer d autres mod les de processus que le RUP Il est donc important de noter que l ind termination des multiplicit s du modele nombre d art facts intrants et extrants par activit nombre d activit s consom matrices et productrices par art fact nombre d activit s et d art facts par r le existe uniquement sur le plan du m tamodele
99. rmain Robillard and Dulipovici 2002b Robillard 1998 in the context of the Software Engineering Studio a project oriented course for senior level students have shown a significant gap between theory as taught and practice In these studies effort slips were used as an indicator of relative activity intensity Analyses performed were however limited by the activity and artifact classification of the UPEDU based process used making it rather difficult to determine exactly which elemental tasks had been performed Using those studies as a foundation we defined a set of cognitive activities aimed 42 at recording the various activity states of a software developer during the course of a project The utilisation of such a classification allows us to study the impact of software process notions learned on the cognitive activities actually performed by the students An important benefit of such an approach is that it opens the door to com parative studies of the two approaches Advocates of these are keen to debate the respective merits of each or even sometimes the fact that there is any dichotomy at all between them see for instance Ant n 2003 Beck and Boehm 2003 Wells 2003 Several studies have been performed to analyse the value of a particular practice see for instance Cockburn and Williams 2001 However very few stud ies have compared two complete software process approaches This paper presents a case study of the impl
100. rocess Reading Addison Wesley Pub 278 p HUMPHREY Watts S 2000 Introduction to the Team Software Process Rea ding Addison Wesley 463 p JEFFRIES Ron ANDERSON Ann HENDRICKSON Chet 2001 Extreme Programming Installed Boston Addison Wesley 265 p 113 KRUCHTEN Philippe 2000 The Rational Unified Process An Introduction 2nd ed Reading Addison Wesley 298 p KRUCHTEN Philippe 2001 Agility with the RUP Cutter IT Journal 14 12 27 33 LARMAN Craig BASILI Victor R 2003 Iterative and incremental develop ment brief history IEEE Computer 36 6 47 56 LEHMAN Meir Manny 1987 Process models process programs programming support Proceedings 9th International Conference on Software Engineering New York IEEE Computer Society Press P 14 16 LEHMAN Meir Manny 1997 Process modelling where next Proceedings 19th International Conference on Software Engineering New York The Associa tion for Computing Machinery P 549 552 LI Ningda R ZELKOWITZ Marvin V 1993 An information model for use in software management estimation and prediction Proceedings of the second In ternational Conference on Information and Knowledge Management New York ACM Press P 481 489 LUTZ Raymond P 1992 Discounted cash flow techniques Handbook of Industrial Engineering Sous la direction de Gavriel Salvendy 2nd ed New York Wiley P 1289 1314 MACDONELL S
101. rojet ce qui permettrait ventuellement de proc der certaines analyses valides dans le contexte de projets variables La pr sente recherche vise approfondir l tat des connaissances sur la relation entre les caract ristiques des processus et projets de d veloppement de logiciels d finis ou r els et l effort d ploy par les individus qui d veloppent des syst mes logiciels Elle a t r alis e en utilisant trois ditions successives d un cours projet intitul Atelier de g nie logiciel gt offert chaque ann e aux tudiants finissants du baccalaur at en g nie informatique concentration g nie logiciel l cole Polytech nique de Montr al Deux tudes distinctes r alis es dans ce cadre sont pr sent es Une premi re tude qui a port sur l dition 2002 de l Atelier a permis de comparer les activit s cognitives r alis es par des tudiants lors de travaux de d veloppement de syst mes logiciels r alis s suivant un m me ensemble de sp cifi cations mais selon deux approches distinctes Elle a n cessit la d finition d une cat gorisation originale de ces activit s cognitives Trois des quipes ont utilis un mod le de processus tr s fortement inspir du Unified Process for Education UPEDU mod le de processus d riv du Rational Unified Process RUP Les trois autres quipes ont utilis un processus construit autour de la m thodologie de programmation extr me Extreme Programm
102. s Alamitos IEEE Computer Society P 18 26 ROBILLARD Pierre N KRUCHTEN Philippe D ASTOUS Patrick 2003 Software engineering process with the UP Edu Boston Addison Wesley 346 p ROYCE Winston W 1970 Managing the development of large software sys tems Concepts and techniques 1970 WESCON Technical Papers Los Alami tos IEEE Computer Society P A 1 1 A 1 9 SEAMAN Carolyn B 1999 Qualitative methods in empirical studies of software engineering JEEE Transactions on Software Engineering 25 4 557 572 SEAMAN Carolyn B BASILI Victor R 1998 Communication and organiza tion An empirical study of discussion in inspection meetings IEEE Transac tions on Software Engineering 24 7 559 572 SELBY Richard W PORTER Adam A SCHMIDT Doug C BERNEY Jim 1991 Metric driven analysis and feedback systems for enabling empirically gui ded software development Proceedings 13th International Conference on Soft ware Engineering Los Alamitos IEEE Computer Society Press P 288 298 117 SLAVICH John 2000 Processus de quantification des attributs logiciels PQAL bas sur une m thode de prise de d cisions multicrit res 147 p M moire de maitrise en g nie lectrique Ecole Polytechnique de Montr al STANDARDS COORDINATING COMMITTEE OF THE COMPUTER SO CIETY OF THE IEEE 1990 JEEE Standard Glossary of Software Engineering Terminology New York Institute of Electrical and Electroni
103. s forces et des faiblesses des m thodologies ou des processus appliqu s 26 1 3 La mesure des processus logiciels La mesure des processus logiciels consid r e au sens large fait partie des taches reconnues par l cole classique du g nie logiciel comme tant n cessaires la pro duction de syst mes logiciels de qualit titre d exemple le niveau 4 du Capability Maturity Model CMM Paulk Curtis Chrissis et Weber 1993 du Software En gineering Institute est enti rement ax sur la gestion quantitative de la qualit des produits et processus logiciels Ce niveau comprend un secteur cl intitul Gestion quantitative du processus qui traite du contr le quantitatif de la performance d une instance de processus L accent est mis sur la recherche des causes sp ciales de variation l int rieur d un processus stable ainsi que sur la correction de ces causes Bien entendu une telle d marche repose sur la capacit des intervenants effectuer une mesure ad quate du processus De m me le Personal Software Pro cess PSP Humphrey 1997 galement du Software Engineering Institute int gre la mesure du processus tous les chelons de celui ci La mesure de processus pres crite couvre plus particuli rement la mesure de l effort des co ts et de la taille du logiciel mais galement celle des d fauts produits des taux d limination des d fauts de la productivit ainsi que de la qualit du proc
104. s sont en format PDF et peuvent tre visualis s notamment l aide du logiciel Adobe Reader version 6 0 Les articles contenus sont les suivants Germain Dulipovici et Robillard 2002a Germain Robillard et Dulipovici 2002b Germain et Robillard 2003 Les noms des fichiers correspondent aux identificateurs apparaissant la bibliographie
105. ses However the average size of a single iteration is likely to vary depending on the process model used Beck 2000 Glossary defines an iteration as a one to four week period while the UPEDU Ecole Polytechnique de Montr al 2002 Guidelines Software Development Plan considers iterations of less than one month as short and more suitable for the Construction phase where the degree of new functionality to be included and the degree of novelty are low One reason for these differences is simply that people using the UPEDU require some considerable time to produce a significant amount of documentation while people using XP are likely to choose not to do so At the same time one may argue that the additional investment in artifacts should enhance the productivity of the software engineers using UPEDU However this claim has not been proven and rightly constitutes one of the aspects that was studied in this setting We chose therefore to arbitrarily customise iteration lengths for each of the processes used Thus the development schedule for the XP process would include a larger number of iterations covering the same time frame However the initial iterations time frame at the beginning of the project was of particular concern to us The first iteration is crucial for laying out the skeleton of the system Also the instructors wanted to leave enough time for every participant to become accustomed to the development environ
106. sons suivantes sont appel s cycles de maintenance La phase d exploration amorce le projet et permet l quipe de d veloppement de s entendre avec le client sur le contenu souhait du logiciel et d valuer avec suffisamment de pr cision les co ts et d lais associ s l envergure de ce contenu Sa port e peut s tendre l ensemble de la dur e du projet Ambler 2002 ou simplement la livraison venir Beck 2000 La phase de planification est r alis e strictement dans la perspective de la li vraison laquelle elle se rattache Elle permet l quipe de d veloppement de s entendre avec le client sur le contenu de la premi re livraison ainsi que sur une date de livraison La phase de d veloppement it ratif est conforme aux principes du d veloppe ment incr mental Mills 1980 Ainsi le logiciel est d velopp graduellement au cours des diverses it rations planifi es au d but de la phase Chaque it ration est d une dur e d une a quatre semaines Elle d bouche non seulement sur du code de production mais galement sur un ensemble de cas de tests fonctionnels couvrant l ensemble des mini sc narios ou histoires gt qui la d finissent En outre tous les composants de tests unitaires et d int gration pertinents a l it ration auront t produits pr alablement la cr ation du code de production et tous devront pouvoir tre ex cut s sans faute avant que l it ration ne puisse t
107. specific project It also shows that projects carried out in the same year vary widely in relative effort ratios 4 5 Study of effort distribution invariance relative to project factors Figure 4 3 shows a 2D plot of team project positioning relative to the three poles formed by each of the three defined disciplines Since the relative effort in each discipline for a given team project adds up to 100 it is possible to represent those 77 Pure V amp V Pure Mr x 2001B 20025 2003B 4 e gl oe 2003A p Xy e 4 2003C 0 0 _ E 2001C e 2002A N Le e SA 2001A 4 N 7 7 N 7 N 0 5 _ ES Y N Y N N r X N 10 Pure Engineering 0 5 0 0 0 5 x Figure 4 3 2D plot of total team project effort ratios relative to the three poles three variables for each team project in a plane The resulting graph is bounded on the three axes by the maximum value for each discipline which is 100 The marker at the far right is reached for a team expending all its effort in coding while the marker at the far left is reached for a team project expending 100 of its effort on V amp V consequently the marker at the bottom of the diagram represents full engineering activities A description of the axes shown as well as calculation details can be found in the appendix These data points represent final project states and provide no information regarding the evolution of the relative weight of eac
108. state refers to work performed by two or more teammates at the same time The Discuss activity refers to every discussion taking place between a team member and one or more individuals who may or may not be team members The Inspect Review activity refers to the technical review activities that may be performed following the production of any artifact The Preparation step refers to activities which may be considered as prereq 53 uisites for coding while the Implementation step covers all coding integration and testing effort The Control step corresponds to explicit quality control work and includes the sole activity Inspect Review The original classification included other activities the occurrence of which would be interpreted as merely accidental and weakly linked to the fundamen tal behavioural characteristics of the participants We removed all slips declaring any of those activities from our subsequent analysis 3 4 Analysis of cognitive activities performed 3 4 1 Raw data analysis The first analysis step is to look at the raw data for each team based on the effort slips that were submitted Figure 3 3 illustrates the effort slips corresponding to the cognitive activities of each XP team XPA XPB XPC and of each UPEDU team UPA UPB UPC The state and step oriented categories are shown along the left and right sides of the diagram respectively We chose at this point to remove all d
109. sure bas sur la classification des activit s du UPEDU et sur le d coupage du temps en quantas bien d finis les donn es recueillies montraient des signes notables d ambiguit et de confusion La litt rature est pauvre en ce qui a trait aux principes de mesure de l effort dans des contextes n cessitant la s paration d taill e de l effort en activit s La mesure des activit s cognitives effectu e par les ing nieurs du logiciel quant elle est relativement r cente Robillard 1998 et a notamment t utilis e dans le contexte de l analyse fine des changes entre les membres d une quipe de d veloppement d Astous 1999 Seaman et Basili 1998 Cette situation peut s expliquer en partie par le degr de difficult associ la mesure des processus en g n ral Seaman 1999 explique que les aspects d un processus de d veloppement de logiciels qui s offrent l observation sont limit s Une partie importante du travail de d veloppement de 31 logiciels s effectue l int rieur de la t te des d veloppeurs et est par cons quent plus difficile observer 1 4 Le contr le des processus Une des applications les plus int ressantes de l approche pr conis e au chapitre 4 touche le d veloppement d approches de contr le de processus et d estimation en cours de projet La pr sente section offre un survol rapide de ces domaines Un expos d taill des concepts et approches en la mati re
110. t categorization at a higher level However the rela tive importance of a category of activities aimed at defining active behaviour was shown to be almost constant for all teams involved possibly showing a fundamen 39 tal behaviour pattern As secondary observations aggregate variations by process model tend to be small and limited to a few activities and coding related activities dominate the effort distribution for all the teams 3 1 Introduction There is increasing interest in the teaching of software processes see for in stance El Emam 2001 Halling Zuser K hle and Biff 2002 H st 2002 Robillard Kruchten and d Astous 2003 Umphress and Hamilton 2003 However this inter est has not yet translated into acceptance of a common set of process principles Rather two main software process approaches seem to be emerging The first promotes the utilisation of a discipline based engineering process involving effec tive definition of the roles to be played activities to be performed and artifacts to be produced This approach involves the production of artifacts to support early decision making on requirements and design matters effective communica tion knowledge reuse and mutual work inspection The main principle here is that efforts made in up front planning activities and in artifact production will result in lower overall cost timely product delivery and better software quality The Ratio nal Unified Process RU
111. t de processus Le travail pr sent a t r alis en utilisant trois ditions successives de l Atelier d crit pr c demment Deux tudes distinctes r alis es dans ce cadre sont pr sen t es Une premi re tude qui a port sur l dition 2002 de l Atelier a permis de comparer les activit s cognitives r alis es par des tudiants sur un m me ensemble de sp cifications mais selon deux approches distinctes de d velop pement Une seconde tude qui a port sur les ditions 2001 2002 et 2003 a permis d analyser les caract ristiques de l effort d ploy par les membres de huit quipes ayant travaill partir de trois ensembles de sp cifications diff rents mais suivant des mod les de processus peu pr s identiques Le premier chapitre pr sente une revue de la litt rature pertinente au domaine des processus et m thodologies de d veloppement de logiciels qui constitue l ob jet principal du pr sent travail de recherche Suit une discussion sur la mesure des processus afin de sensibiliser le lecteur aux probl matiques li es la d tection d in formations pertinentes au sein d un processus logiciel r el Finalement on effleure le domaine du controle des processus susceptible de b n ficier des r sultats du pr sent travail Le chapitre 2 aborde l organisation du pr sent travail Le chapitre 3 reproduit le premier des deux articles pr sent s dans le cadre du m moire alors
112. t of the development of a complete software product The Studio has served as the basis for several empirical studies Those studies generally focused on a single edition of the Studio and featured effort comparison among teams performing identical projects in parallel Recently for instance Germain and Robillard 2004 found that the cognitive activities performed by students were relatively independent from the software process model used Also a set of cognitive activities defined as active has been shown to have a nearly constant weight for all six projects under study regardless of the process used This paper presents the analyses of recorded effort that identify relevant effort patterns as well as a new process monitoring model It shows that it is feasible to analyze projects performed under different processes and development cycles and to extract useful information at the process discipline level First we provide a general overview of the Studio and of the projects under study Second we present the three disciplines that we use as a comparative basis for all projects and aggregated effort data for each team project Third we add the dimension of 72 project completion to the dimension of process discipline and shift our focus to the progression of the effort mix for each team project We categorize team behaviors according to specific patterns exhibited and identify a few fundamental tendencies Finally we synthesize our
113. tance dubious effort slips or time periods without any entry were signalled to the students as soon as detected and immediate corrective action was requested in all cases This attitude has generated two benefits First it helped improve the effective quality of the recorded data Second it gave the students the impression that the instructors really cared about effort slip quality and were determined to ensure it This pushed the students to act proactively and prevent problems by paying careful attention to their task of accurately recording the effort expended 3 5 2 Observations on the methodology The main goal of this paper was to define a methodology that would enable comparison of effort performed by developers at the cognitive level so that fun damental behaviour characteristics of a development team which are independent of the process used can be identified In this respect the consistent balance of ef fort intensity between activities in the Active category and other activities in the state oriented categorisation seems to reflect such characteristics Such an obser vation opens the door to the development of an effort prediction paradigm which 64 would use compound program size estimation techniques encompassing a whole set of artifacts instead of just code length for instance Research activities pre requisite to this goal include validating this supposed invariance of the Active category and measuring the r
114. tephen G SHEPPERD Martin J 2003 Using prior phase 114 effort records for re estimation during software projects Proceedings of the Ninth International Software Metrics Symposium METRICS 03 Los Alamitos IEEE Computer Society P 73 85 MCCONNELL Steve 2002 I know what I know IEEE Software 19 3 5 7 MILLS Harlan D 1980 The management of software engineering part I Principles of software engineering IBM Systems Journal 19 4 414 420 MORISIO Maurizio 1999 Measurement processes are software too The Journal of Systems and Software 49 17 31 MUNCH Jiirgen HEIDRICH Jens 2004 Software project control centers Concepts and approaches The Journal of Systems and Software 70 3 19 NOLL John ATKINSON Darren C 2003 Comparing Extreme Program ming to traditional development for student projects A case study Extreme Programming and Agile Processes in Software Engineering Berlin Springer P 372 374 OBJECT MANAGEMENT GROUP 2002 Meta object faci lity MOF specification En ligne http www omg org techno logy documents formal mof htm Page consult e le 21 mars 2004 OPEN CONSORTIUM 2002 OPEN Object oriented process environment and notation En ligne http www open org au Page consult e le 21 mars 2004 115 OSTERWEIL Leon J 1987 Software processes are software too Procee dings 9th International Conference on Software Engineer
115. tion des processus lo giciels La p riode coul e entre les ann es 1960 et 1980 a t marqu e par le d veloppement parall le de langages de programmation structur e de m thodes et principes de conception ainsi que de cycles de d veloppement de logiciels aussi ap pel s cycles de vie bien que cette appellation puisse porter confusion comme nous le verrons plus loin Le cycle de d veloppement constitue une notion cl dans la d finition globale des t ches menant la r alisation d un syst me logiciel de qualit il d finit les diverses tapes de l volution d un produit logiciel ainsi que les principes directeurs de l ex cution de ces tapes Toutefois le cycle de d veloppement ne saurait prescrire le d tail des activi t s structures organisationnelles outils proc dures politiques et contraintes Ces l ments font plut t partie du processus logiciel ou processus de d veloppement lo giciel Un processus logiciel peut tre d fini comme tant l ensemble des politiques structures organisationnelles technologies proc dures et art facts n cessaires la conception au d veloppement au d ploiement et la maintenance d un produit logiciel Fugetta 2000 Notons au passage que la distinction entre processus et cycle de d veloppement n est pas toujours claire particuli rement lorsqu il est question de ce qui fut connu plus tard sous le nom de mod le de cycle de vie en cascade in
116. tivit s tout en minimisant l influence des facteurs li s l dition ou la taille de l quipe L article comporte une annexe dont le texte est pr sent l annexe I du m moire Le choix et l ordonnancement des articles int gr s dans ce m moire sont justifi s par la n cessit de clarifier successivement les diverses sources d influence pouvant s exercer sur l effort d ploy Avant la r alisation du pr sent travail de recherche les 36 limites de la valeur potentielle de l Atelier comme plate forme de recherche n taient pas clairement tablies L Atelier de g nie logiciel constitue certes une plate forme tr s int ressante pour l tude du comportement des d veloppeurs toutefois un in conv nient notable du concept est le faible nombre d quipes participantes lorsque chaque dition est consid r e s par ment Cet inconv nient emp che l utilisation des outils statistiques conventionnels aux fins d une analyse formelle de la conver gence des comportements d une quipe l autre Il importait donc de clarifier les limites r elles d coulant de ces contraintes Le premier article permettait d identifier l influence du mod le de processus sur l effort d ploy par les participants au niveau d agr gation choisi Une influence indue du mod le de processus sur le comportement cognitif des d veloppeurs aurait grandement limit la capacit de g n ralisation de l analyse au mili
117. troduit par Royce 1970 ce mod le le premier du genre pr voit implicitement la juxtaposition pure et simple des deux concepts Osterweil et Lehman ont par l opposition de leurs vues sur le sujet lanc une nouvelle re en mati re de recherche sur les processus logiciels Ainsi Osterweil 1987 consid re qu un des probl mes principaux emp chant l assimilation de la notion de processus logiciel l application de proc dures ou recettes pour la fa brication d avions ou d automobiles est l absence de gabarits a partir desquels un processus logiciel appliqu une situation sp cifique pourrait tre instanci L approche d Osterweil consiste d finir de tels gabarits de la mani re la plus rigoureuse possible soit travers la r daction de programmes de processus uti lisant des langages aussi formels que les langages de programmation informatique Cette approche met de l avant une recherche ax e vers la cr ation d un langage de programmation de processus et d un syst me de compilation et d interpr tation des programmes r dig s Cugola et Ghezzi 1998 quant eux croient que le concept d environnement de g nie logiciel centr sur les processus PSEE qui d coule naturellement des th ories d Osterweil constitue la voie privil gi e de la recherche sur les proces sus du g nie logiciel et ce en d pit de l impact tr s faible sur le terrain jusqu ici de ces environnements et d
118. tudiants finissants du baccalaur at en g nie informatique concentration g nie logiciel gt constitue non seulement une oppor tunit de formation pratique mais galement un environnement de recherche per mettant d observer et d analyser des processus r els de d veloppement appliqu s la r alisation de syst mes complets par les tudiants L Atelier a servi de base la r alisation de quelques tudes empiriques Germain Dulipovici et Robillard 2002a Germain Robillard et Dulipovici 2002b Slavich 2000 couvrant une seule dition la fois et portant principalement sur la comparaison de l effort d ploy par des quipes devant produire des implantations distinctes conformes des sp cifications communes La recherche pr sent e dans le cadre de ce m moire a t entreprise dans le but d approfondir l tat des connaissances sur la relation entre les caract ristiques des processus et projets de d veloppement de logiciels d finis ou r els et le comporte ment des individus qui d veloppent des syst mes logiciels Elle est exploratoire et repose sur les questions suivantes Quel est l impact du choix d une approche de d veloppement sur le compor tement des ing nieurs du logiciel Existe t il des invariants ou des patrons d effort qui caract risent le compor tement type des ing nieurs du logiciel Ces invariants et patrons d effort transcendent ils les caract ristiques de pro jets e
119. ugging testing and integration of developed components It does not however include reviews of requirements analysis and design artifacts e The Engineering discipline includes all activities related to requirements analysis and design as well as technical planning at the integration and im plementation levels The various artifact review activities are also included Management activities which include project planning scheduling tasks as signments progress reporting and the like are not used for this analysis Figure 4 2 shows the normalized effort distribution for the eight team projects selected for the three years studied sorted by increasing total effort To enable comparison the total effort for each team project is normalized to 100 Each column represents the relative effort for each discipline for a given team project For example the column at the far left represents the team project with the smallest 76 100 80 60 Engineering E V amp V A Coding 40 20 0 2003C 2002B 2003B 2002A 2003A 2001B 2001C 2001A Figure 4 2 Relative effort distribution by category for all team projects sorted by increasing total effort total effort and the one that expended the most relative effort in coding activities Figure 4 2 shows that the relative effort for each discipline varies widely from one team project to another and that effort distribution is not necessarily related to a
120. uipe n si n A B ou C ou it ration n si n est num rique Unified Process for Education Validation and Verification Extreme Programming Extreme Programming it ration de maintenance Extreme Programming quipe n si n A B ou C ou it ration n si n est num rique xxiii LISTE DES TABLEAUX 3 1 Cognitive activity classification 2244 22 PES oe als TN 51 5 1 Un exemple de classification en disciplines bas e sur les disciplines originales du UPEDU EM des purs kak be bh bee Ae es 102 XXIV LISTE DES ANNEXES Annexe I Calculation of the 2D plots of effort 119 Annexe II Contenu du support CD fourni 122 INTRODUCTION In software engineering there is no theory It s all arm flapping and intuition I believe that a theory of software evolution could eventually translate into a theory of software engineering Either that or it will come very close It will lay the foundation for a wider theory of software evolution Manny Lehman cit dans Williams 2002 La capacit de d finir de mani re d taill e et en des termes quantitatifs le comportement des d veloppeurs de logiciels serait susceptible d ouvrir la porte l av nement de m thodes de d veloppement automatis via l implantation d en vironnements de g nie logiciel centr s sur les processus Process centered Software Engineering Environments ou PSEE Cugola et Ghezzi 1998 Toutefois cette vi sion
121. ultats int ressants sur le plan th o rique l laboration de m thodologies d estimation et de contr le en cours de projet risque de n cessiter une granularit plus fine des disciplines D autres approches de segmentation comme celle pr sent e au chapitre 5 pourraient tre propos es et v rifi es Par ailleurs l utilisation de boucles de r troaction en mati re d estimation et 106 controle de projets ne passe pas uniquement par une cat gorisation pr cise en dis ciplines Les algorithmes et heuristiques de controle des processus a partir des informations g n r es en ligne sont susceptibles d avoir un impact important sur la stabilit du processus ainsi que sur la qualit et la convergence des estimations L obtention de cat gorisations valables ouvre donc la voie une d marche d am liorations mutuelles et continues des m thodologies touchant l analyse de l effort et de celles touchant la r troaction apporter Une limitation notable de notre approche est l utilisation de mesures normali s es de l effort L effort normalis constitue sans aucun doute une approche valable pour l utilisation de mod les des fins de contr le de processus tant donn l im possibilit de tenir compte l avance des facteurs d chelle li s la taille du syst me d velopper Toutefois l analyse de l effort absolu par des outils statistiques ap propri s serait susceptible de faire ressorti
122. um of the three curves amounts to 100 for every selected range Terms Elaboration Construction Build up and Finalization shown at the top of the diagram are discussed in section 4 7 2 The diagram shows that coding effort starts at a low level increases smoothly to a peak at between 40 and 80 of completion and then comes back to its earlier levels V amp V effort starts at a low level and increases steadily through the entire project with a plateau at between 40 and 80 of completion Engineering effort starts at a very high level 69 and decreases abruptly to a very low level below 20 which is maintained from 40 of completion to the end of the project Figure 4 13 shows the same information for team projects with irregular but co herent progressions As mentioned earlier irregularity occurs in the case of a very 60 40 20 7 Build up 86 80 60 40 20 60 gt 80 80 gt 100 1 Coding 2001A lt Coding 2001C Coding 2002B X Coding 2003A Coding Avg B V amp V 2001A 4 V amp V 2001C V amp V 2002B 4 V amp V 2003A V amp V Avg Engineering 2001A Engineering 2001C A Engineering 2002B X Engineering 2003A Engineering Avg 0 gt 20 Figure 4 12 Non cumulative effort for team projects with regular an
123. ustrent de fa on pr liminaire la faisabilit de l ap proche entreprise dans la pr sente recherche Ils illustrent galement les difficult s inh rentes la d marche notamment en soulevant la question de l ambiguit et de la confusion de la classification en activit s de processus Le troisi me article Germain et Robillard 2003 constitue une version pr liminaire du chapitre 3 du pr sent m moire 38 CHAPITRE 3 ENGINEERING BASED PROCESSES AND AGILE METHODOLOGIES FOR SOFTWARE DEVELOPMENT A COMPARATIVE CASE STUDY Abstract The emergence of various software development methodologies raises the need to evaluate and compare their efficiencies One way of performing such a compari son is to have different teams apply different process models in the implementation of multiple versions of common specifications This study defines a new cognitive activity classification scheme which has been used to record the effort expended by six student teams producing parallel implementations of the same software re quirements specifications Three of the teams used a process based on the Unified Process for Education UPEDU a teaching oriented process derived from the Ra tional Unified Process The other three teams used a process built around the principles of the Extreme Programming XP methodology Important variations in effort at the cognitive activity level between teams shows that the classification could scarcely be used withou
124. ux fins de la planification de l estimation et du contr le des projets et des processus de d veloppement de logiciels A cet gard les recommandations suivantes devraient tre prises en consid ration 105 Sur le plan pratique la validation de l approche pr sent e dans le cadre d une tude portant sur un nombre lev de projets industriels se pose comme une pers pective de recherche imm diate Elle peut tre r alis e en transposant l approche en milieu industriel ou encore en mesurant directement la viabilit de la classification en trois poles dans un contexte d estimation en cours de projet comme ce fut le cas dans l tude de MacDonell et Shepperd en ce qui concerne leur mod le d analyse par phase du cycle de d veloppement Dans une perspective plus th orique les trois cat gorisations pr sent es ont t analys es la lumi re d un nombre restreint d observations Les caract ristiques observ es notamment l quivalence de l effort de la cat gorie Active pour les deux mod les de processus observ s pourraient faire l objet d une tentative de validation dans un contexte plus g n ral Une autre avenue de recherche pertinente consiste tenter de raffiner notre classification en subdivisant les activit s en un nombre plus lev de disciplines Les trois classifications pr sent es comportent chacune trois disciplines Bien que les choix effectu s permettent d obtenir des r s

UNIVERSITÉ DE MONTRÉAL ÉCOLE

Contents

Download Pdf Manuals

Related Search

Related Contents

UNIVERSIT&Eacute; DE MONTR&Eacute;AL &Eacute;COLE

Contents

Download Pdf Manuals

Related Search

Related Contents

UNIVERSITÉ DE MONTRÉAL ÉCOLE