Mô hình V là một phần mở rộng của mô hình Thác nước, vì vậy đừng hy vọng nó sẽ khác biệt nhiều.
Về cơ bản, bạn theo mô hình V từ trái sang phải , giống như trong mô hình Waterfall. Trong Waterfall, bạn làm các yêu cầu, thiết kế, thực hiện, xác minh và cuối cùng là bảo trì. Theo cùng một cách, trong mô hình V, bạn thực hiện các yêu cầu, thiết kế, thực hiện, xác minh và bảo trì: các bước giống nhau trong cả hai trường hợp.
Sự khác biệt chính với Waterfall là cách nó được trình bày và nhấn mạnh vào thử nghiệm.
Đại diện cho dòng chảy dưới dạng hình chữ V giúp tạo ra sự khác biệt giữa mọi thứ xuất hiện trước khi mã hóa (yêu cầu, kiến trúc và thiết kế) và mọi thứ sau mã hóa (về cơ bản là thử nghiệm). Mặc dù các thử nghiệm chỉ là một trong năm bước trong Waterfall, nhưng có vẻ như thực tế là một nửa của quá trình trong mô hình V.
Sơ đồ trong câu hỏi của bạn phức tạp hơn một chút. Những gì nó cố gắng chỉ ra là, ví dụ, bước thiết kế hệ thống không chỉ dẫn đến tài liệu thiết kế hệ thống, như mô hình Waterfall sẽ đề xuất, mà còn cả thiết kế kiểm tra hệ thống, sau này sẽ giúp viết các bài kiểm tra hệ thống. Các sơ đồ chỉ nhấn mạnh hơn nữa vào thử nghiệm . Cuối cùng, thực hiện thiết kế kiểm tra hệ thống giúp thiết kế kiến trúc (sẽ rất khó để thực hiện thiết kế kiến trúc bất kể thiết kế kiểm tra hệ thống).
Tìm kiếm những lời giải thích khác trên internet, tôi không thể tránh trích dẫn bài viết sau của Bhakti Satalkar :
Sự khác biệt chính giữa mô hình thác nước và mô hình V là trong mô hình thác nước, các hoạt động thử nghiệm được thực hiện sau khi các hoạt động phát triển kết thúc. Mặt khác trong mô hình V, các hoạt động thử nghiệm bắt đầu với giai đoạn đầu tiên. Nói cách khác, mô hình thác nước là một quá trình liên tục, trong khi mô hình V là một quá trình đồng thời. So với một phần mềm được tạo bằng mô hình thác nước, số lượng lỗi trong phần mềm được tạo bằng mô hình V là ít hơn. Điều này là do thực tế, có các hoạt động thử nghiệm, được thực hiện đồng thời trong mô hình V. Do đó, mô hình thác nước được sử dụng, khi các yêu cầu của người dùng được cố định. Nếu các yêu cầu của người dùng không chắc chắn và tiếp tục thay đổi, thì mô hình V là lựa chọn tốt hơn.
Giải thích này là sai lệch . Điều đó chỉ đúng nếu bạn thay thế kiểu V của mô hình V trong mô tả bằng bất kỳ phương pháp Agile nào.
Không giống như bài viết, trong mô hình V, kiểm tra được thực hiện sau khi mã hóa; ví dụ, xem Wikipedia :
Một lời chỉ trích thực tế phổ biến đối với Mô hình V là nó dẫn đến việc thử nghiệm bị ép vào các cửa sổ chặt chẽ khi kết thúc quá trình phát triển khi các giai đoạn trước đã vượt qua nhưng ngày thực hiện vẫn cố định.
Mặc dù, trong mô hình V, thiết kế thử nghiệm hệ thống tuân theo thiết kế hệ thống mà không cần đợi cho đến khi thực hiện sản phẩm, điều này không có nghĩa là các thử nghiệm được thực hiện trước khi mã hóa. Tác giả giới hạn mô hình V với các cách tiếp cận Agile như Phát triển hướng thử nghiệm (TDD) trong Lập trình cực đoan (XP).
V