Progress Report on a Proposed Theory for Software Development

Diana Kirk

and Stephen G. MacDonell

Consultant, Auckland, New Zealand

Software Engineering Laboratory (SERL), Auckland University of Technology (AUT), Auckland, New Zealand

Keywords:

Software Development, Software Engineering, Theoretical Model, Software Context.

Abstract:

There is growing acknowledgement within the software engineering community that a theory of software

development is needed to integrate the myriad methodologies that are currently popular, some of which are

based on opposing perspectives. We have been developing such a theory for a number of years. In this position

paper, we overview our theory along with progress made thus far. We suggest that, once fully developed,

this theory, or one similar to it, may be applied to support situated software development, by providing an

overarching model within which software initiatives might be categorised and understood. Such understanding

would inevitably lead to greater predictability with respect to outcomes.

1 INTRODUCTION

The term Software Engineering was coined in 1968

at a conference whose aim was to discuss the need

for the software development discipline to be more

strongly based on theoretical and engineering princi-

ples (Naur and Randell, 1969). The Waterfall model,

a then-popular model used in manufacturing, was

adopted as the standard approach for developing com-

puter software. As time progressed, it became ap-

parent that a strict implementation of this model was

not appropriate for software. A number of modiﬁ-

cations, for example Spiral (Boehm, 1988), and al-

ternative models, for example XP (Beck, 2000), have

emerged. The authors of the various models have dif-

ferent viewpoints on what kind of activity software

development actually is. Earlier models view soft-

ware development as an engineering activity and fo-

cus on control. More recent models adopt the view-

point of ‘software-as-a-service’and focus on effective

communications. However, regardless of the huge

variation in approach, until recently, the accepted wis-

dom by all methodology architects was that, in or-

der to be fully effective, their approach must be fol-

lowed exactly, with nothingadded and nothingmissed

(Cusumano et al., 2003).

We have long understood from experiences in in-

dustry that this ‘wisdom’ is not based on what actually

happens in the ﬁeld, and have advocated with others

the need to more deeply understand the process of de-

veloping computer software in order to support indus-

try in its need to select practices in a ﬂexible way, ac-

cording to objectives and context (Bajec et al., 2007;

Fitzgerald, 1997; Hansson et al., 2009; Kirk and Tem-

pero, 2004; Kirk and Tempero, 2005; Kirk, 2007).

This viewpoint has now become the accepted one

(Avison and Pries-Heje, 2008; MacCormack et al.,

2012; Petersen and Wohlin, 2009; de Azevedo San-

tos et al., 2011; Turner et al., 2010). The traditional

viewpoint — that methodologies and practices should

be adopted and used as prescribed — has thus been

superseded by one of acceptance that tailoring is both

necessary and unavoidable.

If tailoring is of the essence, we clearly must strive

to fully understand the nature of the relationships be-

tween objectives, process and context. Only then will

we be in a position to advise industry on which prac-

tices might be most suitable or to predict project out-

comes based on context and practices implemented.

The sole route to this kind of general understanding

is through theory-building (Gilmore, 1990). Without

an understanding of the relationships between objec-

tives, practices, context and outcomes, we can at best

expose patterns based on data or observations. Such

patterns represent correlations and correlations can

not be used to predict in a general way. For consis-

tent prediction, we must create frameworks based on

causal relationships i.e. theoretical models. Indeed,

Basili et al. remind us that, when carrying out con-

trolled experiments, “... it is hard to know how to ab-

stract important knowledge without a framework for

relating the studies” (Basili et al., 1999).

161

Kirk D. and MacDonell S..

Progress Report on a Proposed Theory for Software Development.

DOI: 10.5220/0005552401610167

In Proceedings of the 10th International Conference on Software Paradigm Trends (ICSOFT-PT-2015), pages 161-167

ISBN: 978-989-758-115-1

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

The role of theory in software engineering (SE)

has been investigated from a number of perspectives.

Sjøberg et al. observed that there is very little fo-

cus on theories in software engineering and remind

us of the key role played by theory-building if we

wish to accumulate knowledge that may be used in

a wide range of settings (Sjøberg et al., 2008). Han-

