An Ontological Analysis of a Proposed Theory for Software Development

💡 Research Summary

The paper by Kirk and MacDonell (2016) presents an ontological analysis of a newly proposed theory for software development, which they refer to as a “software initiative” model. The authors begin by arguing that the software engineering community has long recognized the need for a unifying theory that can integrate the diverse and often conflicting methodologies that exist today. Traditional approaches, such as the Waterfall model, have given way to a plethora of alternatives (Spiral, XP, Agile, etc.), each embodying different philosophical views of software development—some emphasizing control and engineering rigor, others emphasizing service orientation and communication. Despite this methodological diversity, the prevailing wisdom for many years insisted that a methodology must be followed rigidly, with no tailoring. The authors contend that this view is unsupported by industrial experience and that tailoring is inevitable; therefore, a theory that captures the relationships among objectives, processes (practices), and context is required to guide practice selection and to enable outcome prediction.

The paper surveys related work on theory building in software engineering, noting that prior efforts (e.g., SEMAT) have attempted to define a kernel of concepts (alphas) and associated states to measure project health. The authors criticize SEMAT for being too prescriptive, limited to the project level, and lacking explicit links between activities, objectives, and context. They argue that a more general theory must encompass the entire “software initiative” – the full lifecycle of software as a system‑in‑a‑system (SIAS), including development, deployment, operation, and maintenance, as well as the surrounding organisational and socio‑technical environment.

The authors’ theory is structured around three core constructs:

1. Objectives – They argue that any initiative should consider multiple, possibly conflicting objectives (cost, quality, developer knowledge, customer satisfaction, etc.). Objectives may be expressed as deterministic values, fuzzy categories (Low/Medium/High), or probabilistic distributions, reflecting the inherent uncertainty of software projects. Monitoring progress involves comparing the current value of each objective against its desired target.

2. Process (Practices) – A practice is defined very broadly as any activity that influences the initiative’s trajectory, ranging from formal design inspections to informal “lunch‑room chats.” Practices are organised into three high‑level functional categories—Define what is to be made, Make it, Deliver it—and further subdivided into sub‑categories (e.g., Scope, Roadmap, Release, Support). This functional taxonomy is intended to be paradigm‑agnostic, supporting both traditional and agile approaches. The authors report an exploratory empirical study in three New Zealand organisations, noting that practitioners often spend considerable effort searching for information, suggesting inefficiencies that merit further investigation.

3. Context – Recognising that factor‑based models (which enumerate a long list of variables such as developer experience, tool usage, etc.) are impractical, the authors propose a six‑dimensional orthogonal space: Who, Where, What, When, How, and Why. Each dimension abstracts a set of related attributes: Who captures personal abilities, culture, and group structure; Where captures temporal and physical separation; What captures product characteristics and standards; When captures lifecycle stage; How captures engagement expectations; Why captures purpose and motivation. By plotting an initiative as a point in this space, the model aims to provide a concise yet comprehensive representation of context that is robust to missing factors.

To evaluate the conceptual soundness of their model, the authors apply an ontological analysis using the Unified Foundational Ontology (UFO), which is based on Bunge’s philosophical ontology. They map each construct to UFO’s categories of types, relations, and properties, checking for completeness (no missing essential elements) and non‑redundancy (no duplicated concepts). The analysis reveals that while most elements are well‑defined, certain ambiguities remain—for example, the causal links between specific objectives and practices are not fully formalised, and the Who and How dimensions exhibit overlapping semantics, suggesting a need for refined definitions.

The paper concludes by acknowledging that the theory is still in an embryonic stage. Future work includes broader empirical validation across diverse organisational and cultural settings, refinement of the objective‑practice‑context causal model, and further ontological tightening to eliminate residual redundancies. The authors argue that their ontological approach demonstrates a viable pathway for constructing rigorous, generalisable software engineering theories that can support flexible practice selection, improve predictability of outcomes, and ultimately bridge the gap between academic models and industrial reality.