Năm 1970, Winston Royce vẽ mô hình thác nước. Ngay bên dưới sơ đồ, ông gọi đó là cách làm rủi ro.

18/10/2026 · VietTechies · Biên tập

Tháng 8 năm 1970, Winston W. Royce của công ty hàng không vũ trụ TRW trình bày một bài báo về cách quản lý những dự án phần mềm lớn. Trong bài có một sơ đồ gồm bảy ô xếp thành bậc thang đi xuống, từ yêu cầu hệ thống đến vận hành. Ngày nay, người ta gọi chiếc cầu thang ấy là mô hình thác nước (waterfall). Ngay bên dưới sơ đồ, Royce viết: “Tôi tin vào ý tưởng này, nhưng cách thực hiện vừa mô tả ở trên nhiều rủi ro và mở đường cho thất bại.”

Bài báo mang tên “Managing the Development of Large Software Systems” được đăng trong kỷ yếu WESCON (Western Electronic Show and Convention), một triển lãm kiêm hội nghị ngành điện tử. Trong bài không hề có chữ “waterfall”, và Royce dành phần lớn số trang để bàn cách sửa chính trình tự mà ông vừa vẽ ra. Dù vậy, như Craig Larman và Victor Basili viết năm 2003 trong một bài lược sử về phát triển lặp (iterative development), “nhiều người lầm tưởng bài báo của Royce là hình mẫu tiêu biểu cho mô hình thác nước chỉ đi một lượt”.

Phần mềm tàu vũ trụ và chiếc cầu thang bảy bậc

Royce viết dựa trên kinh nghiệm thực tế. Ông nói bài báo trình bày quan điểm cá nhân của mình, đúc kết từ chín năm công tác, chủ yếu là làm phần mềm cho tàu vũ trụ: lập kế hoạch sứ mệnh, gửi lệnh điều khiển và phân tích sau chuyến bay. Hình 2 trong bài liệt kê các bước theo thứ tự: yêu cầu hệ thống, yêu cầu phần mềm, phân tích, thiết kế chương trình, viết code, kiểm thử và vận hành. Từ mỗi ô có một mũi tên chỉ xuống ô kế tiếp.

Điều Royce phản đối là thời điểm các bất ngờ ập tới trong quy trình. Kiểm thử nằm ở cuối, và Royce gọi bước này là “khâu đầu tiên mà thời gian xử lý, bộ nhớ, việc truyền dữ liệu vào/ra, v.v. được kiểm nghiệm trên thực tế, thay vì qua phân tích”. Nếu đến lúc ấy thời gian xử lý hay bộ nhớ vượt quá giới hạn của hệ thống, thì sẽ cần một đợt thiết kế lại lớn, và có khi chính các yêu cầu cũng phải thay đổi. “Về thực chất, quá trình phát triển đã quay về điểm xuất phát”, ông viết, “và có thể lường trước chuyện trễ tiến độ và/hoặc đội chi phí tới 100%.”

Hình 3 và 4: những mũi tên chỉ ngược lên cầu thang

Hai sơ đồ tiếp theo của Royce thêm những mũi tên chỉ ngược lên các bậc. Hình 3 có lời chú thích đầy hy vọng: “Hy vọng rằng sự tương tác lặp đi lặp lại giữa các giai đoạn chỉ gói gọn trong những bước liền kề.” Hình 4 thì không còn hy vọng ấy nữa. Ở hình này, các mũi tên chạy từ kiểm thử ngược lên tận thiết kế chương trình, và từ thiết kế chương trình ngược về yêu cầu phần mềm, kèm lời chú thích: “Đáng tiếc là với quy trình minh họa ở đây, các vòng lặp thiết kế không bao giờ gói gọn trong những bước liền kề.”