nay et al. conducted a review of the literature on ex-

periments in SE and found that fewer than a third of

studies applied theory to explain the cause-and-effect

relationship(s) under investigation, and that a third of

the theories applied were themselves proposed by the

article authors (Hannay et al., 2007). Gregor exam-

ined the nature of theory in Information Systems (IS)

and found multiple views on what constitutes a the-

ory (Gregor, 2006). Stol and Fitzgerald argue that

SE research does, in fact, exhibit traces of theory and

suggest that the current focus on evidence based soft-

ware engineering (EBSE) must be combined with a

theory-focussed research approach to support expla-

nation and prediction (Stol and Fitzgerald, 2013).

While there is general agreement within the re-

search community that an increased focus on theory

building would produce beneﬁts, there remains un-

certainty about how to proceed. Wand et al. remind

us that “To employ conceptual modeling constructs

effectively, their meanings have to be deﬁned rigor-

ously” and that achievement of this requires an artic-

ulation within the context of ontology (Wand et al.,

1999). The authors apply an ontological framework

developed by Bunge (Bunge, 1977) to analyse the re-

lationship construct in entity-relationship modelling.

A number of authors have used their approach to in-

vestigate various aspects of IS, for example, UML

(Opdahl and Henderson-Sellers, 2002) and reference

models (Fettke and Loos, 2003). A key aspect of the

approach is the ability to conﬁrm that a model is com-

plete and without redundancy.

Our overall research objective is to apply an onto-

logical approach in the development of a conceptual

model to describe a software initiative. By software

initiative, we mean the software-related processes im-

plemented to achieve speciﬁed outcomes. We sug-

gest that the existence of such a model would support

the software industry in the selection of appropriate

practices, according to an organisation’s speciﬁc ob-

jectives and contexts. However, before we are in a po-

sition to formally conceptualise a software initiative,

we must gain a better understanding of the constructs

that will form the basis of our model. In this paper,we

present our progress towards this deeper understand-

ing. In section 2, we overview our progress thus far.

In section 3 we discuss other efforts towards provid-

ing a theoretical foundation for software development

and in section 4, we summarise the paper and discuss

limitations and future work.

2 THEORY OVERVIEW

Our ﬁrst observation is that we must scope our model

to include any software initiative i.e. the scope is

larger than a software project. Our rationale is the

need to consider in a holistic way the entire software-

in-a-system (SIAS) i.e. the software product or ser-

vice as part of a larger whole. This ‘whole’ will vary

in time as the software is ﬁrst created and then used.

The larger system during creation will include the de-

velopment organisation, test environments (possibly

stand-alone) and the client. After deployment, the

software will become part of a system comprising any

of hardware, software, humans and processes. The

job is to create, deliver and sustain healthy software

systems over a lifetime of operation. The reason be-

hind our viewpoint of a need for greater holism has

its roots in the uncertainty that results from the grow-

ing complexity of software systems. This complexity

makes it impossible to categorise in a simple way the

environment during development and makes it difﬁ-

cult to anticipate all future conditions under which

the software will run i.e. we can no longer assume

a stable and bounded operating environment. Con-

ditions such as technology change and inappropriate

use will probably affect the in-situ efﬁcacy of the soft-

ware. Uncertainty also characterises delivery mecha-

nisms — in the past, a project developed a software

productand then delivered this to a knownclient base.

More recently, the web-based mechanism of ‘deliver

a little, solicit immediate client feedback, and deliver

the next increment’ has become popular (Stuckenberg

and Heinzl, 2010), leaving the concept of a ‘project-

to-develop-then-deliver’ no longer tenable.

As early as 1987, Basili and Rombach believed

that ”Sound tailoring requires the ability to charac-

terise ... goals ..., the environment ..., and the effect

of methods and tools on achieving these goals in a

particular environment” (Basili and Rombach, 1987).

Our efforts thus far have focused on clarifying what

this might mean when considering ﬂexibility in soft-

ware initiatives. We thus begin with a consideration

of objectives, process and context. In the following

sections, we overviewour efforts and comment on un-

derstandings achieved.

2.1 Objectives

We ﬁrst observe the need to consider more than one

