![](bg2.png)
project? Should system analysts need to Sit Together
with the development team? What is the Whole
Team with respect to system analysis and design and
how this notion is interpreted in a large-scale
software project?
Another example is the XP primary practice of
Weekly Cycle. According to this practice, the work is
planed on a weekly basis in accordance with full
customer collaboration. In this case, we should ask:
What is the role of the system analysts in these
weekly planning sessions? Are system analysts the
mediators or do they listen to the customer together
with the Whole Team (i.e., developers, testers, and
so on)? How do we expect the project specifications
to be expressed in an agile environment?
This paper presents a field research conducted in
a large-scale software project in the Israeli Air
Force. The research examined the process of
transition from heavyweight software development
to agile development. Focusing on the system
analysis and design aspect, the research aims at
answering questions such as above-mentioned ones.
In Section 2 we elaborate on the transition
process and in Section 3 we explain the research
setting for its investigation. In Section 4 we present
data analysis by comparing the agile project
specifications with those of a team which continues
working according to the previous heavyweight
method. The comparison relates to the first half year
of transition. Size and complexity measures are used
for the comparison. In addition, in Section 4 we
present data and analysis with respect to the change
in the role of the system analysts as they conceive of
it. In Section 5 we conclude.
2 THE TRANSITION PROCESS
The in-transition software project that this paper
focuses on has been developed by about eighty
skilled system engineers, system analysts,
developers and testers, organized in a hierarchical
structure of small teams. The project develops large-
scale, enterprise-critical software, intended to be
used by a large and varied user population.
The army is known as a large and hard-to-change
organization with respect to fixed regulations,
project approval, management methods and
organizational structure and culture. However, when
the project leadership decided to change the software
development method in order to cope successfully
with the challenges that the project set, the Air Force
leadership supported the decided-upon transition as
a mean to improve software process and quality.
After several months during which the fitness of
different development methods to the said project
had been investigated, XP was selected to be
implemented and a pilot team of fifteen people was
established and started working according to the
agile method. All the other teams of the project
continued working according to the previous
heavyweight method.
It is important to note that during the years prior
to the transition, tools and procedures were
developed and used by the people in this software
unit. Though it was accepted that agile development
can improve the process, it was also agreed that
there are tools and procedures that will not be
changed at the current stage, whether because they
are good practices or whether because of time
constraints.
The software project is built based on a large-
scale in-house object-oriented framework
(Mohamed, Schmidt and Johnson, 1999), which
handles many of the underlying technical aspects of
the system. One aspect is the 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. This data is 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 design, 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 have to be formal and precise, and as
formality increases, the cost of communication
increases when teams later on communicate in order
to clarify loose ends.
During the transition process all teams in the
project, including the agile team, continue working
with formal detailed specifications and with the
respective tools that support them.
The roles involved with system analysis and
design in this project are architects, operational
system analysts, functional system analysts, and
system engineers. In this work we focus on the
operational and functional system analysts. The
operational system 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 customers and users. The functional system
analysts process the operational specifications and
ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
12