Comparison of Software Architecture Design and ...

Comparison of Software Architecture Design and Extreme Programming Janne Lemmetti, Mikko Raatikainen, Varvana Myllärniemi and Tomi Männistö

Helsinki University of Technology Software Business and Engineering Institute (SoberIT) P.O. Box 9210, 02015 TKK, Finland [email protected]

Extreme Programming (XP) avoids up-front design by concentrating only on current needs in environments of uncertain requirements. Software architecture design approaches produce architectures to match functional and quality requirements before detailed design and implementation. The approaches seem to be in tension with respect to the role of up-front design. In this paper, XP and three software architecture design approaches are compared in terms of problems they address, solutions to the problems, and applicability in dierent circumstances. In addition, the capability of answering problems addressed by other approaches is analyzed. While applicability of XP or software architecture design approaches depends on several factors, both seem to be able to learn from the practices the other applies, such as concentration on architectural drivers stemming from software architecture design approaches or value of simplicity stemming from XP. Abstract.

1

Introduction

Agile software development has emerged recently as a class of software development methods. A key characteristic of agile methods is that they value the Agile Manifesto [1] that, e.g., emphasizes delivering working software over comprehensive documentation. The agile methods try to avoid the diculties that many other methods, often considered traditional, face when there are unforeseeable changes [2]. Extreme Programming (XP) [3] is one of the best known agile methods. Software architecture refers to the structure or structures of a system comprising the software elements, their relationships, and their externally visible properties [4]. Typically, software architecture is designed in the early stages of development as the up-front design of a system [5,6]. The software architecture of a system is seen as a key means of taking into account and evaluating cross-cutting requirements before the system is implemented; such requirements typically include quality attributes such as performance, security, or reliability. Several dierent approaches to architecture design have been proposed, including Quality Attribute-oriented Software Architecture design (QASAR) [5],

Attribute-Driven Design (ADD) [4], and Rozanski and Woods' architecture definition process (RWADP) [6]. However, software architecture design can be seen to be in conict with agile methods, including XP, that emphasize designing only for current need rather than following an up-front plan. According to Rozanski and Woods [6], there is a tension between the agile movement and software architects: architects are seen as bureaucratic document producers while agile developers are undisciplined hackers. This tension between agile development and software architecture design approaches may lead to problems when trying to ensure the realization of architectural, cross-cutting requirements while at the same time ensuring agility. In this paper, we analyze XP and three software architecture design approaches. The analysis focuses on the main problems each approach aims to answer, solutions to the problems, and the typical situations of applicability of the approaches. We focus on the architectural level aspects. We also discuss how each approach can answer the problems that the others address, learn from the solutions of the others, and be combined. The goal is to provide a neutral and constructive comparison of the approaches while acknowledging the strengths and weaknesses of each, thus enabling a balance between agility and architecture design. The motivation behind this paper is the lack of similar objective comparisons and the fact that it is not obvious when to choose among these approaches. Section 2 introduces XP and especially its approach to software design. The rest of the paper is organized as follows. Three software architecture design approaches are introduced in Section 3. In Section 4, we compare the ndings in terms of problem, solution, and applicability. Section 5 further analyzes the methods and XP from opposite viewpoints. Section 6 discusses combining XP and traditional methods. Section 7 draws conclusions.

2

XP

Extreme Programming (XP) is an iterative and incremental agile software development method that aims to enable software development in environments of unclear and changing requirements [7]. XP relies on modern software development techniques to keep costs caused by later emerging and changing requirements low, whereas in traditional software development the cost of changes is argued to rise exponentially as development proceeds [3,8]. XP consists of a set of values, practices, and principles. Values are abstract concepts like simplicity for which XP strives. Practices are concrete day-to-day activities. Principles are guidelines that help the developers to choose appropriate practices that support the values. For example, to facilitate the value of communication, the principle of humanity guides the developers to the practice of face-to-face communication rather than heavy documentation [8].

