Mô hình thác nước

Mô hình thác nước.
Mô hình thác nước (waterfall model) là một mô hình của quy trình phát triển phần mềm, trong đó quy trình phát triển trông giống như một dòng chảy, với các pha được thực hiện theo trật tự nghiêm ngặt và không có sự quay lui hay nhảy vượt pha là: phân tích yêu cầu, thiết kế, triển khai thực hiện, kiểm thử, liên kết và bảo trì. Người ta thường dẫn bài báo được Winston W. Royce xuất bản vào năm 1970 để giải thích nguồn gốc cho tên gọi "thác nước"; nhưng có điều thú vị là chính Royce đã dùng mô hình phát triển lặp chứ không hề dùng thuật ngữ "mô hình thác nước".

**Nội dung mô hình thác nước**
Vào năm 1970 trong bài báo của mình, Royce đã mô tả ở dạng khái niệm cái mà ngày nay được công nhận với tên gọi "mô hình thác nước", đã bàn luận về những nhược điểm của mô hình này. Trong đó ông cũng chỉ ra rằng mô hình này có thể sẽ được tu sửa thành mô hình lặp.
Mô hình Royce nguyên gốc có các pha theo đúng thứ tự sau:
# Xác định yêu cầu
# Thiết kế
# Xây dựng (hay "triển khai", "mã hóa", "viết mã")
# Liên kết
# Kiểm thử và Chỉnh sửa (hay «kiểm nghiệm»)
# Cài đặt
# Bảo trì
Theo mô hình thác nước, người phát triển phải thực hiện từng giai đoạn theo thứ tự nghiêm ngặt. Trước hết, giai đoạn "xác định yêu cầu" phải được hoàn tất, kết quả nhận được sẽ là danh sách các yêu cầu đối với phần mềm. Sau khi các yêu cầu đã hoàn toàn được xác định, sẽ chuyển sang pha thiết kế, ở pha này người ta sẽ tạo ra các tài liệu dành cho lập trình viên, trong đó mô tả chi tiết các phương pháp và kế hoạch thực hiện các yêu cầu đã được làm rõ ở pha trước. Sau khi pha thiết kế hoàn tất, lập trình viên sẽ triển khai thực hiện (mã hóa, viết mã) đồ án họ nhận được. Giai đoạn tiếp theo là liên kết các thành phần riêng lẻ đã được những đội lập trình viên khác nhau thực hiện thành một sản phẩm hoàn chỉnh. Sau khi pha triển khai và pha liên kết hoàn tất, sẽ diễn ra pha kiểm thử và chỉnh sửa sản phẩm; ở giai đoạn này những khiếm khuyết ở các giai đoạn trước đó sẽ bị loại bỏ. Sau đó, sản phẩm phần mềm sẽ được đưa vào sử dụng; phần bảo trì phần mềm cũng sẽ được bảo đảm bằng cách bổ sung chức năng mới và loại trừ các lỗi.
Như vậy, mô hình thác nước ngụ ý rằng, việc chuyển từ pha phát triển này sang pha khác sẽ diễn ra chỉ sau khi các pha trước đó đã kết thúc hoàn toàn thành công, và không thể quay lui về pha trước đó hay nhảy vượt pha.
Tuy nhiên, tồn tại một số mô hình thác nước biến thể (bao gồm cả mô hình của Royce), trong đó quy trình phát triển đã được mô tả ở trên bị biến đổi không nhiều hoặc cũng có thể bị biến đổi đáng kể.

**Sự phê bình mô hình thác nước và các giải pháp phương pháp học lai**

**Xem thêm**
 Phương pháp học mềm dẻo của việc phát triển- Phát triển lặp- Mô hình xoắn ốc

**Tham khảo**
  Royce, Winston (1970), Managing the Development of Large Software Systems date=2016-03-15  (tiếng Anh)

**Đọc thêm**
chú thích sách | author=McConnell, Steve | title=Software Estimation: Demystifying the Black Art | url=https://archive.org/details/softwareestimati0000mcco | publisher=Microsoft Press | year=2006 | isbn=0-7356-0535-1
*chú thích sách | author=McConnell, Steve | title=Code Complete, 2nd edition | publisher=Microsoft Press | year=2004 | isbn=1-55615-484-4-  isbn=1-55615-900-5 - Parnas, David,  A rational design process and how to fake it (PDF) An influential paper which criticises the idea that software production can occur in perfectly discrete phases.- .-  "Why people still believe in the waterfall model"- The standard waterfall model for systems development NASA webpage, archived on Internet Archive ngày 10 tháng 3 năm 2005.-  Parametric Cost Estimating Handbook date=2010-01-20 , NASA webpage based on the waterfall model, archived on Internet Archive ngày 8 tháng 3 năm 2005.

**Liên kết ngoài**
  Understanding the pros and cons of the Waterfall Model of software development-  "Waterfall model considered harmful" date=2010-04-16 -  Project lifecycle models: how they differ and when to use them-  Going Over the Waterfall with the RUP by Philippe Kruchten-  CSC and IBM Rational join to deliver C-RUP and support rapid business change
Thể loại:Phát triển phần mềm
Thể loại:Thiết kế
Thể loại:Quản lý dự án
Thể loại:Triết lý phát triển phần mềm