Technical Reviews in Agile Development: Case Mobile-DTM Henrik Hedberg and Juha Iisakka Department of Information Processing Science, University of Oulu, Finland I? 0.Box 3000, FIN-90014 University of Oulu
[email protected],juha.
[email protected] Abstract Agile software development methods ale productoriented, whereas technical reviews belong to the process-oriented world The aim of this stu& was to find out iftechnical reviews are usable and valuable in the context of agile software development. Based on the literature, it seems that there are agile methodr that explicitly contain technical reviews in some form, while others are more against them. The case study was based on experiences gathered during an agile project using the Mobile-DTMdevelopment method. It was found that there are many potential targets for technical reviews in agile development. The main contribution was acceptance test reviews, which improved the product quality and knowledge transfer between team members. Howevel; the actual need and usefulness depends on the requirements of the product and the process used.
1. Introduction Agile software development methods have recently become one of the most discussed phenomena in software engineering. Researchers have also given attention to this method arisen fiom the practitioners' ideas. There has been debate over whether agile methods are pure hacking or disciplined software engineering. In traditional software engineering, quality has been achieved by using various verification and validation methods. Typically, for example, tests are specified together with the requirements and design, but executed at the end of the development, and various review types have been used to make sure that development is going in the right direction. In particular, technical reviews and inspections have been found to be very valuable (e.g. [16]). Agile methods emphasise simplicity and the elimination of work that is not absolutely necessary. From the viewpoint of quality techniques and software process improvement, the following value of the Agile Manifesto [4] is central: "Individualsand interactions
over processes and tools." The idea is to rely on developers' skills rather than general consensus through reviewed plans and documents. For example, pair-programming and refactoring techniques are supposed to produce high quality products by focusing on source code only. The Agile Manifesto sums this up: "Working software over comprehensive documentation." Thus, there seem to be fewer targets for technical reviews in agile development than in traditional design-oriented software development. However, is this really the case? Are skilled professionals that make no mistakes always available? Can human actions really be flawless? Should, for example, the source code still be reviewed? Should agile developers produce some plans and documents that are also reviewed? There are many emerging questions. The research problem of this work was to work out whether technical reviews are usable and valuable in the context of agile software development. One software development project has been observed, and directed to use technical reviews. During the project, which used the agile software development method called Mobile-DTM,effects have been evaluated using a controlled case study approach [21]. The most important contribution of this work is the introduction of acceptance test reviews in an agile context. In addition, we also show the possibility and importance of adapting technical reviews into agile development based on our findings. This paper is organized as follows. Chapter 2 deals with the concept of technical reviews and their relation to agile methods based on the literature. Chapter 3 introduces the case study, MobileDTM, and our empirical findings. Chapter 4 is discussion, and Chapter 5 presents conclusions.
2. Technical Reviews in Agile Development Technical reviews acknowledged methods artefacts produced at development. According technical review is "a
Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006
are well-known and for detecting defects in any phase of software to the IEEE standard [9], a systematic evaluation of a
sofn~areproduct by a team of qualzfzed personnel that examines the suitability of the sofhvare product for its intended use and ident~fzes discrepancies from speczj?cations and standarch. " Technical reviews may also ~rovide recommendations of alternatives and examinations of various alternatives. The definition has two key points fiom our viewpoint: a technical review is performed by a team, meaning that the author alone cannot perform a technical review, and it is performed for a product not for a draft or a proof of the product. The authors have finished their product and the purpose of the review is to check whether the product needs repairing. While the authors are writing their product, such as an architectural design document, there is no checking, i.e. reviewers do not participate in preparation. Technical reviews, such as inspections, are part of process-oriented software quality development. Their acknowledged status has built up over many years, for a good reason. Although they are professionals, developers make mistakes that have to be removed so that they do not have a negative influence on product quality. CMM (Capability Maturity Model) level 2, for instance, requires some sort of inspections [IS]. When we examined whether there were technical reviews designed for agile methods, we found that agile methods are not similar in this aspect. Some methods explicitly have technical reviews and some explicitly deny them. Overall, the primary quality control activities in agile processes are code testing and customer feedback. Agile methods typically hold that reviews of software processes and products can be replaced with informal reviews [23]. There are only a few agile methods that explicitly involve technical review. Perhaps the most review-oriented agile method is FDD (Feature-Drive Development), which claims to be a process-oriented software development method for developing business critical systems. The process of FDD includes both design and code inspections. [19,2, 31 According to Jeff De Luca (one of the creators of FDD), FDD incorporates several ideas and practices from the last 30 years of the industry - including Fagan's inspections [19]. The essential purpose of technical reviews, and of software inspections in particular, is to enhance the authoring process. However, if the process is not yet mature enough, there must be another way to, for example, reduce defects. RaPiD7 (Rapid Production of Documents, 7 steps), developed in Nokia, addresses problems of document authoring [14] as an alternative to software inspection. Since the reviews are somehow built-in, there is no need for traditional technical reviews in the RaPiD7 process. The Sprint Review in Scrum [22] sounds like a technical review, but it has been designed for project management purposes to go through the status of the
development and to demonstrate the results to the customer. The focus is on the features of a ~roduct. These features can be added, deleted or changdd based on Sprint Review decisions. The inside of the product is hardly checked. Scrum does not mention anything about quality assurance. Pair Programming in Extreme Programming [5] is a paradoxical review method. The idea is that two developers together write the same source code. Naturally this doubles working costs. Defenders say that this double crew is compensated at least partially since a pair has a higher d&elopment speed than a single programmer, and since the pair-programmed code has a reduced defect density [17]. Wiegers [25] even regards it as a relative of a formal review method. However, there are also some criticisms of pair programming. Hulkko and Abrahamssson's [l 11 empirical data indicated that pair programming did not provide quality benefits or more productivity when compared to solo programming. Keefer [12] lists some empirical studies criticising pair programming, and slams some famous evidence of the superiority of pair programming. In general, the quality assurance of agile methods relies on code testing and fiequent customer interaction. If the software project is agile, it is essential that the customer is committed to giving continuous feedback. There are even examples where the customer's representative has suffered from bum out because of this [12]. Usually there might be technical reviews but they are informal -even ad hoc occasions. For quality critical artefacts, the emphasis of agile methods is on testing, and in particular the TDD (Test-Driven Development) practice of Extreme Programming is advertised for these projects. [23, 20, 56, 151 Technical reviews are part of software quality enhancement. According to Berard [6], the term "quality"shows up frequently in discussions on agile technology, e.g., agile development being described as "a relentless pursuit of quality". So, it is easy to understand why organisational process methods, such as technical reviews, are not usually present in definitions of agile methods, which seem to favour the individual's skills and motivation as a quality tool. However, the importance of technical reviews is not questioned. As Kent Beck writes [5]: 'Yf code reviews are good, we'll review code all the time @air programming). "The adaptation of technical reviews as a part of agile methods is worth pursuing.
3. Case Mobile-DTM To examine whether technical reviews are usable and valuable in the context of agile software development, we observed one software development project using Mobile-DTM[I]. This is an agile software
Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006
development method tailored especially to mobile applications. It has been developed in the ENERGI laboratory (Industry-Driven Experimental Software Engineering Initiative) at VTT, the Technical Research Centre of Finland. The method has undergone various case studies where it has been empirically evaluated and further developed. In our research, the focus was on the role of technical reviews in Mobile-DTM.The process consists of typical agile techniques, such as pair programming, that were claimed to enhance product quality. However, traditional reviews were seen as worthy of experimentation, and appropriate joint points in the Mobile-DTMprocess were explored.
The researchers working in the laboratory constituted a steering group, whose mission was to observe, control, and support the project team. During the project, researchers were invited to propose their ideas based on their distinct research interests, and the implementing team members followed the ideas. In addition, the researchers sometimes took a back seat in developers' room. After the project, a post-mortem review session was held. As a part of the session, the feedback from team members was collected using semi-structured interviews.
3.1 Background and Research Approach
At the beginning of the project, seven different potential targets for technical reviews or related quality control procedures were identified. These were user stories, solo and pair-programmed source code, refactored code, module ownership, other documents, and supporting tools. During the experiment, acceptance tests were also seen as important targets for improvement. All of those were given special attention, and judged as to whether a technical review or other quality techniques should be integrated with them. During the project, some of the initial targets were found to be irrelevant, and others were deepened and a corresponding quality technique was introduced in practice.
Mobile-DTM is based on well-known agile practices particularly well-suited to mobile development taking place over a short time-period. It combines ideas fkom Extreme Programming (practices), Crystal Methodologies (scalability) and Rational Unified Process (coverage). The process is founded upon the following nine principal elements: Phasing and Pacing, Architecture Line, Mobile Test-Driven Development, Continuous Integration, Pair Programming, Metrics, Agile Software Improvement, Off-Site Customer, and User-Centred Focus. The Mobile-DTMpractices are described in the form of process patterns [24]. The process has also been assessed as fulfilling the CMMI level 2 requirements. [I] In Mobile-DTM,a development project is divided into five short-term (i.e. two-week) iterations which consist of three different types of development days. These are Planning days, Working days, and Release days. Customer interaction takes place during Planning and Release days in the form of planning games, acceptance testing, and release ceremonies. Otherwise the team is mainly on its own. The work is managed with informal team meetings, and done in pairs most of the time. The experimental case study that was used to evaluate the adequacy of the technical reviews in agile software development was one of the projects executed in the ENERGI laboratory. The project, called unicorn, ported the production monitoring system implemented with Java in an earlier project to the Syrnbian environment. The team consisted of four Syrnbian course undergraduates and one experienced professional developer. In the series of the ENERGI projects, a controlled case study approach [21] has been used to evaluate empirically the enhancements made in the agile development process. It considers the systematic generation of quantitative data in terms of time, size, and defect metrics, as well as qualitative data collected with diaries and in post-mortem sessions.
3.2 Findings
User story reviews. On Planning day, one of the key activities was planning the next iteration. Following the XP conventions, this should have been carried out by writing user stories together with the customer. In Mobile-DTM,however, user stories were mostly written by project members based on original user requirements negotiated with the customer immediately before. The concern was raised as to whether the impression of the requirements was somehow changed during this process. The correctness of the requirements was analysed and the validity of the user stories was given special attention. The idea was that, if problems were found, user stories should have been reviewed together with the customer if not even explicitly written with them. The finding was that, although user stories are written by the team members, these members are able to consult the customer directly during the planning day. This eliminates the need for reviews. Acceptance test reviews. Following XP practices, acceptance test were also written at the same time as user stories. However, these were written by one developer, and were never shown to the customer. Acceptance tests contained technical details that are vital for development. The test-driven development utilized in the project increased their importance even
Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006
more, since test code was written first, and then the actual source code was based on that. We proposed that the morning after the planning day the whole project team would perform a walkthrough for acceptance tests. The purpose was to check that the tests corresponded to user stories and to find additional tests that could be vital for the task. The main constraint was that the session should last a maximum of two hours, but the actual working methods could evolve during the initial trials. The project team implemented this procedure, and the results were success~l.The reviewed acceptance tests were better in quality and contained less defects. The applicability for knowledge transfer was also recognized. The process now contained a single moment when the team had the opportunity to go through the system requirements and tests derived from them. This set the convention that acceptance test reviews were held during planning day when there was enough time. A team-member responsible for testing, who had written the test, presented the test, and then it was discussed by the team and revised by the individual responsible for testing. Finally, the customer accepted the test or changes made to it as well as its correspondence the requirements. The execution of the acceptance test review was as light-weight as possible following the idea of a walk-through, and thus suitable for a short implementation duration. For example, there was no time reserved in the review session for preparation. Since the study, the acceptance test review has been formulated as a process pattern in the Mobile-DTM method description by WT researchers [24]. Source code reviews. Source code is naturally the most important element in software development, but its role is emphasized even more in agile development. Since the focus is on working software and not on documentation, source code is usually the only output of development efforts. It should be selfdocumentative, and thus strict coding conventions are essential. These are typical objectives for technical reviews too. Mobile-DTM incorporates the practice of pair programming, and thus source code is already under some sort of review by the non-driver participant of the pair. In this case, pair programming was used to produce most of the source code, but some parts were also solo-programmed, meaning that they were written by a single programmer. Solo-programmed code should have been less important or easier to produce than pair-programmed code. The division of code between solo-programmed and pair-programmed code, between less-important and more-important, or between simple and complex, is slightly awkward. On the one hand, solo-
programmed parts are not automatically reviewed by a partner, but as less-important tasks technical reviews sound extravagant for them. On the other hand, pairprogrammed code is already reviewed by a partner, but as more important and complex tasks, it should gain as much attention as possible, for example, in the form of additional technical review. It could be the case, for example, that the pair shares the same misconception that affects the code. In addition, team members got to choose quite fieely between solo programming and pair programming. The first concern was that, if essential and complex tasks were solo-programmed, the review aspect would have been totally omitted. Thus, project members were asked to consider whether there were some other drivers than the simplicity of the task that lead to solo programming. Different reasons were found [ll], e.g., the difficulty of considering logical problems together, or a disturbing background noise in the office. However, the effort spent on pair programming was nearly 80 percent. The obvious question was if the solo-programmed code contained more defects than the pair-programmed code (or vice versa). This aspect was already taken over by another researcher, who analysed the quality of the code with two metrics: comment ratio and defect density [ll]. The comment ratio, i.e. the ratio of comment lines to total lines of code, was about 60%. Although the number does not measure the actual quality of the comments, the high ratio implies very readable and maintainable code. Therefore, for this aspect, technical reviews were not necessary for the pair-programmed code. A very low relative defect density was also found in pair programming. The solo-programmed code contained over six times more defects than the code written in pairs. That evidence supports the usage of pair programming in favour of solo programming with separate technical reviews. However, pair programming is not always as good as it seems to be on the grounds of the former results. Another ENERGI case study, executed immediately before this one, did not support its superiority. Comment ratios were higher in pair-programmed code than in solo-programmed, but relative defect densities were not lower. In fact, the pair-programmed code contained an amount of defects per logical code line roughly equal to that of solo-programmed code. [l 11 In addition to pure defect- and comment-based metrics, the complexity of solo- and pair-programmed code should be compared. If solo programming injects significant amount of defects into the code base, pair programming should be used. Furthermore, if pair programming is not sufficient to produce high quality code for a complex task, technical reviews can help. It should be assessed, on a case by case basis, whether
Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006
the pair-programmed code fiagrnents are sufficiently complex or defective to start code reviews. That decision depends also on the targeted quality standard of the organisation. Refactored code and module ownership. Refactoring [8] aims to improve the design of existing code by applying a series of small transformations preserving the original behaviour. It is important that the program is checked with regression tests after the modification. When TDD is used, this should be fairly straightforward to do. However, although one of the practices in Mobile-DTMis TDD, this was not always possible, since not all unit tests were written. In those cases, technical reviews could have been used. Finding a suitable reviewer is not obvious. One possibility would be that refactored code is reviewed by a module owner, but in Mobile-DTM,modules do not have owners. Collective ownership is a typical technique in agile methods. ~urtherhore, it was questioned whether this could affect the quality of a product, since no one is interested in the evolution of the individual module. One possibility would have been to establish a practice of changing ownership, meaning that a module is owned by the member who made the last change to it. That way the previous owner could review the refactored code after it was, for example, committed to the repository. Since the amount of refactoring was quite small in the project, rehctored code was not reviewed in this project[ However, the importance of high quality refactorings was recognized, since erroneous changes can break a working piece of software. Document reviews. In Mobile-DTM,there were two main types of documents: a small amount of project management documentation, such as architectural plans, and end-user documentation. Earlier projects had shown that there might be problems with producing documents on time. Because the documentation was usually written at the end of the project, the amount and quality of the documentation varied and may have been low. The aim was to advance the schedule, so that there would be enough time to prepare documents. To achieve this, technical reviews could be introduced after each iteration to check that enough attention is given to the documentation. Because these documents are written for end-users, a customer representative should be one of the reviewers. The obvious timing would be planning day, since the assessment of the documentation affects the tasks done during the next iteration. A checklist can be derived from a set of typical questions concerning documentation quality. Architectural documents should also be reviewed, since their quality affects the product as a whole. However, mobile applications are still quite small if
compared to desktop or server applications, and are built on established architectural models and divisions, such as Model-View-Controller. Therefore, the importance of architecture is not as great as in traditional software engineering. But when needed, technical review techniques can be used both to validate architectural documents and to verify that the working software follows them. Although the need for both types of technical reviews of documentation arose during the project, these reviews were not implemented in practice. Five weeks was not enough to experiment with this aspect as well, so it was left for subsequent case studies. Supporting tools. The role of tools is interesting in agile methods. For example, the Agile Manifesto [4] values keeping the usage of tools to a minimum, or using only simple tools. On the other hand, techniques such as test-driven development, especially in the mobile environment, require quite complex tools. In addition, versatile IDES (Integrated Development Environments) make developers more effective if used properly. The key is to reduce the amount of routine work required in development. Geographically distributed work. which on the other hand is not common in the agile world, also pushes towards the use of more complex tools than simple pen and paper. Since reviews produce a lot of data that should be collected and analysed, computer-based tools [lo] would also be suitable in agile development. In the unicorn project, various templates and spreadsheets were used. Some data was required only for research purposes, and thus it was collected with as little disturbance to personnel as possible. When feasible, the only tools were pen and paper. In our case, acceptance test reviews were performed manually, so there was no need for automation. If, for instance, source code reviews had been organized, automation would have been the most cost-effective way to implement such reviews and collect data.
4. Discussion We have now participated in the debate on agile methods versus traditional quality assurance techniques. Our background lies in software inspection research, which may influence us towards using certain lenses to look through. In any case, we interpret our empirical findings as showing that there is room for technical reviews in agile development. Typically, agile developers think that their skills and practices prevent defects and enhance the quality of the product. The following quotation from Tom DeMarco (DeMarco and Boehm 2002, 91) is a fine example of this: "Igave myselfthe luxury of sitting in on one of Kent Beckk XP immersion w e e k and came away impressed by how much people grew during the
Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006
experience. He teaches an approach to the key implementation steps - specification, versioning, design partitioning, testing, and so on - as an exeltlise in skill-building. When they finish that week, the course participants have power$ul new capabilities to produce a better design than each could produce alone. [...I If agile means anything to me, it means investing heavily in individual skill-building rather than organizational rulesets. " The need for strict rules and processes depends heavily on the nature of the development process. Small projects can rely on individuals and loose cooperation. Skilled professionals can solve relatively large problems by themselves or with a partner. When the project gets larger and more interaction is needed between team members, more procedures are needed. In our case, acceptance test reviews were discovered to be successful. They were lightweight and thus suitable for the mental world of agile methods. The very key role of acceptance tests must be remembered, since they are a link between user requirements written as stories and test code transformed to product code using TDD. If the process of writing the tests had been different - for example, if it had taken place with the customer there might not have been demand for technical reviews. However, the customer may not always be in place, so also other methods have to be available. Technical reviews are a good and acknowledged way to perform verification. In addition, the study of the Mobile-DTMprocess revealed that there are also many other potential targets for technical reviews in agile methods. Despite the fact that the actual need and usefulness depends on the requirements of the product and the working methods of the team, the possibility of implementing reviews should be taken into account when planning and introducing an agile process in an organization. In future, the variations of technical reviews in the context of agile development should be studied, and quantitative data should be collected and analysed. Our initial findings give hints of the possible aspects to focus on. For example, one interesting perspective is that of architectural plans, since those are the rare design documents that should be produced and followed in MobileDTM. The importance of the reviewed architecture should be underlined, and implementation should be compared against it using review techniques.
5. Conclusions Technical reviews such as inspections are not a common talking point in agile literature. It emerged that technical reviews are not a typical element of agile methods, with the exception of FDD. Supposing that developers' proficiency and motivation in software
production prevents defects and enhances the quality of the product is characteristic of agile methods. However, quality procedures may become de rigueur when the projects are very large or have a large number of underskilled developers. The purpose of this study was to examine whether technical reviews are usable and valuable in the context of agile software development. From that viewpoint, agile methods differ from each other, and thus it is difficult to study quality procedures in agile methods in general. The specific method studied was Mobile-DTM,developed in the ENERGI laboratory at VTT. As a result. the acceDtance test reviews were discovered to be successful, as they were suitable for the mental world of agile methods. Also, during the case study, we identified many potential places where technical reviews could be used to enhance product quality. It is obvious that the variations of traditional quality control procedures within agile methods are worth empirical studies.
Acknowledgements We would like to thank the ENERGI laboratory at
VTT and its personnel for the invitation and access to the Mobile-DTMcase studies, as well as their support
during this work. In particular, we would like to mention Pekka Abrahamsson and Outi Salo, who made our study possible.
References [l] P. Abrahamsson, A. Hanhineva, H. Hulkkp, T. Ihme, J. JSililinoja, M. Korkala, J. Koskela, P. Kylltinen, and 0. Salo, "Mobile-D: an agile approach for mobile application development", Companion to the 19th Annual ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA), ACM Press, New York, 2004, pp. 174-175. [2] P. Abrahamsson, 0. Salo, J. Ronkainen, and J. Warsta, Agile software development methods, VTT publications, Espoo, 2002. [3] P. Abrahamsson, J. Warsta, M.T. Siponen, and J. Ronkainen, "New directions on agile methods: a comparative analysis", Proceeding of the 25th International Conference on Software Enaineerina, 2003. [4] ~ g i l e~an&sto,h~.pd/agilemanifesto.org/,accessed May 2nd. 2006. [5] .K. Beck, Extreme programming explained, Boston, Addison-Wesley, 1999. [6] E.V. Berard, Misconceptions of the Agile Zealots. httpdt www.svspin.org~EventslPresentationd MisconceptionsArticle20030827.pdf,2003. [7] T. DeMarco, and B.W. Boehm, "The agile methods fiay". Computer; 35(6): 90-92,2002. [8] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring: Improving the Design of Existing Code, Addison-Wesley Professional, 1999. [9] IEEE standardfor software reviews, IEEE Std 1028-1997
Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006
(1998),IEEE Computer Society, 1998. [lo] H. Hedberg, and J. Lappalainen, "Preliminary Evaluation of Software Inspection Tools". Proceedings of the 5th International Conj2rence on Quality Sofhare (QSIC), , 2005. [ll]H.Hulkko, and P. Abrahamsson, "A multiple case study
on the impact of pair programming on product quality", Proceedinas o f the 27th international Conference on Sojiware zngineering (ICSE '05). ACM Press,- New York,
2005. [12]G. Keefer, Extreme prrogramming considered harmfil for reliable software development, Avoca GmbH, 2003. [13] G. Keefer, "Pair Programming: An Alternative to Reviews and Inspections?" Cutter IT Journal, 18(1): 14-19, 2005. [14] R KylmZikoski, "Eficient authoring of software documentation using RaPiDT, Proceedings of 25th International Conference on Sofiware Engineering (ICSE), 2003. [15] M. Lindvall, V.R. Basili, B.W. Boehm, P. Costa, K. Dangle, F. Shull, R Tesoriero, L. Willams, and M.V. Zelkowitz, "Empirical Findings in Agile Methods", D. Wells, and L. Willams.(eds.), XP/Agile Universe 2002, Springer-Verlag, Berlin, pp. 197-207,2002. [16] S. McConnell, "The Best Influences on Software Engineering", IEEE Software, January, 2000. [17]M. Miiller, and F. Padberg, "On the economic evaluation
of XP projects", European Software Engineering Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE), 2003. [18] J.R Nawrocki, B. Walter, A. Wojciechowski, "Comparison of CMM Level 2 and extreme Programming", ~ u r o i e a nConfeence on Software Quality (ECSQ), 2002, 288-297. [19]Nebulon Pty Ltd, Company's web-pages, httpil www.nebulon.com, accessed May 3rd, 2006. [20]M. Poppendieck, Lean Programming, httpi///www.ddj.com/dept/architect/l84414744, 2001. [21]0. Salo, and P. Abrahamsson, "Empirical Evaluation of Agile S o h a r e Development: The Controlled Case Study Approach", Proceedings of Product Focused Software Process Improvement: 5th International Conference, (PROFES), Lecture Notes in Computer Science, Volume 3009,Jan 2004,pp. 408 - 423 [22] K. Schwaber, and M. Beedle, Agile Software Development with Scrum, Reading, Upper Saddle River, Prentice Hall, 2002. [23] D. Turk, R France, and B. Rumpe, "Assumptions Underlying Agile Sohare-Development Processes", Journal ofDatabase Management, 16(4): 62-87,2005. [24]Mobile-D Patterns, httpi/agile.vtt.fdmobile-d/,VTT Electronics, 2005. [25]K.E. Wiegers, Peer reviews in software : a practical guide, Boston, Addison-Wesley, 2002.
Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006
pp.
