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

Mô hình Waterfall là một mô hình SDLC cổ điển được nhiều người biết đến, hiểu và sử dụng phổ biến. Nó được Royce giới thiệu vào năm 1970 và vẫn đang được tuân theo như một phương pháp phổ biến để phát triển phần mềm trong các tổ chức khác nhau trong toàn ngành.

Trong mô hình Waterfall, mỗi giai đoạn vòng đời chỉ có thể bắt đầu sau khi giai đoạn vòng đời trước đó hoàn tất. Do đó, nó là một mô hình tuyến tính không có vòng phản hồi.

Mô hình thác nước - Điểm mạnh

Điểm mạnh của mô hình Waterfall là -

Dễ hiểu, dễ sử dụng.
Cung cấp cấu trúc cho nhóm phát triển thiếu kinh nghiệm.
Các mốc quan trọng được hiểu rõ.
Đặt yêu cầu ổn định.
Lý tưởng cho việc kiểm soát quản lý (lập kế hoạch, giám sát, báo cáo).
Hoạt động tốt khi chất lượng quan trọng hơn chi phí hoặc tiến độ.

Mô hình thác nước - Điểm yếu

Điểm yếu hoặc nhược điểm của mô hình Waterfall là -

Lý tưởng hóa - Nó không phù hợp với thực tế.
Không thực tế - không thể mong đợi các yêu cầu chính xác sớm trong dự án.
Không phản ánh bản chất lặp đi lặp lại của phát triển khám phá phổ biến hơn.
Khó khăn và tốn kém để thực hiện các thay đổi.
Phần mềm chỉ được chuyển giao khi kết thúc dự án. Do điều này -
- Chậm phát hiện ra các khuyết tật nghiêm trọng.
- Khả năng cung cấp các yêu cầu lỗi thời.
Chi phí quản lý đáng kể, có thể gây tốn kém cho các nhóm và dự án nhỏ.
Yêu cầu nguồn lực có kinh nghiệm ở mọi giai đoạn - nhà phân tích, nhà thiết kế, nhà phát triển, người thử nghiệm.
Thử nghiệm chỉ bắt đầu sau khi quá trình phát triển hoàn tất và người thử nghiệm không tham gia vào bất kỳ giai đoạn nào trước đó.
Việc kiểm tra chuyên môn của các nhóm chức năng chéo không được chia sẻ vì mỗi giai đoạn được thực hiện trong các silo.

Khi nào thì sử dụng mô hình thác nước?

Bạn có thể sử dụng mô hình Waterfall nếu -

Yêu cầu rất nổi tiếng.
Định nghĩa sản phẩm là ổn định.
Công nghệ được hiểu rõ.
Phiên bản mới của một sản phẩm hiện có.
Chuyển một sản phẩm hiện có sang một nền tảng mới.
Tổ chức lớn với các nhóm chức năng chéo có cấu trúc.
Các kênh liên lạc được thiết lập tốt trong tổ chức và với cả khách hàng.

Mô hình tạo mẫu tiến hóa

Trong quá trình phát triển phần mềm sử dụng mô hình Tạo mẫu Tiến hóa, các nhà phát triển xây dựng một nguyên mẫu trong giai đoạn yêu cầu. Người dùng cuối sau đó đánh giá nguyên mẫu và đưa ra phản hồi. Phản hồi có thể là các sửa đổi đối với nguyên mẫu hoặc chức năng bổ sung. Dựa trên phản hồi, các nhà phát triển sẽ tinh chỉnh thêm nguyên mẫu.

Do đó, sản phẩm phát triển thông qua Chu kỳ nguyên mẫu → Phản hồi → Chu kỳ nguyên mẫu tinh chỉnh và do đó có tên là Chế tạo mẫu tiến hóa. Khi người dùng hài lòng với chức năng và hoạt động của sản phẩm, mã nguyên mẫu được đưa đến các tiêu chuẩn bắt buộc để cung cấp sản phẩm cuối cùng.

Mô hình tạo mẫu tiến hóa - Điểm mạnh

Điểm mạnh hoặc lợi thế của mô hình Tạo mẫu tiến hóa là:

Khách hàng / người dùng cuối có thể hình dung các yêu cầu hệ thống khi họ được thu thập khi xem xét nguyên mẫu.
Các nhà phát triển học hỏi từ khách hàng và do đó không có sự mơ hồ nào về miền hoặc môi trường sản xuất.
Cho phép thiết kế và phát triển linh hoạt.
Tương tác với nguyên mẫu kích thích nhận thức về chức năng bổ sung cần thiết.
Các yêu cầu bất ngờ và các thay đổi yêu cầu dễ dàng được đáp ứng.
Các dấu hiệu tiến bộ ổn định và rõ ràng được tạo ra.
Phân phối sản phẩm cuối chính xác và có thể bảo trì.

Mô hình tạo mẫu tiến hóa - Điểm yếu

Những điểm yếu hoặc bất lợi của mô hình Tạo mẫu Tiến hóa như sau:

Xu hướng từ bỏ phát triển có cấu trúc trong phát triển mã và sửa lỗi, mặc dù nó không phải là những gì được quy định bởi mô hình.
Mô hình này đã nhận được tiếng xấu vì các phương pháp nhanh chóng và bẩn thỉu.
Khả năng bảo trì tổng thể có thể bị bỏ qua.
Khách hàng có thể yêu cầu giao nguyên mẫu cuối cùng, không tạo cơ hội cho các nhà phát triển thực hiện bước cuối cùng, tức là tiêu chuẩn hóa sản phẩm cuối cùng.
Dự án có thể tiếp tục mãi mãi (với phạm vi thay đổi liên tục) và ban quản lý có thể không đánh giá cao nó.

Khi nào sử dụng mô hình tạo mẫu tiến hóa?

Bạn có thể sử dụng mô hình Tạo mẫu Tiến hóa -

Khi yêu cầu không ổn định hoặc phải làm rõ
Là giai đoạn làm rõ các yêu cầu của mô hình thác nước
Để phát triển giao diện người dùng
Đối với các cuộc biểu tình ngắn hạn
Để phát triển mới hoặc ban đầu
Để triển khai một công nghệ mới