The rationale behind the approach of XP to software design is twofold [8]. First, all early decisions and plans are believed to be subject to change. Second, the software is kept as simple as possible by building only for present need rather than for possible future functionality that might never actually be implemented. By keeping the design simple, features that are eventually actually needed are easier to add. Hence, the goal of XP is to produce a design that can accommodate changes and new functionality at any point in development. The costs of continuous change are kept under control by following XP practices meticulously [9]. Implementation is planned around user stories that describe user-visible functionality. At the beginning of each development iteration, a customer selects the stories to be implemented next [8]. Software design in XP is driven primarily by the practice of incremental design. In incremental design [8], software design and implementation are done in parallel to optimize the design for the present need rather than in anticipation of the future. XP has no explicit software architecture-related practices, since the concept of architecture is not separated from the concept of detailed design. In practice, incremental design is done by constantly refactoring the code. Refactoring is done to accommodate new functionality and to enhance the design by modifying and restructuring existing code without changing its external behavior [10]. Because refactoring is error-prone, it has to be supported by the practice of test-rst programming in which all the implementation work begins with creating unit tests for the intended functionality [9]. Once the tests are in place, implementing code is written. The practice provides test coverage that will also reveal errors during refactoring. The developers also integrate their changes often in order to avoid diculties when merging changes. In addition to its incremental design, XP has a few other practices that contribute to the shape of the architecture in some way. Spike solutions, skeleton of the software produced in the rst iteration, and quick feedback due to small releases have an impact on how the architecture turns out. The now obsolete metaphor practice was supposed to help to communicate the architecture between stakeholders but it has turned out to be too dicult to use.

3

Software Architecture Design Methods

In this section we describe three software architecture design methods: Quality Attribute-oriented Software Architecture design method (QASAR) [5], Attribute Drives Design (ADD) [11,4], and Rozanski and Woods' architecture design process (RWADP) [6]. The methods are described in terms of their motivation, concepts, steps, iterativeness, and entry and exit criteria. Since the methods are relatively similar, we look especially at their unique characteristics. The methods are presented visually in Figure 1 as the sequences of their steps.

(a)

(b)

(c)

Fig. 1: Software architecture design processes (a) QASAR [5] (b) ADD [11,4] (c) RWADP [6]

3.1

QASAR

Motivation. Architecture is constructed in QASAR from requirements formu-

lated before more detailed design and implementation are done. The method addresses both functional requirements and quality attributes derived from the quality requirements. The initial architecture is designed on the basis of functional requirements. Thereafter, architecture is transformed also to meet quality attributes. Concepts. QASAR assumes that quality attribute requirements will be cap-

tured using scenarios ; no specic format for functional requirements is assumed. Quality attribute requirements are achieved using transformations, which include applying an architectural style, applying an architectural or design pattern, or converting quality attribute requirements to functionality or distributing requirements. Styles and patterns are codied best practices that have known consequences; the dierences between them lie in the scope of their eects on the architecture. Steps. The rst step performs functionality-based design that constructs initial

architecture design to match functional requirements. Second, the architecture is assessed against the quality attribute requirements. The assessment may use scenario proling, simulation, mathematical modeling, or experience-based reasoning. Third, if the assessment indicates that the architecture does not fulll its quality attribute requirements, architecture is transformed. A transformation leads to a new version of architecture that has the same functionality but dierent quality attributes. The assumption is that functional requirements do not preclude the use of transformations to optimize for quality attribute requirements. Iteration. The method iterates between the second and third step, i.e., it itera-

tively assesses and transforms the architecture until satisfactory architecture in terms of quality requirements is found. Entry and exit criteria. QASAR assumes partial or full requirements spec-

ication as input, and produces a set of design artifacts as output. Design is considered nished when satisfactory architecture is found.

3.2

ADD

Motivation. ADD designs software architecture top-down, recursively decom-

posing higher level elements to detailed sub elements. ADD aims at satisfying architectural drivers. Concepts. Architectural drivers in ADD are those quality attribute and func-

tional requirements that shape the architecture. The focus of ADD is on quality attribute drivers. ADD assumes that driving quality attribute requirements are captured using scenarios derived from the provided scenario templates. Functional requirements can be expressed as use cases [4]. Further, ADD relies on the existence of tactics or patterns to guide decomposition. Tactics are general design decisions required to achieve certain quality attributes, whereas patterns are concrete instantiations of one or more tactics.

