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.

Tiến Vũ Minh

Xem tất cả bài viết của tác giả

Bài viết khác

Test Automation(Kiểm thử tự động)

1.Test Automation (Kiểm thử tự động) là gì? Trong các dự án phát triển phần mềm truyền thống trước đây, toàn bộ quy trình kiểm thử (Testing) đều được thực hiện thủ công (Manual Testing) bởi con người. Các kiểm thử viên trực tiếp thao tác trên giao diện, nhập dữ liệu, kiểm tra kết […]

Đọc thêm

Logging – Monitoring – CI/CD

Logging, Monitoring và CI/CD là gì? Vai trò trong phát triển Backend 1. Tổng quan Khi xây dựng một ứng dụng Backend, viết code và chạy được chương trình mới chỉ là bước đầu. Khi ứng dụng được đưa vào sử dụng, lập trình viên còn cần biết ứng dụng đang hoạt động như thế […]

Đọc thêm

Redis & Caching là gì?

Redis & Caching là gì? Hướng dẫn sử dụng Redis trong Go 1. Caching là gì? Vì sao cần cache khi đã có database? Caching (bộ nhớ đệm) là kỹ thuật lưu tạm dữ liệu thường được truy cập để có thể lấy lại nhanh chóng khi cần, thay vì phải thực hiện lại toàn […]

Đọc thêm

Background Jobs & Queues

1. Background Jobs & Queues là gì? Trong một ứng dụng backend, không phải công việc nào cũng cần hoàn thành ngay trong lúc xử lý HTTP request. Ví dụ, khi người dùng đăng ký tài khoản, hệ thống có thể cần: Lưu thông tin người dùng vào database. Gửi email xác nhận. Gửi thông […]

Đọc thêm

Saga Pattern

Saga Pattern là gì? Quản lý Transaction trong kiến trúc Microservices 1. Saga Pattern là gì? Saga Pattern là một mẫu thiết kế được sử dụng để quản lý các nghiệp vụ phân tán gồm nhiều bước xử lý, trong đó mỗi bước có thể thực hiện một local transaction tại một service hoặc Database […]

Đọc thêm

Two-Phase Locking (2PL)

Two-Phase Locking (2PL) là gì? Cơ chế khóa hai pha trong Database 1. Two-Phase Locking (2PL) là gì? Two-Phase Locking (2PL — khóa hai pha) là một giao thức quản lý khóa trong Database, quy định cách một transaction được phép lấy và giải phóng lock trong quá trình thực thi. Khi nhiều transaction cùng […]

Đọc thêm