Page 96 -

TRANSITION TO AGILE SOFTWARE DEVELOPMENT IN A LARGE-SCALE PROJECT 81
Figure 6.5 Complexities per Size in Eight Monthly Checkpoints

Logic Complexity per Size
0.20

0.15

0.10

0.05
Feb Mar Apr May Jun Jul Aug Sep
SpecP SpecA

Keyword Complexity per Size
0.15

0.13

0.11

0.09

0.07
Feb Mar Apr May Jun Jul Aug Sep
SpecP SpecA

for the division of tests into test suites: by modules in the plan-driven project and by tasks in the
agile project. This gives the plan-driven project the advantage of matching the structure of test
suites to the structure of the specifications, and gives the agile project the advantage of parallel
development and a larger available testing force.
Accordingly, as has been explained above, the absolute number of test suites in each project
is not an appropriate indicator of the actual complexity of the tests in each project. The number
of tests steps, however, is a sound factor for assessing test complexity, since, by nature, it does
not depend on how tests are packaged. The number of test scenarios (a list of test steps) is also a
reasonable indicator, since scenarios are usually written in the same way in both projects.
In order to compare the two projects, some form of normalization is required. It is possible to
normalize in different ways: by the number of modules in each project, the total size, the keyword-
based complexity, or the logic-based complexity. Table 6.1 summarizes, according to these four
factors in the last checkpoint, the ratio of the plan-driven project to the agile project.