Waterfall – Mô hình thác nước trong quản lý dự án

Mô hình thác nước (waterfall model) ra đời vào khoảng những năm 70 và được áp dụng nhiều vào quy trình phát triển phần mềm của nhiều công ty lớn. Mô hình này là kết quả của sự kết hợp các mô hình sản xuất từ các ngành kỹ thuật khác áp dụng cho công nghệ phần mềm. Nó định nghĩa ra chuỗi qui trình phát triển theo thứ tự từ trên xuống và các pha/giai đoạn phải được thực hiện tuần tự bao gồm:

• Phân tích các yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn xác định những “đòi hỏi” liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và sản phẩm đầu ra là một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” (software requirement specification). SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án.
  

• Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra “làm thế nào” để hệ thống phần mềm đáp ứng những “đòi hỏi” mà khách hàng yêu cầu trong SRS.
  

• Cài đặt và kiểm thử từng phần (Coding & Unit Test): Chuyển bản thiết kế phần mềm thành một tập hợp các chương trình, hoặc đơn vị chương trình sau đó tiến hành kiểm thử các đơn vị để phát hiện khiếm khuyết và sửa chữa.
  

• Tích hợp và kiểm thử hệ thống (Testing): giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện thực, bao gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test). Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không.
  

• Cài đặt và bảo trì (Deployment and Maintenance): đây là giai đoạn cài đặt, cấu hình và huấn luyện khách hàng. Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống).
  

Ưu điểm của mô hình Waterfall:

• Các giai đoạn được định nghĩa, với đầu vào và đầu ra rõ ràng nên dễ phân công công việc, phân bổ chi phí, giám sát công việc
• Quá trình phát triển đơn giản nên phù hợp với những dự án có ít thay đổi
• Giảm thiểu các lỗi mắc phải trong giai đoạn thiết kế

Tuy nhiên, mô hình này vẫn để lộ một số nhược điểm:

• Mối quan hệ giữa các giai đoạn (pha) không được thể hiện
• Thời gian thực hiện lâu
• Quy trình sửa lỗi khó khăn và tốn nhiều chi phí. Bởi vì nếu hệ thống xuất hiện lỗi thì không thể biết được là do giai đoạn nào, nếu lỗi xuất hiện ở những giai đoạn đầu thì việc quay lại sửa lỗi sẽ tốn rất nhiều thời gian, chi phí.
• Chỉ tiết xúc với khách hàng ở giai đoạn đầu để lấy yêu cầu nên hầu hết không đáp ứng được yêu cầu của khách hàng
• Và một vấn đề quan trọng nữa được phát hiện bởi Frederick Brooks trong cuốn sách kinh điển về quản lý dự án "The Mythical Man-Month" (Bí mật về tháng nhân công) đó là: "trong phát triển phần mềm không phải cứ thêm nhân công thì dự án sẽ nhanh hơn theo cùng cấp số". Các dự án về phần mềm có những đặc thù riêng, chỉ khi đưa vào thử nghiệm trong môi trường thực các vấn đề mới bắt đầu phát sinh và việc thay đổi yêu cầu diễn ra thường xuyên.

Những dự án nào nên tiến hành theo mô hình waterfall?

• Mô hình waterfall chỉ nên sử dụng khi mà đội dự án đã có kinh nghiệm làm việc, bởi mô hình này đòi hỏi sự chính xác ngay từ đầu.
• Waterfall hợp với những dự án mà khách hàng xác định được yêu cầu cụ thể, chính xác ngay từ đầu và ít có khả năng thay đổi
• Đối với những khách hàng lớn mà phong cách làm việc của họ chủ yếu theo mô hình truyền thống (waterfall) hoặc những khách hàng lo ngại có nhiều thay đổi trong dự án
• Nên áp dụng waterfall với những dự án có fixed scope và fixed-price contract