SDLC - V-Model
Mô hình V là một mô hình SDLC trong đó việc thực thi các quy trình diễn ra tuần tự theo hình chữ V. Nó còn được gọi làVerification and Validation model.
V-Model là một phần mở rộng của mô hình thác nước và dựa trên sự liên kết của một giai đoạn thử nghiệm cho mỗi giai đoạn phát triển tương ứng. Điều này có nghĩa là đối với mỗi giai đoạn trong chu kỳ phát triển, có một giai đoạn thử nghiệm được liên kết trực tiếp. Đây là một mô hình có tính kỷ luật cao và giai đoạn tiếp theo chỉ bắt đầu sau khi hoàn thành giai đoạn trước.
V-Model - Thiết kế
Theo V-Model, giai đoạn thử nghiệm tương ứng của giai đoạn phát triển được lên kế hoạch song song. Vì vậy, có các giai đoạn Xác minh ở một bên của giai đoạn 'V' và xác thực ở phía bên kia. Giai đoạn mã hóa tham gia vào hai bên của V-Model.
Hình minh họa sau đây mô tả các giai đoạn khác nhau trong Mô hình V của SDLC.
V-Model - Các giai đoạn xác minh
Có một số giai đoạn Xác minh trong V-Model, mỗi giai đoạn này được giải thích chi tiết bên dưới.
Phân tích yêu cầu kinh doanh
Đây là giai đoạn đầu tiên trong chu kỳ phát triển mà các yêu cầu của sản phẩm được hiểu theo quan điểm của khách hàng. Giai đoạn này liên quan đến việc trao đổi chi tiết với khách hàng để hiểu những mong đợi và yêu cầu chính xác của họ. Đây là một hoạt động rất quan trọng và cần được quản lý tốt, vì hầu hết khách hàng không chắc chắn về những gì họ cần chính xác. Cácacceptance test design planning được thực hiện ở giai đoạn này vì các yêu cầu nghiệp vụ có thể được sử dụng làm đầu vào để kiểm tra chấp nhận.
Thiết kế hệ thống
Khi bạn đã có các yêu cầu sản phẩm rõ ràng và chi tiết, đã đến lúc thiết kế hệ thống hoàn chỉnh. Thiết kế hệ thống sẽ hiểu và chi tiết hóa thiết lập phần cứng và giao tiếp hoàn chỉnh cho sản phẩm đang được phát triển. Kế hoạch kiểm tra hệ thống được phát triển dựa trên thiết kế hệ thống. Thực hiện điều này ở giai đoạn sớm hơn để lại nhiều thời gian hơn cho việc thực thi thử nghiệm thực tế sau đó.
Thiết kế kiến trúc
Thông số kỹ thuật kiến trúc được hiểu và thiết kế trong giai đoạn này. Thông thường, nhiều hơn một cách tiếp cận kỹ thuật được đề xuất và dựa trên tính khả thi về kỹ thuật và tài chính, quyết định cuối cùng được đưa ra. Thiết kế hệ thống được chia nhỏ hơn nữa thành các mô-đun đảm nhận các chức năng khác nhau. Điều này cũng được gọi làHigh Level Design (HLD).
Việc truyền dữ liệu và giao tiếp giữa các mô-đun bên trong và với thế giới bên ngoài (các hệ thống khác) được hiểu và xác định rõ ràng trong giai đoạn này. Với thông tin này, các bài kiểm tra tích hợp có thể được thiết kế và ghi lại trong giai đoạn này.
Thiết kế mô-đun
Trong giai đoạn này, thiết kế nội bộ chi tiết cho tất cả các mô-đun hệ thống được chỉ định, được gọi là Low Level Design (LLD). Điều quan trọng là thiết kế phải tương thích với các mô-đun khác trong kiến trúc hệ thống và các hệ thống bên ngoài khác. Các bài kiểm tra đơn vị là một phần thiết yếu của bất kỳ quá trình phát triển nào và giúp loại bỏ tối đa các lỗi và lỗi ở giai đoạn rất sớm. Các bài kiểm tra đơn vị này có thể được thiết kế ở giai đoạn này dựa trên các thiết kế mô-đun bên trong.
Giai đoạn mã hóa
Mã hóa thực tế của các mô-đun hệ thống được thiết kế trong giai đoạn thiết kế được thực hiện trong giai đoạn Mã hóa. Ngôn ngữ lập trình phù hợp nhất được quyết định dựa trên yêu cầu về hệ thống và kiến trúc.
Việc mã hóa được thực hiện dựa trên các hướng dẫn và tiêu chuẩn mã hóa. Mã trải qua nhiều lần đánh giá mã và được tối ưu hóa để đạt hiệu suất tốt nhất trước khi bản dựng cuối cùng được đưa vào kho lưu trữ.
Các giai đoạn xác thực
Các giai đoạn xác thực khác nhau trong V-Model được giải thích chi tiết bên dưới.
Kiểm tra đơn vị
Các bài kiểm tra đơn vị được thiết kế trong giai đoạn thiết kế mô-đun được thực thi trên mã trong giai đoạn xác nhận này. Kiểm thử đơn vị là kiểm thử ở cấp mã và giúp loại bỏ lỗi ở giai đoạn đầu, mặc dù không thể phát hiện tất cả các lỗi bằng kiểm thử đơn vị.
Thử nghiệm hội nhập
Kiểm thử tích hợp được liên kết với giai đoạn thiết kế kiến trúc. Các bài kiểm tra tích hợp được thực hiện để kiểm tra sự chung sống và giao tiếp của các mô-đun nội bộ trong hệ thống.
Thử nghiệm hệ thống
Kiểm thử hệ thống được liên kết trực tiếp với giai đoạn thiết kế hệ thống. Kiểm tra hệ thống kiểm tra toàn bộ chức năng hệ thống và giao tiếp của hệ thống đang phát triển với các hệ thống bên ngoài. Hầu hết các vấn đề tương thích phần mềm và phần cứng có thể được phát hiện trong quá trình thực hiện kiểm tra hệ thống này.
Kiểm tra chấp nhận
Thử nghiệm chấp nhận được liên kết với giai đoạn phân tích yêu cầu kinh doanh và liên quan đến việc thử nghiệm sản phẩm trong môi trường người dùng. Kiểm tra chấp nhận phát hiện ra các vấn đề tương thích với các hệ thống khác có sẵn trong môi trường người dùng. Nó cũng phát hiện ra các vấn đề phi chức năng như lỗi tải và hiệu suất trong môi trường người dùng thực tế.
V- Mô hình ─ Ứng dụng
V- Ứng dụng mô hình gần giống như mô hình thác nước, vì cả hai mô hình đều thuộc loại tuần tự. Các yêu cầu phải rất rõ ràng trước khi dự án bắt đầu, vì thường tốn kém khi quay lại và thực hiện các thay đổi. Mô hình này được sử dụng trong lĩnh vực phát triển y tế, vì nó là một lĩnh vực có kỷ luật nghiêm ngặt.
Những gợi ý sau đây là một số tình huống phù hợp nhất để sử dụng ứng dụng V-Model.
Các yêu cầu được xác định rõ ràng, ghi chép rõ ràng và cố định.
Định nghĩa sản phẩm là ổn định.
Công nghệ không năng động và được nhóm dự án hiểu rõ.
Không có yêu cầu mơ hồ hoặc không xác định.
Dự án ngắn hạn.
V-Model - Ưu và nhược điểm
Ưu điểm của phương pháp V-Model là rất dễ hiểu và dễ áp dụng. Sự đơn giản của mô hình này cũng giúp bạn dễ dàng quản lý hơn. Điểm bất lợi là mô hình không linh hoạt để thay đổi và chỉ trong trường hợp có yêu cầu thay đổi, điều này rất phổ biến trong thế giới năng động ngày nay, việc thực hiện thay đổi trở nên rất tốn kém.
Các ưu điểm của phương pháp V-Model như sau:
Đây là một mô hình có tính kỷ luật cao và các giai đoạn được hoàn thành từng giai đoạn một.
Hoạt động tốt cho các dự án nhỏ hơn, nơi các yêu cầu được hiểu rất rõ.
Đơn giản và dễ hiểu và sử dụng.
Dễ dàng quản lý do độ cứng của mô hình. Mỗi giai đoạn có các phân phối cụ thể và một quy trình xem xét.
Những nhược điểm của phương pháp V-Model như sau:
Rủi ro cao và không chắc chắn.
Không phải là một mô hình tốt cho các dự án phức tạp và hướng đối tượng.
Mô hình kém cho các dự án dài và đang diễn ra.
Không phù hợp với các dự án mà các yêu cầu có nguy cơ thay đổi từ trung bình đến cao.
Khi một ứng dụng đang trong giai đoạn thử nghiệm, rất khó để quay lại và thay đổi một chức năng.
Không có phần mềm đang hoạt động nào được sản xuất cho đến cuối vòng đời.