Page 89 -

74 DUBINSKY, HAZZAN, TALBY, AND KEREN
The software project is built based on a large-scale in-house object-oriented framework (Fayad,
Schmidt, and Johnson, 1999), which handles many of the underlying technical aspects of the sys-
tem. One aspect is formal detailed specifications. This framework relies on a metadata repository
(Talby et al., 2002), which contains most of the system’s specifications: data entities, data types,
actions, transactions, user types and privileges, messages, external interfaces, and so forth. These
data are edited in the repository, in formal forms—in contrast to free-text documents—and much
of it is used to automatically generate code and other files.
As a result of working with this framework, the process of development starts with functional
analysis, continues with writing the formal detailed specifications in the metadata repository,
and then coding those parts of the specifications that are not automatically generated. In such a
process, the specification writers should adopt a formal and precise style, and as the formality
increases, the cost of communication increases since team members should communicate later
for clarifications.
During the transition process all teams in the project, including the agile team, continue work-
ing with formal detailed specifications and with the tools that support them.
The roles involved with the systems analysis and design in this project are architects, operational
systems analysts, functional systems analysts, and systems engineers. In this work we focus on the
operational and functional systems analysts. The operational systems analysts are practitioners in
the operational aspects of the project subject matter and are part of an operational analysis group.
They define the system to be developed and they represent the customer and the end users. The
functional systems analysts process the operational specifications, converting them into engineered
technical specifications. They are part of the development group.
The change in the role definitions stems mainly from the change in development process. As
part of the transition process, prior to the development work of the agile team, systems analysts
make only preliminary analysis and deliver the knowledge to the agile team by face-to-face con-
versations, presentations, and/or high-level documents. The agile team then, together with the
customer and systems analysts, produces the detailed project specifications.
THE RESEARCH FRAMEWORK

The exploration of this transition process started two years ago when it was decided to change the
traditional plan-driven software development method that had been used in this organization for
many years. In previous work, we presented the way agile software development was introduced
into this project (Dubinsky, Hazzan, and Keren, 2005) as well as the set of product and process
metrics evolved in the first release of the pilot team, which guided in practice the development
process (Dubinsky et al., 2005).
Two approaches were used in this research of the transition process: a quantitative comparative
approach and a qualitative approach, as is elaborated in what follows.

Quantitative Comparative Approach

The first approach is a quantitative comparative one, by which we aimed at measuring the im-
plications of the transition to the agile method on the systems analysis and design. Accordingly,
we examined and compared two sets of specifications and tests produced by both kinds of teams.
The first set belongs to the team that worked according to the plan-driven method and during the
examined period was in the phase of development and fault corrections before delivery. The sec-
ond set belongs to the team that worked according to the agile method and during the examined