Quản lý dự án sử dụng mô hình thác nước (Waterfall Model) là phương pháp quản lý dự án dựa trên quy trình thiết kê tuần tự và liên tiếp.
Trong phát triển phần mềm, thường ít có sự lặp lại và ít có sự linh hoạt. Các quy trình phát triển trông giống như một dòng chảy, thông qua các giai đoạn hình thành, khởi tạo, phân tích, thiết kế, xây dựng, thử nghiệm, triển khai và bảo trì.
Các giai đoạn của mô hình thác nước (Waterfall Model)
1. Xác định yêu cầu
Nếu bạn tham gia phát triển phần mềm hoặc bất kỳ quy trình phát triển dự án nào, bạn sẽ muốn biết mục tiêu của dự án đang đảm nhận – bạn muốn xác định vấn đề 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 như thế nào. Sau khi bạn xác định tất cả các yêu cầu này, bạn có thông tin đầu vào để chuyển qua bước tiếp theo.
2. Thiết kế
Bước này bao gồm các bước mà bạn cần làm để đáp ứng tất cả các yêu cầu đã xác định trước đó. Trong phát triển phần mềm, đây sẽ là phần thiết kế phần mềm và phần cứng, ngôn ngữ lập trình, lưu trữ dữ liệu, v.v. Và cũng là phần giúp bạn xác định dự án sẽ hữu ích như thế nào đối với 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 để đáp ứng các tiêu chuẩn đã thực hiện ở các bước trước. Đây là phần mà các thành viên trong team cùng nhau tiến hành hoàn thành các nhiệm vụ công việc đã thảo luận ở các bước trước đó.
4. Kiểm thử
Đây là phần của phương pháp mà mọi thành viên trong nhóm đảm bảo chất lượng và không mắc bất kỳ sai lầm nào. Đây cũng rất có thể là phần mà mọi người nhận ra điều gì đang hoạt động hiệu quả hoặc không hiệu quả trong kế hoạch.
Lưu ý
Khi tất cả mọi thứ được đồng thuận từ các developers, khách hàng hoặc người dùng cuối cũng có nghĩa sản phẩm đã sẵn sàng để được đưa vào sử dụng.
Phương pháp Waterfall cho thấy rằng khi có sự cố xảy ra trong 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ì đã xảy ra. Ví dụ, nếu có vấn đề trong việc Thực hiện Kế hoạch và lúc đó chỉ đơn giản làm theo bản thiết kế đã được bàn giao, thì các nhà quản lý sẽ xem xét kế hoạch và sửa đổi từ đó.
Có thể bạn muốn tìm hiểu:
- 12 kỹ năng cần nắm vững để làm trong ngành khoa học dữ liệu
- 100 câu hỏi phỏng vấn và trả lời vị trí Business Analyst
- Top 25 người phụ nữ quyền lực nhất trong ngành IT năm 2020
Các vấn đề của mô hình Waterfall
Khách hàng có thể không biết chính xác yêu cầu của họ trước khi họ thấy phần mềm hoạt động và do đó họ thay đổi yêu cầu, dẫn đến thiết kế lại, phát triển lại và kiểm tra lại, đồng thời tăng chi phí.
Các nhà thiết kế 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ế từ ban đầu.
Do đó, không có gì đảm bảo rằng sau khi hoàn thành một dự án sẽ thực sự hoạt động, từ đây bạn sẽ biết được rằng mô hình thác nước cũng có nhiều vấn đề xảy ra:
1. Mọi người làm theo kế hoạch một cách mù quáng.
Trong phương pháp truyền thống, mọi người chú ý nhiều hơn đến việc mọi thứ sẽ diễn ra như thế nào trong thời điểm thích hợp mà không quan tâm đến việc nó sẽ như thế nào trong thời điểm hiện tại. Mặc dù lập kế hoạch là quan trọng, nhưng điều quan trọng là các developer và bộ phận tester phải hiểu mọi thứ sẽ diễn ra như thế nào, đặc biệt là với khách hàng hoặc người dùng cuối.
2. Quy trình tuần tự và sẽ tốn thêm chi phí nếu có sự thay đổi
Theo phương pháp làm việc này không cho phép thay đổi các yêu cầu đã xác định trước đó khi dự án đang trong giai đoạn phát triển. Vì vậy, có một khả năng lớn là 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.
Điều này khá bất cập vì developer phải quay lại bước yêu cầu cần thay đổi và bắt đầu thực hiện dự án từ giai đoạn này.
3. Người dùng cuối cũng chưa xác định được chính xác họ muốn gì
Hầu hết mọi người đều có ý tưởng mơ hồ về các yêu cầu phần mềm của họ và khi phần mềm phát triển, họ mới xác định được yêu cầu mình muốn chính xác là gì.
Cho đến lúc bàn giao sản phẩm, có khả năng họ sẽ không thích nữa. Khách hàng và người dùng cuối có thể dễ dàng thay đổi những gì họ muốn theo thời gian. Hệ thống Waterfall vẫn 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à thực hiện lại toàn bộ dự án.
4. Có thế sẽ phát hiện ra nhiều lỗi trong quá trình kiểm tra chất lượng dự án
Không thể dự đoán chính xác kết quả của một dự án và khi toàn bộ nhóm bị thúc ép về thời gian, có thể cắt ngắn giai đoạn thử nghiệm để bàn giao đúng deadline.
5. Bạn sẽ không bao giờ biết mình 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, nên bạn không thực sự chắc chắn liệu mình vẫn đang lên kế hoạch hay bạn đang trong giai đoạn phát triển.
Cuối cùng, phương pháp Waterfall 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 để tìm ra cái gì đang hoạt động hiệu quả hay không.
Xem bài viết gốc tại đây !
Bạn cũng có thể xem bài: khi nào thì nên sử dụng mô hình waterfall trên Viblo
Bạn có biết?
tham gia cộng đồng ITguru trên Linkedin, Facebook và các kênh mạng xã hội khác có thể giúp bạn nhanh chóng tìm được những chủ đề phát triển nghề nghiệp và cập nhật thông tin về việc làm IT mới nhất
Linkedin Page:
Facebook Group:
cơ hội việc làm IT : ITguru.vn
