V Model – Mô Hình Phần Mềm Chữ V

V Model là tên viết tắt của Verification software development model.

Mô hình phát triển phần mềm xác minh, hay còn gọi tắt là mô hình chữ V.

1. Nguyên lý của V Model.

Về cơ bản V Model được phát triển mở rộng từ mô hình thác nước, và nó tập trung mạnh vào quá trình kiểm thử.

Mỗi giai đoạn của V-Model đều có một giai đoạn kiểm thử tương ứng  tạo thành hình chữ V

Đó cũng chính là điểm khác biệt rõ rệt với mô hình water-fall

Hãy cùng xem mô hình minh họa dưới đây.

Step 1: BRS 

    Viết tắt của Business Requirement Specification.

    BRS thực hiện quá trình đọc các yêu cầu kỹ thuật của công việc để xem dự án viết cho loại hình công việc nào.

    Kỹ sư phần mềm có nhiệm vụ đọc, phân tích và hiểu toàn bộ yêu cầu nghiệp vụ, sau đó họ có thể diễn giải lại các yêu cầu bằng ngôn ngữ của mình để đảm bảo đã hiểu đúng và đầy đủ.

  Ví dụ: 

       + Hệ thống phần mềm này  phục vụ cho lĩnh vực nào (tài chính, xây dựng, thương mại, giáo dục…)

       + Sản phẩm có hỗ trợ đa nền tảng (web, mobile, desktop) hay chỉ dành cho 1 nền tảng

       + Sản phẩm có bao nhiêu bản(miễn phí, trả phí, cao cấp)

       + Đối tượng người dùng sản phẩm sẽ là ai.

       + Thời gian bắt đầu thực hiện, thời gian cần hoàn thành dự án.

 

    Và để đảm bảo người kỹ sư đã hiểu đúng, hiểu đầy đủ, thì cần có một đội ngũ khác kiểm tra lại.

   Qúa trình kiểm tra đó gọi là: Acceptance test.

   ====> Như vậy câu trả lời cuối cùng của BRS phải là: Hiểu chính xác, đầy đủ yêu cầu của công việc

 

Step 2: SRS  (System requirement Specification)

    SRS thực hiện quá trình đọc và phân tích chất của công việc, tìm hiểu về hệ thống sản phẩm mà dự án đề ra.

    + Sản phẩm mà dự án đưa ra là một hệ thống như thế nào ?

    + Có những tính chất gì, đặc điểm,

    + Có bao nhiêu nhóm chức năng, mỗi nhóm có cơ bản bao nhiêu chức năng

    + Có thể phân chia thành bao nhiêu giai đoạn phát triển

    + Mỗi giai đoạn có thể phân tích được nó khó, hay dễ, thời gian ước lượng là bao nhiêu

    + Mỗi giai đoạn lại có thể chia được thành bao nhiêu task công việc, và số lượng người cần tham gia để xử lý 

    Trong thực tế, chúng tôi thường nói vui thế này:   “Đây là toàn bộ công việc, vậy thì nó có bao nhiêu khúc, khúc nào ngon ăn nhất, khúc nào khó ăn nhất”

   Việc phân tích, mổ sẽ và chia nhỏ được một yêu cầu lớn thành 1 loạt các task công việc nhỏ, sẽ giúp người quản lý và người kỹ sư dễ hình dung hơn, và dễ giao việc phù hợp với từng thành viên

    Kết hợp với việc quản lý thời gian, phân bổ thời gian linh hoạt, công việc nào dễ làm trước,

    công việc nào đã cố định thông tin yêu cầu làm trước, công việc nào khó, còn cần trao đổi, thắc mắc chỉnh sửa thì xử lý sau

   Sau toàn bộ quá trinh phân tích ở trên, và thể hiện bằng một kết quả số liệu rõ ràng, thì một quá trình test đi kiểm để kiểm tra lại,

   xem toàn bộ quá trình phân tích ở trên đã ok chưa, có cần chỉnh sửa bổ sung gì không, có sai sót gì không ?

   Đó là quá trình System Testing

=====> SRS trả lời câu hỏi “hệ thống sẽ hoạt động như thế nào?”

Step 3: HLD (High Level Design)

    Giai đoạn này của V Model được thực hiện trên kỹ thuật hệ thống và thiết kế.

   Nó được coi là mức độ thiết kế tầm cao.

   Khi đã phân tích được tối đa các yêu cầu công việc, hệ thống sản phẩm ở step2

   Step đặt ra câu hỏi, vậy thì áp dụng các giải pháp nào, nền tảng nào thực hiện các task

   Ví dụ viết một hệ thống thương mại điện tử 

   ===> Lựa chọn ngôn ngữ lập trình gì, và hệ thống FrameWork nào sẽ được sử dụng (java, python, c#, js) 

  ===> Lựa chọn hệ quản trị dữ liệu nào (Mysql, sqlite, MongoDB…)

  ===> Các phương pháp test nào sẽ được áp dụng (UnitTest, API Test,….)

  ===> Các hệ thống hỗ trợ bên ngoài nào sẽ được dùng và nó là free hay trả phí

Giai đoạn test cho bước này được gọi là : Integration Test.

Step 4: LLD (Low Level Design)

Đây là bước mức độ thấp của thiết kế.

Là giai đoạn mà sản phẩm phần mềm đã được tiến hành thiết kế thực tế,

Bắt đầu đi vào xác định các yếu tố logic, các sơ đồ lớp với mọi phương thức, mối liên quan giữa các lớp trong LLD.

Giai đoạn này có thể phát sinh các mâu thuẫn, sự phù hợp hay không phù hợp.

Ví dụ thế này cho dễ hiểu:

       Xây dựng một trang web bán hàng thương mại điện tử, vậy nó cần các mục gì

              + Trang Home => phải xây dựng module Home

              + Trang Products (toàn bộ sản phẩm) => Phải xây dựng module Products

              + Trang Post (1 sản phẩm)  => xây dựng module Post

              + Trang Admin             ===> xây dựng module Admin

……

===> LLD trả lời cho câu hỏi, các module ở mức độ thiết kế code là gì 

Sau khi bước này được thực hiện thành công thì được chuyển đến công đoạn test gọi là : Component Test.

⚠️ Lưu ý:

Ở bước này, có thể phát sinh các vấn đề như:

• Mâu thuẫn logic giữa các module.

• Trùng lặp chức năng.

• Quan hệ giữa các lớp chưa hợp lý (tight coupling).

• Thiếu tài liệu mô tả chi tiết cho dev junior thực hiện.

Step 5: Coding

     Là bước bắt đầu tiến hành triển khai dự án.

     Mỗi thành viên đảm nhiệm một chức năng nhiệm vụ của riêng mình.

     Bắt đầu sử dụng ngôn ngữ lập trình và các thuật toán để coding ra một phần chức năng của phần mềm.

              Ví dụ :

                  + Dev1 code trang Home, Dev2 lo code toàn bộ phần admin

                  + Khi code các dev sẽ phải viết logic code như các hàm, các lớp, các thuật toán xử lý code…

                  + Để đảm bảo các hàm chạy tốt,  các module thực hiện đúng các chức năng, thì một quá trình test được thực hiện cho giai đoạn này

    Người ta gọi đó là công đoạn Unit Test.

    Unit Test là cấp độ test ở mức đơn vị của xử lý, ví dụ một hàm xử lý có đầu vào và có đầu ra, người test sẽ phải kiểm một số các trường hợp cho đầu vào của hàm

     Người ta gọi đó là các test case mức độ Unit Test

    Ví dụ: 

    + Đối số đầu vào là một giá trị số nguyên:   

                                kiểm tra với case là số 0

                                kiểm tra với case là số âm, số dương

                                kiểm tra với case là các số tiệm cận số 0, ví dụ 1, -1

                                kiểm tra với 1 số thật lớn, hoặc thật nhỏ

                                thử kiểm tra với 1 giá trị vượt ngoài phạm vi của biến

     + Đối số đầu vào là 1 chuối ký tự:

                                  kiểm tra với ký tự asscii, ký tự unicode, ký tự đặc biệt, ký tự chữ, ký tự số, ký tự lẫn lộn,  không có ký tự….

 

⚠️ Rủi ro nếu thiết kế kém:

Unit Test là công việc chi tiết và tốn nhiều công sức. Nếu ở các bước trước (BRS, SRS, HLD, LLD)

có sai sót hoặc thay đổi thiết kế, thì dev sẽ phải sửa lại rất nhiều đoạn code và update lại toàn bộ test case, gây lãng phí thời gian lớn.

Do đó nếu như các step1, step2, step3, step4 mà không chính xác, không có quá trình test cẩn thận,

thì ở step5 này, nếu đã viết hàng trăm test case Unit Test, mà sau đó phải sửa lại step3, thì việc update lại các UnitTest là vô cùng vất vả

    ====> Coding trả lời câu hỏi, các logic code, các hàm, các moudle, các lớp đã hoạt động chính xác chưa với đủ các case đặc biệt.

Step 6: Code/Testing

Đây chính là bước test thực sự các chức năng của hệ thống phần mềm. 

Nó trả lời cho câu hỏi:  Tester sẽ test những gì trong sản phẩm phần mềm.

Tester sẽ test toàn bộ các chức năng phần mềm, từ các chức năng đơn giản đến phức tạp.

Dựa trên một danh sách các test case được viết ra, phân chia theo từng module, từng nhóm chức năng, từng chức năng để test

==> Mỗi khi có bug, họ sẽ gửi bug cho đội code để thực hiện quá trình chỉnh sửa.

Nếu những bug quá đơn giản ví dụ như:

   Chương trình bị crashed khi nhập một giá trị 0 vào giao diện. kết quả điều tra cho thấy, bị crashed là do hàm xử lý chia cho 0

==> Như vậy lúc này câu hỏi đặt ra là vì sao UnitTest không phát hiện ra lỗi này => quay về step 5 để thực hiện lại UnitTest

 

2. Ưu điểm và Nhược Điểm của V Model

* Ưu điểm.
– Rất trực quan và dễ áp dụng.
– Có hoạt động, kế hoạch cụ thể cho quá trình test.
– Tiết kiệm được thời gian (mà chủ yếu là thời gian xử lý bug), và có cơ hội thành công cao hơn waterfall.
– Chủ động trong việc phát hiện bug, sớm tìm ra bug ngay từ những bước đầu.

* Nhược điểm.
– Độ linh hoạt bị ảnh hưởng do nó có một chút cứng ngắc về nguyên tắc test. Nghĩa là cứ sau mỗi step lại phải có test.

Nếu yêu cầu dự án dễ hiểu, không quá phức tạp thì việc thực hiện nhiều công đoạn test như vậy là tốn thời gian, và chi phí phát triển, cũng như nhân lực tham gia

– Giống với water fall, sản phẩm của dự án chỉ được xuất hiện khi tất cả các bước được hoàn thành xong, không có nguyên mẫu ngay từ ban đầu.

       Không đáp ứng được yêu cầu dịch vụ vừa phát triển song song với vừa bán sản phẩm.

– Nếu có sự thay đổi về kỹ thuật ở nửa chừng, thì sẽ phải quay lại các bước đầu tiên, thực hiện lại, update lại tài liệu.

3. Áp dụng V Model cho những dự án như thế nào.

+ Dự án có kích thước nhỏ, và trung bình, các yêu cầu dự án là rõ ràng, cố định.

+ Khi team phát triển có đội ngũ kỹ thuật tốt, có nguồn tài nguyên phong phú, sẵn có để đảm bảo được yêu cầu, đọc nhanh, test nhanh và coding nhanh.

+ Nếu khách hàng có sự tự tin cao trong yêu cầu thiết kế (nghĩa là ít thay đổi, ít dao động) thì V model là lựa chọn cần thiết.

Lưu

Lưu

Lưu

Lưu

Lưu

Lưu

Lưu