Classifying software development work into ‘design’, ‘construction’, and ‘maintenance’ should be mostly left behind. It imports a model that doesn't fit because the basic material is different. (Software is not conceived separately in design, and then ‘realised’, and it is not then degraded by external forces.)
The material of software is abstraction. So the fundamental way of understanding its activities should be through what is done with abstractions.
There seem to be three initial candidates for basic activities: 1, creating/designing abstractions – e.g. coming up with function/class/module structures; 2, making instantiations/parameterisations of existing abstractions – i.e. adjusting by making new sub/alt-structures in pre-supported directions; 3, changing/transforming existing abstractions into different ones – i.e. neither creating from nothing, nor parameterising existing.
Essentially, they are all the same thing – in software, everything is design. All design reuses parts in unforeseen ways, and that can also be viewed as a parameterisation of a general potential form. So the different activities are really shades of the same basic technical action. They are psychologically/sociologically/practically defined.
But such a non-technical-oriented division is fine. There are two fundamental legitimate ways to distinguish, or bases of analysis for, software concepts: the technical, functional side; and the requirements, representational side – one is about the capabilities and properties of the material, and the other about what we conceive of to create. These are the essential two sides of any engineering activity. So a good basis for understanding an engineering is to form a model from the right fusion of function and representation.
What is needed next is further sophistication: first, defining what is determinate and measurable and what not – largely, fixing the bound between the two sides of representation and function, and then clarifying and deepening rational models for the determinate part.
Then we have a model of software development that means something and is useful. It fits the basic material, and can be manipulated logically as far as possible.