objective for an initiative (Kirk and Tempero, 2005;

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends

162

Kirk et al., 2009). The reason is that a focus on a

single outcome may lead to the identiﬁcation of a lo-

cal maximum and a possible sub-optimisation of the

whole system (Kitchenham et al., 2002; Lakey, 2003;

Lehman, 1997). We next observe that there are many

possible objectives, including the common product-

related ones of minimisation of cost and maximisa-

tion of quality, but also including the people-related

ones such as ‘increase developer subject-area knowl-

edge’, ‘retain developers’ or ‘keep a speciﬁc customer

happy’. For some of these, an associated numerical

value will change throughout the initiative, for exam-

ple, when spending increases throughout a project.

For others, the goal is less deﬁnitive and a more

fuzzy measure may be appropriate, for example, de-

veloper satisfaction levels may be described as ‘Low’,

‘Medium’ and ‘High’ (Kirk and MacDonell, 2009). A

third observation is that most software initiatives are

characterised by uncertainty (Atkinson et al., 2006;

Perminova et al., 2007) and this means that values

cannot be represented in a deterministic way. A prob-

abilistic distribution is a more suitable measure for

some kinds of objective (Connor, 2007; Kitchenham

and Linkman, 1997; Rao et al., 2008). Our proposal

is that a set of objectives may be modelled by a set of

values, the type of value for each depending upon the

nature of the objective. An implementation would in-

volve representing an objective by a name, a descrip-

tion and a desired value.

Monitoring of progress, i.e. ‘current state’, will

involve a consideration of the current value for each

objective in the set. This takes into account the fact

that state values are generally not ‘empty’ at com-

mencement. For example, developers will have a cer-

tain ‘satisfaction’ level at commencement; in a prod-

uct line situation, there is an existing code base that

is characterised by a level of quality. We have as yet

taken this investigation no further i.e. the structure of

objectives is an open research question.

2.2 Process

We view a process as a set of practices. Each Prac-

tice has the effect of moving the initiative closer to (or

further away from) its Objectives. We observe that,

in addition to the accepted practices such as ‘design

inspection’, our deﬁnition includes anything that has

the desired effect. For example, in a small startup or-

ganisation, an informal, unplanned practice such as

‘chat over lunch’ may be crucial for supporting the

developer’s understanding of what is to be built and is

thus an acceptable ‘practice’ in our model. Accord-

ing to our model, an effective practice is one that suc-

cessfully moves the initiative in the right direction. A

‘lean’ process is one in which every practice is effec-

tive.

The space of all possible practices is huge, and

includes practices for identifying the target audience

for a proposed product and understanding what the

product should do, practices for designing, imple-

menting and delivering the product, and practices

for supporting product use in the target environ-

ment(s). We clearly need to introduce some struc-

ture, but found that the standard reference models

did not suit when attempting to elicit information

from individuals in smaller, less formal organisations

(Kirk and Tempero, 2012a). It was clear that, if we

wanted to capture practices-as-implemented-in-the-

real-world, some new perspective was required.

Our approach considers what organisations need

to achieve at a high level when involved in a software

initiative. Our top-level functional categories are

• Deﬁne what is to be made

• Make it

• Deliver it

We extended these categories to be what we be-

lieve are the main sub-categories for software. These

are shown in table 1.

Table 1: Categories for practices.

Deﬁne Roadmap

Scope

Make Design

Implement

Integrate

Deliver Release

Support

Because we have structured based on function, the

categorisation will support any practice deemed to be

relevant for meeting objectives. Informal meetings in

the lunch room that help developers understand scope

clearly ﬁt into the ‘scope’ category. We hypothesise

that the proposed categorisation addresses all soft-

ware practices. A precondition that an objective be

met is that each category must contain one or more

effective practices. To illustrate, for a ‘Quality’ ob-

jective, including quality considerations during prod-

uct design, implementation and integration will fail to

achieve the objective if quality expectations are not

included during scoping. The identiﬁcation of gaps is

straightforward.

The categorisation above does not imply any or-

dering of practices. Such ordering would exist at a

higher level and might be used to describe strategies

of iteration and incremental delivery. We also sub-