Steps. First, architectural drivers are selected on the basis of decomposition.

Second, an architectural pattern or tactic is selected to satisfy architectural drivers, and child modules to implement the pattern or tactic are identied. Third, child modules are instantiated and functionality is allocated to them. Fourth, the interfaces of the child modules are dened. Fifth, quality and functional requirements are veried and imposed as constraints on the child modules. Finally, a new module is chosen for decomposition, for which the steps are repeated. Iteration. ADD is a recursive but not iterative process since it does not ex-

plicitly mention iterations. ADD decomposes one level of a module hierarchy at a time, but it does not explicitly address rening or transforming existing decomposition. Entry and exit criteria. ADD assumes architectural drivers as an input and

produces a high-level conceptual architecture as an output.Therefore, ADD can begin as soon as architectural drivers are known with some condence and continue until further architectural decomposition is no longer needed [4].

3.3

RWADP

Motivation. RWADP aims to design a software architecture that satises and

balances dierent stakeholder requirements for both function and quality. Stakeholders' requirements can be in conict with each other. Special emphasis is put on communicating the architecture to the stakeholders. Concepts. Major functional and quality requirements are captured using sce-

narios. The requirements originate from stakeholders, who are persons or entities relevant to architecture. RWAPD includes a catalog of viewpoints and perspectives. A viewpoint is a collection of templates and conventions for constructing one type of view . A view is a representation of one or more structural aspects of an architecture. A perspective is a collection of activities, tactics, and guidelines used to ensure that a system exhibits quality requirements that require consideration several views. Steps. First, stakeholders with their requirements are engaged. Second, sce-

narios are captured. Third, architectural styles are identied to match requirements. Fourth, an architecture is drafted using the identied styles, viewpoints and perspectives. Fifth, dierent architectural options for rening the draft are explored, and architectural decisions are made to choose among them. Sixth, architecture is evaluated with stakeholders. RWADP lists several methods for evaluation. Finally, if the architecture does not fulll stakeholder requirements, the architecture design is reworked and requirements possibly revisited. Iteration. The steps proceed iteratively. Until evaluation indicates that archi-

tecture fullls stakeholder requirements, architecture is reworked or requirements revisited and architectural options are explored and decisions made. Entry and exit criteria. RWADP assumes that stakeholders provide input for

the phases, and it produces an architectural description, that can act as a basis for skeleton system implementation. Ideally, the architecture denition process can be considered complete once the evaluation with stakeholders does not result

in signicant comments or actions. However, the denition is often nished when most stakeholders' requirements are addressed and the project can proceed with an acceptable level of risk.

4

Comparison

The approaches described in previous sections are compared in terms of problem,

solution, and applicability in Table 1. The problem refers to the key architectural challenges that the approach aims to answer. The solution describes how the approach proposes to solve the problem. Applicability identies typical or recommended situations where the approach is meant to be used. The comparison explicates the fact that software architecture design approaches are relatively similar to each other, whereas XP diers from them more signicantly. The main dierence is that the concept of architecture is not explicit in XP, but rather the architecture emerges alongside other design. XP also diers in that there are no tangible artifacts related to the architecture such as documentation. The emerged architecture is manifested only in the actual software. Because of similarities, Section 5 analyzes the approaches by treating software architecture design as one class and XP as the other. The similarities and dierences between architecture design approaches are briey summarized in the following. All software architecture design approaches address the fulllment of functional requirements and quality attribute requirements. The methods dier slightly in terms of the role of quality attributes: ADD seems to be the most oriented toward quality attributes. Further, RWADP emphasizes stakeholder involvement. All the software architecture design approaches apply scenarios for capturing architectural requirements. All also utilize some kind of codied knowledge for ensuring fulllment of these requirements, such as patterns, tactics, styles, or viewpoints, although the applied form of knowledge diers. QASAR and RWADP are iterative such that each iteration changes design while ADD is recursive such that each recursion further decomposes the system. All the architecture design methods assume that the architecturally signicant requirements are known at least to some extent at the beginning of the architecture design process.

