Ai đó có thể giải thích quá trình V Model? Tại sao nó khác với mô hình Thác nước?


19

Có vẻ như Mô hình V chỉ là Mô hình Thác nước với nửa dưới của Thác nước được uốn cong lên để tạo thành một V. Tôi không thấy nó bổ sung bất cứ điều gì mới.

Từ các sơ đồ, tôi cũng không hiểu dòng chảy. Có những mũi tên chỉ theo mọi hướng và tôi không thể hiểu điều gì đến trước. Chúng ta có theo V từ phía trên bên trái, xuống trung tâm dưới cùng sau đó quay lại phía trên bên phải không? Hay chúng ta tiến xuống V làm mọi thứ cao hơn trước khi vật phẩm thấp hơn?

Internet đang thiếu một lời giải thích đầy đủ về mô hình này. Thật tuyệt vời nếu ai đó có thể giải thích nó dưới dạng StackExchange thật :)

Mô hình V

Câu trả lời:


17

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).


1
Vâng - đó là những trích dẫn giống như những gì bạn trích dẫn làm tôi bối rối! Có vẻ như quá trình đang tiến triển xuống và không tuân theoV
CodyBugstein

2
Ngoài thác nước, mô hình V cho thấy các lớp trách nhiệm theo chiều ngang khi chúng tồn tại trong thực tế. Ví dụ: các cấp cao hơn hiển thị cả yêu cầu và kiểm tra hệ thống và không lo lắng về chi tiết của nguồn. Mức nguồn được tách ra khỏi sản phẩm hoàn chỉnh (cần thiết cho các hệ thống rất lớn - nơi bạn có thể có 20 CSCI được tạo thành từ một vài triệu SLOC mỗi cái.)
mattnz

Representing the flow as V-shape helps making the difference between everything which comes prior to coding (requirements, architecture and design) and everything which follows coding (essentially testing). While tests are just one of five steps in Waterfall, it looks like practically half of the process in V-model.= đóng đinh nó! Cảm ơn
CodyBugstein 17/03/2016
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.