In Yingxu Wang. "Software Engineering Foundations A Software Science Perspective" Auerbach Publications, 8 August 2007 (1444 pages)." Wang said that "Software engineering is an ideal testbed for existing theories and methodologies in disciplines mentioned above in the book, from mathematics to cognitive informatics, and from Science to sociology for two reasons:

(1) Software engineering is the latest and the most complicated engineering branch that humankind has ever experienced, and

(2) Software engineering s a transdisciplinary field with both its theoretical foundation and empirical applications inherently. An excellent book treated software engineering as a science.

In the gang of four (GoF) Book Erich Gamma, Richard Helm, Ralph Johnson, et al. "Design Patterns: Elements of Reusable Object-Oriented Software," Addison-Wesley Professional, October 1994, and another huge number of traditional analysis and design patterns books are programming languages where they claim that Patterns are micro-architecture. Question: Where are the macro and mini architectures?

All the citations of Knuth (1974), Parnas (1998), Dijkstra (1998) & (2004) summarize the following problematic issues:

[1] Knuth indicated that software engineering (SE) is programming, and programming is an art.

[2] Parnas said that Software is a form of engineering.

[3] Dijkstra predicted the death of software engineering (SE) and named it

a. Radical Novelty

b. Miserable Science

c. Doomed Discipline

Dijkstra does not believe that SE is not Art, Science, or Engineering.

[4] Wang emphasizes that SE is a science.

[5] GoF and other traditional patterns are programming and have nothing to do with art, Science, and engineering.

During the discussion of these problematic issues with many academics and professionals and no good answers

What are the few causes of these problematic issues (will be addressed and criticized in different publications with examples):

(I) Most people working in computing (academics and partitioners) are software engineers, such as programmers, researchers, managers, and top Faculty, and this is the case with any engineering work.

(II) The existing programs at universities, training companies, Gurus, and top authors need to learn about proper software engineering. They inherited this from their previous education and training.

(III) In reality, most people treat software engineering as programming in the Colleges of Engineering, Science, and Business, and they are different.

(IV) The demand for SE positions is very high and will continue to be high. However, many organizations' hiring committees at universities and human recourses need to learn the proper qualifications for such positions. Unfortunately, discrimination influenced the hiring committees and Human Resources during the entire career experience. For example, the hiring process on hiring committees, once they kicked, prevented a seat in hiring and promotion committees.

(V) The existing software engineering books are all the same, and we cannot classify them as proper forms of Art, Science, and Engineering. Unfortunately, many software engineering instructors consider them all the same and do not offer anything related to software engineering. Therefore, they are flawed and have reductase art, Science, and engineering knowledge.

VI. All the existing research is done, and going on is a waste of money, time, and energy – Billions of $s. we need to have new directions and research agenda for accurate Software Engineering.

VII. The programmers think they are software engineers, which indicates that software engineering is programmers by the majority. According to proper software engineering, it is less than 5% of the software development lifecycle if done correctly. These answer the questions related to the cancelations of many systems, maintenance nightmare, disappearance, and short life spans of many existing software companies, failure of 98% of startups, and legacy systems (Billions of $s)

VIII. As practitioners and academics, we have been in software engineering for more than 45 years. Unfortunately, software researchers, academics, and professionals need deep knowledge of proper software engineering.

IX. The SE deals with two spaces: (1) the Problem Space and (2) the Solution Space.

(1) The problem space has three properties: (I) one problem, (II) represents the "WHAT," (III) Analysis of the functional and non-functional requirements.

(2) Solution Space has three properties: (I) Many Solutions, (II) Design, Architecture, and Coding, and (III) Represents the "HOW-TO."

The problem space only exists in some places. It is disastrous and misses the problem space in SE and leads to building software development as instance developments, leading to vast numbers of software applications per instance.

The solution space provides many solutions. However, unfortunately, this is also disastrous and misses the ultimate solution.

X. Specialized SE professors are needed at many software engineering programs in computer science, Computer Engineering, mathematics, information systems, and other colleges that need more—for example, Taken San Jose State University and all CSUs. Software Engineering Programs are extensive, with a minimal number of Faculty vs. the number of Students.

At SJSU, the Computer Engineering Department serves more than 2300 undergraduate and graduate students. It offers BS and MS degrees in computer and software engineering, and its Software Engineering Program serves more than 2000 graduate and undergraduate students. The funny thing, all the Faculty in SE are considered Software Engineering Faculty, and part-time lecturers (Who are not qualified) teach software engineering and management courses. In contrast, we believe all the systems exit in the Software section of the department to be Software Engineering courses.

XI. Existing software engineering methodologies/methods/techniques/processes have a lot of problematic issues and pitfalls that are not appropriate for SE, such as existing domain analysis, abstraction techniques, modeling, standards, functional and non-functional, design, architecture, testing, and many others

XII. We are developing instance-oriented software systems and applications based on what We call industrial objects (IOs) with the following properties: (1) Tangible, (2) Changeable, (3) Application Objects, [4] Known to most people, such as a specific book, or car, or computer, and others

The big question: Do we have ways to fix the above problematic issues and pitfalls?

YES.

Check the next Article – Old Question – Part Two.