5

Cross Comparison

In the following, we compare XP and architecture design approaches to each other from problem and solution points of view.

5.1

Addressed Problem

How architecture design approaches address the problem addressed by XP: The main concern of XP is the ability to respond to change. The solution is to minimize work and aim at simplicity. Instead of preparing for change, software is constantly refactored to keep it modiable and exible.

Method XP

QASAR

ADD

RWADP

Designing and describing software architecture for the concerns of a large group of dierent kinds of stakeholders.

Fulll the architectural drivers i.e. combinations of the architecturally signicant functional requirements and quality attributes.

Focus on functional and quality attributes of software with emphasis on satisfying several dierent quality attributes at once.

Under changing or uncertain requirements, deliver working software early and continuously.

Problem

Scenarios and styles as input. Evaluate architecture, and then either rework architecture using viewpoints and perspectives, or rene requirements until satisfactory solution is found.

Top-down and recursive decomposition of the system applying architectural tactics and patterns is required to fulll the quality scenarios and allocating functionality to instantiate the module types provided by the patterns.

First design for functionality and then assess and transform architecture in terms of quality attributes until satisfactory solution is found. Four assessment and ve transformation techniques are described.

Do not anticipate and design for the future, and keep design as simple as possible. Adhering to the practices ensures that the emerging architecture is easily extensible and modiable.

Solution

Focus on large-scale information systems characterized by complex and concurrent information ows, deployment to multiple heterogeneous processing units, long life-cycles, multiple users, and several quality requirements such as security, availability, performance, scalability, and evolution.

Requires the architectural drivers as input, and thus needs requirements before the analysis phase although the phase does not have to be nished before the architecture design begins. ADD doesn't result in an implementation-ready architecture in the sense that further technology-specic design decisions have to be made.

Applicability not directly described. Applied in realarm systems, measurement systems, and dialysis systems. Since quality attributes are taken into account only after functionality, application in situations with strict, possibly conicting quality requirements may lead to several iterations until satisfactory architecture is found.

Typically successful in small projects with small teams in high-change environments [2]. XP's applicability to larger more complex projects has been questioned [12,13,14]. Successful in larger project when extended with, e.g., explicit architecture design [15,16,17].

Applicability

Table 1: Problem, solution, and applicability of approaches.

In contrast, architecture design approaches address change through responding to architectural drivers. Since changes may have architectural ramications, modiability, exibility and portability concerns are often reected within architectural drivers. Architecture design approaches aim at nding a trade-o between the ability to change and other possibly conicting drivers, such as performance or reliability. On one hand, all the discussed architecture design approaches use scenarios for concretizing ability to accommodate change. ADD does this in the most detail by specifying templates for modiability scenarios. However, it is not feasible to design an architecture able to answer to every possible modiability scenario. Instead, approaches highlight the importance of minimizing risk, that is, anticipating the most probable and most laborious changes. On the other hand, software architecture design approaches employ dierent means of achieving design that is easy to change. Typically, approaches utilize codied knowledge such as styles, tactics and patterns that have known eects on the ability to accommodate change. RWADP also provides an evolution perspective that groups activities, tactics and guidelines aimed at enhancing the ability to accommodate changes after deployment. The weakness of architecture design approaches is their ability to handle uncertain or changing architectural drivers. All approaches assume that architecturally signicant requirements are known at least to some extent before the design can begin. However, such requirements may still be uncertain at that point, or change later on. To summarize, the fundamental dierence with XP is that architecture design approaches respond to change by trying to anticipate it and reecting this anticipation in the design. If changes can be anticipated to some degree, they can be prepared for in the design. However, if the need for change emerges completely unexpectedly, the architecture design approaches give no explicit support. Where expected changes do not occur, the architecture design approaches have caused some unnecessary work.

