Mô hình thác nước là một phương pháp thiết kế tuần tự tương đối tuyến tính cho một số lĩnh vực thiết kế kỹ thuật.
Trong phát triển phần mềm, nó thường là một trong những phương pháp ít lặp lại và linh hoạt hơn, vì tiến trình chủ yếu chảy theo một hướng xuống dưới, giống như một thác nước, qua các giai đoạn hình thành, khởi đầu, phân tích, thiết kế, xây dựng, kiểm tra, triển khai và bảo trì. Được sử dụng trong các dự án phát triển phần mềm, các giai đoạn thường trông như thế này:
1. Yêu cầu
Nếu bạn đang tham gia vào phát triển phần mềm hoặc bất kỳ loại nhóm tạo dự án nào, bạn sẽ muốn biết bối cảnh kinh doanh của những gì bạn đang cố gắng tạo ra – bạn muốn xác định loại vấn đề mà bạn đang cố gắng giải quyết và cách mọi người sẽ phản ứng với sản phẩm hoàn thiện của bạn. Sau khi bạn xác định tất cả những “yêu cầu” này, bạn có đầu vào cần thiết để tiến tới bước tiếp theo.
2. Thiết kế
Bước này bao gồm tất cả các bước mà bạn cần để đáp ứng tất cả các yêu cầu mà bạn đã xác định trước đó. Trong phát triển phần mềm, đây là phần mà bạn xác định tất cả kiến trúc phần mềm và phần cứng, ngôn ngữ lập trình, lưu trữ dữ liệu, v.v. Đây cũng là phần mà bạn xác định dự án sẽ hữu ích như thế nào cho người dùng cuối.
3. Triển khai
Trong bước này, bạn bắt đầu xây dựng những gì bạn đã thiết kế trong kế hoạch của mình. Phần này của phương pháp Thác nước được dành riêng để đáp ứng các tiêu chuẩn mà bạn đã đặt ra trong các bước trước đó. Đây là phần mà những người từ nhóm phát triển tham gia và thực hiện tất cả những điều đã thảo luận trong các bước trước.
4. Xác minh
Đây là phần của phương pháp mà những người đảm bảo chất lượng tham gia để đảm bảo rằng nhóm phát triển không mắc phải sai sót nào. Đây cũng có thể là phần mà mọi người nhận ra điều gì đang hoạt động hoặc không hoạt động trong kế hoạch của họ.
Lưu ý rằng
Khi tất cả mọi thứ được các nhà phát triển dự án thỏa mãn, khách hàng hoặc người dùng cuối sẽ vào và đưa ra quyết định cuối cùng xem dự án có sẵn sàng để được triển khai hay không.
Phương pháp Thác nước nhấn mạnh rằng khi có điều gì đó sai ở một giai đoạn cụ thể, mọi người có thể quay lại giai đoạn trước để xem điều gì đã sai. Ví dụ, nếu có vấn đề trong việc Triển khai Kế hoạch và mọi người biết rằng họ chỉ đơn giản là làm theo bản thiết kế đã được giao cho họ, thì các nhà quản lý sẽ xem xét kế hoạch của họ và thực hiện các sửa đổi từ đó.
Vấn đề của mô hình Thác nước là gì?
Khách hàng có thể không biết chính xác yêu cầu của họ là gì trước khi họ thấy phần mềm hoạt động và do đó thay đổi yêu cầu của họ, dẫn đến việc thiết kế lại, phát triển lại và kiểm tra lại, cùng với chi phí tăng lên.
Các nhà phát triển có thể không nhận thức được những khó khăn trong tương lai khi thiết kế một sản phẩm hoặc tính năng phần mềm mới, trong trường hợp đó, tốt hơn là sửa đổi thiết kế hơn là kiên trì với một thiết kế không tính đến bất kỳ ràng buộc, yêu cầu hoặc vấn đề mới nào được phát hiện.
Do đó, không có đảm bảo rằng các yêu cầu mà tổ chức đã nghĩ ra sẽ thực sự hoạt động. Từ đây, bạn sẽ nhận ra rằng mô hình Thác nước có những vấn đề sau:
1. Mọi người mù quáng làm theo kế hoạch.
Trong phương pháp truyền thống, mọi người chú ý nhiều hơn đến cách mọi thứ sẽ diễn ra vào thời điểm thích hợp mà không chú ý xem mọi thứ có thực sự diễn ra đúng như kế hoạch hay không. Trong khi lập kế hoạch là quan trọng, thì cũng quan trọng rằng các nhà phát triển và người kiểm tra chất lượng hiểu cách mọi thứ nên diễn ra, đặc biệt là với khách hàng hoặc người dùng cuối. Cũng quan trọng là tất cả những người tham gia vào dự án có thể ngay lập tức nói ra cách mà một bước cụ thể trong việc thực hiện dự án có thể bị sụp đổ mà không cần phải chờ đến giai đoạn kiểm tra.
2. Quy trình tuần tự và thay đổi trở nên tốn kém
Phương pháp này không cho phép thay đổi các yêu cầu đã xác định khi dự án tiến triển. Do đó, có khả năng lớn rằng phần mềm sẽ không đáp ứng đầy đủ yêu cầu của người dùng, nó sẽ không hiệu quả và có chức năng kém.
Nó không đủ vì các nhà phát triển không thể chỉ quay lại và thay đổi điều gì đó ở giai đoạn trước khi yêu cầu của người tiêu dùng thay đổi, nhưng nhà phát triển phải quay lại nơi yêu cầu cần thay đổi và bắt đầu lại giai đoạn đó. Chỉ khi giai đoạn đó hoàn thành, họ mới có thể tiến tới giai đoạn tiếp theo.
3. Người dùng cuối không biết họ muốn gì.
Hầu hết thời gian, tâm trí của người dùng cuối liên tục thay đổi và hầu hết mọi người có một ý tưởng mơ hồ về yêu cầu phần mềm của họ và chính khi phần mềm phát triển thì họ mới xác định yêu cầu của mình.
Khi đến lúc bàn giao sản phẩm hoàn thiện cho khách hàng, có khả năng họ sẽ không thích cách mà nó đã diễn ra, mặc dù đã nói ngược lại một cách có chủ ý trong các giai đoạn ban đầu. Khách hàng và người dùng cuối dễ dàng thay đổi những gì họ muốn theo thời gian. Hệ thống Thác nước chưa có cách nào để giải quyết điều đó, mà không cần phải sửa đổi kế hoạch và làm lại toàn bộ dự án.
4. Kiểm tra chất lượng có thể bị ảnh hưởng.
Thật không thể dự đoán chính xác kết quả của một dự án, và khi toàn bộ đội ngũ bị áp lực về thời gian, có thể sẽ rút ngắn giai đoạn kiểm tra để đáp ứng thời hạn.
5. Bạn sẽ không bao giờ biết bạn thực sự đang ở giai đoạn nào.
Vì sản phẩm mà bạn đang cố gắng tạo ra sẽ không được sản xuất cho đến cuối cùng, bạn không thực sự chắc chắn liệu bạn vẫn đang ở giai đoạn lập kế hoạch hay bạn đã ở giai đoạn phát triển. Điều đó có nghĩa là bạn cũng có khả năng sẽ dành nhiều thời gian hơn cho một giai đoạn so với những gì bạn đã mong đợi vì sự thiếu minh bạch này.
Cuối cùng, phương pháp Thác nước có thể quá rủi ro vì nó quá cứng nhắc. Để bạn có thể sản xuất một sản phẩm hoạt động và đủ linh hoạt để giúp bạn xác định điều gì đang hoạt động hoặc không.
Tài nguyên liên quan
- Agile & Scrum – Các bài viết về phát triển phần mềm (Tiếng Anh) (Tiếng TrungTiếng Nhật)
This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.