Here is a way of dividing up and placing the parts of software development. Reality is not as clear-cut, but a map is supposed to simplify and clarify. It is a way of organising thought. When trying to understand something about software it is useful to know where it is on the map.
The intention, and principle, is to see software in terms of other fields: so understanding can be supported by recognised, proven knowledge.
There are three main sub-disciplines:
This is about what the software is and does: the external, usable features. The input is some pattern of intellectual activity: of learning, creating, or communicating. This is tailored to fit the user group and to be realised by digital means. It transforms requirements into a structure of usage.
It is mostly made of two established external fields, adapted for software [1]:
This is about how the software does what it does: the internal, technical implementation. The input is from Software Product Design: effectively, digested requirements. These are implemented by processing data: efficiently, accurately, reliably, securely. It transforms usage into a system of data processing.
It is made of two established common knowledge and work patterns, specialised for software. It does something creative, with something scientific (in an organised way):
This is the determinate, scientific, knowledege: theory of computation, algorithmic complexity, and related things. It is objective, quantifiable, logically manipulable and provable – the basis of understanding the ‘material’ of software. This is the crucial feature in software as engineering.
This is the creative activity. Its purpose is to join the requirements to the capacities of the material; its basis is to embody abstract rational structures; its procedure is recursive and iterative; it is assembling by understanding and experiment. Though it is supported by science and organisation, design at its core is a human skill. [2]
This design work has two products, focused on two separate goals (‘getting things right, and getting things done’):
This is the chief role, doing two main things: leading the development of what is done, and overseeing and co-ordinating the various sub-tasks and interests in a project.
It reflects the established discipline of building architecture. The definitive job is forming what to build – doing a higher-level kind of product design. Architecture works to see and define useful new arrangements and expressions of ‘logical structure’ in human behaviour – to crystallise something of an activity into a unified software artefact. [3]
There is also an aspect that, as part of management, works across all the above:
This is the organisation. Essentially, it is about knowing where you are: that is, knowing what you have done, and what you still have to do. When there are multiple people working on multiple tasks, with various criteria and dependencies, what was basically a to-do list becomes a complex means of organisation – a process.
References: