Functional Point Analysis (cont) – II

Trước khi bắt đầu mình sẽ giới thiệu lại quy trình tính toán FP như sau:

1. 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ó)
2. Xác định phạm vi của dự án.
3. Xác định số lượng Function Points thô (Unadjusted Function Points)
4. Xác định hệ số cân đối (Value Adjusted Factors).
5. 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 Inquiries (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

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

   

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

     

3. 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ý…
       

       

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