mit that the categorisation is ‘paradigm-agnostic’ —

ProgressReportonaProposedTheoryforSoftwareDevelopment

163

whether an initiative is run in a traditional or agile

way, the basic functions of deﬁning, making and de-

livering the productmust be carried out. Of note is the

fact that the sub-categories ‘Roadmap’ and ‘Support’

lie outside of a traditional development project and

sub-categories ‘Scope’ and ‘Release’ relate to prac-

tices that span development organisation and client.

Our work on the practices aspect of the proposed

theory is embryonic. Testing thus far is limited to

a single, exploratory study in which we captured

practices in three New Zealand software organisa-

tions (Kirk and Tempero, 2012a; Kirk and Tempero,

2012b). We did expose some interesting areas for

further study. For example, all participating organ-

isations reported a dependence on practices that in-

volved having to actively search for information, pos-

sibly implying some inefﬁciency as individuals must

spend time. However, the study was exploratory in

nature and this is an open research area.

2.3 Context

This represents the most challenging aspect of any

theory for software development. There have been

many attempts to relate project outcomes to speciﬁc

contextual factors, for example, (Avison and Pries-

Heje, 2008; Clarke and O’Connor, 2012; Kruchten,

2013; Stuckenberg and Heinzl, 2010). Our main cri-

tique of existing approaches is that they remain fac-

tors based (Kirk and MacDonell, 2013). We suggest

that such an approach is misguided because

• there are simply too many possible factors to take

into consideration, and this number will increase

as new paradigms for software are introduced.

• it is unlikely that any two projects will be ex-

actly the same and so understanding key factors

for some is unlikely to be of use in a general way.

We believe that it is crucial that we develop an op-

erationalisation of context that will be relevant for all

software initiatives i.e. takes into account the situ-

ated nature of a software product throughtout its life-

time. It seems clear that the required model must

comprise a number of orthogonal dimensions in order

that an initiative can be plotted as a point in the dimen-

sional space. In order to remove the ‘factors-based’

aspect, it is necessary to also ﬁnd suitable abstrac-

tions for each dimension, abstractions that support

a straight-forward identiﬁcation of value for a given

initiative. For example, rather than deﬁne a number

of factors such as ‘developer experience’, ‘developer

subject area knowledge’, we must abstract in such a

way as to render it irrelevant if we have missed a fac-

tor out (for example, ‘developer commitment’).

Our ﬁrst efforts at modelling this space involved

a consideration of the dimensions Who, Where, What,

When, How and Why (Kirk and MacDonell, 2013).

These dimensions have been applied by others to

ensure orthogonality (Dyb˚a et al., 2012; Zachman,

2009). Of course, the usefulness of the abstraction de-

pends upon the choices about what these dimensions

mean. Our assigned meanings are (Kirk and Mac-

Donell, 2014b):

Who associates with peoples’ ability to perform.

Personal characteristics, culture and group struc-

ture are relevant, as these affect levels of under-

standing and conceptual sharing.

Where associates with peoples’ availability. The de-

grees of temporal and physical separation are rel-

evant.

What associates with product characteristics.

Standards expectations, product interfaces and

achieved quality are relevant.

When associates with product life cycle. Examples

are in-development, recently deployed, near re-

tirement (MacDonell et al., 2008).

How associates with engagement expectations.

Client and developer expectations for the mecha-

nisms for product speciﬁcation and delivery will

affect which practices are most appropriate.

Why associates with establishing objectives.

We carried out some ‘proof-of-concept’ studies

on this model, each involving categorising contex-

tual factors from a small number of studies from the

software engineering literature (Kirk and MacDonell,

2014b; Kirk and MacDonell, 2014a). These studies

caused us to reﬁne our understanding of context in

the following ways. In the ﬁrst instance, it became

clear that the dimension why addresses objectives and

is thus not part of a model for context. We also found

that many contextual factors mentioned in the litera-

ture are vague or ambiguous, and so must be clariﬁed

prior to categorising. For example, when considering

the commonly-mentioned factor ‘Company size’, we

suggest that it is not size itself that affects practice se-

lection and/or outcomes, but rather what this means in

terms of culture and physical and temporal separation.