How XP addresses the problem addressed by architecture design approaches: The main concern of architecture design approaches is to ensure support for crosscutting architectural concerns, or architectural drivers. In contrast, XP does not explicitly address such concerns in its practices or values. However, modiability as an architectural driver receives specic attention in XP. The practices aim to keep design and implementation as simple and loosely coupled as possible, thus making future modications easier. Further, automated testing tries to ensure that modications and refactoring do not create faults in the existing code. XP assumes that architectural concerns are embedded into stories that specify the requirements for each iteration. However, unless otherwise directed, stakeholders are argued to have a tendency to focus on functionality, not on quality attributes [18]. Therefore, without explicit focus, the eciency of user stories to represent architectural drivers is questionable.

5.2

What the approaches can learn from each other

What architecture design approaches can learn from the solution of XP: Although XP itself is in contrast to the architecture design approaches because of its lack of up-front design, some of the values and practices of XP are already reected in software architecture design approaches. For example, an emphasis on stakeholder involvement is consistent with many values and practices of XP. However, there are several ways in which architecture design approaches can adopt ideas from XP. Values of communication, respect, and feedback could be given more emphasis. Face-to-face communication helps to increase tacit knowledge related to the architecture [2]. Architecture design could be less document driven: Nord and Tomayko [18] suggest keeping the architecture, quality attributes, and constraints visible on a wall or a whiteboard in the work room. Architecture design could also learn from XP's values of simplicity and courage. Instead of trying to over-engineer architecture design that tries to take every little detail into account, the degree of up-front design should be in relation to the architectural complexity of the requirements. Courage could be shown by emphasizing the need to end the design eort once the most important and risky concerns have been addressed in order to ensure that something will be delivered. Iterative and incremental practices are at the core of XP. While QASAR and RWADP acknowledge iterations, the iterations are more concerned with adjusting the design to meet requirements than with reacting to change. Especially when architectural drivers are not clear at the beginning, architecture design should be conducted iteratively and incrementally. In this respect, XP contains detailed knowledge on applying such iterations in practice. Software architecture methods should, for example, concentrate on keeping the architecture documentation easy to update and modify in order to enable changes in design decisions.

What XP can learn from the solution of architecture design approaches: The key issue in adopting software architecture design approaches into XP is to ensure its agility and agile values. Since XP is heavily based on not designing up front, care should be taken when adopting design practices or concepts. For example, a full-edged architecture design before starting implementation might cause a lot of work in vain if changes occur during development. Architecture design approaches emphasize the involvement of stakeholders for providing requirements. In contrast, XP assumes that a customer or customer representative picks stories to be implemented. It might be that XP focuses too closely on the customer, and neglects the requirements of other stakeholders. In fact, customer requirements may be in conict with requirements of other stakeholders, such as administrators or deployers: Although XP acknowledges dierent roles within the XP team [8], it does not cover the whole spectrum of stakeholders as requirement providers. For example, input by a person with experience in software maintenance could be used at least to ensure that no design decisions are made that will impair maintainability.

While software architecture design approaches utilize scenarios for capturing architectural drivers, XP provides its requirements in the form of stories that capture customer-visible functionality [8]. In order to put more focus on quality attribute requirements and other nonfunctional architectural drivers, XP could adopt ideas from architectural scenarios. Nord and Tomayko [18] suggest that Quality Attribute Workshop (QAW) be used during XP's story production to elicitate quality attribute requirements in the form of scenarios with the help of stakeholders. Architecture design approaches emphasize the importance of making architecturally signicant design decisions early on, that is, design decisions that focus on architectural drivers. This avoids costly architecture-level refactoring later. Since architecture in XP is designed as an integrated activity during iterations, the order of stories aects the order of design decisions that are made. If stories are picked in such an order that architecturally signicant stories come very late, costly refactorings will be required to accommodate changes to the architecture. XP states that the stories should be sequenced for business, not technical reasons [8]. However, not only the business needs, but also their level of diculty to achieve determines whether a story is architecturally signicant. Therefore, XP could benet from the practice of prioritizing stories on the basis of their architectural complexity as well as their importance, and selecting stories in this order. Architecture design approaches use architecture evaluation to assess whether the design meets stakeholders' concerns. Nord and Tomayko [18] suggest that the Architecture Trade-o Analysis Method (ATAM) be used to provide early feedback in XP. However, the exact place and format of the evaluation depends on when and how architecture is designed. If at least part of the architecture is designed up front, ATAM or any other evaluation method could be used for providing early feedback. If architecture design is a continuous activity during iterations, very lightweight evaluations could be performed during the iterations. According to Fowler [9], XP discourages using patterns before they are needed but the design evolves toward patterns as they become needed. XP doesn't prescribe any tactics or transformations: it relies on the experience of the developers for the design to evolve in the right direction. However, catalogs of general tactics or transformations could be used as guidelines in strategies of refactoring and design.

6

Discussion

In this section we discuss combining XP with software architecture design methods. We also examine a ve-factor evaluation method [2] intended for choosing between agile and plan-based software processes and propose an extension to help in choosing a similar balance in architecture design.

6.1

Issues in combination of approaches

Based on the comparison in the previous sections, XP and architecture can be combined in dierent ways to nd a balance. First, architecture design approaches could be used in XP during the rst iterations to design an initial architecture. This approach introduces up-front design to XP and might therefore have a negative eect on its agility. Second, practices of architecture design approaches could be used in XP during its iterations. By this we mean that in addition to user stories, the architect and the stakeholders could, e.g., create quality scenarios to discover quality requirements and then create stories related to them. The implementation order of the stories could also be prioritized to ensure easier implementation of the discovered qualities. A third approach would be to use a software architecture design approach to create the initial architecture and decomposition and then apply XP to the development of the individual modules. In this approach, XP would consider the architectural aspects of the system as requirements for the modules. Ideally, the decomposition could take into account the dynamism of the requirements of decomposed modules. For example, an information management system could be decomposed into business logic, database and graphical user interface. Thereafter, uncertain and changing requirements of GUI could be alleviated by developing the module using XP. As with the rst approach, however, this could have a negative eect on the overall agility of the project.

6.2

Applicability

Based on the research it seems that the software architecture design approaches in question are not well suited for environments of high uncertainty because the architectural drivers might not be clear initially. The up-front nature of the architecture design approaches is argued to be ineective in high-change environments [2] although conicting reports suggest that higher investment in architecture design is a key factor in response to change [19]. On the other hand, the approach of XP seems to be lacking when it comes to architectural drivers other than modiability. Therefore, XP does not seem to be optimal for projects where architectural complexity is high. Boehm and Turner [2] have proposed ve factors to consider when determining the relative suitability of agile or plan-driven methods in a project (Figure 2). The factors are size of the team, criticality of the software, skill level of the personnel, dynamism of the environment, i.e. frequency of requirement changes, and the orderliness or chaos of the culture. Although the factors proposed by Boehm and Turner are meant to be used when considering the whole development process, they could also be used when considering the balance between agile and more traditional architecture design approaches. Architecture design approaches don't explicitly state how they should be situated in the overall development process nor do they make claims

Fig. 2: Boehm and Turner's factors aecting the suitability of agile or plan-driven methods in a project. [2]

about the kind of process in which they can be used. Thus it is possible to combine solutions from both sides, as discussed in Section 5.2. In addition to the factors mentioned by Boehm and Turner, we propose two factors that should aect the selection. The rst is the amount of uncertainty related to the requirements, especially related to architectural drivers. In contrast to dynamism, which considers changes to existing requirements, uncertainty means the probability of new, previously unknown requirements emerging during the project. In projects where such uncertainty is high, the axis would point toward a more agile approach like XP. The second factor is the expected diculty of architectural concerns or the expected architectural complexity or risk in general. Plan-driven methods lean toward the higher end of the scale, whereas agile methods like XP are recommended when architectural complexity is low. Architectural complexity might be dicult to evaluate at the beginning of the project but more experienced architects should be able to give some estimates.

7

Conclusions

We have presented a comparison of Extreme Programming (XP) and three software architecture design approaches from an architecture point of view, namely QASAR, ADD and the one by Rozanski and Woods.