Royce vẫn cho rằng cách tiếp cận cơ bản này “về bản chất là đúng đắn”. Theo lập luận của ông, cách làm ấy cần bổ sung năm yếu tố “để loại bỏ phần lớn rủi ro trong quá trình phát triển”. Ông thừa nhận yếu tố nào cũng tốn thêm tiền, nhưng theo kinh nghiệm của ông, “phương pháp đơn giản hơn chưa bao giờ hiệu quả với những dự án phát triển phần mềm lớn”.

Năm biện pháp của Royce: thiết kế trước, viết tài liệu, làm hai lần

Biện pháp thứ nhất là làm một bản thiết kế chương trình sơ bộ trước bước phân tích, để phần mềm không thất bại “vì những lý do về bộ nhớ, thời gian xử lý và lưu lượng dữ liệu”. Biện pháp thứ hai là viết tài liệu, và theo Royce thì cần viết “khá nhiều”. “Quy tắc đầu tiên trong quản lý phát triển phần mềm là thực thi không khoan nhượng các yêu cầu về tài liệu”, ông viết. Theo ước tính của ông, một thiết bị phần cứng trị giá 5 triệu USD cần bản đặc tả dài 30 trang, còn phần mềm trị giá 5 triệu USD cần khoảng 1.500 trang. Ông cho rằng nhờ có tài liệu ghi chép, người thiết kế không thể tháng này qua tháng khác núp sau hội chứng “Tôi đã xong 90%”.

Biện pháp thứ ba là “làm hai lần”. Với một chương trình được xây dựng lần đầu, Royce muốn phiên bản giao cho khách hàng “thực ra là phiên bản thứ hai, xét ở những phần thiết kế/vận hành then chốt”. Ông gợi ý rằng một dự án 30 tháng có thể dựng trước một mô hình thử nghiệm (pilot) trong 10 tháng. Hai biện pháp cuối là: lên kế hoạch, kiểm soát và theo dõi việc kiểm thử; cho khách hàng tham gia chính thức ở một số thời điểm trước khi bàn giao, bởi theo ông, “thả nổi cho nhà thầu từ lúc xác định yêu cầu đến lúc vận hành là tự rước lấy rắc rối”.

Sơ đồ có tên gọi từ đâu, và các tiêu chuẩn phần mềm của Lầu Năm Góc

Đến năm 1976, cái tên “waterfall” đã lên mặt giấy, trong một bài báo có lẽ là nơi đầu tiên dùng cách gọi này: bài của T. E. Bell và T. A. Thayer, cũng làm việc ở TRW, trình bày tại Hội nghị Quốc tế về Kỹ thuật Phần mềm lần thứ hai. Hai tác giả viết rằng các tiêu chuẩn quân sự MIL-STD-490 và MIL-STD-483 quy định một chuỗi tài liệu yêu cầu đi từ trên xuống. Theo họ, bài báo của Royce đã giải thích chính cách tiếp cận từ trên xuống ấy “mà không dùng thứ biệt ngữ chuyên ngành quân sự”, và Royce “đã giới thiệu khái niệm ‘thác nước’ của các hoạt động phát triển”.

Bộ Quốc phòng Mỹ đặt ra trình tự của riêng mình trong DOD-STD-2167, tiêu chuẩn phát triển phần mềm cho các hệ thống quốc phòng, ban hành ngày 4 tháng 6 năm 1985. Tiêu chuẩn này đòi hỏi một chu trình phát triển gồm sáu giai đoạn, từ phân tích yêu cầu phần mềm đến kiểm thử, kèm các đợt rà soát chính thức và tài liệu trong suốt quá trình. Thật ra, văn bản tiêu chuẩn có cho phép một số vòng lặp diễn ra song song, và ghi rằng quy trình này “có thể gọi là cách tiếp cận ‘mua sắm tiến hóa’ hoặc ‘xây dựng tăng dần’”.

Dẫu vậy, theo Larman và Basili, người soạn thảo chính của DOD-STD-2167 về sau bày tỏ hối tiếc vì đã tạo ra “tiêu chuẩn nghiêm ngặt dựa trên mô hình thác nước”. Ông cho biết khi ấy mình chưa nghe đến phát triển lặp, và nhìn lại thì lẽ ra mình sẽ hết sức khuyến nghị cách làm này.

