[Hỗ trợ - Cách làm việc] Mô hình Waterfall

Năm 1970, mô hình nổi tiếng và được áp dụng trong qui trình phát triển phần mềm tại phần lớn các công ty hiện nay ra đời: mô hình thác nuớc (Waterfall model). 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. Mô hình Waterfall là một chuỗi qui trình phát triển như một luồng đều đặn từ trên xuống giống như một thác nước, bao gồm các giai đoạn: phân tích yêu cầu khách hàng, thiết kế, cài đặt, kiểm tra, tích hợp và bảo trì. Bạn sẽ thấy mô hình này giống hệt với qui trình xây một căn nhà: kiến trúc sư tìm hiểu yêu cầu của chủ nhà, thiết kế căn nhà, đưa cho đội ngũ thi công thực hiện, kiểm tra chất lượng và cuối cùng trao chìa khóa cho người sở hữu.

Sự phát triển như một luồng đều đặn từ trên xuống giống như một thác nước.





Mô hình này bao gồm các giai đoạn xử lý nối tiếp nhau như sau:


Phân tích 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” (“What”) 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à kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification), trong đó bao gồm tập hợp các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối với dự án (từ phía khách hàng). 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” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS. Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện thực để đáp ứng yêu cầu đó.

Hiện thực và kiểm thử từng thành phần (Coding and Unit Test): là giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”.

Kiểm thử (Test): 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).

Thực tế cho thấy đến những giai đoạn sau mới có khả năng nhận ra sai sót trong những giai đoạn trước và phải quay lại để sửa chữa. Đây chính là kiểu waterfall dạng lặp (Iterative Waterfall) và được minh hoạ trong hình sau:







Mô hình này đã được sử dụng rộng rãi trong những dự án phát triển phần mềm lớn của bộ Quốc Phòng Mỹ và NASA, và trong rất nhiều dự án lớn khác của chính phủ. Những cơ quan sử dụng mô hình này không phải lúc nào cũng phân biệt được mô hình Waterfall nguyên bản và các mô hình Waterfall đã được sửa đổi vì thế thật khó để xác định chính xác mô hình nào được sử dụng và những gì được mở rộng.

Người ta đã nhận ra rằng một lỗi được phát hiện ở các giai đoạn ban đầu trong quá trình phát triển phần mềm như là đặc tả yêu cầu và thiết kế thì tốn ít tiền, công sức và thời gian để sửa lỗi hơn là cùng lỗi đó những được phát hiện muộn hơn. McConnell (1996) đánh giá rằng một sai sót trong đặt tả nếu không được phát hiện cho đến khi cài đặt hoặc bảo trì sẽ tốn từ 50 đến 200 lần giá thành để khắc phục hơn là khi khắc phục nó từ giai đoạn đặc tả. Do đó, đối với mô hình Waterfall, đầu tiên phải chắc rằng đặc tả và thiết kế hoàn toàn đúng sẽ giúp tiết kiệm thời gian và công sức sau này. Và trong mô hình này, mỗi pha phải được chăc chắn rằng đã hoàn thành 100% và hoàn tòan đúng trước khi tiếp tục chuỷển sang pha tiếp theo của quá trình.

Nhiều năm qua đi, người ta ngày càng học hỏi được nhiều hơn về cách tốt nhất để làm một phần mềm và cũng bắt đầu nhận thức được rằng mô hình thác nước là quá cứng nhắc và thiếu thực tế. Không giống như việc bạn xây một căn nhà, ngay khi thiết kế, người ta đã dự kiến được 99% hình thù và chi tiết căn nhà sẽ như thế nào. Một dự án phần mềm hiếm khi được hình dung một cách chi tiết và đúng theo yêu cầu công việc. 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 người “ngoại đạo” thường nghĩ rằng vì phần mềm là “mềm” nên có thể dễ dàng thay đổi chỉnh sửa tùy hứng. Nhưng thực ra phầm mềm cũng giống như bất kỳ một cơ cấu kỹ thuật nào khác (như máy móc cơ khí chẳng hạn), nó cũng có thiết kế và cấu trúc (mà thường lại còn phức tạp hơn các máy móc cơ khí rất nhiều).

Khi yêu cầu công việc thay đổi, việc thay đổi trong phần mềm là tất yếu và trong thế kỷ 21 này các thay đổi lại càng diễn ra thường xuyên và nhanh chóng. Với mô hình Waterfall, việc theo kịp các thay đổi là không thể thực hiện vì vòng qui trình của nó quá dài. Nó giống như việc cứ mỗi lần có bất kỳ thay đổi nào là bạn phải gần như phải phá căn nhà đi và xây lại từ đầu. Bạn có thể hình dung ra được sự tốn kém và bất tiện sẽ lớn như thế nào.

Năm năm sau, Frederick Brooks phát hiện ra lỗ hổng lớn đầu tiên của mô hình này trong cuốn sách kinh điển về quản trị dự án: The Mythical Man-Month (Bí mật về tháng nhân công). Chắc các bạn làm phần mềm đều biết khái niệm man-month (hay man-day) là thước đo căn bản để tính giá cho việc phát triển phần mềm: đó là công lao động trong một tháng (hay một ngày) của một lập trình viên. Phát hiện nổi tiếng nhất của Brooks 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ố“. Vấn đề là do sự mất cân đối trong giao tiếp khi số lượng người tham gia tăng lên.

Thật khó có thể xác định hết các yêu cầu từ thời điểm ban đầu của một dự án phần mềm. Khách hàng chỉ làm việc với nhóm phát triển trong pha phân tích ban đầu. Khách hàng không thể có một nhận thức chính xác về những gì họ yêu cầu trước khi họ có thể nhìn thấy mô hình họat động. Họ có thể thay đổi yểu cầu bất cứ lúc nào mà người thiết kế và cài đặt không thể kiểm soát. Nếu khách hàng thay đổi yêu cầu của họ sau khi pha thiết kế đã kết thúc, thì thiết kế sẽ phải được thay đổi để thích hợp với những yêu cầu mới. Và người thiết kế cũng có thể không thầy hết được những khó khăn trong cài đặt ở tương lai khi thiết kế một sản phần phần mềm không có khả năng cài đặt. Trong trường hợp này tốt hơn là thiết kế lại phần mềm hơn là sửa chữa thiết kế cũ.

Việc thay đổi là có thể xuất hiện bất cứ lúc nào trong cả quá trình của dự án, và người ta không thể biết chắc rằng cần phải tốn bao nhiêu thời gian và công sức cho mỗi pha để đảm bảo rằng tất cả đã thỏa mãn yêu cầu của người dùng, và thật khó để đánh giá một cách chính xác thời gian, giá thành của dự án ngay từ hợp đồng ban đầu.

Tóm lại, hai vấn đề lớn nhất của mô hình thác nước là:

1. Mô hình này quá tự tin với giả định rằng chúng ta luôn có thể làm được một hệ thống hoàn hảo ngày lần đầu.

2. Phần mềm ngày càng khác với các cơ cấu kỹ thuật cứng nhắc mà giống như các cơ thể sống - nó phải tiến hóa để thích hợp với môi trường. Đây chính là tiền đề cho một phương thức phát triển mới chiếm lĩnh ưu thế trong những năm gần đây: phương thức phát triển linh hoạt ( Agile Development Methods )