Existing book Software Engineering Methodologies:
1. Waterfall Model
2. Prototyping Model
3. Automatic Programming
4. Reusable Model
5. Incremental Model
6. Spiral Model
7. Fountain Model
Existing most commercial Software Engineering Methodologies:
1. Agile Software Development Methodology
2. DevOps Methodology
3. Scrum Development Methodology
4. Waterfall Model
5. Prototype Methodology
6. Feature-Driven Development
7. Rapid Application Development (RAD)
8. Spiral Model
9. Dynamic Systems Development Model Methodology
10. Extreme Programming Methodology
11. Joint Application Development Methodology
12. Lean Development Methodology
We will address several questions about the above books and commercial methodologies later and provide a Unified and Stable Methodology to replace all these existing methodologies.
Existing Software Engineering Methodologies. Good, Bad, and ugliness, and please do not be fooled by several propagandas about https://en.wikipedia.org/wiki/Software_engineering and https://en.wikipedia.org/wiki/List_of_software_development_philosophies (Contain flawed information about software engineering) which include many named existing paradigms and models, such as UAP, XP, RAD, RUP, DSDM, MBSE, and other methodologies and Frameworks, Supporting Disciplines, Practices, Tools, Body of knowledge, and Glossaries. We will address all this propaganda and more in evidence and empirical studies.
Check the. Software engineering References – We will look at some references (bizarre). We will also provide critical looks at course notes and exciting books.
https://www.win.tue.nl/~wstomv/edu/2ip30/references/#general
All the SWE Methodologies have the following phases Explicitly and Implicitly, with the amount of work allocated per each phase according to the
Software Engineering simplified Guidelines:
Requirements (Functional and Non-Functional) 35%
Design 25%
Coding or Programming & Code Testing 10%
Testing 30%
In Practice:
Requirements (Functional and Non-Functional) 0
Design 5%
Coding or Programming & Code Testing 95%
Testing 0
See Attachments
Major Problems:
[1] Sequential
[2] Testing in the wrong place in the lifecycle
{3] Requirements and Design (60% of the lifecycle) 60% of the lifecycle.
In reality, there needs to be a trace of the requirements and design.
[4] The professors, lecturers, teachers, gurus, Deans, and Chairs need to learn about Requirements, Design, and Testing, and they are poor coders.
[5] All SWE Books, leading authors, and SWE Gurus need to learn about Requirements (Functional and Non-Functional): a) Do not know how to do it and b) it needs to be addressed.
[6] Design / Architecture ---
a) The majority of the professors, lecturers, teachers, Guru, and authors are poor modelers
b) Most professors, lecturers, teachers, gurus, and authors have yet to learn what they are doing.
Software Lifecycle with no Testing Stage
A proposal for a software methodology includes Testing with 1) Functional & non-functional Requirements, 2) Design & Architecture, and 3) Coding instead of having the Testing at the end of the lifecycle.
The leading authors in Software Engineering and software testing indicated that Testing starts from or makes it part of the requirements (functional and non-functional), design, and coding.
Tkachenko indicated five primary and four secondary attributes of requirements for software testing:
+ Five primary attributes of requirements testing are Completeness, Clearness, Correctness, Consistency, and Testability.
+ Four secondary attributes of requirements testing are Necessity, Priority, Traceability, and Conciseness.
Evgeny Tkachenko, “5 key attributes of requirements testing: Know before you code.” TechBeacon, 2022
Major Problems
[1] There are no functional and non-functional not exist. How do we test if something is not existing?
[2] Indicating the attributes of requirements Testing without telling what to test and how to test each one of the attributes within the requirements, how to assess or measure such attributes, and others.
The reality did not change, and still, the design was 5% and coding 95%
See attachments.
Conclusions:
Each of the existing books and commercial software engineering methodologies has Good and Bad, but unfortunately, the Ugly (disastrous evil) of all the existing software engineering methodologies exceeds its Bad.
Can you separate your questions that remain unanswered from your questions that you've answered yourself?
Of the questions you have left unanswered, can you simplify your questions?
Robert Schaefer -- Thank you for your question.
First of all: My understanding is to separate my questions to:
1) Unanswered Questions
2) Answered Questions by myself
Point (1): I don't know how to separate them.
Point (2): I didn't provide any answers to all my questions
Moment (3): The same questions got thousands in reading and discussion on LinkedIn, and I have no idea what is going on ResearchGate
Issue (4): I posted the questions to get the conversation going and provide answers.
I posted the dark side clearly, and I would have hoped to hear from the respected researchers on ResearchGate the following:
1) Do you agree with the listed dark sides or not?
2) Justify your answer.
3) What do you think we should or should not do?
I can address the dark side issues and provide better methodologies in this case.
Software engineering methodology is a tool of humans.There is a dark side to any human endeavor, if by dark side, you mean going against ethical or moral rules. (Leaving open the questions: what rules, whose rules, etc.) Per history and human experience, the problem is complex (an epic understatement), and there is no one solution that works for everyone, everywhere, under all conditions. Rules are static and human behavior is dynamic, sees (or ignores) the rules and then changes (or doubles-down) in reaction. Given that, asking questions is a good place to start. Are you looking for more ethical methods or more ethical outcomes? One does not necessarily produce the other.
- Badges
- Science topic
- Similar topics
- Methodology
- Research Methodology
- Research Papers