Một số kỹ thuật ước lượng dự án và đánh giá phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ






TRẦN KHÁNH DUNG




MỘT SỐ KỸ THUẬT ƯỚC LƯỢNG DỰ ÁN
VÀ ĐÁNH GIÁ PHẦN MỀM





LUẬN VĂN THẠC SĨ




NGƯỜI HƯỚNG DẪN KHOA HỌC
PGS.TS:ĐẶNG VĂN ĐỨC

Hà Nội - 2007



2



MỤC LỤC
MỞ ĐẦU 5
CHƢƠNG 1. TỔNG QUAN VỀ ƢỚC LƢỢNG DỰ ÁN PHẦN MỀM VÀ
ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM 7
1.1 Ƣớc lƣợng dự án phần mềm 7
1.1.1 Ƣớc lƣợng kích cỡ (LOC & FP) 9
1.1.2 Ƣớc lƣợng công sức 12
1.1.3 Ƣớc lƣợng về tài nguyên 14
1.2 Đánh giá chất lƣợng phần mềm 16
1.2.1 Các nhân tố chất lƣợng phần mềm 16
1.2.2 Đánh giá thông qua tính đúng đắn 19
1.2.3 Đánh giá thông qua tần suất bảo trì 19
1.2.4 Đánh giá thông qua tính toàn vẹn 20
1.2.5 Đánh giá dựa trên khả năng tiếp cận ngƣời dùng 20
CHƢƠNG 2. KỸ THUẬT ƢỚC LƢỢNG DỰ ÁN PHẦN MỀM 21
2.1 Phƣơng pháp Function Points 21
2.1.1 Giới thiệu 21

2.1.2 Tính hay ƣớc tính 23
2.1.3 Mô hình điểm chức năng 23
2.1.4. Các bƣớc thực hiện 29
2.1.5 Thí dụ áp dụng phƣơng pháp Function Points 36
2.2 Phƣơng pháp Use Case Points 37
2.2.1 Giới thiệu về phƣơng pháp UCP 37
2.2.2 Vai trò của biểu đồ Use Case trong ƣớc lƣợng phần mềm 38
2.2.3 Các bƣớc thực hiện với phƣơng pháp ƣớc lƣợng UCP 40
2.2.4 Thí dụ áp dụng phƣơng pháp UCP 45
2.3. Các mô hình ƣớc lƣợng dự án phần mềm 47
2.3.1 Tổng quan về các mô hình ƣớc lƣợng kinh nghiệm 47
2.3.2 Mô hình ƣớc lƣợng COCOMO (Contructive Cost Model) 48
2.3.3 Mô hình ƣớc lƣợng Putnam 87
2.4 Công cụ ƣớc lƣợng tự động 89
CHƢƠNG 3. KỸ THUẬT ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM
92
3.1 Độ đo chất lƣợng phần mềm 92
3.2 Khoa học phần mềm của HALSTEAD 93
3.3 Đo độ phức tạp của Thomas McCabe 95
3.4 Độ tin cậy phần mềm 96
3.5 Cách tiếp cận bảo đảm chất lƣợng phần mềm 97
CHƢƠNG 4. PHÁT TRIỂN CHƢƠNG TRÌNH ỨNG DỤNG 100
4.1 Mục tiêu 100

3


4.2 Tóm lược cơ sở khoa học 100
4.2.1 Các bước tính Function Points trong chương trình 100
4.2.2 Các bước tính Use Case Points trong chương trình 104

4.3 Cài đặt 105
KẾT LUẬN 108
TÀI LIỆU THAM KHẢO 109
PHỤ LỤC 110


4


DANH MỤC CÁC KÝ HIỆU THUẬT NGỮ VIẾT TẮT

COCOMO
Contructive Cost Model
FP
Function Points
KSLOC
Thousand of Source Line Of Code
LOC
Line Of Code
PM
Person-Month
IFPUG
Internatinal Function Point Users Group
FPA
Function Point Analysis
EI
External Input
EO
External Output
EQ

External Query
EF
Environmental Factor
ILF
Internal Logical File
ELF
External Logical File
SLOC
Source Line Of Code
SQA
Software Quality Assurance
SPR
Hiệu suất phần mềm
SMPEEM
Mô hình đánh giá nỗ lực dự án bảo trì phần mềm
SMI
Chỉ số chín muồi phần mềm
TCF
Technical Complex Factor
UUCP
Unadjusted Use Case Point
UAW
Unadjusted Actors Weight
UCP
Use Case Points
UUCPW
Unadjusted Use Case Point Weight
UFP
Unadjusted Function Points
VAF

Value Adjustment Factor
WBS
Work Breakdown Structure







5


MỞ ĐẦU

Mặc dù việc nghiên cứu về các chủ đề này đã được quan tâm nhiều trên thế
giới, nhưng ở Việt Nam các nghiên cứu và ứng dụng chỉ mới ở bước đầu. Thực vậy,
nhu cầu ước lượng tốt dự án phần mềm để tránh rủi ro là vấn đề bức xúc của các
công ty sản xuất phần mềm, tổ chức thực hiện dự án phần mềm. Việc định giá cho
phần mềm cũng vậy, cần có sự đánh giá chính xác dựa trên chất lượng thực tế của
phần mềm.

Tiến trình quản lý dự án kỹ nghệ phần mềm bắt đầu với một tập các hoạt
động gọi chung là lập kế hoạch dự án. Hoạt động đầu tiên trong những hoạt động
này là ước lượng. Người lập kế hoạch dự án phần mềm phải ước lượng ba điều
trước khi một dự án bắt đầu: dự án kéo dài bao lâu, cần bao nhiêu nỗ lực và bao
nhiêu người cần tham gia. Bên cạnh đó, người lập kế hoạch phải dự kiến các tài
nguyên (phần cứng và phần mềm) sẽ cần tới và rủi ro trong dự án. Như vậy, khi một
dự án phần mềm được lập kế hoạch, cần phải đưa ra những ước lượng về công sức
con người cần có, thời hạn dự án theo ngày tháng và chi phí của dự án. Những việc

này được tiến hành như thế nào? Trong nhiều trường hợp ước lượng được thực hiện
bằng cách dùng kinh nghiệm qúa khứ xem như hướng dẫn duy nhất. Nếu một dự án
mới rất giống về kích cỡ và chức năng với một dự án quá khứ thì rất có thể dự án
mới sẽ đòi hỏi xấp xỉ khối lượng công sức, mất một khoảng thời gian, chi phí như
dự án cũ. Nhưng điều gì sẽ xảy ra nếu dự án mở ra một “miền đất mới”. Khi đó chỉ
riêng kinh nghiệm quá khứ có thể không đủ. [4]
Ngày nay, phần mềm là yếu tố tốn kém nhất trong nhiều hệ thống dựa trên
máy tính. Lỗi lầm ước lượng chi phí lớn có thể tạo ra sự chênh lệch giữa lợi nhuận
và thất thoát. Việc bội chi có thể là thảm hoạ cho người phát triển.
Để giải quyết vấn đề trên, đã có rất nhiều kỹ thuật ước lượng được nghiên
cứu và ứng dụng rộng rãi trong ngành công nghiệp phần mềm. Mặt khác, để ước
lượng dự án được chính xác, đòi hỏi phải dùng ít nhất hai trong các kỹ thuật để
kiểm tra chéo. Bằng cách so sánh và điều tiết các ước lượng được suy ra khi dùng
các kỹ thuật khác nhau, người lập kế hoạch có thể suy ra một ước lượng chính xác.
Việc ước lượng dự án phần mềm không phải là một khoa học chính xác, nhưng tổ
hợp các dữ liệu lịch sử tốt kết hợp với việc sử dụng các kỹ thuật ước lượng có thể
cải thiện độ chính xác của ước lượng.
Vấn đề “nóng” thứ hai đang được quan tâm là đánh giá phần mềm, vì đây là
cơ sở chính xác để đưa ra giá thành của phần mềm cũng như để phân biệt các tổ
chức sản xuất phần mềm cạnh tranh trên một sản phẩm cùng loại. Khác với việc

6


ước lượng dự án phần mềm (được tiến hành trong khoảng thời gian giới hạn lúc bắt
đầu dự án phần mềm, và được cập nhật đều đặn trong tiến trình dự án) việc đánh giá
phần mềm được tiến hành khi phần mềm đã được mã hoá và được cập nhật sau một
thời hạn nhất định khi phần mềm được đưa vào sử dụng. Để đánh giá phần mềm,
một tập các kỹ thuật cũng được phát triển và ý nghĩa hơn, từ những nghiên cứu về
chất lượng cũng như cách đánh giá nó, quy trình đảm bảo chất lượng cho phần mềm

đã được xây dựng.
Mục đích của luận văn này không nằm ngoài việc nghiên cứu đầy đủ các kỹ
thuật ước lượng phổ biến, các cách đánh giá chất lượng phần mềm hiện có và xây
dựng một công cụ ước lượng tự động có thể áp dụng trong thực tế. Nội dung luận
văn chia thành ba phần, phần đầu (chương 1) đưa ra tổng quan về ước lượng dự án
phần mềm và đánh giá chất lượng phần mềm trong quản lý dự án phần mềm, trên cơ
sở đó, phần hai (chương 2 và 3) đi sâu vào các kỹ thuật ước lượng và kỹ thuật đánh
giá cụ thể, phần cuối cùng (chương 4) dựa trên những nghiên cứu thu được, phát
triển một công cụ ước lượng tự động dùng để ước lượng công sức và ngày công cho
dự án phần mềm.
/
.

7


CHƢƠNG 1. TỔNG QUAN VỀ ƢỚC LƢỢNG DỰ ÁN PHẦN
MỀM VÀ ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM
1.1 Ước lượng dự án phần mềm
[4] Trong những ngày đầu của tin học, chi phí phần mềm bao gồm một phần
trăm nhỏ của toàn bộ chi phí cho hệ thống dựa trên máy tính. Một lỗi lầm lớn trong
ước lượng chi phí phần mềm có thể tương đối ít ảnh hưởng. Ngày nay, phần mềm là
yếu tố tốn kém nhất trong nhiều hệ thống dựa trên máy tính. Lỗi lầm ước lượng chi
phí lớn có thể tạo ra sự chênh lệch giữa lợi nhuận và thất thoát. Việc bội chi phí có
thể là thảm hoạ cho người phát triển. Ước lượng chi phí và công sức phần mềm
chắc chắn không là một khoa học chính xác. Có quá nhiều tham biến (con người, kỹ
thuật, môi trường, chính trị ) có thể ảnh hưởng tới chi phí chung cuộc của phần
mềm và công sức cần để phát triển nó. Để đạt được các ước lượng chi phí và công
sức tin cậy, một số tuỳ chọn nảy sinh:
 Trì hoãn việc ước lượng tới giai đoạn sau của dự án

(hiển nhiên chúng ta có thể đạt được ước lượng chính
xác 100% khi dự án đã hoàn tât);
 Dùng các kỹ thuật phân rã để sinh ra ước lượng về chi
phí và công sức dự án;
 Phát triển mô hình kinh nghiệm cho chi phí và công
sức làm phần mềm;
 Thu được từ một hay nhiều công cụ ƣớc lƣợng tự
động.
Tuỳ chọn đầu tiên mặc dầu rất „hấp dẫn‟ nhưng lại không thực tế. Các ước
lượng chi phí phải đưa ra ngay từ đầu. Tuy vậy đợi càng lâu thì chúng ta biết càng
nhiều, và biết càng nhiều thì càng ít có khả năng phạm lỗi lầm trong ước lượng.
Ba tuỳ chọn còn lại là những cách tiếp cận có thể đứng được tương đối đối
với ước lượng dự án phần mềm. Một cách lý tưởng, các kỹ thuật được lưu ý cho
từng tuỳ chọn nên được áp dụng nối tiếp nhau, mỗi tuỳ chọn được dùng như một
phép kiểm tra chéo cho tuỳ chọn khác. Các kỹ thuật phân rã lấy quan điểm „chia để
trị‟ cho việc ước lượng dự án phần mềm. Bằng cách phân rã một dự án thành các
chức năng chính và các nhiệm vụ kỹ nghệ phần mềm có liên quan, việc ước lượng
chi phí và nỗ lực có thể được thực hiện theo kiểu từng bước. Các mô hình ước
lượng theo kinh nghiệm có thể được dùng để bổ sung cho các kỹ thuật phân rã và
đưa ra một cách tiếp cận ước lượng tiềm năng có giá trị theo đúng nghĩa của nó.
Một mô hình dựa trên kinh nghiệm (dữ liệu lịch sử) có dạng:

8


d = f(v
i
)
d: là một trong một số các giá trị ước lượng (như công sức, chi phí, thời hạn
dự án )

v
i
: các tham biến độc lập được chọn lựa (LOC hoặc FP được ước lượng)
Có các công cụ ước lượng tự động cài đặt cho một hay nhiều kỹ thuật phân rã
(hay mô hình kinh nghiệm). Khi được tổ hợp với một giao diện người-máy tương
tác, các công cụ tự động hoá đưa ra một tuỳ chọn cho việc ước lượng. Trong một hệ
thống như vậy, các đặc trưng của tổ chức phát triển (như kinh nghiệm, môi
trường…) và phần mềm cần phát triển sẽ được mô tả. Các ước lượng chi phí và nỗ
lực được suy ra từ dữ liệu này. [4]
Một dự án khi được thực hiện hoặc lập kế hoạch sẽ cần phải đánh giá được
độ lớn của nó, các tài nguyên cần thiết, lịch thực hiện và các cột mốc quan trọng
như: gửi tài liệu, bắt đầu kiểm thử, bàn giao Thông thường thì giá thành và lịch
trình thực hiện của một dự án thường mang tính rủi ro nhất do không được đánh giá
đúng mức. Một số trong các những lý do đó là:
 Giá thành và lịch trình thường được quyết định trước bởi các đối tượng ngoài
dự án như: khách hàng, chủ đầu tư…;
 Công việc phân tích thiết kế không phải bao giờ cũng bao quát hết các trường
hợp, tình huống, các yêu cầu chưa được hiểu hết, hiểu đúng;
 Thường thì khách hàng không hiểu được việc phát triển phần mềm là một
công việc có tính công nghệ cao với giá thành cao.
Quy trình ước lượng chi phí phần mềm dưới đây mô tả các bước cần thiết
cho việc bắt đầu đánh giá một vòng đời phần mềm và sau đó là theo dõi, tinh chỉnh
những đánh giá xuyên suốt thời gian thực hiện dự án. Thiết lập quy trình này càng
sớm sẽ giúp cho việc đánh giá được chính xác hơn, tin cậy hơn, từ đó có thể xác định
rõ ràng các nhân tố liên quan tới giá thành của dự án. Quy trình này cũng đồng thời
cung cấp các phương pháp cho dự án cách thức quản lý các rủi ro liên quan tới chi
phí và lịch trình dự án.
Quy trình ước lượng là một quá trình liên tục, được thực hiện không ngừng
trong thời gian thực hiện dự án. Các hoạt động của nó bao gồm:
1. Ước lượng kích cỡ;

2. Ước lượng chi phí và các nỗ lực;
3. Ước lượng lịch trình;
4. Ước lượng các tài nguyên máy tính;

9


5. Đánh giá rủi ro;
6. Kiểm tra / xác nhận;
7. Theo dõi và báo cáo về tiến độ;
8. Đánh giá và cải tiến quy trình.
Các hoạt động ước lượng kích cỡ, nỗ lực và chi phí cần được thực hiện trước
khi xây dựng vì thứ tự trên là bắt buộc trong tất cả các mô hình tính toán giá thành.
Tuy nhiên việc xây dựng lịch trình thường được bắt đầu thực hiện trước khi hoàn
thành tất cả công việc xác định các nỗ lực. Ngoài ra, việc sớm thiết lập bảng cấu
trúc phân việc (Work Breakdown Structure - WBS) giúp việc phân chia các nỗ lực
ra các phần việc độc lập mà có thể lập lịch hoặc xét mức độ ưu tiên xem thực hiện
phần việc nào trước.

1.1.1 Ƣớc lƣợng kích cỡ (LOC & FP)
Kích cỡ của phần mềm thường được đánh giá bằng đại lượng số lượng dòng
mã (Source Lines of Code - SLOC) hoặc số nghìn dòng mã (Thousands of Source

Ước lượng kích cỡ

Ước lượng nỗ lực/chi phí

Ước lượng lịch trình

Ước lượng hệ thống máy tính

Quản lý rủi ro

Kiểm tra/xác thực

Theo dõi, báo cáo về dự án

Đánh giá và cải tiến quy trình
(ít nhất 2 người cùng tham gia xây dựng )
Cơ sở dữ liệu các dự
án đã ước lượng
Yêu cầu
(lặp lại định kỳ)
(dùng ít nhất là 2

kỹ thuật )
(dùng ít nhất là 2
kỹ thuật )
(dùng ít nhất là 2
kỹ thuật )
Hình 1. Quy trình ước lượng dự án phần mềm

10


Lines of Code - KSLOC). Phần mềm thường được phát triển theo cách viết mới
hoàn toàn hoặc dùng một hay nhiều module có sẵn, do vậy việc ước lượng các đoạn
mã đã có cũng cần được quan tâm như việc ước lượng các đoạn mã mới cần viết
thêm. Việc tích hợp các module sẵn có và có vẻ đơn giản nhưng thực sự thì các nỗ
lực dành cho nó cũng không kém so với việc phát triển mới từ đầu. Kích cỡ cũng có
thể được đánh giá qua đơn vị điểm chức năng (Function Points). Các điểm chức
năng được đánh giá dựa trên chức năng của phần mềm và thường được áp dụng
trong pha tìm hiểu yêu cầu. Dòng mã (LOC – Line Of Code) và điểm chức năng
(FP – Function Point) là những dữ liệu cơ sở để từ đó tính ra độ đo hiệu năng. Dữ
liệu LOC và FP được dùng theo hai cách trong việc ước lượng dự án phần mềm
như:
(1) Các biến ước lượng được dùng để lấy “kích cỡ” cho từng phần tử phần
mềm.
(2) Độ đo vạch ranh giới được thu thập từ những dự án quá khứ và được dùng
chung với các biến ước lượng để xây dựng các dự tính chi phí và công sức.
Ước lượng LOC và FP là các kỹ thuật ước lượng phân biệt, nhưng cả hai đều
có một số đặc trưng chung. Người lập dự án bắt đầu với một tuyên bố về phạm vi
phần mềm, từ đó, dự định phân rã phần mềm thành các chức năng nhỏ hơn có thể
được áp dụng riêng biệt. LOC và FP sẽ được ước lượng cho từng chức năng con đó.
Độ đo tính hiệu năng vạch ranh giới (như LOC/người-tháng hay FP/người-tháng)

sau đó được áp dụng cho biến ước lượng thích hợp và ước lượng về chi phí và công
sức từ đó được suy dẫn ra. Các ước lượng chức năng con được tổ hợp lại để tạo ra
một thiết kế ước lượng tổng thể cho toàn bộ dự án.
Các ước lượng kỹ thuật LOC và FP khác nhau ở mức độ chi tiết cần cho việc
phân rã. Khi LOC được dùng như biến ước lượng thì việc phân rã chức năng thường
được thực hiện cho các mức chi tiết đáng kể. Vì dữ liệu cần cho việc ước lượng
điểm chức năng ở mức vĩ mô hơn, nên mức độ phân rã được dùng khi FP là biến
ước lượng sẽ ít chi tiết hơn. Cũng cần lưu ý rằng LOC được ước lượng trực tiếp
trong khi FP được xác định gián tiếp bằng cách ước lượng số cái vào, cái ra, tệp dữ
liệu, câu hỏi, và giao diện ngoài kèm theo 14 giá trị điều chỉnh độ phức tạp sau:
F
i
:
1. Hệ thống có đòi hỏi sao lưu và phục hồi không?
2. Có đòi hỏi trao đổi dữ liệu không?
3. Có chức năng xử lý phân tán không?

11


4. Có đòi hỏi cao về làm việc tốt không?
5. Hệ thống có chạy trong môi trường hiện có mà nặng về vận hành tiện ích
không?
6. Hệ thống có đòi hỏi việc vào dữ liệu trực tuyến không?
7. Việc vào dữ liệu trực tuyến có đòi hỏi phải xây dựng thao tác đưa vào thông
qua nhiều màn hình thao tác không?
8. Tệp chính có phải cập nhật trực tuyến không?
9. Cái vào, cái ra, tệp, truy vấn có phức tạp không?
10. Xử lý bên trong có phức tạp không?
11. Mã chương trình có được thiết kế để dùng lại không?

12. Việc chuyển đổi và cài đặt có được đưa vào trong thiết kế không?
13. Hệ thống có được thiết kế cho nhiều cài đặt trong các tổ chức khác nhau
không?
14. Liệu ứng dụng có được thiết kế để làm thuận tiện cho việc thay đổi và dễ
dàng cho người dùng không?
Bất kể là biến ước lượng nào được dùng, người lập kế hoạch dự án về cơ bản
phải đưa ra một phạm vi các giá trị cho từng chức năng đã phân rã. Bằng cách dùng
dữ liệu lịch sử hay trực giác, người lập kế hoạch ước lượng một giá trị LOC hay FP
lạc quan, có thể nhất và bi quan cho từng chức năng.
Giá trị kỳ vọng cho LOC hay FP sau đó được tính. Giá trị kỳ vọng cho biến
ước lượng, E, có thể được tính như trung bình trọng số của ước lượng LOC hay FP
lạc quan (a), có thể nhất (m) và bi quan (b).
Ví dụ:
E=
6
4 bma 

cho niềm tin đối với ước lượng có thể nhất và tiếp đó là phân bố xác suất beta.
Giả sử rằng có một xác suất rất nhỏ là kết quả của LOC hay FP thực tại sẽ ra
ngoài các giá trị và bi quan. Bằng cách áp dụng các kỹ thuật thống kê chuẩn chúng

12


ta có thể tính độ lệch của ước lượng, tuy nhiên, độ lệch dựa trên một dữ liệu không
chắc chắn (ước lượng) phải được dùng một cách thận trọng.
Một khi giá trị kỳ vọng của biến ước lượng đã được xác định thì ta áp dụng dữ
liệu hiệu năng LOC và FP. Tại giai đoạn này, người lập kế hoạch áp dụng một trong
hai cách tiếp cận khác nhau:
1. Giá trị biến ước lượng toàn bộ cho tất cả các chức năng con có thể được nhân

lên với độ đo hiệu năng trung bình tương ứng với biến ước lượng đó. Chẳng
hạn, nếu ta giả sử rằng đã ước lượng 310 FP về tổng số và hiệu năng trung
bình FP dựa trên các dự án quá khứ 5.5 FP/người-tháng thì tổng công sức
cho dự án sẽ là:
Công sức =
5.5
310
= 56 người-tháng
2. Giá trị biến ước lượng cho từng chức năng con có thể được nhân lên với giá
trị hiệu năng được điều chỉnh dựa trên một mức độ nhận biết được về độ
phức tạp của các chức năng con. Đối với các chức năng có độ phức tạp
trung bình người ta dùng độ đo hiệu năng trung bình. Tuy nhiên nó được
điều chỉnh lên hay xuống dựa trên việc cao hơn hay thấp hơn độ phức tạp
trung bình đối với chức năng con đăc biệt. Ví dụ, nếu độ phức tạp trung bình
là 490 LOC/người-tháng, chức năng con phức tạp hơn đáng kể so với độ
trung bình đó, có thể phản ánh một hiệu năng được ước lượng chỉ vào cỡ
300 LOC/người-tháng và chức năng đơn giản là 650 LOC/người-tháng.
Các ước lượng này có đúng không? Câu trả lời duy nhất cho câu hỏi này là:
Chúng ta không thể chắc chắn được. Mọi kỹ thuật ước lượng, dù phức tạp đến đâu
cũng phải được kiểm tra chéo bằng các tiếp cận khác. [4]
1.1.2 Ƣớc lƣợng công sức
Ước lượng công sức là kỹ thuật thông thường nhất cho việc xác định chi phí
cho bất kỳ dự án phát triển công nghệ nào. Số người – tháng, tháng hay năm được
áp dụng cho giải pháp của từng nhiệm vụ dự án. Chi phí được gắn với từng đơn vị
công sức và suy ra được chi phí ước lượng.

13


Giống như kỹ thuật LOC và FP, ước lượng công sức bắt đầu với việc phác hoạ

các chức năng phần mềm thu được từ phạm vi dự án. Một loạt các nhiệm vụ kỹ
nghệ phần mềm - phân tích yêu cầu, thiết kế, mã hoá và kiểm thử - phải thực hiện
cho từng chức năng.
Hình 2. Phát triển ma trận công sức - chức năng


Người lập kế hoạch ước lượng công sức (người - tháng) sẽ cần để hoàn thành
từng nhiệm vụ kỹ nghệ phần mềm cho từng chức năng phần mềm. Những dữ liệu
này chứa trong ma trận trung tâm của bảng. Tỷ lệ lao động (chi phí/đơn vị công
sức) được áp dụng cho từng nhiệm vụ kỹ nghệ phần mềm. Rất có thể là tỷ lệ lao
động sẽ thay đổi với mỗi nhiệm vụ. Nhân viên cấp cao tham gia nhiều vào nhiệm vụ
phân tích yêu cầu và thiết kế; nhân viên tập sự (thường lương thấp) tham gia vào
các nhiệm vụ thiết kế về sau, mã hoá và kiểm thử.
Chi phí và công sức cho từng chức năng và nhiệm vụ kỹ nghệ phần mềm được
tính vào bước cuối. Nếu ước lượng công sức được thực hiện độc lập với ước lượng
LOC và FP thì bây giờ có hai ước lượng cho chi phí và công sức để so sánh và củng
cố. Nếu cả hai tập các ước lượng này biểu lộ sự phù hợp hợp lý với nhau thì có lý
Chức
năng
Tổng cộng
Tổng cộng
Tỷ lệ $
Giá thành $
Nhiệm vụ
Ước lượng theo người -
tháng

14

do vững chắc để tin rằng các ước lượng là tin cậy. Mặt khác, nếu các kết quả của
hai kỹ thuật phân rã này không chỉ ra sự phù hợp thì phải nghiên cứu thêm và phải
tiến hành phân tích.
Điều gì xảy ra khi thiếu sự phù hợp giữa các ước lượng? Việc trả lời câu hỏi
yêu cầu phải đánh giá lại thông tin đã dùng làm ước lượng. Những ước lượng khác
biệt lớn thường do hai nguyên nhân:
1. Phạm vi của dự án chức được người lập kế hoạch hiểu chưa thích đáng hoặc
bị hiểu sai.
2. Dữ liệu hiệu năng được dùng trong kỹ thuật dòng mã là không thích hợp đối
với ứng dụng hiện tại, đã lạc hậu hoặc đã bị hiểu sai.
Người lập kế hoạch phải xác định được nguyên nhân của sự phân tán và củng
cố lại ước lượng.
1.1.3 Ƣớc lƣợng về tài nguyên
Đầu tiên là việc ước lượng về tài nguyên. Hình 3. mô tả các tài nguyên cần
có cho nỗ lực phát triển phần mềm. Ở đáy là các công cụ - phần cứng và phần mềm
- phải có để hỗ trợ cho nỗ lực phát triển. Ở mức cao hơn tài nguyên chính là con
người - yếu tố bao giờ cũng cần tới. Mỗi tài nguyên đều được xác định với bốn
thuộc tính: mô tả tài nguyên, phát biểu về tính có sẵn, thời gian hạn định cần có tài
nguyên, thời hạn tài nguyên cần được sử dụng. Hai đặc trưng cuối có thể xem như
cửa sổ thời gian.
Hình 3. Tài nguyên
Tính sẵn có của tài nguyên đối với một cửa sổ phải được thiết lập ở giai đoạn
thực hành sớm nhất.

Công cụ phần
cứng, phần mềm
Người
Xác định:
- Kỹ năng cần
có

- Tính sẵn có
- Thời hạn
nhiệm vụ
- Ngày bắt đầu
Xác định:
- Mô tả
- Tính sẵn có
- Thời hạn
dùng
- Ngày bàn
giao

15


Tài nguyên con ngƣời
Người lập kế hoạch bắt đầu bằng việc ước lượng phạm vi và lựa chọn kỹ năng
cần để hoàn thành việc phát triển. Cả vị trí trong tổ chức (như người quản lý, kỹ sư
phần mềm cấp cao…) và tính chuyên môn (như viễn thông, cơ sở dữ liệu, bộ vi xử
lý) đều phải xác định rõ. Với những dự án tương đối nhỏ (1 người-năm hay ít hơn)
riêng một người có thể thực hiện tất cả các bước kỹ nghệ phần mềm, với việc tư vấn
các chuyên gia cần thiết. Số người cần cho dự án phần mềm có thể được xác định
chỉ sau khi đã xây dựng được ước lượng nỗ lực phát triển (như người-tháng hay
người-năm).
Tài nguyên phần cứng
Ngay từ đầu, chúng ta đã tham khảo tới phần cứng như là tiềm năng tính toán.
Bên trong vấn đề tài nguyên, phần cứng cũng là một công cụ cho việc phát triển
phần mềm. Có ba loại phần cứng cần phải được xem xét tới trong việc lập kế hoạch
dự án phần mềm: hệ thống phát triển, máy đích và các phần tử khác của hệ thống
mới.

Hệ thống phát triển (cũng được gọi là hệ thống chủ) là một máy tính và các thiết
bị ngoại vi có liên quan sẽ được dùng tới trong khi phát triển phần mềm. Chẳng hạn,
máy tính 32-bit có thể phục vụ như hệ thống phát triển cho một bộ vi xử lý 16-bit
máy đích – trên đó phần mềm cuối cùng sẽ được thực hiện. Hệ thống phát triển
được dùng bởi vì nó có thể hỗ trợ cho nhiều người dùng, duy trì khối lượng thông
tin lớn có thể dùng chung cho nhóm phát triển phần mềm, và hỗ trợ cho sự phân
loại phong phú về công cụ phần mềm. Vì phần lớn các tổ chức phát triển đều có
nhiều vị trí đòi hỏi thâm nhập vào hệ thống phát triển nên người lập kế hoạch phải
mô tả cẩn thận cửa sổ thời gian cần thiết và kiểm chứng rằng tài nguyên có sẵn.
Tài nguyên phần mềm

Như ta dùng phần cứng làm công cụ để xây dựng phần cứng mới, chúng ta
dùng phần mềm để hỗ trợ cho việc phát triển phần mềm mới. Bộ dịch hợp ngữ
nguyên thủy đã được viết trong ngôn ngữ máy và được dùng để phát triển nhiều
trình hợp dịch phức tạp. Xây dựng trên khả năng của các phần mềm phiên bản
trước, người phát triển cuối cùng được chuyển sang các trình biên dịch ngôn ngữ
cấp cao và các công cụ khác. Bất kỳ một thảo luận nào về tài nguyên phần mềm
cũng đều sẽ không đầy đủ nếu không thừa nhận về tính sử dụng lại - tức là việc tạo
ra và dùng lại các khối xây dựng phần mềm. Các khối xây dựng như vậy phải được
lên danh mục cho dễ tham khảo, phải được chuẩn hoá cho dễ ứng dụng và phải
được làm hợp lệ cho việc tích hợp dễ dàng. Các khối phần mềm sẽ có sẵn để cho
phép việc xây dựng các chương trình lớn với việc phát triển từ „tay trắng‟ ở mức tối
thiểu. Thư viện các phần mềm tái dụng đã có cho các ứng dụng thương mại, các hệ

16


thống và công việc thời gian thực, các vấn đề khoa học và công nghệ. Tuy nhiên,
còn ít có các kỹ thuật hệ thống để bổ sung cho một thư viện, các giao diện chuẩn
cho phần mềm dùng lại còn khó tăng cường, vấn đề chất lượng và bảo trì cần có còn

chưa được giải quyết, và điều cuối cùng, người phát triển thường không biết rằng
các khối xây dựng phần mềm đã có sẵn. Người lập kế hoạch phần mềm nên xem xét
tới hai quy tắc khi phần mềm dùng lại được xác định như một tài nguyên:
1. Nếu phần mềm hiện có đáp ứng được yêu cầu thì hãy dùng nó. Chí phí để có
được phần mềm hiện có gần như bao giờ cũng ít hơn chi phí để phát triển
một phần mềm tương đương.
2. Nếu phần mềm hiện có đòi hỏi phải có sửa đổi nào đó trước khi nó được tích
hợp đúng đắn với hệ thống thì hãy xử lý cho cẩn thận. Chí phí để sửa đổi
phần mềm hiện có đôi khi có thể còn lớn hơn chi phí phát triển phần mềm
tương đương.
Trong thực tế, các tài nguyên phần mềm lại thường hay bị bỏ qua trong khi lập kế
hoạch, chỉ trở thành mối quan tâm trong giai đoạn phát triển của tiến trình kỹ nghệ
phần mềm. Ta nên xác định yêu cầu tài nguyên phần mềm sớm, nhờ đó, việc đánh
giá kỹ thuật cho các phương án có thể được tiến hành và thu được đúng hạn.
1.2 Đánh giá chất lượng phần mềm
Đánh giá chất lượng phần mềm là một công việc khó khăn vì chất lượng phần
mềm phụ thuộc vào nhiều yếu tố kể từ khi bắt tay vào xây dựng một phần mềm cho
tới khi nó được bàn giao cho khách hàng và vẫn còn tiếp tục trong quá trình phần
mềm đó được sử dụng.
1.2.1 Các nhân tố chất lƣợng phần mềm
Các nhân tố chất lượng phần mềm được coi như những cái mốc để đánh giá
chất lượng phần mềm. Các nhân tố chất lượng phần mềm được mô tả sau đây hội tụ
vào ba khía cạnh quan trọng của sản phẩm phần mềm là: các đặc trưng vận hành,
khả năng trải qua thay đổi, và tính thích nghi với môi trường mới. Một sản phẩm
phần mềm cần được xét theo các tiêu chuẩn dưới đây.
Tính đúng đắn: Phần mềm thực hiện chính xác những mục tiêu và chức năng
đã đề xuất ở giai đoạn thiết kế. Tính đúng đắn của phần mềm được xác minh qua
những căn cứ sau:
1. Tính đúng đắn của thuật toán;
2. Tính tương đương của chương trình với thuật toán. Thuật toán có thể đúng

nhưng chương trình lập ra không tương đương với thuật toán nên dẫn đến
kết quả sai. Trong trường hợp này người ta nói rằng việc mã hoá bị sai;

17


3. Tính đúng đắn của chương trình có thể được chứng minh trực tiếp trong văn
bản của chương trình;
4. Tính đúng đắn của chương trình có thể được khẳng định dần dần qua việc
kiểm thử (testing), qua việc áp dụng chương trình trong một khoảng thời
gian đủ lớn trên một diện khá rộng với tần suất sử dụng cao;
5. Các tác giả của phần mềm cần cung cấp đầy đủ những luận chứng và kết
quả xác nhận tính đúng đắn của sản phẩm. Những tài liệu đó bao gồm:
Chương trình có kèm theo các luận đề phục vụ cho việc chứng minh, các
phương pháp và kỹ thuật kiểm thử chương trình, các kết quả chạy thử, các
giấy chứng nhận hay nhận xét của cá nhân đơn vị đã khảo sát và áp dụng
chương trình.
Tính khoa học: Tính khoa học của sản phẩm được thể hiện qua những mặt sau
1. Khoa học về cấu trúc: Bản thân phần mềm được chia thành những đơn vị
cân đối, không trùng lập nhau về chức năng, có quan hệ hữu cơ với nhau, có
thể tổ hợp thành nhiều chức năng mới. Bản thân thuật toán và chương trình
được thiết kế và cài đặt một cách có cấu trúc.
2. Khoa học về nội dung: Các thuật toán dựa trên thành tựu mới của toán học
và tin học phải có cơ sở chặt chẽ.
3. Khoa học về hình thức thao tác: Tên của các lệnh phải hợp lý, thể hiện tính
logic và phù hợp với tư duy tự nhiên của người dùng. Ví dụ: một hệ thống
biểu thị cả tiếng Anh, tiếng Việt lẫn lộn sẽ được xem là vi phạm tính khoa
học về hình thức. Trong trường hợp như vậy cách giải quyết tốt nhất là là
thiết kế hai chế độ giao tiếp một bằng tiếng Anh, một bằng tiếng Việt. Ví
dụ: Các thông báo lỗi phải rõ ràng và bao gồm các chú giải sau: lỗi số mấy,

nội dung lỗi, nơi xảy ra lỗi, cách giải quyết.
Tính hữu hiệu: Tính hữu hiệu của một sản phẩm được xác định qua những tiêu
chuẩn sau:
1. Hiệu quả kinh tế, ý nghĩa hoặc giá trị thu được do áp dụng sản phẩm đó;
2. Tốc độ xử lý của sản phẩm (v) tính bằng tỉ lệ giữa khối lượng đối tượng xử
lý (m) và tổng số đơn vị thời gian cần thiết để xử lý khối lượng trên (t):
v=m/t;
3. Giới hạn tối đa của sản phẩm hoặc miền xác định của chương trình được xác
định ua khối lượng tối đa của các đối tượng mà sản phẩm đó quản lý;
4. Dung lượng bộ nhớ mà tối đa trong RAM mà chương trình sử dụng;

18


Tính sáng tạo: Tính sáng tạo của sản phẩm phần mềm thể hiện qua các đặc
điểm sau:
1. Sản phẩm đó được thiết kế và cài đặt lần đầu tiên trên thế giới ;
2. Sản phẩm được sản xuất phục vụ cho những đặc thù riêng của Việt Nam. Ví
dụ: bộ xử lý văn bản tiếng Việt, bộ chương trình nhận dạng các loại men
gốm, hoa văn trang trí…;
3. Sản phẩm phần mềm có những điểm khác về mặt nguyên lý so với các sản
phẩm hiện hành;
4. Sản phẩm đó có những ưu thế nổi bật so với các sản phẩm cùng loại hiện
hành;
Tính an toàn: Sản phẩm trong trường hợp cần thiết có cơ chế bảo mật và
bảo vệ các đối tượng do nó phát sinh hay quản lý. Bản thân sản phẩm cũng cần
được đặt trong một cơ chế bảo mật nhằm chống sự sao chép trộm hoặc làm biến
dạng sản phẩm đó.
Tính toàn vẹn: Tính toàn vẹn của sản phẩm thể hiện qua những chức năng
sau:

1. Không gây ra nhập nhằng trong thao tác, đảm bảo tính nhất quán về cú pháp,
có cơ chế ngăn ngừa việc phát sinh ra những đối tượng sai quy cách hoặc
mâu thuẫn với các đối tượng có sẵn (dữ liệu, đơn thể…);
2. Có cơ chế khôi phục lại toàn bộ hoặc một phần những đối tượng thuộc diện
quản lý của sản phẩm trong trường hợp có sự cố như hỏng máy, mất điện đột
ngột…;
Tính đầy đủ: Tính đầy đủ của một sản phẩm được đánh giá thông qua tập
các chức năng mà sản phẩm đó cung cấp. Tập các chức năng cần và nên thoả
mãn các tính chất sau:
1. Tính đối xứng: Nếu có thao tác phát sinh thì nên có thao tác huỷ bỏ và ngược
lại. Ví dụ: Một hệ thống quản lý các bảng điện tử đã có thao tác thêm một số
cột vào bảng hiện có thì cần có thêm thao tác đối xứng là xoá một số cột từ
bảng hiện có;
2. Tính tiêu chuẩn: Sản phẩm phần mềm cần đạt được một số tiêu chuẩn tối
thiểu được thừa nhận trên thị trường thế giới hoặc trong khoa học. Ví dụ:
một hệ quản lý tệp cần có các chức năng tối thiểu sau: Tạo các tệp, Huỷ bỏ
các tệp, Sao chép các tệp, Tổ chức thư mục cho các tệp, Cập nhật dữ liệu vào
tệp, Quản lý được nhiều loại tệp (tệp văn bản, tệp chương trình, tệp dữ
liệu…), các lệnh thao tác tệp có thể hoạt động đơn lẻ nhưng cũng có thể
nhúng vào các ngôn ngữ lập trình cao cấp…

19


Tính độc lập: Sản phẩm phần mềm cần và nên đảm bảo tính độc lập với các
đối tượng sau:
1. Độc lập đối với thiết bị. Sản phẩm có thể cài đặt dễ dàng trên nhiều loại máy
và có thể quản lý được nhiều thiết bị đi kèm với máy. Những sửa đổi để thích
nghi là không đáng kể;
2. Độc lập với cấu trúc của đối tượng mà sản phẩm đó quản lý. Ví dụ: Một hệ

quản trị CSDL có tính độc lập cao sẽ không đòi hỏi người dùng phải viết lại
chương trình ứng dụng khi chuyển từ việc quản lý các tệp tuần tự sang các
tệp tuần chỉ và ngược lại;
3. Độc lập với nội dung của đối tượng mà sản phẩm đó quản lý. Ví dụ: đơn thể
COPPY có thể sao chép các tệp không phục thuộc gì vào nội dung cụ thể của
các tệp đó ra sao (rỗng hay không rỗng, lưu văn bản hay chương trình, lưu
mã nhị phân hay mã trung gian…).
Tính phổ dụng: Sản phẩm phần mềm có thể áp dụng cho nhiều lĩnh vực cho
nhiều chế độ làm việc khác nhau.
Tính đơn giản: Sản phẩm có tính đến những yếu tố tâm lý sau đây của đông
đảo người dùng:
- Dễ thao tác;
- Dễ học và dễ hoàn thiện;
- Ngôn ngữ trong sáng dễ hiểu, dễ nhớ (tên lệnh, thực đơn, thông báo, cú
pháp…)
Tính dễ phát triển, hoàn thiện: Sản phẩm có thể mở rộng, tăng cường về
mặt chức năng một cách dễ dàng. [4]
1.2.2 Đánh giá thông qua tính đúng đắn
Một chương trình phần mềm phải vận hành đúng nếu không nó sẽ ít giá trị
đối với người sử dụng. Tính đúng đắn là mức độ mà các phần mềm thực hiện được
chức năng được trông đợi ở nó. Cách đo thông dụng nhất cho tính đúng đắn là số
khiếm khuyết theo KLOC, với số khiếm khuyết được định nghĩa như việc thiếu tuân
thủ theo yêu cầu đã được kiểm chứng. Khiếm khuyết do người dùng báo cáo lại về
chương trình sau khi đã được xuất xưởng để dùng đại trà và được tính theo từng
thời kì chuẩn, điển hình là 1 năm.
1.2.3 Đánh giá thông qua tần suất bảo trì
Việc bảo trì phần mềm ngốn nhiều công sức hơn bất kì hoạt động kỹ nghệ
phần mềm nào khác. Tính bảo trì được thể hiện thông qua một số yếu tố chính:
- Có thể chỉnh sửa được nếu phát sinh lỗi trong quá trình sử dụng;

20


- Có thể thích nghi khi môi trường thay đổi;
- Có thể nâng cấp được do yêu cầu cụ thể đặt ra.
Tuy nhiên việc đo trực tiếp tính bảo trì là hoàn toàn không khả thi, do vậy
phải dùng một cách đo gián tiếp. Một khoảng thời gian trung bình được đề xuất cho
mỗi phần mềm. Khoảng thời gian này cần cho việc phân tích sự thay đổi yêu cầu,
thiết kế sửa đổi thích hợp, cài đặt sự thay đổi và kiểm thử nó.
1.2.4 Đánh giá thông qua tính toàn vẹn
Tính toàn vẹn của phần mềm được thể hiện bằng khả năng trụ được của nó
đối với sự tấn công (cả ngẫu nhiên lẫn có chủ định) vào sự an toàn của nó. Những
sự công kích có thể được tiến hành trên ba thành phần phần mềm:
- Chương trình;
- Dữ liệu;
- Tư liệu.
Để đo tính toàn vẹn của một phần mềm cần xác định hai thuộc tính phụ:
- Sự đe doạ: “Đe doạ là xác suất để cho việc công kích sẽ xuất hiện trong
thời gian đã nêu”;
- Độ an toàn: “Độ an toàn là xác suất rằng sự công kích sẽ bị đẩy lùi”.
Cả hai thuộc tính đã nêu ở trên có thể được ước lượng hay suy dẫn từ kinh
nghiệm
Ta có công thức về tính toàn vẹn như sau:
Tính toàn ven=

[ 1-đe doạ

(1-an toàn) ]
1.2.5 Đánh giá dựa trên khả năng tiếp cận ngƣời dùng
Sự thành công của một sản phẩm phần mềm phụ thuộc rất nhiều vào yếu tố

“thân thiện” đối với người sử dụng. Dù cho phần mềm được xây dựng với rất nhiều
tính năng có giá trị, tuy nhiên việc người dùng khó tiếp cận với phần mềm đó thì
hậu quả tất yếu là phần mềm đó sẽ thất bại. Tính “thân thiện”có thể được đo dưới
bốn dạng đặc trưng:
- Kĩ năng vật lý (và/hoặc trí tuệ để học hệ thống);
- Thời gian cần thiết để người dùng tiếp cận hiệu quả với hệ thống;
- Sự tăng lên rõ rệt về mặt hiệu năng (so với cách tiếp cận mà hệ thống thay
thế);
- Một xác nhận chủ quan (có thể thông qua bảng hỏi).
Bốn nhân tố ở trên chỉ là một cách lấy mẫu cho những điều đã được đề nghị
là cách đo cho chất lượng phần mềm.

21


CHƢƠNG 2. KỸ THUẬT ƢỚC LƢỢNG DỰ ÁN PHẦN MỀM

Phương pháp Function Points và Use Cases Points là hai phương pháp được
sử dụng rộng rãi nhất hiện nay để ước lượng nguồn lực cho việc phát triển một phần
mềm.
Function Point (FP) là phương pháp ước lượng được phát triển bởi Allan
Albrecht và được ban bố rộng rãi vào năm 1979, cung cấp độ đo được ứng dụng
chung và không phụ thuộc vào công nghệ được sử dụng cho việc phát triển phần
mềm. Function Point là một phương pháp chuẩn để tính kích thước phần mềm dựa
trên việc phân tích các chức năng mà phần mềm đó phải thực hiện.
Phương pháp Use Cases Points (UCP) là phương pháp do hãng Rational giới
thiệu, dùng để xác định kích thước một phần mềm đặc biệt là đối với phần mềm
dùng ngôn ngữ hướng đối tượng trong phân tích, thiết kế và xây dựng. Trên thực tế
có một mối quan hệ giữa các use case và code vì các use case phức tạp thường sẽ
tốn nhiều thời gian để code hơn. UCP dựa trên việc xác định độ phức tạp của các

Actor và các giao dịch trên mỗi Use Cases. Các điểm mà phương pháp UCP quan
tâm khi ước lượng kích thước phần mềm là:
 Số lượng và độ phức tạp của các Use case trong hệ thống;
 Số lượng và độ phức tạp của các Actor (thực hiện) trong hệ thống;
 Các yêu cầu non-functional khác như (ngôn ngữ lập trình, động lực của
nhóm phát triển,…);
 Môi trường để phát triển hệ thống (ngôn ngữ lập trình, động lực của nhóm
phát triển,…).
2.1 Phương pháp Function Points
2.1.1 Giới thiệu
[2] Mô hình điểm chức năng được ra đời vào năm 1979 tác giả Allan
Albrecht và năm 1984, Nhóm những người sử dụng điểm chức năng quốc tế
(Internatinal Function Point Users Group – IFPUG) đã đưa ra cách rõ ràng các quy
tắc, thiết lập các chuẩn cho việc sử dụng mô hình này. Phân tích điểm chức năng
(Function Point Analysis – FPA) cung cấp một phương pháp luận tiêu chuẩn cho
việc ước lượng các chức năng của ứng dụng phần mềm. FPA đo các chức năng từ
quan điểm của người sử dụng, dựa chính vào các yêu cầu của người dùng. Các điểm
chức năng đạt được bằng việc đo những ứng dụng phần mềm từ hai dạng sau :
 Kích cỡ của các yêu cầu chức năng, được tính bằng cách gán trọng số
cho mỗi chức năng đã rõ. Sau đó ta tính được đại lượng Điểm chức
năng chưa được hiệu chỉnh (Unadjusted Function Points – UFP) ;

22


 Tính đại lượng Nhân tố hiệu chỉnh giá trị (VAF – Value Adjustment
Factor), nhân tố này phản ánh đặc tính của hệ thống phần mềm đang
xây dựng chẳng hạn như độ phức tạp môi trường, độ phức tạp của ứng
dụng hay ta còn gọi là các yêu cầu phi chức năng.
Sự xuất hiện của kỹ thuật điểm chức năng đã cho phép cộng đồng công nghệ

tin học - viễn thông gia tăng đáng kể khả năng áp dụng phép đo phần mềm so với
việc sử dụng phương pháp dòng mã truyền thống. Nhưng việc tính điểm chức năng
đòi hỏi phải thực hiện một mức lập tài liệu mô tả hoàn thiện và chi tiết. Có ít nhất
hai tình huống mà trong đó phương pháp ước tính (một phương pháp tương thích
nhưng có thể thay thế cho các quy tắc tiêu chuẩn đối với điểm chức năng) có thể có
tính quyết định. Trường hợp đầu tiên xảy ra khi một dự án phát triển hoặc tăng
cường đang trong giai đoạn ban đầu mà đơn giản là không thể thực hiện phép tính
điểm chức năng theo các tiêu chuẩn IFPUG (tức là trong nghiên cứu khả thi).
Trường hợp thứ hai xảy ra khi cần ước tính tài sản phần mềm hiện có, nhưng không
có tài liệu hoặc thời gian cần thiết và nguồn lực để thực hiện phép tính điểm chức
năng chi tiết. Căn cứ trên những tình huống này và các tình huống tương tự, nhu cầu
về các phương pháp ước tính - không phải là tính - các điểm chức năng đã phát sinh
từ các tổ chức tham gia kinh doanh phần mềm. Tài liệu kỹ thuật đưa ra một số
phương pháp ước tính mà có thể được kiểm tra và so sánh. Vì vậy, phần này trình
bày các đặc điểm của một số phương pháp đáng chú ý (các điểm chức năng sớm,
các mô hình ILF đem lại kết quả trái ngược) và cả mô hình đánh giá so sánh chung
theo điểm chuẩn, hữu ích cho việc đánh giá các phương pháp bổ sung.
FP - điểm chức năng: là thước đo kiểu hàm được sử dụng rộng rãi nhất, thích
hợp cho việc xác định kính cỡ của ứng dụng phần mềm. Nó dựa trên năm hàm lôgic
có thể được người sử dụng xác định, chia thành hai kiểu hàm dữ liệu và ba kiểu hàm
giao dịch (bảng 1). Đối với một ứng dụng phần mềm đã cho, mỗi phần tử trong
bảng này sẽ được xác định kích thước và mức độ quan trọng, có tính đến các phần
tử đặc trưng của nó, ví dụ các tham chiếu tệp hoặc các trường lôgic. [2]


Thấp
Trung bình
Cao
ILF (Tệp lôgic nội bộ)
7

10
14
EIF (Tệp Lôgic bên ngoài)
5
7
10
EI (Đầu vào bên ngoài)
3
4
6
EO( Đầu ra bên ngoài)
4
5
7
EQ(Hỏi bên ngoài)
3
4
6
Bảng 1. Chỉ số độ phức tạp với số UFP tương ứng
Các số thu được (UFP - FP không điều chỉnh) được xếp vào các bộ hàm bổ
sung, thay đổi hoặc xoá và được kết hợp với hệ số điều chỉnh giá trị (VAF) để thu

23


được số cuối cùng của FP. Một công thức riêng cuối cùng được sử dụng cho từng
kiểu tính: ứng dụng, dự án phát triển hoặc dự án tăng cường.
2.1.2 Tính hay ƣớc tính
Nhìn chung, sự phân tích FP được coi là kỹ thuật xác định kích thước phần
mềm sớm và hiệu quả. Nhưng nếu xem xét các cách tính IFPUG tiêu chuẩn thì nó

ngụ ý bao hàm một bộ tài liệu mô tả đầy đủ và chi tiết về những yêu cầu hàm của
người sử dụng đối với ứng dụng bất cứ phần mềm cần được đo nào.
Có ít nhất hai tình huống mà trong đó phương pháp ước tính (một phương
pháp tương thích nhưng có thể thay thế cho các quy tắc tiêu chuẩn đối với FP) có
thể có tính quyết định. Trường hợp đầu tiên xảy ra khi một dự án phát triển hoặc
tăng cường ở trong giai đoạn ban đầu mà đơn giản là không thể thực hiện phép tính
FP theo các tiêu chuẩn IFPUG (tức là trong nghiên cứu khả thi). Trên thực tế, việc
tính tiêu chuẩn đòi hỏi phải xác định các phần tử, mà không phải luôn luôn có thể
được xác định khi bắt đầu dự án, nhưng đó là khi mà yêu cầu dự báo công sức, thời
gian và chi phí dựa trên sự ước tính kích thước chắc chắn sẽ lớn hơn so với vào lúc
kết thúc giai đoạn xác định đặc điểm chức năng. Trường hợp thứ hai xảy ra khi cần
ước tính tài sản phần mềm hiện có, nhưng không có tài liệu hoặc thời gian cần thiết
và nguồn lực để thực hiện phép tính FP chi tiết.(2.1.1)
Ngoài quá trình đo tiêu chuẩn một cách chính xác, mà nên luôn luôn thực
hiện khi có thể được, các phương pháp ước tính khác nhau đã được đề xuất để đáp
ứng nhu cầu đánh giá kích thước của dự án phần mềm càng sớm càng tốt hoặc với
việc sử dụng các nguồn lực càng ít càng tốt: "ước tính" có nghĩa là sử dụng ít thời
gian và công sức hơn để thu được giá trị xấp xỉ của FP. Những ưu điểm của kỹ thuật
ước tính rõ ràng là đối lập với độ chính xác nhỏ hơn không thể tránh khỏi khi khảo
sát các FP, nhưng khía cạnh này thường được bản thân những người sử dụng
phương pháp tự đánh giá.
Vì vậy, chúng ta cần luôn luôn phân biệt rõ giữa các thuật ngữ và khái niệm
khác nhau: "Tính FP", có nghĩa là đo kích thước phần mềm bằng cách sử dụng các
phương pháp IFPUG tiêu chuẩn như thông thường, trong khi đó "ước tính FP" có
nghĩa là đánh giá gần đúng cũng kích thước đó nhờ các phương tiện khác.
2.1.3 Mô hình điểm chức năng
Các Chức năng trong mô hình
Mô hình FP xác định 5 kiểu chức năng cơ sở để ước lượng quy mô của phần
mềm. Hai kiểu chức năng dữ liệu là các file logic trong (ILF) và các file giao diện
ngoài (EIF) và 3 kiểu chức năng giao tác còn lại là các dữ liệu đầu vào ngoài (EI),

dữ liệu đầu ra ngoài (EO) và các phần hỏi đáp ngoài (EQ).
Để lựa chọn mô hình FP, việc tính toán điểm chức năng của dự án duy trì và
tăng cường phần mềm gồm 3 thành phần chức năng: (l) chức năng ứng dụng nằm

24


trong phần yêu cầu đối với người sử dụng trong dự án; (2) chức năng chuyển đổi; và
(3) thừa số điều chỉnh giá trị (VAF).
Chức năng ứng dụng bao gồm các điểm chức năng được bổ sung, thay đổi và
xoá bởi dự án bảo trì. Chức năng chuyển đổi bao gồm các điểm chức năng được cấp
phát bởi một quá trình chuyển đổi. Thừa số điều chỉnh giá trị (VAF) dựa trên cơ sở
14 đặc tính trọng lượng. Mức độ ảnh hưởng nằm trong khoảng từ 0 đến 5, từ không
ảnh hưởng đến ảnh hưởng mạnh.
Công thức cho tính toán điểm chức năng dự án bảo trì và tăng cường phần
mềm được xác định như sau:
EFP = (ADD + CHG + CFP) x VAFa + (DEL x VAFb) (3.1)
Trong đó, EFP điểm chức năng dự án tăng cường phần mềm, bổ sung
(ADD), thay đổi (CHG), xoá bỏ (DEL).
Các điểm chức năng được tính toán như là chức năng ứng dụng và CFP có
nghĩa là điểm chức năng không được điều chỉnh được bổ sung bởi quá trình chuyển
đổi. VAFa và VAFb thừa số điều chỉnh giá trị của ứng dụng tuần tự sau và trước dự
án.
Các Counts điểm chức năng là một phép đo kích cỡ phần mềm ưu tiên phù
hợp hơn so với các dòng mã lệnh. Điểm chức năng hiện tại là kích cỡ chức năng đo
được sử dụng thường xuyên nhất và nó tiếp tục đạt được sự gắn kết trong trường hệ
thống thông tin quản lý và đã chứng tỏ thành công trong xây dựng các mô hình hiệu
suất và dự toán chi phí dự án.
Tuy nhiên, thừa số điều chỉnh giá trị (VAF) của mô hình này được giới thiệu
nguyên bản cho một dự án phát triển phần mềm mới.

Có một vài ví dụ về thừa số điều chỉnh giá trị (VAF) như là truyền đạt dữ
liệu, xử lý phân phối và thực thi, v.v Các thừa số này không thể áp dụng trong môi
trường bảo trì và không thể đo lường bằng cách nhìn khách quan. [2]

Các thừa số hiệu suất về việc duy trì phần mềm
Nhìn chung, các chi phí bảo trì khó dự toán, bởi các chi phí này liên quan
đến số lượng sản phẩm, quy trình và các thừa số tổ chức liên quan đến hiệu suất bảo
trì phần mềm.
Một vài mô hình không phân biệt các thừa số hiệu suất của việc bảo trì phần
mềm với các thừa số hiệu suất của phát triển phần mềm. Tuy nhiên, các thừa số hiệu
suất của bảo trì phần mềm khác với các thừa số hiệu suất của phát triển phần mềm.
Bộ phận điều khiển chi phí duy trì lớn gắn liền với kích cỡ, tuổi thọ và tính
phức tạp. Sommerville quả quyết rằng các thừa số hiệu suất liên quan đến môi
trường bảo trì phần mềm có thể bao hàm các đặc tính như là độc lập về module,
ngôn ngữ lập trình, kiểu lập trình
Trong năm 1985, từ những nghiên cứu về hiệu suất phần mềm (SPR) đã giới
thiệu một cách mới trong tính toán các điểm chức năng. Kỹ thuật nghiên cứu hiệu

25


suất phần mềm nhằm xử lý tính phức tạp là phải tách tính phức tạp tổng thể thành 3
phạm vi riêng biệt: Tính phức tạp thuộc về vấn đề, tính phức tạp mã và tính phức
tạp dữ liệu. Theo cách này, nỗ lực hoàn thiện các phép tính cũng có thể được giảm
xuống.
Các bảng câu hỏi trong quá trình nghiên cứu đã yêu cầu thu thập những
thông tin về các đặc tình môi trường gồm cả các ràng buộc về kỹ thuật (thời gian
đáp ứng, an ninh, số lượng người từ dụng, nền), dụng cụ và kỹ thuật bảo trì (phương
pháp luận phát hiện, các dụng cụ tình huống) và các thừa số liên quan đến nhân sự
(số lượng lập trình viên, kinh nghiệm). Trong các triển vọng của sản phẩm phần

mềm, quy mô của cả hiểu biết về phần mềm và kiểm tra giao điện module có thể
giảm xuống bởi kết cấu phần mềm tốt, bởi vì kết cấu dạng module và thứ bậc có thể
giảm được số lượng giao diện cần kiểm tra.
Vì vậy, các đặc tính khác nhau có ảnh hưởng đến hiệu năng phần mềm cần
phải được gạn lọc.

Mô hình đánh giá nỗ lực bảo trì dự án
Cách lựa chọn này diễn giải về mô hình đánh giá nỗ lực dự án bảo trì phần
mềm (SMPEEM). Sau khi giới thiệu phương pháp, quy trình tính toán và điều chỉnh
các điểm chức năng được giải thích. Cuối cùng, các điểm chức năng đã được điều
chỉnh được áp dụng trong đánh giá nỗ lực bảo trì phần mềm bằng cách sử dụng mô
hình SMPEEM.

Phƣơng pháp
Cơ cấu của SMPEEM của dựa trên nền tảng các khái niệm trình bày trong
hình 4. Trước tiên, để ước lượng quy mô của nhiệm vụ bảo trì, khái niệm của một
mô hình điểm chức năng được áp dụng. Thứ hai, để điều chỉnh điểm chức năng (FP)
liên quan đến môi trường bảo trì, chúng tôi cần giới thiệu khái niệm mới về thừa số
điều chỉnh giá trị (VAF). Các VAF của mô hình này liên quan đến các thuộc tính
của mỗi nhóm đặc tính như: Kỹ năng của kỹ sư, các đặc tính kỹ thuật và môi trường
bảo trì [2].






Hình 4. Khái niệm SMPEEM được đề xuất

Tính toán trỏ
chức năng
Điều chỉnh trỏ
chức năng
Đánh giá dự án
bảo trì
Không được điều chỉnh Điểm
chức năng
Được điều chỉnh
Điểm chức năng