Tháng 2 năm 1988, bản sửa đổi DOD-STD-2167A nêu rằng tiêu chuẩn này “không nhằm quy định hay can ngăn việc sử dụng bất kỳ phương pháp phát triển phần mềm cụ thể nào”. Larman và Basili ghi nhận rằng nhiều người đọc vẫn thấy 2167A ngầm nghiêng về mô hình thác nước qua các cột mốc dựa trên tài liệu. Cùng năm đó, Barry Boehm, cũng làm ở TRW, viết rằng “mô hình thác nước đã trở thành nền tảng cho hầu hết các tiêu chuẩn mua sắm phần mềm của chính phủ và ngành công nghiệp”. Tháng 12 năm 1994, một tiêu chuẩn quân sự mới là MIL-STD-498 thay thế 2167A. Larman và Basili dẫn một bản tóm tắt những thay đổi, trong đó có một mục mang tên “Removing the Waterfall Bias” (tạm dịch: Gỡ bỏ sự thiên lệch về mô hình thác nước).

Royce ủng hộ hay phản đối mô hình thác nước?

Con trai của Royce là Walker Royce, người vào giữa thập niên 1990 đã góp phần tạo ra Rational Unified Process, một phương pháp phát triển lặp. Walker kể với Larman và Basili rằng cha mình “luôn ủng hộ lối phát triển lặp, tăng dần và tiến hóa”. Theo lời Walker, bài báo “trình bày thác nước như cách mô tả đơn giản nhất, nhưng cho rằng mô hình ấy sẽ không hiệu quả, trừ ở những dự án đơn giản nhất”.

Bản thân bài báo đưa ra một câu trả lời hẹp hơn: Royce ủng hộ trình tự mà ông cho rằng “về bản chất là đúng đắn”, nhưng phản đối việc chỉ đi qua các bước đúng một lượt. Các biện pháp của ông vẫn đặt thiết kế trước khâu viết code, đòi hỏi khối lượng tài liệu lớn và dựa vào một phiên bản thử nghiệm duy nhất thay vì nhiều chu kỳ lặp lại. Larman và Basili thấy trong bài báo có “dấu hiệu manh nha của phát triển lặp, phản hồi và thích ứng”, nhưng cho rằng bước “làm hai lần” trong bài “rõ ràng không phải IID kinh điển”. Hai ông gọi IID (phát triển lặp và tăng dần) là một trong những nền móng của các phương pháp Agile. Còn Barry Boehm mô tả bước “làm hai lần” ấy là một hình thức sơ khai của việc đưa kỹ thuật làm bản mẫu (prototyping) vào vòng đời phần mềm.

Vì sao sơ đồ đơn giản sống lâu hơn lời cảnh báo đi kèm

Larman và Basili đưa ra một số lý do khiến trình tự đơn giản ấy lan rộng. Trình tự này dễ giải thích và dễ nhớ: xác định yêu cầu, rồi thiết kế, rồi xây dựng. Cách làm ấy còn “tạo ra ảo giác về một quy trình ngăn nắp, rõ trách nhiệm và đo lường được, với những cột mốc đơn giản dựa trên tài liệu”. Và ngay cả “mô hình thác nước nguyên bản gồm hai vòng lặp” của Royce cũng “lập tức thoái hóa thành một bước tuần tự duy nhất khi được những người khác áp dụng và được các tác giả mô tả lại”.

Sơ đồ quy trình nào cũng là một lời khẳng định về chỗ vấn đề sẽ lộ ra. Các hình vẽ của Royce đưa ra hai lời khẳng định khác nhau: chiếc cầu thang mà những người áp dụng và các tác giả về sau giữ lại, và Hình 4, nơi một mũi tên chạy từ kiểm thử ngược lên tận thiết kế chương trình.

Bài liên quan

Đọc bằng ngôn ngữ khác: English