WATERFALL

Mô hình phát triển phần mềm tuần tự

1.1. Trước Agile: thế giới phần mềm làm việc như thế nào?

Trước khi các phương pháp Agile phổ biến, một tư duy phát triển thường gặp là:

Muốn xây dựng một hệ thống lớn thì trước tiên phải lập kế hoạch thật kỹ, sau đó thực hiện từng bước.

Tư duy này khá giống với việc xây dựng một căn nhà.

Requirement (Xác định yêu cầu) -> Design (Thiết kế) -> Construction (Xây dựng) -> Inspection (Kiểm tra) -> Handover (Bàn giao)

Không ai đang xây móng nhà mà đột nhiên yêu cầu:

“Ê, đổi thiết kế nhà đi, thêm hai tầng nữa.”

Vì việc sửa đổi giữa chừng có thể rất tốn kém.

Đối với các ngành sản xuất sản phẩm vật lý, tư duy này khá tự nhiên. Ngành phần mềm cũng từng áp dụng cách suy nghĩ tương tự.

1.2. Waterfall là gì?

Waterfall // thác nước là mô hình phát triển phần mềm theo các giai đoạn tuần tự. Các giai đoạn thường được hoàn thành lần lượt trước khi chuyển sang giai đoạn tiếp theo.

Requirements (Thu thập yêu cầu)  -> Design (Thiết kế hệ thống) -> Implementation (Lập trình) -> Testing (Kiểm thử) -> Deployment (Triển khai) -> Maintenance (Bảo trì)

Ý tưởng cơ bản:

Hoàn thành giai đoạn A → chuyển sang B → rồi C → rồi D.

Khác với cách làm liên tục nhận phản hồi và thay đổi, Waterfall chú trọng việc xác định yêu cầu, lập kế hoạch và thực hiện theo trình tự đã định.

1.3. Winston Royce và lịch sử Waterfall

Một thông tin thường được nhắc đến là:

Winston Royce là người phát minh ra Waterfall.

Tuy nhiên, câu nói này không hoàn toàn chính xác.

Năm 1970, Winston W. Royce công bố bài nghiên cứu Managing the Development of Large Software Systems // Quản lý việc phát triển các hệ thống phần mềm lớn.

Trong bài viết, ông trình bày một quy trình tuyến tính gồm:

Requirements (Yêu cầu) -> Design (Thiết kế) -> Code (Viết mã nguồn) -> Test (Kiểm thử) -> Operation (Vận hành)

Điểm thú vị là Royce không hề khẳng định quy trình tuyến tính đơn giản này là cách tốt nhất.

Ngược lại, ông cảnh báo rằng quy trình như vậy có rủi ro lớn và đề xuất bổ sung những hoạt động như:

• Feedback // phản hồi.
• Iteration // lặp lại.
• Prototyping // tạo mẫu thử.

Do đó, câu chuyện lịch sử chính xác hơn là ngành công nghiệp về sau thường gọi mô hình tuyến tính là Waterfall, trong khi bài viết thường được gắn với mô hình này đã chứa những cảnh báo về việc không nên phát triển phần mềm theo cách tuyến tính đơn giản.

1.4. Ví dụ thực tế: dự án website bán hàng

Giả sử năm 2026, mày nhận một dự án xây dựng website bán hàng.

Khách hàng ký hợp đồng và team bắt đầu triển khai theo kế hoạch:

Đến tháng 7, khách hàng xem sản phẩm và nói:

“Ủa, tao muốn bán hàng qua livestream nữa.”

Developer phản hồi:

“Ủa, requirement ban đầu đâu có chức năng này?”

Khách hàng giải thích:

“Giờ thị trường thay đổi rồi.”

Đây là tình huống thể hiện một vấn đề lớn của mô hình phát triển dựa trên kế hoạch ban đầu: yêu cầu có thể thay đổi trong khi sản phẩm đang được xây dựng.

1.5. Tại sao mô hình tuyến tính trở thành vấn đề?

Một đặc điểm quan trọng của phần mềm là khả năng chỉnh sửa và cập nhật.

Khi xây dựng nhà:

Requirements (Yêu cầu) -> Design (Thiết kế) -> Build (Xây dựng)

Việc thay đổi thiết kế khi công trình đang thi công thường tốn nhiều thời gian, công sức và chi phí.

Khi phát triển phần mềm:

Code (Viết mã nguồn) -> Code lại (Sửa đổi) -> Deploy (Triển khai) -> Update (Cập nhật)

Phần mềm có thể được sửa đổi, cập nhật và triển khai nhiều lần mà không cần xây dựng lại toàn bộ hệ thống từ đầu.

Ví dụ:

Monday

Version 1.0

Tuesday

Version 1.1

Wednesday

Version 1.2

Thursday

Version 1.3

