Software engineering is about understanding and assembling data processes and objects, but can this be analysed further? Highest, there are two main parts:
First, there is knowledge of particular subject models. These are logical structures embodied by their subject area, eg: meteorology, or project management. They are of varying kinds and sophistication, from well-defined mathematical, to vaguely-defined social. But they are all graspable by software because of their logical aspect. This first part is where architecture and engineering join: choosing and tailoring it is a matter of architecture, building it (using the following second part) is engineering. The former is vague and usage lead, the latter is determinate.
Second, there is knowledge of software per se. This is in two sub-parts: First, computation mechanics: modelling performance of systems, by understanding basic data movement/transform/storage behaviour. (Mechanics is a reasonable name: analogously from civil engineering, linguistically from Greek for machine.) This is really the core of software engineering: it is all determinate, purely ‘software’, and only about functionality. Second, rework structure: organising code to be more understandable and changeable. The term ‘design’ is casually taken to mean only this, which seems wrong. It is of value but inessential, because it is only to assist the engineering process, rather than the product. Both sub-parts are somewhat immature. Maybe advance will be from Stochastic Process Algebras and Category Theory respectively.
References: