#function point

Project estimation is a quantitative assessment of the total amount of different variables including resources, duration and costs. The types of estimating techniques can be classified as –

Analogous or high level technique

Parametric or calculative technique

Bottom-up or detailed technique that includes all the ground level functions.

There are multiple project estimation techniques that are used by different organizations to analyse various projects. Some of the common techniques are:

Pure expert judgement

Historical data

Wideband Delphi

Source line of code

Use case point

Monte Carlo

Function point

Test case points

Function test points

Out of the above-listed techniques, function point analysis (FPA) is one of the most used in various project estimations.

What is the concept of function point?

The function count measures the functionality from user’s side and depends totally upon incoming and outgoing sources from user’s end. The basis of comparison is accounted by its available quantitative measure and organizational data. FPA has its principle decomposed into functional units. It essentially measures functionality that a user requests or receives and the 5 functional units incorporated into it are-

EI – It’s information entering the system

EO – It’s data which passes the boundary

EI – These are requests for having prompt access to info

ILF – It’s information residing within the system’s boundary

ELF – It’s the data stored in another system which is used only for reference purposes.

Function Point Analysis or FPA covers one very critical and difficult area of project planning that is size estimation. Users often face difficulty in establishing measuring units according to size of the system. Two of the most common methods by which one can do the evaluation are -

Function count

Lines of code

These 5 components can once again be sub-divided into two broadly divisible categories -

1.      Transactional function types

External Inquiry (EQ)

External Output (EO)

External Input (EI)

2.      Data functional types

EIF or External Interface Files

ILF or Internal Logical Files

A sneak peek into the history of function point:

Function Point was developed by Alan Albrecht in 1970s specifically for size estimation while working for IBM. It gained huge recognition as an ideal solution to the problem of size measurement. Function point is also regarded as the best system for measuring size of computer software.

Few of its special features are as follows:

Function point is free of any language tool or methodology used for implementation.

It can be estimated from requirements specification or design specification; hence, the estimation of the development effort in the initial stages.

Function point can directly connect with the necessary statements that can again easily be followed by re-estimate.

It is dependent on the external view of the system by the consumer. Even a non-technical user of the system software can have a better understanding of the function point estimation for measuring.

Ở Nhật đợt vừa rồi đc nghỉ tết Tây nên N ngồi học/nghiên cứu phương pháp estimation này để xem lợi hại của nó thế nào, sau khi nghiên cứu xong nên muốn viết 1 bài chia sẻ cho anh em. Hi vọng giúp ích cho anh em PM trong việc estimation

Vì cái phương pháp này nói có mà cả ngày nên N sẽ cố gắng viết ngắn gọn và tóm tắt nhất có thể (hi vọng dễ hiểu T-T). Còn slide thì mọi người có thể tham khảo slide trên fsoft insight (~130 slide, chỉ dành cho người làm fsoft :D) + search thêm trên google.

Bài viết này không nhắm đến việc so sánh với các phương pháp estimation khác. Quy cho cùng estimation cũng chỉ là estimation không thể đúng chính xác 100% và mỗi phương pháp đều có 1 điểm mạnh/yếu riêng của mình.

----

Khái quát

Như tên gọi, phương pháp Function Point (FP) cơ bản dựa vào việc đánh điểm/trọng số cho các chức năng của phần mềm để từ đó ra được số FP cuối cùng rồi convert ra con số MM dựa trên 1 số parameter như ngôn ngữ gì, fulllife cycle hay 1 phần công đoạn.

Kỹ thuật quan trọng nhất của FP chính là phải biết ĐẾM ILF, EIF, DET, RET, EI, EO, EQ, FTR (giải thích bên dưới),. Đếm có 2 đối tượng cần được đếm là Data và Transaction. Nói đơn giản data tương ứng với table/item trong DB, còn transaction là các hành động/event hay các chức năng chính của phần mềm (như thêm, xóa sửa, hiển thị,...) Đếm data: có 2 loại data

ILF: data nội bộ application dùng để read/write. Thường là table/file.

EIF: data ngoại bộ của application, chủ yếu dùng để refer/read-only. Thường là table/file.

Mỗi loại data sẽ có 2 khái niệm con

DET: là các item của table mà người dùng có thể HIỂU ĐƯỢC (ví dụ item trên màn hình, ko phải item kiểu ẩn, mang tính kỹ thuật).

RET: tương ứng với record, hiểu đơn giản là cha của DET. RET được phân loại làm 2 loại chính là Optional và Mandatory. Ví dụ: khi đăng ký acc trên web có 2 loại người dùng là: có request nhận tin thì item bắt buộc là email và không request nhận tin thì email là optional. Ví dụ này, RET này là Optional và có RET = 2. 1 ví dụ khác, khi xuất data thì có 2 loại data là plain text và HTML, với plain text thì item bắt buộc có 1 cái là encoding, với HTML thì item bắt buộc có 2 cái là encoding và HMTL version. Kiểu này là RET mandatory  có số RET = 2. trường hợp không có phân group gì cả thì cứ đếm RET=1

Đếm transaction: có 3 loại transaction

EI: là transaction có sử dụng các file/table nội bộ. Có xử lý tính toán. Phục vụ cho xử lý bên trong.

EO: là các transaction có tham chiếu file/table. Mục đích để export thông tin ra. Có xử lý tính toán trước khi export ra.

EQ: là các transaction có tham chiếu file/table. Không có xử lý tính toán. Mục đích để export thông tin ra. (ví dụ chỉ select từ DB ra)

Mỗi loại transaction lại có 2 khái niệm con là FTR và DET.

FTR: là EIF or ILF mà transaction tương ứng có sử dụng/tham chiếu

DET: các item/field được sử dụng/tham chiếu trong transaction. Nói đơn giản là input/output/trigger của transaction đó. (ví dụ checkbox, event, textbox, listbox,...)

---

Dựa vào 1 template có sẵn (FSOFT có), chỉ cần count xong các item đã mô tả ở trên ta sẽ ra con số UFP tức Unadjusted Function Point). Sau đó tiếp tục trả lời 14 câu hỏi về đặc điểm của phần mềm được phát triển để tính toán ra 1 hệ số VAF.  

Cuối cùng ta sẽ có Final FP = UFP * VAF.

Cách tính toán thế nào mọi người không cần quan tâm lắm vì trong excel đã hỗ trợ hết (file excel chỉ dành cho người làm fsoft  :D)

---

Vậy pp FP này phù hợp cho những style dự án nào?

PP này phù hợp cho các dự án đặc thù về nghiệp vụ doanh nghiệp. Không phù hợp cho các dự án mang nặng tính cá nhân/kỹ thuật/nghệ thuật hay phải tốn thời gian điều tra/nghiên cứu.

--- Sau khi lấy dự án TRA mới làm xong ra  estimate thử để kiểm chứng thì N thấy cũng khá ổn. Nhưng thực sự để ra con số ổn này cũng đã phải tự mình nghiền ngẩm "đếm" đi đếm lại nhiều lần vs so sánh với con số MM thực tế của dự án để hiểu đuợc mình đếm "sai" or "chưa phù hợp" chỗ nào.

Cá nhân N nghĩ, estimation theo pp FP khó nhất là vụ đếm, nếu mình đếm sai, không đúng thì sẽ ra lệch rất nhiều + nếu có quá nhiều data/table kiểu "quá đơn giản" thì FP cũng sẽ bị đội lên rất nhiều.

PP này phù hợp khi mình đã mường tượng ra 1 mức nào đó ở Basic Design sẽ gồm những table gì, item gì.Việc phân tách hóa quá nặng về hướng kỹ thuật như chia tách bảng để tối ưu,v.v... cũng không dc khuyến khích vì đó là thuộc công đoạn sau và end-user không hiểu nó là gì và cũng sẽ gây đội FP lên khá cao.

-- Tỉ lệ các công đoạn theo %MM (copy trên mạng)

Basic Design 20%

Detail Design 30%

Coding+UT 30%

CT1 8%

CT2 6%

ST 6%

1 số dự án thì mình dùng tỉ lệ khác như bên dưới

Requirement/Define specs+basic design:  25%

Detail Design 15%

Coding+UT 35%

IT: 20%

ST 5%

--

FP/MM theo 1 số ngôn ngữ phổ biết

(năng suất trung bình của thế giới thì phải, không rõ scope)

Java: 16

ASP.NET:19.34722

C:11

C++:16

C#:16.20831

VB:19.06237

PHP:16

Python:16

--

Update ngày 2021/07/04

Thật sự bất ngờ vì không nghĩ bài viết này của mình được nhiều người tham khảo thế, ngay cả trong công ty cũng rất nhiều bạn đã search ra bài viết này và hỏi mình nhiều câu hỏi. Sẵn dạo gần đây mình cũng đang phải est 1 số dự án bằng function point cho khách nên sẵn update thêm một số thông tin mình nghĩ là có ích cho mọi người.

Khó khăn khi đếm FTRs, 

EIF: mỗi lần đụng vào 1 table cứ đếm +1 FTR

ILF: mỗi lần đụng vào 1 table cứ đếm +1 FTR

Với EO thì chỉ count EIF, ILF 1 lần duy nhất (không cộng vào cho nhiều lần gọi, ví dụ select nhiều lần)

Với EQ thì count input và ouput độc lập (cho dù có trùng nhau)

Khó khăn không biết đếm RETs thế nào, hình minh họa bên dưới là chân kinh, ai lười thì cứ đếm chính table đang đếm là 1 + số table mà nó refer tới bằng khóa ngoại, cách đếm nhanh này cũng cho độ chính xác tầm 80%, số DETS thì là số columns của bảng

