# Towards a Digital Transformation Hyper-Framework:
## 3 Materials and Methods
### The Foundation of Hypothesis 1 (H1)--Integrated Tailorable Life Cycle Models
#### 3.1.2 The Role of Software Engineering (SwEng)  
The multidisciplinary nature of Software Engineering (SwEng) emerges from the Software Engineering Body of Knowledge (SWEBOK) [50] Key Knowledge Areas (KAs) (Software Requirements, Software Design, Software Construction, Software Testing, Software Maintenance, Software Configuration Management, Software Engineering Management, Software Engineering Process, Software Engineering Models and Methods, Software Quality), the Related KAs (Software Engineering Professional Practices, Software Engineering Economics, Computing Fundamentals, Mathematical Fundamentals, and Engineering Fundamentals), and the variety of associated Software Engineering Standards defined by the mainstream standardization organizations (the Institute of Electrical and Electronic Engineers (IEEE), and the International Organization for Standardization (ISO)) [51]. The recent modification of SWEBOK V.3.0 preliminary announced as the SWEBOK V.4.0 document is, unfortunately, not publicly available at this research preparation time. A clear distinction between Software Engineering and software development aids the overall understanding of Model-Driven-Software-Development (MDSD), Model-Driven-Software-Engineering (MDSE), and the associated LCMs that address software process management (Figure 5). Software engineering is generally closer to Systems Engineering, assuming that software artifact represents a system. It perceives software as a final product of interleaved engineering activities with a broader scope than just particular software artifacts development. Consequently, software development closely relates to program development, often called programming methodologies. According to our experience, the only invariant through the entire history of software development (SD) (aka programming) is the eternal balancing between Algorithm and data complexity, presented as the opposite ends of an exotic scale's arm (Figure 5a), meaning that to decrease the unmanageable data complexity, reached in a particular programming stage, the only possible solution is to increase the Algorithmic complexity and vice versa. Accordingly, the only invariant throughout the entire history of Software engineering (SE) is the eternal balancing between the Abstraction level and the degree of Reusability, meaning that for the sake of higher Reusability, the abstraction level has to decrease and vice versa. Considering that SE encapsulates SD, the overall complexity emerges from the nonlinear synergy of all four dimensions (Algorithm, Data, Abstraction, and Reusability). On the other hand, the (Effort, Time) and (Quality, Scope) (Figure 5b) represent the essential invariant dimensions of Software process management. The Effort/Time scale arm interrelates two unavoidable project management assets, Budget (Effort) and Deadline (Time), while the (Quality, Scope) scale arm reflects the individual quality and number of delivered services in a particular project stage. Different assessment contexts may result from the universal obstacles during software project management. Assuming, for example, that the quality is not negotiable (aka mutually agreed), with a fixed deadline and budget, when the project runs into problems, the only possible solution to preserve the fixed ends is to negotiate on decreasing the scope. Research Software Engineering (RSE) has been announced as an emerging profession that highly depends on the stability of novel computing technologies and their adoption by the other dependent professions [52]. The proliferation of quantum Software Engineering (QSE), quantum software life cycle development, and quantum software reuse methodology add challenging concepts to the future Software Engineering profession. Software architecture and patterns for quantum computing systems [53], Software Engineering issues [54], and quantum communications [55] represent typical examples of challenging domains that will affect Software Engineering's role in framing future DgTs.