Although these studied architecture design approaches are relatively similar to each other, they dier from XP in terms of problems, solutions, and applicability. XP's strength and focus are in coping with changing and, especially, uncertain requirements by ensuring exibility and simplicity. Architecture design methods concentrate on and are strongest in fullling major cross-cutting requirements that often are nonfunctional. We have identied three ways to combine XP and software architecture design approaches: use architecture design approaches during the rst iterations of XP, use practices of architecture design approaches throughout XP, or use architecture design approaches to design the overall architecture and distinct modules that are implemented using XP. We have also proposed two additional factors, namely uncertainty of requirements and number of dicult architectural drivers, to consider when choosing between a more traditional and an agile approach to architecture design. However, further research is needed because of the seeming tension between the approaches. Ways to combine the practices of XP as well as architecture design approaches should be studied because the problem of choosing between an agile and a traditional approach can have a major eect on the outcome of a project. Further, practical guidance should be given in selecting a suitable combination. Finally, we limited our study to architecture. However, other software artifacts and phases, such as requirements and requirements engineering, should be studied similarly, instead of assuming the results of this paper are directly generalizable to them.

Acknowledgements The authors acknowledge the nancial support of Tekes, the Finnish Funding Agency for Technology and Innovation.

References 1. Fowler, M., Highsmith, J.: The Agile Manifesto. http://agilemanifesto.org 2. Boehm, B., Turner, R.: Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley (2003) 3. Beck, K.: Embracing Change with Extreme Programming. IEEE Computer 32(10) (1999) 4. Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice, 2nd Edition. Addison-Wesley (2003) 5. Bosch, J.: Design And Use of Software Architectures: Adopting and evolving a product-line approach. Addison-Wesley (2000) 6. Rozanski, N., Woods, E.: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional (2005)

7. Abrahamsson, P., Warsta, J., Siponen, M.T., Ronkainen, J.: New Directions on Agile Methods: A Comparative Analysis. In: 25th International Conference on Software Engineering, IEEE Computer Society (2003) 8. Beck, K., Andres, C.: Extreme Programming Explained: Embrace Change 2nd Edition. Addison-Wesley Professional (2004) 9. Fowler, M.: Is Design Dead? Extreme Programming Examined (2001) 317 10. Fowler, M.: Refactoring: Improving the Design of Existing Code. Addison-Wesley (1999) 11. Bass, L.J., Klein, M., Bachmann, F.: Quality Attribute Design Primitives and the Attribute Driven Design Method. In: 4th International Workshop on Software Product-Family Engineering. (2002) 12. Lindvall, M., Basili, V.R., Boehm, B.W., Costa, P., Dangle, K., Shull, F., Roseanne Tesoriero, L.A.W., Zelkowitz, M.V.: Empirical Findings in Agile Methods. In: Second XP Universe and First Agile Universe Conference on Extreme Programming and Agile Methods - XP/Agile Universe 2002. (2002) 13. Boehm, B.: Get Ready for Agile Methods, with Care. IEEE Computer 35(1) (2002) 6469 14. Juric, R.: Extreme Programming and its Development Practices. In: 22nd International Conference on Information Technology Interfaces ITI 2000. (2000) 97104 15. Cao, L., Mohan, K., Xu, P., Ramesh, B.: How Extreme Does Extreme Programming Have to Be? Adapting XP Practices to Large-Scale Projects. In: 37th Annual Hawaii International Conference on System Sciences. (2004) 16. Bowers, J., May, J., Melander, E., Baarman, M., Ayoob, A.: Tailoring XP for Large System Mission Critical Software Development. In: Second XP Universe and First Agile Universe Conference on Extreme Programming and Agile Methods - XP/Agile Universe 2002, Springer-Verlag (2002) 100111 17. Eckstein, J.: Agile Software Development in the Large: Diving Into the Deep. Dorset House Publishing Company, Incorporated, New York, NY, USA (June 2004) 18. Nord, R.L., Tomayko, J.E.: Software Architecture-Centric Methods and Agile Development. IEEE Software 23(2) (2006) 4753 19. MacCormack, A., Verganti, R., Iansiti, M.: Developing Products on "Internet Time": The Anatomy of a Flexible Development Process. Manage. Sci. 47(1) (2001)