Giới thiệu Function Points Analysis (FPA ) - Phương pháp định lượng phần mềm dựa trên Function Points

Abstract: Khi bạn nhận được một yêu cầu xây dựng phần mềm từ khách hàng, bạn hiểu yêu cầu phần mềm, và bạn cần phải đưa ra thời gian cũng như định giá phần phàn mềm mà bạn sắp xây dựng. Nhưng bạn cần định giá như thế nào? Bạn cần dựa trên cơ sở nào để đưa ra một mức giá hợp lý? Và Function Points đã được ra đời làm cơ sở để định lượng phần mềm

I. Tổng quan về Function Points Analysis (FPA)

• Phân tích FPA là một phương pháp định lượng phần mềm dựa trên các chức năng nghiệp vụ của hệ thống khi bàn giao sản phầm cho khách hàng được đưa ra bởi Allan Albretch năm 1979
• FPA phân tích hệ thống thành cách chức năng nhỏ, dễ hiểu. Ví dụ khi ta cần xây dựng ứng dụng hiển thị ảnh đã có sẵn trên điện thoại android, dựa trên phương pháp này, chúng ta cần phân ra 2 chức năng, 1 chức năng đọc file và chuyển nó thành bitmap, một chức năng hiển thị ảnh. Nếu có chức năng thêm, ví dụ như cho phép xem nhiều ảnh, thì ta phân thêm chức năng xem nhiều ảnh.
• FP là một đơn vị đo lường cho phần mềm giống như giờ để đo lường thời gian, dặm là đơn vị đo của khoảng cách, hay Celsius là đơn vị đo của nhiệt độ.
• FP định lương phần mềm bằng số lượng các chức năng mà hệ thống cung cấp cho người sử dụng chủ yếu dựa trên thiết kế logic.
• Khi thiết kế ứng dụng phần mềm, cũng giống như một tảng băng trôi, phần lớn chìm ở dưới còn nổi trên bề mặt chỉ là một phần nhỏ. Ví dụ như việc người dùng thực hiện một chuyến bay, họ chọn ngày bay và đặt vé. Nhìn bề ngoài thì có vẻ rất đơn giản nhưng thực tế bên trong phải thực hiện hàng nghìn câu lệnh, hàng nghìn tiến trình. Khi đánh giá ứng dụng phần mềm chúng ta phải hiểu những gì là bên trong và những gì là bên ngoài.

II. Lịch sử và sự phát triển

1. Lịch sử
   • Function Point Analysis (FPA) được phát triển đầu tiên bởi Allan J. Albrecht vào năm 1970.
   • Và được công bố vào năm 1979, tiếp đó là 1983.
   • Tiếp theo đó, vào năm 1986, International Function Point User Group ( IFPUG) ra đời.
2. Sự phát triển
   • Từ năm 1987 – 1997: số lượng thành viên tăng từ 100 thành viên lên tới 600 thành viên.
   • 1988 – 1997: Các hội thảo liên quan tăng từ 125 tới 300 hội thảo/ năm
   • Ban đầu, IFPUG chỉ mở rộng trong các thành viên ở Bắc Mỹ, sau đó truyền bá sang Châu Âu rồi tới Châu Á tạo ra một sự liên kết mạnh mẽ.
3. Phạm vi
   • FP có thể được sử dụng để giao tiếp hiệu quả hơn khi đàm phán giữa khách hàng và doanh nghiệp.
   • Chức năng:
     • Xác định thời điểm hoàn thành.
     • Ước tính các test case.
     • Xác định phạn vi mở rộng của sản phẩm.
     • Xác định phạm vi liên quan.
     • Tính được chi phí thực của phần mềm.
     • Ước lượng được chi phí dự án tổng thể, thời hạn và kết quả đạt được
     • Xác định chi phí bảo trì.
     • Giúp cho việc đàm phán hợp đồng.