Năng suất trung bình FP/MM mình post phía trên là không hợp lý với thực tế (mình đoán số đó không phải full life cycle), số full life cycle thị trường Mỹ tầm 10 (search 1 bài post trong công ty có info này),  thị trường Nhật thì mình nghĩ tầm 7-8 thôi , dạo này hot trend low code thì năng suất low code outsystem tầm 14. Anh em VN est thì cứ ghi tầm 10-12 chắc ổn (tùy ngôn ngữ) (tùy công ty, quốc gia thì số khác nhau nha)

Dự án migration thường nên est theo số LOC nhưng nếu bị khách yêu cầu est theo FP thì cũng không vấn đề, vẫn đề nằm ở chỗ tỉ lệ các công đoạn. Ví dụ migration 1:1 thì bạn không phải viết requirement viết specs hay thậm chí base design nên % là 0, giai đoạn test UT, IT, ST thì vì là test compare nên create test case là 1 nhưng excute là x2 nên cần phải tính lại % tương ứng. Ví dụ CT 20% cho dev mới thì migration có thể là 32% (=20%*60%*2+ 20% *40%, giả sử  tỉ lệ create là 40%, test là 60%). Vì vậy số % tổng có thể bé hay lớn hơn 100% của final FP tính ra. Lưu ý nữa làm migration thì năng suất phải cao hơn code mới là điều hiển nhiên nhé.

Khi est FP việc trả lời list câu hỏi GSC để tính điểm là tối quan trọng để tính toán độ phức tạp của hệ thống từ đó sẽ có thay đổi trong số FP final rất lớn. Do đó hãy nhớ đọc hiểu và trả lời thật kỹ và chính xác list 14 câu hỏi này.

Nốt luôn các công thức cho mọi người

AFP = UFP * VAF

UFP＝FPs of ILF/EIF＋FPs of EI/EO/EQ

VAF = (TDI * 0.01) + 0.65

ILF, ELF, EI, EO,  EQ point table thì bà con google nhé

Một số checklist khi est bằng FPT

Không đếm duplication (ví dụ: màn hình khởi tạo search all + màn hình search là 1 or tái sử dụng >80%, chức năng export ra csv tái sử dụng phần lớn logic chức năng search,...)

Không đếm double (dễ nhầm, ví dụ màn hình cha có hyperlink, click vào ra màn hình con, màn hình cha coi chừng đếm double)

Cân nhắc tính tái sử dụng, common (layout, same function,...) để loại bỏ FP cho các chức năng trùng.

Các chức năng quản lý DB master thường rất dễ, cần hạ FP thấp nhất, nếu không số lượng nhiều sẽ đội số FP rất lớn

Đảm bảo mỗi loại transaction (EI/EO/EQ) của mỗi chức năng (1 chức năng con của màn hình) chỉ có duy nhất 1 xử lý

Verify thật kỹ các chức năng có FP >10 (vì khi breakdown ra đến level function như thêm xóa sửa thì chỉ trường hợp cực khó FP mới đội >10)

Khi count data ILF cho loại file, chỉ nên count cho các chức năng nghiệp vụ để xử lý data nghiệp vụ và liên kết file giữa các chức năng.

How Software Can Improve with Automated Software Analysis and Measurement: IV Edition CIO Conference, a Productive Morning

On May 13th, a group of IT executives highlighted the importance of these software analysis and measurement in order to maintain software quality standards and to uphold a healthy and efficient relationship with business stakeholders and application service providers..

(more…)

Summary of the 2015 International Function Point User Group Conference (IFPUG) & International Software Measurement & Analysis Conference (ISMA10)

From SNAP to Automated Function Points – Creating Value from Measurement

Infographic from “Enabling Enterprise Productivity Measurement by Combining Manual and Automated Functional Sizing”

CAST sponsored the 2015 International Software Measurement & Analysis Conference(ISMA10) held in Charlotte, on April 30th.  This conference, hosted by the International Function Point User Group (IFPUG), brings…

Function Point Counting Unleashes Business Innovation (Infographic)

In this post, we wanted to take a step back and break down exactly what a function point is and how an IT organization can use them to measure application development productivity, improve IT project planning and estimating, and better manage application service providers. (more…)

Businesses Gain Value Perspective Through Software Analytics

You’d be hard pressed to find any organization that isn’t using measurement — either for marketing, sales, social media, and countless other ways. In fact, a recent report from IDC predicts that by 2017, 80% of the CIO’s time will be focused on analytics, cybersecurity, and creating new revenue streams through digital services.

So why is it that, with such a clear understanding of the value of…

The Best Software Analysis and Measurement Engine Just Got Better

In this era of big data, analytics has become an invaluable tool for IT organizations to succeed. Not only for ensuring a high quality product, but also keeping your customers safe from malicious hackers and application crashes. Despite the obvious need, some executives struggle with the business case for proper software analytics and opt for skunk-work metrics that are less accurate and more…