The discussed approaches for software architecture analysis have mostly been devel- oped for plan-driven processes. This is mainly because architecture is the primary
means for planning [50] and risk reduction [23] in such processes. An architecture
is usually defined, fully documented, and evaluated before the implementation phase
[5,23]. Architecture evaluation is thus a critical and thorough activity in plan-driven
processes, which requires a significant amount of time and human resources [51]. For
example, an ATAM review may require up to 30 person-days [9].
In agile processes, however, typically no complete up-front architectures are defined. Either a core architecture is created in early iterations of an agile software development process, or the architecture emerges as part of subsequent iterations.
Risk reduction is inherent to the process itself [52]: software is developed in itera-
tions and planning can be adjusted at the beginning of each new iteration to anticipate changes late in development. The focus of agile processes is on early and continuous delivery of customer value in the form of working software. This is achieved, for example, through valuing working software over documentation and communication
over processes and tools [53].
Whether plan-driven methods with an up-front architecture or agile methods with little or no up-front architecture are the appropriate means for development depends
on the kind of project [54,55]. But there is no doubt that the role and means for archi-
tecture analysis are different in agile and lean processes than in plan-driven processes with big up-front design. This leads us to the question of the potential role, the
167
suitability, and the requirements of architecture analysis and architecture analysis methods in agile and lean processes.
Since in agile processes architecture design is also a continuous activity that spreads across the entire development process, architecture analysis needs to be per- formed continuously, too. The concept of analyzing the complete architecture design at a dedicated time in the development process does not hold for agile processes. Also, other assumptions of existing analysis methods—like comprehensive architec- ture documentation, external stakeholders, and long-running, resource-intensive processes—do not align with agile principles. This raises the questions, “Which kinds of analysis and analysis approaches are useful in agile processes?” and, “How do existing analysis approaches need to be adapted?”
7.4.1
CSAA and different kinds of architecture analysis
Different kinds of analysis, in terms of analysis goals, were discussed inSection 7.2.
Continuous releases in agile processes require means for continuous quality control (CQC) to ensure that a system possesses the required quality for each release.
In terms of architecture analysis, continuous compatibility analysis ensures that the (implemented) architecture conforms to company-wide standards, reference architectures, and guidelines.
Continuous analysis of architecture/implementation conformance can be used to prevent architectural drift. In agile processes, it can be used to ensure that the imple- mentation conforms to architectural core decisions and structures defined in previous iterations.
Consistency analysis is important if architectural models are used for capturing these core architectural decisions in agile processes. In this case, continuous consis- tency analysis ensures that the consistency of such models is preserved over time. Completeness analysis plays a minor role in agile processes, since the architecture design evolves continuously. It is thus reduced to completeness analysis of potentially used architectural models, since these models need to be complete if they are to be used for other kinds of analysis or for the generation of implementation artifacts.
We assume that the role of architecture evaluation will also change significantly in agile processes, though we lack reports on the role and importance of this kind of analysis in this context. In plan-driven processes, evaluation is an important means of risk reduction, while in agile processes, risk reduction is inherent to the process itself. In plan-driven processes architecture, evaluation is based on a complete architecture design, but in agile processes, architecture evaluation will be rather incremental and selective, focusing on specific parts of an architecture. Our assumption is that archi- tecture evaluation will still play a role, though we assume that it is less important in agile processes than in plan-driven ones. We also assume that evaluation will require more lightweight methods to support the principles of agile software development. In the following, we take a look at other approaches to CQC in agile processes to derive requirements for CSAA and to discuss the suitability of current approaches for CSAA in the following sections.
7.4.2
Approaches for continuous quality control (CQC)
Approaches for CQC in agile processes include continuous testing [56], continuous
code analysis [57], continuous integration (CI) [57], continuous refactoring [52,58],
and pair-programming [52].
Continuous testing is a combination of techniques and tools like test-driven
development(TDD) andregression testing[56]. TDD [59] is essentially a method
for continuously developing test-cases as part of software design. It is thus also seen as a design approach, because it ensures that the system is testable by applying good
design principles [60]. Regression testing, on the other hand, is the process of retest-
ing software after modifications to ensure that the new version of the software has retained the capabilities of the old version and that no new defects have been intro-
duced [61]. Both TDD and regression testing are well integrated into the develop-
ment process. Tools for creating and executing test cases are integrated with development tools and environments and provide test automation, which is impor- tant due to the principle of constant change in agile processes.
Continuous code analysisas provided by static code analysis tools like PMD,b
Checkstyle,cand FindBugs™dare either directly integrated in an Integrated Devel-
opment Environment (IDE) or in the build infrastructure and can thus be applied automatically and on a regular basis.
CI[57,62] also provides automation using a dedicated build infrastructure (build
server). It promotes the principle of early build and delivery. Builds are typically performed on a daily basis. Building a system usually incorporates the execution of test cases and of static code analysis.
Continuous refactoring [52], on the other hand, focuses on problem resolution
rather than analysis, though analysis activities need to precede refactoring activities.
In the ideal case, refactoring is also performed continuously [58], because it is easier
to make several smaller changes throughout the development process than to make larger changes later in development. However, large refactorings cannot always be
avoided [43]. Refactoring support is often part of modern IDEs.
Finally,pair programming[52] is an example for continuousad hocanalysis dur-
ing development. Code is developed collaboratively by two developers sitting in front
of one machine. Analysis during development isad hocand thus not easily repeatable.
7.4.3
Characteristics of CQC approaches
If we look at the main characteristics of the above approaches, we see integration and continuous application as prominent properties, which are typically not present in approaches for quality control in plan-driven processes.
bhttp://pmd.sourceforge.net/ chttp://checkstyle.sourceforge.net/ dhttp://findbugs.sourceforge.net/
169
Integration takes place not only at the level of the development process, but also
at the level of the development tools and the development team.Process integration
makes it possible to assess a system’s quality as part of the daily development work,
which is necessary to detect and resolve problems early.Tool integrationpermits
seamless switching between constructive and quality control activities, and it also permits performing quality control in response to changes in the implementation. This results in fast feedback of analysis results. Finally, quality control is typically performed by members of the development team—either by developers themselves, or by integrating other stakeholders, like testers, with other team members.
Continuous application of quality control activities means their frequent and repeated application during development. The actual meaning of “frequently”
depends on the CQC approach used and can vary betweeninstantly(on each mod-
ification), multiple times a day,on a daily or weekly basis, orin each iteration.
Repeatability, on the other hand, is important because in agile development processes a system—including requirements, design, and implementation—is continuously extended and modified. Continuous modifications require reanalysis of already-analyzed system parts after system modifications.
In addition, we should note that an important aspect of continuous application is support for problem resolution. In agile processes, it is not only important to detect problems as early as possible, but also to resolve the detected problems as part of the CQC activities used. Therefore, problem resolution is typically, and often implicitly, part of CQC activities.
To summarize, integration and continuous application are main characteristics of approaches for CQC. It can be observed that continuous application in many CQC approaches is facilitated through automation and tool support. For example, continuous testing, continuous code analysis, and CI would not be possible without automation because these approaches encompass activities that would be tedious, time-intensive, and error-prone if performed manually. However some approaches, like refactoring and pair programming, do not rely on automation but rather on process and team integration.
7.4.4
CSAA process
The main activities of a CSAA process align with the typical activities of the soft-
ware architecture analysis meta-process outlined in Section 7.2: goal definition,
preparation, actual analysis, and problem resolution. The main extension is the con-
tinuous application of these activities. This is illustrated inFigure 7.2.
The figure shows that the original architecture analysis process fromSection 7.2
is now a cyclic process. It also starts with the definition of analysis goals—a step that is optional—because once defined, the goals need not be defined anew in subsequent iterations. This is followed by a step for creating and maintaining architectural infor- mation as a basis for performing the actual analysis. Preparing architectural informa- tion is a major activity in plan-driven analysis approaches, and thus it consumes significant resources. In a CSAA process, it is important that this activity can also
be performed with as little effort and resources as possible and as an integrated activ- ity of the development process. This means that it is not possible to create complete and extensive documentation, which has to be maintained in subsequent iterations. Instead, this effort needs to be reduced by restricting the created information selec- tively to the analysis task at hand and by automatically generating architectural infor- mation from other artifacts (e.g., by extracting architecture from code). In subsequent iterations, the available architecture documentation (e.g., architecture models) need to be incrementally updated as part of the development process. This means the prep- aration phase of the original architecture analysis process is not mainly concerned with creating architectural information, but with updating and maintaining the exist- ing documentation. Finally, problem resolution is an integrated activity of continu- ous analysis to support the principle of continuous delivery in agile processes.