4. Mục đích
   • FP sử dụng để thiết lập một bảng kiểm kê các giao dịch và các file của ứng dụng hay dự án hiện tại. Bản kiểm kê này dùng như một phương tiện đánh giá tài chính của một ứng dụng. Nếu bản kiểm kê được thực hiện cho một cho một dự án phát triển hoặc dự án muốn mở rộng thêm thì bản kiểm kê này có thể giúp duy trì phạm vi và kiểm soát độ phát triển của dự án. Quan trọng hơn là bản kiểm kê này giúp chúng ta hiểu tầm quan trọng của vấn đề.
   • FP có thể sử dụng để ước lượng quy mô ứng dụng phần mềm. Quy mô là thành phần quan trọng trong việc xác định hiệu suất (đầu vào, đầu ra), dự tính nhân lực, nắm bắt chi phí , ...
   • Không giống như một số số liệu phần mềm khác, những người khác nhau có thể đếm các FP tại các thời điểm khác nhau, để có được những biện pháp tương tự trong biên độ hợp lí của lỗi. Có nghĩa là, kết luận giống nhau sẽ được rút ra từ kết quả.
   • FPA có thể giúp các tổ chức hiểu được đơn vị chi phí của phần mềm hoặc dự án. Một khi chi phí đơn vị được hiểu là các công cụ, ngôn ngữ, nền tảng có thể so sánh về số lượng thay vì chủ quan. Loại phân tích này dễ dàng hơn để hiều kĩ thuật thông tin. Có nghĩa, một người dùng ko chuyên có thể dễ dàng hiểu các FP.
5. Phân loại
   • Development Project Function Point Counts: các FP có thể được đếm trong tất cả các pha của dự án từ yêu cầu cho đến thực hiện. Phạm vi lân cận có thể được theo dõi và giám sát nhờ sự hiểu biết kích thước chức năng ở tất cả các pha của dự án.
   • Enhancement Project Function Point Count: được áp dụng để nâng cao phần mềm sau khi nó đã được đưa vào sản xuất. Bằng cách theo dõi kích thước tăng thêm và liên hệ với những chi phí thực hiện trước mà dự án có thể được thực hiện.
   • Application Function Point Count: số các ứng dụng đã hoàn thành, tồn tại trong ứng dụng hiện có. Loại đếm cơ bản này có thể được sử dụng với số liệu ứng dụng tổng thể.
6. Một số công thức tính

• Năng suất lao động

    Năng suất = kết quả đầu ra/đầu vào (trong một khoảng thời gian và chất lượng xem xét)
    Năng suất đầu vào = FP/đầu vào
  

  • Tiến trình đếm FP: không có định nghĩa chính xác về FP vì nó được áp dụng cho nhiều môi trường phần mềm khác nhau. Mục tiêu tổng thể là để xác định điều chỉnh số điểm chức năng thông qua các bước:
    • Xác định loại FPC
    • Xác định phạm vi ứng dụng
    • Xác định và đánh giá các giao dịch
    • Xác định tốc độ dữ liệu
    • Xác định hệ số điều chỉnh giá trị
    • Tính toán điều chỉnh số FP
  • Số FP ko điều chỉnh được xác định trong bước 3 và 4
  • Cuối cùng số FP điều chỉnh được xác định bằng tổng số FP và số FP ko điều chỉnh.

• FPA Steps for Transactional Function Types: mỗi giao dịch phải là một đơn vị hoạt động nhỏ nhất, có ý nghĩa cho người dùng cuối. Tài liệu ứng dụng và quy tắc giao dịch được sử dụng để xác định giao dịch, xác minh loại giao dịch, xác định số lượng và loại tập tin tham chiếu. Mỗi giao dịch được gán giá trị thấp, trung bình hoặc cao dựa trên loại, các yếu tố dữ liệu và tệp tin tham chiếu. Tất cả giao dịch được tổng hợp để tạo ra một giao dịch ko điều chỉnh các FP.

• Tính toán Function Point Count(FPC)

    FPC là tích của thời gian VAF và UAF
    FPC = VAF.UAF
    FPC: function point count
    VAF: values adjustment factor: giá trị hiệu chỉnh
    UAF: giá trị mặc định
  

  • Công thức với mục đính tính toán ra số lượng chức năng phát sinh trong dự án. Thông thường, khi một ứng dụng được nâng cấp lên phiên bản mới, dữ liệu càn phải được chuẩn bị, và khi đó, một số chương trình nhỏ để hỗ trợ việc chuyển đổi này, nhưng lại không tồn tại khi chương trình được nâng cấp và khởi chạy. Và đây là nguyên nhân của công thức này.

      DFP = (UFP + CFP)VAF
      DFP: số lượng chức năng phát triển
      UFP: khung định mức
      CFP: số chức năng được tăng thêm khi chuyển đổi
      VAF: giá trị điều chỉnh
    

III. Kết luận

Ở trên, tôi đã giới thiệu về phương pháp định lượng cho phần mềm, một vấn đề quan trọng khi bạn cần giao tiếp khách hàng, để đôi bên cùng có lợi.

Cảm ơn các bạn đã theo dõi!