Tổng quan về Function Point Analysis (FPA)
1. Giới thiệu
Khi bắt tay vào việc thực hiện một dự án, điều bạn băn khoăn đó là làm sao có thể xác định được khối lượng công việc, từ đó có thể tính toán được chi phí về tài nguyên (con người, thời gian, tiền bạc…). Ví dụ như xây một ngôi nhà cần hết bao nhiêu ngày công, khối lượng vật liệu cần thiết, số lượng nhân công, thời gian thực hiện các công đoạn nhỏ như đào móng, xây tường, đổ bê-tông… để cho ngôi nhà được hoàn thành đúng dự kiến. Để tính được khối lượng công việc cho một dự án phần mềm, người ta dùng phương pháp Function Point Analysis (FPA).
FPA là một phương pháp được ISO chấp nhận, dùng để xác định kích thước về mặt chức năng (functional size) của một hệ thống thông tin. Functional size phản ánh số lượng chức năng liên quan tới và được chấp nhận bởi người dùng trong doanh nghiệp. Nó hoàn toàn độc lập với công nghệ được sử dụng để triển khai hệ thống. Đơn vị dùng để đo lường được gọi là function points (FPs) cũng tương tự như để đo khối lượng, người ta sử dụng “kilôgram”, đo độ dài người ta dùng “mét”…Chính vì vậy, phương pháp FPA biểu diễn độ lớn của hệ thống thông tin bằng số lượng các FPs. Ví dụ như độ lớn của một hệ thống X là 256FPs.Khái niệm FP được đưa ra bởi Allan Albrecht vào giữa những năm 1970 nhằm thay thế cho phương pháp đo lường kích thước phần mềm bằng cách đếm số dòng code, sau đó được IBM xuất bản vào năm 1979, và sau đó là IEEE tái bản vào năm 1981.
Thuật ngữ:
| FP (Function Point (FP) |
The function point is a "unit of measurement" to express the amount of business functionality an information system provides to a user. |
| EI (External Inputs) | An external input (EI) is an elementary process that processes data or control information that comes from outside the application boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system. Examples of EIs include: Data entry by users. |
| EO (External Outputs) | An external output (EO) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external output is to present information to a user through processing logic other than, or in addition to, the retrieval of data or control information |
| EQ (External Queries) | An external inquiry (EQ) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information from an ILF of EIF. The processing logic contains no mathematical formulas or calculations, and creates no derived data. No ILF is maintained during the processing, nor is the behavior of the system altered. |
| ILF (Internal Logical File) | An user-identifiable group of logically related data or control information maintained within the boundary of the application. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being counted. |
| EIF (External Interface File) | An external interface file (EIF) is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary processes within the boundary of the application counted. This means an EIF counted for an application must be in an ILF in another application. |
| DET (Data Element Types) | A unique user recognizable, non-repetitive field. |
| FTR (File Types Referenced) | FTR – File Type Referenced is a file type referenced by a transaction. An FTR must also be either an Internal or External file |
| RET (Record Element Type) | RET – Record Element Type is a user recognizable sub group of data elements within an Internal or External File. |
2. Mục tiêu
- Tính toán số chức năng dựa trên góc nhìn từ phái end-users về các chức năng của hệ thống.
- Giảm thiểu hóa công sức, chi phí dùng cho việc tính toán, đo đạc.
- Thiết lập nên một phương pháp đo đạc thống nhất giữa các tổ chức.
3. Lợi ích
- Có thể xác định được kích thước của phần mềm từ sớm trong quy trình phát triển.
- Giữ vai trò như một phương pháp đo đạc căn bản, tăng cường năng suất.
- Độc lập với công cụ và môi trường phát triển.
- Cung cấp phương pháp đo lường kích thước thống nhất giữa các nhóm và tổ chức.
- Là công cụ quan trọng để xác định năng suất, ước lượng chi phí, công sức…
4. Quy trình ( 5 bước)
- Xác định loại dự án (phát triển dự án mới, nâng cấp dự án hay chỉ đánh giá một dự án đã có)
- Xác định phạm vi của dự án.
- Xác định số lượng Function Points thô (Unadjusted Function Points)
- Xác định hệ số cân đối (Value Adjusted Factors).
- Xác định số lượng Function Points cân đối.
Quy trình tính toán FP như sau:
- Xác định kiểu đo lường (ước lượng cho dự án mới, nâng cấp dự án hay chỉ đánh giá một dự án đã có)
- Xác định phạm vi của dự án.
- Xác định số lượng Function Points thô (Unadjusted Function Points)
- Xác định hệ số cân đối (Value Adjusted Factors).
- Xác định số lượng Function Points cân đối (Adjusted Function Points).
Step 1: Xác định kiểu đo lường (Type of Count)
Bước đầu tiên trong phương pháp FPA đó là xác định loại dự án cần ước lượng. Do đó, việc xác định số lượng FPs có thể là việc xác định số lượng FPs của một dự án hoàn toàn mới (Development Project FP Count), số lượng FPs của việc nâng cấp một dự án (Enhancement Project FP Count) hoặc đơn giản chỉ là đánh giá lại một dự án hoàn thành (Application FP Count).
Step 2: Xác định đường biên (boundary) của ứng dụng
– Ứng dụng mà bạn đang xây dựng là ứng dụng độc lập (standalone) hay chỉ là một phần trong một gói (suite) ứng dụng. Nghĩa là nguồn cung cấp dữ liệu để ứng dụng của bạn hoạt động là “nguồn tự cung tự cấp” hay là từ một ứng dụng nào đó. Chẳng hạn như khi một trường đại học muốn gửi thông báo về kết quả của một sinh viên cho gia đình của sinh viên đó, thì nó “hệ thống quản lý điểm thi” phải lấy dữ liệu (tức là thông tin liên lạc của sinh viên đó) từ hệ thống “quản lý sinh viên”.
– Việc xác định đường biên của ứng dụng là rất quan trọng, nó ảnh hưởng trực tiếp lên độ phức tạp của ứng dụng, bởi vì việc phát triển một ứng dụng standalone bao giờ cũng đơn giản hơn các ứng dụng trong các “gói” ứng dụng. “Tiền của tui tui xài!”, dĩ nhiên là cảm thấy “thoải mái” hơn là sử dụng tiền của người khác vì bạn không bị phụ thuộc, và rõ ràng những thay đổi xảy ra đối với cá nhân khác không làm ảnh hưởng lớn đến “việc xài” của bạn. Nó cũng tương tự như trong một dự án, sự trì trệ tại một khâu, một giai đoạn nào đó trong chu trình phát triển sẽ ảnh hưởng lên toàn bộ chu trình. Hay như việc phát triển các phần mềm quản lý nhân viên, quản lý tiền lương riêng lẻ bao giờ cũng đơn giản hơn là việc phát triển một gói giải pháp ERP cho doanh nghiệp rồi! Dĩ nhiên ưu điểm của ERP là tài nguyên được sử dụng hiệu quả hơn song đó cũng chính là vấn đề của nó, làm thế nào để sử dụng hiệu quả nguồn tài nguyên đó!
– Giả sử chúng ta cần xây dựng một ứng dụng “đơn giản” nhằm quản lý điểm cho sinh viên, đồng thời khi có yêu cầu, ứng dụng sẽ in ra kết quả thi và gửi đến gia đình sinh viên đó. Chúng ta giả định rằng, không hề có một ràng buộc nào về một học kỳ phải học những môn học nào, đơn giản, chúng ta có một danh sách các sinh viên, danh sách các môn học và chi tiết điểm của sinh viên cho tất cả các môn học đó (không giống như thực tế lắm vì nếu có một số môn chưa học thì kết quả bằng “zero”… nhưng giả định để cho đơn giản mà).
– Như vậy về mặt CSDL ta sẽ có như sau
- SinhVien(MaSV, HoTen, MaLop)
- MonHoc(MaMH, TenMH, SoTinChi)
- KetQua(MaSV, MaMH, Diem)
– Một lưu ý là thông tin chi tiết của một SinhVien có thể truy xuất từ hệ thống quản lý SinhVien với CSDL như sau (đã lược bỏ một số thông tin)
- SinhVien(MaSV, HoTen, NgaySinh, DiaChiNha, PhuongXa, QuanHuyen, TinhThanhPho)
Như vậy bạn có thể xác định được boundary của ứng dụng của bạn như sau
Step 3a: Xác định FP thô (UFP)
Độ phức tạp của ứng dụng phụ thuộc vào hai yếu tố, đó là mức độ phức tạp của dữ liệu (data) và mức độ phức tạp của việc xử lý (transaction). Do đó, việc xác định UFP là công việc xác định số FPs của dữ liệu (Data Function Points)và số FPs của xử lý (Transaction Function Point).
Data FPs thể hiện khía cạnh dữ liệu trong các chức năng cung cấp cho khách hàng. Nó đặc trưng bởi hai yếu tố ILF (Internal Logical File) và EIF (External Interface File). Việc xác định ILF hay EIF cần được thực hiện trước khi tiến hành chuẩn hóa (normalize) dữ liệu.
– Một ILF là một nhóm các dữ liệu được lưu trữ và bảo trì trong phạm vi hệ thống (bên trong boundary). Thông thường nó là một bảng (table) trong cơ sở dữ liệu của ứng dụng.
– Một EIF cũng là một nhóm dữ liệu nhưng được lưu trữ và bảo trì bởi một ứng dụng khác (bên ngoài boundary). Dĩ nhiên, một EIF này có thể là một ILF của một ứng dụng khác. Thông thường EIF được cung cấp thông qua các services. Chẳng hạn như các services chứng khoán, bảng ngoại tệ, thời tiết…
Transaction FPs thể hiện khía cạnh xử lý của ứng dụng trong các chức năng cung cấp cho khách hàng. Nó đặc trưng bởi ba yếu tố EI (External Inputs), EO (External Outputs), External InQuiry (EQ).
– Một EI là một tiến trình căn bản (element process) trong đó dữ liệu được truyền từ bên ngoài vào bên trong của boundary. Thông thường EI là các thao tác thêm, xóa, cập nhập dữ liệu trong cơ sở dữ liệu
– Một EO là một tiến trình căn bản (element process) trong đó dữ liệu phát sinh (derived data) được truyền từ bên trong ra bên ngoài boundary. Dữ liệu phát sinh đó thường là các dữ liệu được kết hợp với nhau bằng các công thức tính toán như SUM, AVERAGE… Dĩ nhiên, các dữ liệu phát sinh này không xuất hiện trong các ILF hay IEF. Thông thường các EO là bảng báo cáo (reports), các thông báo hay dữ liệu gửi tới các ứng dụng khác.
– Một EQ là một tiến trình căn bản (element process) có hai chiều nhập dữ liệu (input) và xuất dữ liệu (output) nhằm truy xuất dữ liệu từ một hay nhiều ILF/EIF. Trong đó dữ liệu nhập (input) không làm thay đổi dữ liệu của ILF/EIF và dữ liệu xuất không chứa các dòng dữ liệu phát sinh (derived data). Thông thường, EQ là các thao tác tìm kiếm, truy vấn dữ liệu từ các ILF/EIF.
Lưu ý: Tiến trình căn bản (element process) là một xử lý đơn vị đối với người dùng (có nghĩa với họ). Ví dụ, người dùng yêu cầu chức năng thêm một sinh viên với mô tả là một sinh viên có mã số sinh viên, họ tên sinh viên… thì tiến trình căn bản chính là “thêm một sinh viên” chứ không phải là thêm một họ tên, mã số sinh viên…
Cách tính UFP
- Xác định độ phức tạp cho các ILF và EIF: Gồm việc xác định số lượng ILF và độ phức tạp (Complexity) của mỗi ILF thông qua việc xác định số lượng RETs và DET
- Xác định số lượng ILF.
- Xác định độ phức tạp của mỗi ILF bằng cách tính số lượng DETs (Data Element Type) và số lượng RETs (Record Element Type). Trong đó, DETs là các cột (field) dữ liệu, còn RETs là nhóm các cột dữ liệu (có quan hệ phụ thuộc vào nhau, được cập nhập cùng nhau). Để xác định các RETs, thông thường người ta sử dụng phương pháp chuẩn hóa cơ sở dữ liệu.
- Từ độ phức tạp tính được số FP tương ứng.
Ma trận ưu tiên - Xác định độ phức tạp cho các EI: Căn cứ vào số lượng FTR (File Types Referenced) và DET (Data Element Types) để quyết định độ phức tạp của mỗi EI.
- Xác định các EI có trong dự án.
- Tính FTRs và DET cho mỗi EI. Trong đó, mỗi FTR phải là một ILF hoặc một IEF mà EI đó tương tác. Còn DET là mỗi dòng dữ liệu nhập (Data Input Field), thông báo lỗi(error message), thông báo xác nhận (confirm message), buttons, mỗi nhóm radio buttons, check boxes, listbox…
- Mỗi DATA INPUT FIELD được tính là 1 DET
- Tất cả các ERROR MESSAGE được tính là 1 DET
- Tất cả các CONFIRM MESSAGE được tính là 1 DET
- Mỗi BUTTON được tính là một DET.
- Mỗi RADIO BUTTON GROUP được tính là 1 DET
- Mỗi CHECK BOX được tính là 1 DET
- Mõi LISTBOX, DROP-DOWNLIST… được tính là 1 DET
- Xác định độ phức tạp cho các EO: Hoàn toàn tương tự như cách xác định FP cho EI.
- Xác định các EO có trong dự án.
- Tính FTRs và DETs cho mỗi EI để suy ra độ phức tạp và số lượng FPs tương ứng. Trong đó số lượng DET được xác định như sau:
- Mỗi cột dữ liệu đọc được từ ILF, EIF được tính là 1 DET.
- Mỗi dữ liệu phát sinh (derived data) được tính là 1 DET.
- Các error message được tính là 1 DET.
- Các Confirm message được tính là 1 DET.
- KHÔNG TÍNH tiêu đề (heading) của cột, ngày tháng ngày lập báo cáo. Chỉ tính ngày tháng là một DET nếu nó là dữ liệu có ý nghĩa trong kinh doanh (như lập hóa đơn, ngày đăng ký…
- Xác định độ phức tạp cho các EI: Như đã biết, mỗi EI là một tiến trình xử lý gồm hai chiều (thể hiểu như gồm EI và EO). Do đó số lượng FTRs và DETs cuối cùng là sự kết hợp giữa FTRs và DÉTs phía EI và EO. Điều này có nghĩa là nếu cả phía EI và EO cùng sử dụng một FTR thì FTR đó chỉ được tính là MỘT. Tương tự như đối với DET.
Sau khi xác định được độ phức tạp của ta sẽ tính được số lượng FP tương ứng với mỗi EI, EQ, EO.
Cuối cùng ta tính được UFP dựa vào bảng sau. Tạm thời ta chỉ quan tâm tới Total Number of Unadjusted Function Points (Trong bài viết sau sẽ trình bày cách tính Value Adjustment Factor và Total Adjusted Function Points)