We labelled such factors as ‘Secondary’. Some fac-

tors, such as ‘requirements uncertainty’, may be the

result of one of a number of possible scenarios. For

example, perhaps the client is not clear about what

the product exactly is; perhaps (s)he is simply weak

on decision-making; perhaps (s)he is unable to state

what is wanted because of client-internal processes

i.e. (s)he is waiting for a decision from someone else.

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends

164

We cannot know which practices will be effective un-

til we understand which meaning is relevant. A prac-

tice of ‘regular client meetings with prototypes’ will

not help if the client is waiting for someone else. We

labelled this kind of factor as ‘ambiguous’. Finally,

we noticed that some factors were more ‘high level’in

that they could be more usefully viewed as affecting

strategy. For example, ‘lack of funds’ would likely

force some consideration about strategy, and the re-

sulting decision may, in turn, affect objectives and/or

context. It might be decided that the project should be

abandoned, that some developers should be removed,

or that a minimal product only should be delivered.

We recognise these factors as Strategic factors and re-

move from our discussion of context.

Our current status is that, with our reﬁned deﬁ-

nition of context, we are well into a study to cate-

gorise contextual factors from the literature into our

dimensional model. Thus far, we have met no obsta-

cles. However, we have as yet included only litera-

ture from the software engineering domain and have

constrained the study to the development project. Al-

though we are optimistic, there clearly is much scope

for research in this area, research that must be carried

out before we can be conﬁdent in our proposed struc-

ture for context.

3 RELATED WORK

As far as we are aware, the only initiative to cre-

ate a theory for software is the SEMAT initiative,

launched in 2009 by Ivar Jacobson, Bertrand Meyer

and Richard Soley (Jacobson et al., 2013a). The ap-

proach proposes a SEMAT kernel comprising three

parts. The ﬁrst is a means of measuring project

progress and health, the second categorises the ac-

tivities required to effect progress, and the third de-

ﬁnes the competencies required to effect the activities

(Jacobson and Seidewitz, 2014). There are seven top-

level ‘alphas’ - Requirements, Software System, Work,

Team, Way of Working, Opportunityand Stakeholders.

It is claimed that these concepts support determina-

tion of a project’s health and facilitate selection of a

suitable set of practices.

Although the authors of the SEMAT approach

state that the initiative promotes a “non-prescriptive,

value-based” philosophy that encourages selection of

practices according to context, we suggest that the ap-

proach is, in fact, prescriptive in intent. Each of the

SEMAT elements has a number of states “which may

be used to measure progress and health” (Jacobson

et al., 2013b), and this implies that the health of every

software project can be measured in a common way.

We do not believe this to be the case, because of the

vast number of possible objectives and contexts. In

addition, the SEMAT model appears to offer no guid-

ance on how to choose activities. Other than men-

tioning competencies required for activities, there is

no link between activities and objectives or context.

How do we know if an activity is suitable when the

developers are in different countries or when the team

comprises multiple cultures? The authors state that

gaps and overlaps in activities can be easily identi-

ﬁed, but it is not clear how this can be achieved in

an objective way. We also note that the theory re-

lates to a software project, a scope we have iden-

tiﬁed as being too narrow. For the above reasons,

we have issue with the claim that a general theory is

being developed. We cannot see how the approach

will help researchers better understand practice limi-

tations. Weiringa, discussing the ﬁeld of requirements

engineering, reminds us of the dangers of confusing

solution design with research (Wieringa, 2005). We

suggest that SEMAT, at this point, represents a design

initiative rather than a theory building exercise.

4 DISCUSSION

One characteristic of a successful theory is that op-

posing viewpointscan be more deeply understood and

can be seen to be part of a larger picture. Our concep-

tualisation must address the traditional versus agile

dichotomy. It is not difﬁcult to see that, as a practice

is deﬁned simply as a transformation of current state,

many different practices will exist that implement the

same kind of transformation. For example, in relation

to table 1, the practices ‘Formally document require-

ments’ and XP’s ‘Planning Game’ both result in an in-

creased understandingof what is to be built. However,

if we consider the objectives ‘Reliability’ and ‘In-

