Những phương pháp phát triển phần mềm nào có thể được coi là nền tảng

Tôi đang viết một bài nghiên cứu nhỏ liên quan đến phương pháp phát triển phần mềm. Tôi đã xem xét tất cả các phương pháp có sẵn và tôi đã tự hỏi, từ tất cả các phương pháp, có bất kỳ phương pháp nào đã cung cấp nền tảng cho các phương pháp khác không?

Ví dụ, xem xét các phương pháp sau:
Agile, Prototyping, Cleanroom, Iterative, RAD, RUP, xoắn ốc, Waterfall, XP, Lean, Scrum, V-Model, TDD.

Chúng ta có thể nói rằng:
Tạo mẫu, Lặp lại, Xoắn ốc và Thác nước là "nền tảng" cho những người khác không?

Hoặc không có thứ gọi là "nền tảng" và mỗi phương pháp có lịch sử duy nhất của riêng nó không?

Tôi muốn mô tả tất cả các phương pháp trong tài liệu nghiên cứu của mình, nhưng tôi đơn giản là không có thời gian để làm như vậy và đó là lý do tại sao tôi muốn biết phương pháp nào có thể được xem là đại diện.

Các tên trong danh sách của bạn không phải là tất cả các phương pháp và chúng có tỷ lệ theo các cấp độ khác nhau:

• Lặp đi lặp lại là một đặc điểm, một đặc điểm được chia sẻ bởi một số phương pháp và kỹ thuật. Scrum là một phương pháp lặp, TDD là một kỹ thuật lặp.
• Tôi thấy Agile là một siêu phương pháp luận vẫn còn ở mức độ khái niệm / triết học. Trong lập trình hướng đối tượng, bạn có thể mô tả nó là trừu tượng - đó là một tập hợp các giá trị và nguyên tắc không thể khởi tạo và phải được bắt nguồn và thực hiện. Đó là những gì Scrum và XP làm.
• Phòng sạch, RAD, RUP, Xoắn ốc, Thác nước, XP, Lean, Scrum, V-Model là những phương pháp phù hợp, tức là các quy trình phát triển phần mềm (mặc dù Scrum tuyên bố là một "khung" nhẹ so với quy trình nặng)
• Tạo mẫu và TDD là các kỹ thuật, hoạt động. TDD là một thực hành XP.

Phân biệt đó là nền tảng của một công việc khó khăn. Bạn có thể vẽ một dòng lịch sử rõ ràng, nhưng một phương pháp hiếm khi trực tiếp dựa trên một dòng khác. Họ thay vì chồng chéo, vay mượn lẫn nhau, đôi khi trả lời lẫn nhau ... Tôi có thể thấy không có phân loại được xác định rõ ràng, mặc dù bạn có thể phác thảo một vài gia đình lớn.

Một cách khác để xem xét nó là từ một quan điểm thế hệ. Về phần mềm doanh nghiệp tôi sẽ nói chúng ta đã biết 2 thế hệ phương pháp luận. Những cái đầu tiên, trong đó Waterfall và V-Model, hầu hết là các quy trình có sẵn từ các ngành kỹ thuật khác được áp dụng cho phần mềm. Thế hệ thứ hai (bạn có thể gọi nó là Agile nhưng nó đã bắt đầu từ lâu trước khi thuật ngữ Agile được tạo ra) được khởi xướng để phản ứng với sự nặng nề của các quy trình thế hệ thứ nhất, khi mọi người bắt đầu nhận ra rằng phần mềm là một động vật hoàn toàn khác và tiêu chí đó rất tốt phần mềm và các bước có thể đảm bảo các tiêu chí này thực sự cụ thể và vẫn phải được khám phá.

Cuối cùng, bạn cần lưu ý rằng, trong phần mềm thậm chí có thể nhiều hơn so với các ngành khác, phương pháp không phải là công thức mà bạn chỉ có thể áp dụng để làm cho mọi thứ hoạt động. Phát triển phần mềm có nhiều khía cạnh con người như các khía cạnh kỹ thuật và một nhóm hoặc người quản lý đưa ra phương pháp viên đạn bạc và một danh sách kiểm tra những thứ cần áp dụng một cách mù quáng có thể gây ra một số bất ngờ. Chỉ cần nhìn vào các nghiên cứu về tỷ lệ thành công của dự án phần mềm như Báo cáo Chaos hàng năm, bạn có thể biết lịch sử của các phương pháp phần mềm có liên quan nhiều hơn đến một loạt các nỗ lực thất bại so với quy tắc lặp lại, được thiết lập một cách khoa học, vững chắc.

Có ba:

1. không có (hay còn gọi là cao bồi)
2. thác nước
3. phát triển ứng dụng nhanh chóng (RAD hoặc xoắn ốc)

phần còn lại là các biến thể và sự kết hợp của những

lưu ý rằng các tạo phẩm từ thác nước (khởi động, yêu cầu, thông số chức năng, thông số thiết kế, thông số kiểm tra, thông số kiểm soát chất lượng, v.v.) đều bao gồm những thứ quan trọng đối với dự án, hầu hết nếu không phải tất cả đều được bao phủ bởi các phương pháp khác nhưng trong những cách rất khác nhau. Ví dụ, trong TDD, các tính năng, câu chuyện của người dùng và mô tả thử nghiệm bao gồm các yêu cầu, thông số chức năng và thông số thử nghiệm từ thác nước. Trong RUP, thậm chí nhiều tạo tác được thêm vào, phá vỡ một phần của thông số thác nước (ví dụ, tài liệu của các bên liên quan là một phần của tài liệu Khởi động) nhưng tiến hành theo hình xoắn ốc

vui lòng xuất bản một liên kết đến kết quả của bạn khi hoàn thành, nó có vẻ như một bài báo thú vị!

Có lẽ bạn muốn chỉ đề cập đến các phương pháp cổ (không phải 'phương pháp luận) như:

1. xử lý hàng loạt: gửi một cỗ bài và lấy lại đầu ra vào ngày hôm sau. Hạn chế: quá nhiều thời gian giữa các lần gửi; để gỡ lỗi, nghiên cứu một bãi chứa lõi.

2. phương pháp cli - sử dụng vi hoặc emacs, sau đó biên dịch; tất cả từ dòng lệnh giống như được thực hiện trong một vỏ linux cho đến ngày nay. Nhược điểm: khó gỡ lỗi (gdb? Bạn có phải là tôi không?), Các lệnh shell 40 tuổi tối nghĩa.

Chỉ là một ý nghĩ.

Bạn có thể đề cập đến ba cách tiếp cận cơ bản: Tạo mẫu, Xoắn ốc và Thác nước. Tôi sẽ không coi Lean, TDD hay Cleanroom là một phương pháp, mà là quá trình có thể là một phần của phương pháp luận.