Page 90 -

TRANSITION TO AGILE SOFTWARE DEVELOPMENT IN A LARGE-SCALE PROJECT 75
period developed four releases that were each two months long and composed of four two-week-
long iterations.
We use several measures to compare specifications and tests. One measure is the size of the
specifications and tests, which is used for comparison alignment. Another measure of the specifi-
cations is composed of two measures that are used to assess the complexity of the specifications,
one of which is inspired by the measure of code cyclomatic complexity (McCabe, 1976; Watson
and McCabe, 1996). In the data analysis section the measures are elaborated and illustrated. These
measures were selected because we wanted the quantitative data to represent ongoing real work
rather than one or a few checkpoints of an artificial setting. Using the specifications and test data
enables us to examine continuous fieldwork over eight months.
Though the compared specifications and tests are taken from two different products of two dif-
ferent teams, we suggest that when a comparison between two development methods is made, it
is more important that the two teams work in the same organization, with the same infrastructure
and tools, and with people of similar experience and expertise. Furthermore, in order to eliminate
as much as possible the differences in the two products, we searched for trends and relative-to-size
technical measures rather than absolute numbers.

Qualitative Approach

The second research approach is a qualitative approach in which we sought to understand the
process from the systems analysts’ and designers’ point of view. Accordingly, we interviewed
systems analysts and asked them questions such as “Do you feel that your role has changed? If
no, please describe your role before and after the transition. If yes, please describe how your role
has changed.” “Compare the traditional method of software development and the agile Extreme
Programming one.”
In addition, we used two questionnaires. The first one is a software development culture ques-
tionnaire (Hazzan and Dubinsky, 2005) that maps the perspective of our interviewees with respect
to software development processes (see Appendix 6.1). The second questionnaire is related to the
role of the systems analyst (see Appendix 6.2).

DATA ANALYSIS

In this section, the project specifications and acceptance tests are compared, and the change in the
role of the systems analysts is examined.

Specifications Comparison

As stated earlier, some of the specification measures consider modularity and relative complexity.
To define such measures, we define a module of specifications—in contrast to a module of code,
such as a class or a package. As described above, the specifications of the analyzed projects were
written in a semiformal metadata repository, which enabled the systems analysts and architects
to define specifications modules.
The chosen method of specifications was data-centered; that is, a module in this system com-
pletely specifies one data entity and its related processes. Each module specifies—for one entity
and its subentities—the database layout and properties, application server services, user interface
forms, queries, input and output to external interfaces, permissions, and other specified features.
This comprises the entire business logic that must be implemented. Part of this business logic is