Tuy nhiên, việc phần mềm dễ sửa hơn sản phẩm vật lý không có nghĩa mọi thay đổi đều rẻ. Những thay đổi lớn liên quan đến kiến trúc, dữ liệu, bảo mật hoặc hệ thống đang vận hành vẫn có thể rất tốn kém.

Vấn đề là khi yêu cầu thay đổi, một kế hoạch tuyến tính đã được xác định quá sớm có thể không còn phù hợp.

1.6. Software Crisis là gì?

Software Crisis // khủng hoảng phần mềm là thuật ngữ dùng để mô tả hàng loạt khó khăn trong việc phát triển các hệ thống phần mềm ngày càng lớn và phức tạp.

Đây không phải một ngày cụ thể mà toàn ngành phần mềm đồng loạt sụp đổ.

Một dấu mốc lịch sử quan trọng là NATO Software Engineering Conference năm 1968, được tổ chức tại Garmisch, Đức.

Hội nghị tập trung thảo luận các vấn đề lớn của việc phát triển phần mềm, bao gồm:

• Reliability // độ tin cậy.
• Schedule // tiến độ.
• Specifications // đặc tả và yêu cầu.
• Khó khăn khi phát triển các dự án phần mềm lớn.

Một số vấn đề tiêu biểu của Software Crisis:

• Dự án trễ tiến độ.
• Vượt ngân sách.
• Khó đảm bảo độ tin cậy.
• Khó đáp ứng đầy đủ đặc tả và yêu cầu.
• Hệ thống phức tạp, khó bảo trì.
• Khó ước lượng chính xác thời gian và chi phí.
• Chất lượng phần mềm không ổn định.

Từ những vấn đề đó, khái niệm Software Engineering // kỹ nghệ phần mềm được thúc đẩy mạnh mẽ, hướng tới một cách tiếp cận có hệ thống hơn trong quá trình phát triển phần mềm.

1.7. Vấn đề không đơn giản là developer code chậm

Đây là một điểm rất quan trọng.

Software Crisis không đơn giản có nghĩa là developer viết code quá chậm.

Vấn đề sâu xa hơn nằm ở mối quan hệ giữa quy mô hệ thống, độ phức tạp, khả năng dự đoán và những thay đổi trong quá trình phát triển.

System càng lớn (Hệ thống càng lớn) -> Complexity càng cao (Độ phức tạp càng tăng) -> Khó dự đoán -> Khó estimate (Khó ước lượng) -> Khó lập kế hoạch chính xác -> Requirement thay đổi (Yêu cầu thay đổi) -> Kế hoạch cũ mất giá trị

Nói cách khác:

Chúng ta đang cố dự đoán một thứ vốn rất khó dự đoán.

Đây là một trong những bối cảnh quan trọng để hiểu sự phát triển của những phương pháp linh hoạt hơn.

1.8. Waterfall có phải là mô hình tệ?

Không.

Waterfall không phải lúc nào cũng là lựa chọn sai. Nó vẫn có thể phù hợp với những môi trường mà:

• Yêu cầu tương đối ổn định.
• Quy định và quy trình nghiệm thu chặt chẽ.
• Cần lập kế hoạch và tài liệu hóa kỹ từ đầu.
• Việc thay đổi trong quá trình thực hiện bị hạn chế.
• Các giai đoạn và đầu ra cần được kiểm soát rõ ràng.

Điểm cần hiểu không phải Waterfall xấu còn Agile tốt, mà là mỗi cách tiếp cận có những giả định và bối cảnh phù hợp khác nhau.

Vấn đề nảy sinh khi một dự án có nhiều yếu tố không chắc chắn nhưng lại cố dự đoán và cố định toàn bộ công việc từ quá sớm.

Bài viết khác

AGILE

2.1. Agile bắt đầu xuất hiện như thế nào? Trước năm 2001, nhiều phương pháp phát triển phần mềm đã được hình thành nhằm giải quyết những khó khăn của các dự án phần mềm truyền thống. Một số phương pháp tiêu biểu: Extreme Programming (XP) // lập trình cực hạn, tập trung vào phản […]

Đọc thêm

TỔNG HỢP KIẾN THỨC GIT CƠ BẢN

TỔNG HỢP KIẾN THỨC GIT CƠ BẢN 1. Git là gì? Git là một hệ thống quản lý phiên bản phân tán (Distributed Version Control System – DVCS), được sử dụng để lưu trữ, quản lý và theo dõi những thay đổi trong mã nguồn, dữ liệu và các tệp tin của một dự án. […]

Đọc thêm

Làm việc hiệu quả : đẩy tiến độ công việc trong vùng xám và hoàn thành

Là một người chịu trách nhiệm 1 đôi nhóm xây dựng 1 tính năng, 1 công việc, hoặc là 1 thành viên của đội nhóm, bất kì ai cũng muốn mọi thứ rõ ràng. Thiết kế rõ ràng, quy trình rõ ràng, tính năng rõ ràng, mục đích đạt được rõ ràng v.v Trên thực […]

Đọc thêm