crease developer subject area knowledge’, it is likely

that the formal documentation approach will address

the former (as non-functional requirements are an in-

herent part of formal requirements documents) while

‘Planning Game’ will not. The XP approach may re-

quire additional practices to address quality expecta-

tions.

Thus far, we have aimed to gain a better under-

standing of what appear to be the key constructs re-

quired i.e. objectives, process and context. From the

perspective of the Bunge model, we suspect that ob-

jectives and context represent basic ‘things’. How-

ever, a number of aspects are less clear, for example,

the role of process. One possibility is that it may be

represented as a basic ‘thing’. It is more likely that the

constituent practices and context mutually affect each

ProgressReportonaProposedTheoryforSoftwareDevelopment

165

other and this situation is represented as a ‘mutual

property’ in the Bunge scheme. Our analysis above

also exposed the need for a new idea, that of Strate-

gic factor and we do not yet understand what this is

from an ontological perspective. We do not under-

stand how to represent the dimensions we propose for

context — are these properties or constituent compo-

nents of context? What are the repercussions of the

decisions made? This is an exciting step on our jour-

ney, one which we now feel ready to address.

In this paper, we have presented an overview of

the theoretical approach we have been pursuing for

several years. Our work is in-embryo. Our contribu-

tion is that we are making an honest attempt to tackle

an extremely difﬁcult problem, and believe we have

made pockets of progress in some areas. Our hope is

that the efforts we have made thus far will be used as

a starting point for other researchers. We submit that,

if the community does not take the theory-building

initiative seriously, we are doomed to endless cycles

of ‘new’ process paradigms and architectures, each of

which has some merit and many shortfalls.

REFERENCES

Atkinson, R., Crawford, L., and Ward, S. (2006). Fun-

damental uncertainties in projects and the scope of

project management. International Journal of Project

Management, 24:687–698.

Avison, D. and Pries-Heje, J. (2008). Flexible informa-

tion systems development: Designing an appropriate

methodology for different situations. In Filipe, J.,

Cordeiro, J., and Cardoso, J., editors, Enterprise infor-

mation systems : 9th International Conference, ICEIS

2007, pages 212–224, Berlin, Heidelberg. Springer.

Bajec, M., Vavpotic, D., and Krisper, M. (2007). Practice-

driven approach for creating project-speciﬁc software

development methods. Information and Software

Technology, 49:345–365.

Basili, V. R. and Rombach, H. D. (1987). Tailoring the Soft-

ware Process to Project Goals and Environments. In

Proceedings of the Ninth International Conference on

Software Engineering. IEEE, IEEE Computer Society

Press.

Basili, V. R., Shull, F., and Lanubile, F. (1999). Building

Knowledge through Families of Experiments. IEEE

Transactions on Software Engineering, 25(4):456–

473.

Beck, K. (2000). eXtreme Programming eXplained - Em-

brace Change. Addison-Wesley, United States of

America.

Boehm, B. W. (1988). A Spiral Model of Software Devel-

opment and Enhancement. IEEE Computer, May(11).

Bunge, M. A. (1977). Treatise on Basic Philosophy 3. On-

tology 1: The Furniture of the World. D.Reidel Pub-

lishing Company, Dordrecht, Holland.

Clarke, P. and O’Connor, R. V. (2012). The situational fac-

tors that affect the software development process: To-

wards a comprehensive reference framework. Infor-

mation and Software Technology, 54:433–447.

Connor, A. (2007). Probabilistic estimation of software

project duration. New Zealand Journal of Applied

Computing and Information Technology, 11(1):11–22.

Cusumano, M., MacCormack, A., Kemerer, C., and Cran-

dall, B. (2003). Software development worldwide:

The state of the practice. IEEE Software, 20(6):28–

34.

de Azevedo Santos, M., de Souza Bermejo, P. H.,

de Oliveira, M. S., and Tonelli, A. O. (2011). Ag-

ile practices: An assessment of perception of value of

professionals on the quality criteria in performance of

projects. Journal of Software Engineering and Appli-

cations, 4:700–709.

Dyb˚a, T., Sjøberg, D. I., and Cruzes, D. S. (2012). What

