![](bg2.png)
unavailable for serious reflection. This approach of
proposing generic process ‘solutions’ can no longer
be justified. In addition, the intertwining of practice
and context means that context alters as a result of
practice, and so our viewing of ‘context’ as some-
thing fixed is also no longer helpful. An inexperi-
enced developer who participates in a series of formal
design reviews is changed by the experience. Rather
than continuing to propose and justify sets of defined
practices within fixed contexts, we must follow other
disciplines and turn our focus towards understanding
more deeply the relationships between practice and
context. Many researchers have sought such under-
standing, mainly by examining practice efficacy in a
specific situation. For a comprehensive overview of
this research, see (McLeod and MacDonell, 2011).
We suggest that such investigations, although in-
teresting, have limited utility because of the large
number of possible contextual factors. Without a the-
oretical model of the problem space, our investiga-
tions must necessarily remain fragmented. In this
paper, we address this gap by first abstracting the
problem space and then aiming to understand the
relationships between practices and our abstraction.
Our model is based on observations made by Or-
likowski during a study of distributed development
(Orlikowski, 2002) (see section 2). We propose a six-
dimensional model, with dimensions organisational
drivers (why), space and time (where), culture (who),
product life-cycle stage (when), product constraints
(what) and engagement constraints(how). We test our
model by analysing a reported study into the causes of
overscoping in a large organisation, and explore pos-
sible explanations for findings.
The contributions of this paper are a novel ap-
proach to understanding situated software practices
and an abstraction of the software problem space
based on work in other disciplines. In section 2, we
overview studies aimed at problem space abstraction.
In section 3, we present our proposed model. In sec-
tion 4 we apply it to understand an implementation
study from the literature and in section 5 we discuss
findings. In section 6, we summarise the paper and
discuss limitations and future work.
2 ABSTRACTING THE PROBLEM
SPACE
In this section, we overview research aimed at cate-
gorising the problem space along various dimensions.
Avison and Pries-Heje aimed to support selec-
tion of a suitable methodology that is project-specific
(Avison and Pries-Heje, 2008). For a given project,
the authors plotted position along each of eight di-
mensions on a radar graph and inferred an appropriate
methodology from the shape of the plotted graph.
While we support the intent to understanding
project-space in this way, we see two limitations in
the work. First, the abstracted categories are based
on inputs from a single organisation and so are in-
evitably scoped to the operating space for the organ-
isation. This means that, although key ideas such as
distance, quality, and culture are included, some im-
portant contexts are missing. One example is the need
to consider the business goals of the organsation when
selecting practices (Wang et al., 2012). Lepmets et
al. suggest that processes “are part of a larger or-
ganizational system and therefore cannot be tinkered
with in isolation” (Lepmets et al., 2012). A second
limitation is that the abstraction is based at the level
of the project. In the realm of software development
this has implications of spanning requirements deter-
mination through to product delivery and we suggest
that this scope is not sufficiently broad. For exam-
ple, the most important practices recommended for
new product developmentare at ‘the leading edge’ i.e.
involve issues of strategy and product determination,
and these occur before a ‘project’ to develop the new
product is commenced. Another example involves
the ‘software-as-a-service (SaaS)’ delivery paradigm.
Here we note that the emphasis changes from a ‘de-
veloper driven’ to a ‘customer-driven’ environment,
where the on-going relationship between develop-
ment group and customer becomes key (Stuckenberg
and Heinzl, 2010). Again, this is not part of a ‘project’
as we generally understand it.
Clarke and O’Connor propose a reference frame-
work for situational factors affecting software devel-
opment (Clarke and O’Connor, 2012). One aim is
to “develop a profile of the situational characteris-
tics of a software development setting” and to use
this to support process definition and optimisation.
The framework includes eight classifications: Person-
nel, Requirements, Application, Technology, Organi-
sation, Operation, Management and Business, further
divided into 44 factors. Our critique of this approach
is that it remains ‘factors-based’. Although factors are
grouped into classifications, there is no meaning that
helps us understand relevance. For example, the fac-
tor ‘Cohesion’ represents a number of different kinds
of ‘meaning’, including “team members who have not
worked for you”, “ability to work with uncertain ob-
jectives” and “team geographically distant”. These
three meanings can be viewed as quite different.
Kruchten presents a contextual model based on
experience for situating agile practices. The aim of
the model is to “guide the adoption and adaptation of
ENASE2013-8thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering
198