3.1 A philosophical perspective
In the late 1980s W. M. Turski (1986) observed that developing software is inherently difficult because it involves descriptions of properties of both formal and non-formal domains. Formal domains are those which pertain to the artificial, i.e., the software itself and its hardware – man-made artefacts which can be described using fully formal notations, such as code or statements of logic. Non-formal domains are those which pertain to the natural, such as people, organisations or natural phenomena; such domains don’t always allow formal description, and even when they do, different linguistic descriptions are used, which raises the further challenge of how to relate them and reason about them. Consequently, Turski sees developing software as compounding the difficulties of mathematics, in its concern with relationships between formal domains, and of natural science, in its concern with descriptions of the properties of non-formal domains. In Turski’s view an effective software development process would have to deal adequately with descriptions across the formal/non-formal divide.
Think of various descriptions used in software development. Which do you think pertain to the formal and non-formal domains identified by Turski?
You may have considered some of the following.
Code is intrinsically a formal description, usually expressed in a language with formally specified syntax and semantics. Software design can also be captured formally, although semi-formal descriptions (e.g., sketches) can also be used to describe it. Requirements statements are usually non-formal descriptions, often expressed in natural language, that try to capture properties of formal and informal domains, e.g., how people might interact with the system and how the system might respond in turn. Some requirements can be specified using formal languages and notations; this is particularly true in certain domains, as with embedded safety-critical software, although the limitations of formal language for expressing general requirements are widely acknowledged.
Building upon Turski’s thinking, M. Jackson and others (Jackson, 1995; Gunter et al., 2000; Hall and Rapanotti, 2003) proposed a view of software development encompassing two distinct but related ‘spaces’: the problem space, in which the problem to be addressed is located; and the solution space, in which the software solution resides. In this view, descriptions, whether formal or non-formal, are further categorised into indicative and optative: an indicative description is a statement of fact – that is, an assumption which is believed to be true and on which further reasoning can be constructed; an optative description is a statement of wish – that is, something we would like to become true at some point. To give an example, a requirement is an optative description, as it states something that it is hoped will be true once the system is designed and operational; on the other hand, an existing business rule is an indicative description, as it states how the business works currently; that is, this is something taken for granted in developing the system.
Note: one way to understand the distinction between optative and indicative is to consider optative descriptions as statements of something we wish to be true in the future, but which may not be true now, and indicative descriptions as statements of something which is true now and which we expect still to be true in the future.
In this view, specifications provide the point of contact between the two spaces: a specification captures optative requirements as to how the software system should behave at its interface with the real world. As such, the specification can be validated against the problem: we can check whether building a software system to that specification will address the problem; and the software can be verified against the specification: i.e., we can check that the software has been built in such a way that it will satisfy the specification. In this view, therefore, an effective software development process would have to deal adequately with building and separating optative and indicative descriptions across the problem/solution divide, and transform optative requirements before development into indicative statements once the software is in operation.
Consider the problem and solution spaces proposed by Jackson and others. How would you describe the way the waterfall process spans the two? What about iterative and incremental development processes?
The waterfall model assumes that we proceed in linear fashion from the problem to the solution space: first, through analysis, we understand the problem and express requirements and specification; then we proceed to design and implementation in the solution space, and test the outcome against the specification.
On the other hand, iterative and incremental processes assume that we cross the problem/solution divide many times: at each iteration we revisit the problem space to identify new requirements and define new specifications; we then proceed to the solution space for related design, implementation and testing.
The work of Turski and of Jackson and others provides useful insights into the nature of the descriptions required in software development, and processes can be, and have been, defined which establish when and where such descriptions are required. However, there are further dimensions to software development which are widely recognised as being highly influential, and which should be taken into account. One such dimension in those descriptions is fitness for purpose – and how this can be established. The other dimension is the design rationale, i.e., the explicit articulation and capture of the reasons behind and justifications for decisions made when designing an artefact, including alternatives considered and trade-offs.
Hall and Rapanotti (2009) have proposed a view of software development as spanning two orthogonal spaces: the design space, to which the descriptions of Turski and Jackson and others belong; and the assurance space, where consideration of design rationale and fitness for purpose take place and related descriptions are generated. In this view, contact between the two spaces occurs throughout the development process, both in the problem and solution spaces, at points at which assurance artefacts are shared and checked by different stakeholders – for example, as with a business analyst checking understanding of business processes with the customer, or a software architect reviewing and approving an architectural blueprint for a system. Hence, the fitness for purpose of any description, from problem statement to working code, can only be established by the stakeholders involved in the process, bringing stakeholders to the heart of software development and highlighting their identification and participation in the process as a key success factor. As a consequence, in this view, an effective software development process would have to deal adequately with building and separating descriptions not just across the problem/solution divide, but also across the design/assurance divide, and would also have to identify key representative stakeholders and account for their involvement in the development process.
Consider Hall and Rapanotti’s design and assurance spaces. To what extent does the waterfall process address the relationship between these two spaces? What about iterative and incremental development processes?
The waterfall model fits primarily within the design space, as it makes no explicit reference to assurance and its relevant stakeholders. The only activity that could be related to the assurance space is testing, which can be interpreted as developing assurance descriptions – the set of test cases – to demonstrate specific properties of the working software, often to the customer. Similar observations can be made of iterative and incremental processes, which have developed directly from the waterfall model.
Historically, software development processes have focused primarily on the design space. However, the importance of the assurance space has long been acknowledged and recognised, and a parallel discipline of project management has developed in a bid to address some of the assurance needs of software development processes highlighted by Hall and Rapanotti (2009). It should be noted that the importance of stakeholders is also explicitly recognised by Agile development, whose manifesto explicitly values individuals and interactions as well as customer collaboration.