Works for Whom, Where, When and Why? On the

Role of Context in Empirical Software Engineering.

In Proceedings of the 6th International Symposium

on Empirical Software Engineering and Measurement

(ESEM 2012), pages 19–28, Lund, Sweden.

Fettke, P. and Loos, P. (2003). Ontological Evaluation

of Reference Models using the Bunge-Wand-Weber

Model. In Proceedings of the Ninth Americas Con-

ference on Information Systems (AMCIS 2003), pages

2944–2955. Association for Information Systems.

Fitzgerald, B. (1997). The use of systems development

methodologies in practice: a ﬁeld study. Information

Systems Journal, pages 201–212.

Gilmore, D. J. (1990). Methodological Issues in the Study

of Programming. In Hoc, J.-M., Green, T., Samur-

cay, R., and Gilmore, D., editors, Psychology of Pro-

gramming, pages 83–98. Academic Press Ltd., Lon-

don, U.K.

Gregor, S. (2006). The nature of theory in Information Sys-

tems. MIS Quarterly: Management Information Sys-

tems, 30(3):611–642.

Hannay, J. E., Sjøberg, D. I. K., and Dyb˚a, T. (2007). A sys-

tematic review of theory use in software engineering

experiments. IEEE Transactions on Software Engi-

neering, 33(2):87–107.

Hansson, C., Dittrich, Y., Gustafsson, B., and Zarnak, S.

(2009). How agile are software development prac-

tices? Journal of Systems and Software, 79:1295–

1311.

Jacobson, I., Meyer, B., and Soley, R. (2013a). Software

Engineering Method and Theory.

Jacobson, I. and Seidewitz, E. (2014). A New Software En-

gineering. Communications of the ACM, 57(12):49–

54.

Jacobson, I., Spence, I., and Ng, P.-W. (2013b). Agile and

SEMAT - Perfect Partners. Communications of the

ACM, 56(11):53–59.

Kirk, D. (2007). A Flexible Software Process Model.

PhD thesis, University of Auckland, Auckland, New

Zealand.

Kirk, D. and MacDonell, S. (2009). A Simulation

Framework to SupportSoftware Project (Re)Planning.

ICSOFT-PT2015-10thInternationalConferenceonSoftwareParadigmTrends

166

In Proceedings of the 35th Euromicro Conference

on Software Engineering Advanced Applications

(SEAA)), pages 285–292. IEEE Computer Society

Press.

Kirk, D. and MacDonell, S. (2013). A model for soft-

ware contexts. In Proceedings of the Eighth Interna-

tional Conference on Evaluation of Novel Approaches

in Software Engineering (ENASE 2013), pages 197–

204.

Kirk, D., MacDonell, S., and Tempero, E. (2009). Mod-

elling software processes - a focus on objectives. In

Proceedings of the 24th ACM SIGPLAN conference

companion on Object oriented programming systems

languages and applications (OOPSLA), Session: On-

ward short papers session 2., pages 941–948, Or-

lando, Florida, USA. ACM Press.

Kirk, D. and MacDonell, S. G. (2014a). Categorising soft-

ware contexts. In Proceedings of 20th Americas Con-

ference on Information Systems, AMCIS 2014.

Kirk, D. and MacDonell, S. G. (2014b). Investigating a con-

ceptual construct for software context. In Proceedings

of the Conference on Empirical Assessment in Soft-

ware Engineering (EASE), number 27.

Kirk, D. and Tempero, E. (2004). Proposal for a Flexible

Software Process Model. In Proceedings of the 5th

International Workshop on Software Process Simula-

tion and Modeling (ProSim’04), Edinburgh, Scotland.

Kirk, D. and Tempero, E. (2005). A Conceptual Model of

the Software Development Process. In Proceedings

of the 6th International Workshop on Software Pro-

cess Simulation and Modeling (ProSim’05), St. Louis,

Missouri. Fraunhofer IRB.

Kirk, D. and Tempero, E. (2012a). A lightweight frame-

work for describing software practices. Journal of

Systems and Software, 85(3):581–594.

Kirk, D. and Tempero, E. (2012b). Software development

practices in New Zealand. In Proceedings of the Nine-

teenth Asia-Paciﬁc Software Engineering Conference

(APSEC 2012), pages 386–395, Hong Kong.

Kitchenham, B. and Linkman, S. (1997). Estimates, Uncer-

tainty and Risk. IEEE Software, 14(3):69–74.

Kitchenham, B. A., Pﬂeeger, S. L., Hoaglin, D. C., El

Emam, K., and Rosenberg, J. (2002). Preliminary

Guidelines for Empirical Research in Software Engi-

neering. IEEE Transactions on Software Engineering,

28(8):721–734.

Kruchten, P. (2013). Contextualizing agile software devel-

opment. Journal of Software: Evolution and Process,

25(4):351–361.

Lakey, P. B. (2003). A Hybrid Software Process Simula-

tion Model for Project Management. In Proceedings

of the 2003 International Workshop on Software Pro-

cess Simulation and Modeling (ProSim’03), Portland,

Oregan, U.S.A.

Lehman, M. (1997). Process Modelling - Where Next. In

Proceedings of the 1997 Conference on Software En-

gineering. IEEE Computer Society Press.

MacCormack, A., Crandall, W., Henderson, P., and

Toft, P. (2012). Do you need a new product-

development strategy? Research Technology Man-

agement, 55(1):34–43.

MacDonell, S., Kirk, D., and McLeod, L. (2008). Rais-

ing Healthy Software Systems. In The 4th Interna-

tional ERCIM Workshop on Software Evolution and

Evolvability (Evol’08), pages 21–24, L’Aquila, Italy.

The European Research Consortium for Informatics

and Mathematics (ERCIM), IEEE Computer Society

Press.

Naur, P. and Randell, B. (1969). NATO Software Engi-

neering Conference 1968. Conference report, NATO

Science Committee. Report on a conference spon-

sored by the NATO SCIENCE COMMITTEE held in

Garmisch, Germany, in October 1968.

Opdahl, A. L. and Henderson-Sellers, B. (2002). Ontolog-

ical Evaluation of the UML Using the Bunge-Wand-

Weber Model. Software and Systems Modeling, 1(1).

Perminova, O., Gustaffson, M., and Wikstrom, K. (2007).

Deﬁning uncertainty in projects a new perspective.

International Journal of Project Management, 26:73–

79.

Petersen, K. and Wohlin, C. (2009). A comparison of issues

and advantages in agile and incremental development

between state of the art and an industrial case. Journal

of Systems and Software, 82:1479–1490.

Rao, U. S., Kestur, S., and Pradhan, C. (2008). Stochastic

Optimization and Modeling and Quantitative Project

Management. IEEE Software, May/June:29–36.

Sjøberg, D. I., Dyb˚a, T., Anda, B. C., and Hannay, J. E.

(2008). Building Theories in Software Engineering,

pages 312–336. Springer-Verlag.

Stol, K. and Fitzgerald, B. (2013). Uncovering Theories

in Software Engineering. In Proceedings of the 2nd

Workshop on Grand Theory in Software Engineering

(GTSE 2013), colocated with ICSE 2013, pages 5–14,

San Francisco, USA.

Stuckenberg, S. and Heinzl, A. (2010). The Impact of

the Software-as-a-Service concept on the Underlying

Software and Service Development Processes. In Pro-

ceedings of the 2010 Paciﬁc Asia Conference on Infor-

mation Systems (PACIS 2010), pages 1297–1308.

Turner, R., Ledwith, A., and Kelly, J. (2010). Project

management in small to medium-sized enterprises:

Matching processes to the nature of the ﬁrm. Interna-

tional Journal of Project Management, 28:744–755.

Wand, Y., Storey, V. C., and Weber, R. (1999). An Ontolog-

ical Analysis of the Relationship Construct in Con-

ceptual Modeling. ACM Transactions on Database

Systems, 24(4):494–528.

Wieringa, R. (2005). Requirements researchers: are we

really doing research? Requirements Engineering,

10:304–306.

Zachman, J. A. (2009). Engineering the Enterprise: The

Zachman Framework for Enterprise Architecture.

ProgressReportonaProposedTheoryforSoftwareDevelopment

167