Các đặc trưng cơ bản của các mô hình ứng dụng ước lượng chi phí phần mềm thông dụng nhất và nghiên cứu mô hình COCOMO II

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP
1. Mục đích nội dung của Đồ Án Tốt Nghiệp
Tìm hiểu về mô hình ước lượng chi phí COCOMO II, từ đó xây dựng ứng dụng để ước
lượng chi phí trong xây dựng và quản lý phần mềm.
2. Các nhiệm vụ cụ thể của Đồ Án Tốt Nghiệp
 Tìm hiểu chung về ước lượng chi phí phần mềm qua các kỹ thuật phổ biến.
 Nghiên cứu phương pháp luận của mô hình COCOMO II.
 Cài đặt các giải thuật ước lượng trong mô hình COCOMO II thành một ứng dụng
có thể áp dụng trong thực tế.
3. Lời cam đoan của sinh viên:
Tôi – Đoàn Hữu Hậu - cam kết Đồ Án Tốt Nghiệp là công trình nghiên cứu của bản
thân tôi dưới sự hướng dẫn của Thạc sỹ Bùi Thị Hòa.
Các kết quả nêu trong Đồ Án Tốt Nghiệp là trung thực, không phải là sao chép toàn
văn của bất kỳ công trình nào khác.
Hà Nội, ngày 20 tháng 5 năm 2008
Tác giả Đồ Án Tốt Nghiệp

Đoàn Hữu Hậu
4. Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho
phép bảo vệ:

Hà Nội, ngày tháng năm
Giáo viên hướng dẫn

Thạc Sỹ Bùi Thị Hòa


LỜI CẢM ƠN

Đầu tiên em xin bày tỏ lòng biết ơn sâu sắc đến cô Bùi Thị Hòa, người đã tận tình
hướng dẫn, chỉ bảo em hoàn thành đề tài này.

Em cũng xin chân thành cảm ơn các thầy, các cô trong khoa Công nghệ Thông tin,
cũng như các thầy, các cô trong bộ môn Công nghệ phần mềm đã tận tình giảng dạy
trang bị cho em những kiến thức cần thiết trong suốt quá trình học tập, cũng như đã tạo
điều kiện thuận lợi cho em thực hiện đề tài này.
Xin cảm ơn Công ty Việt Khánh JSC, Công ty Vĩnh Hưng JSC và công ty SunNet JSC
đã giúp đỡ, hỗ trợ tôi tiếp cận với công nghệ, với dữ liệu thực tế để có được những kinh
nghiệm quý báu áp dụng vào đề tài
Xin cảm ơn tất cả bạn bè đã nhiệt tình giúp đỡ tôi trong việc sưu tầm tài liệu tham
khảo, tư liệu thực tế, ứng dụng mẫu phục vụ cho đề tài.
Cuối cùng, con xin chân thành cảm ơn bố, mẹ và cả gia đình đã nuôi dạy, luôn tạo điều
kiện tốt nhất cho con học tập và luôn quan tâm, động viên, hỗ trợ cho con, đặc biệt là
trong thời gian thực hiện đề tài.

Hà nội, tháng 5 năm 2008

Người thực hiện
Đoàn Hữu Hậu


MỤC LỤC
PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP.........................................1
LỜI CẢM ƠN...................................................................................................2
MỤC LỤC.........................................................................................................3
LỜI GIỚI THIỆU..............................................................................................5
DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ...................................7
CHƯƠNG I: TỔNG QUAN VỀ.....................................................................15
ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM...........................................................15
I.Đối tượng ước lượng và các phương pháp xác định...........................15
1.Phương pháp 1: Hướng tiếp cận các độ đo câu hỏi mục tiêu............15
2.Phương pháp 2: Mô hình tạo quyết định............................................16

3.Phương pháp 3: Các độ đo các hệ số chuẩn........................................16
4.Phương pháp 4: Mở rộng GQM: Độ đo kỹ xảo..................................17
5. Đối tượng đo lường là một chức năng của thời gian.........................17
6.Tổng kết:.................................................................................................18
II.Các kỹ thuật ước lượng chi phí phần mềm........................................18
1.Các kỹ thuật dựa trên mô hình:...........................................................19
2.Các kỹ thuật dựa vào chuyên gia.........................................................26
3.Các kỹ thuật hướng học........................................................................28
4.Các kỹ thuật dựa vào động học............................................................30
5.Các kỹ thuật dựa vào hồi quy...............................................................32
6.Các kỹ thuật tổng hợp...........................................................................34
CHƯƠNG II: MÔ HÌNH COCOMO II..........................................................37
1.Tổng quan...............................................................................................37
2.Các biểu thức ước lượng trong mô hình COCOMO II......................37
3.Định kích cỡ phần mềm........................................................................38
4.Ước lượng công sức...............................................................................46
5.Các hệ số nhân công sức.......................................................................55
6.Ước lượng công sức cho các dự án nhiều thành phần........................66
7.Bảo trì phần mềm..................................................................................67


8.Tổng kết:.................................................................................................68
CHƯƠNG III: CHƯƠNG TRÌNH ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM –
ÁP DỤNG MÔ HÌNH COCOMO II...............................................................69
CHƯƠNG 4: TỔNG KẾT...............................................................................86
TÀI LIỆU THAM KHẢO...............................................................................87


LỜI GIỚI THIỆU
Cùng với sự phát triển mạnh mẽ và đa dạng, Công nghệ thông tin ngày càng

được ứng dụng rộng rãi vào hầu hết mọi ngành nghề và lĩnh vực khác nhau của đời
sống, và do đó góp phần nâng cao hiệu quả công việc nhiều lần. Do đó đề cập đến
Công nghệ thông tin là đề cập đến một vấn đề rất rộng lớn, bao gồm nhiều mảng ứng
dụng khác nhau. Tuy nhiên, trên thực tế, ngoài những công nghệ và các lý thuyết hỗ trợ
cho việc xây dựng, phát triển các phần mềm ứng dụng, vẫn chưa có nhiều nghiên cứu
về các khía cạnh khác không trực tiếp liên quan đến kỹ thuật như: vấn đề quản lý dự
án, đánh giá chất lượng sản phẩm.. và đặc biệt là vấn đề ước lượng chi phí phần mềm
mà từ đó có thể ước lượng đánh giá hiệu năng trong sản xuất phần mềm, tính kinh tế
của sản phẩm phần mềm cũng như góp thêm thông tin cho việc định giá phần mềm. Để
hoàn thiện thêm những kiến thức bổ trợ cho việc phát triển phần mềm trong tương lai,
em đã chọn đề tài: “Các đặc trưng cơ bản của các mô hình ứng dụng ước
lượng chi phí phần mềm thông dụng nhất và nghiên cứu mô hình
COCOMO II” để nghiên cứu. Đề tài nghiên cứu về các đặc trưng cơ bản của các mô
hình ứng dụng ước lượng chi phí phần mềm phổ dụng nhất. Từ những tìm hiểu chi tiết
về các mô hình này, chọn ra một mô hình tiêu biểu với những ưu điểm nổi bật để cài
đặt một mô hình ước lượng có tính ứng dụng. Mô hình đó là mô hình COCOMO II.
Trên thực tế, việc ước lượng chi phí phần mềm không hề đơn giản, đặc biệt là
đối với các dự án có quy mô lớn thì quy trình đánh giá càng khó khăn. Trước đây, khi
nhận thức chưa đầy đủ về việc ước lượng chi phí phần mềm, người ta thường tự đánh
giá chi phí phần mềm theo các mô hình riêng _ không có chuẩn mực chung. Tuy nhiên,
ngày nay, với nhận thức về tầm quan trọng của việc ước lượng chi phí phần mềm, hầu
hết các doanh nghiệp lớn đều sử dụng các mô hình tiêu chuẩn để đánh giá . Bởi lẽ: các
mô hình tiêu chuẩn đã được các nhà nghiên cứu hàng đầu trên thế giới nghiên cứu trên
các dự án của các công ty hàng đầu về công nghệ thông tin _ đây là kho dữ liệu khổng
lồ về các dự án tiền nhiệm, liên quan đến đủ mọi lình vực _ nên có được các tiêu chuẩn
đánh giá có độ chính xác cao, và có thể dễ dàng hiệu chỉnh cho phù hợp với môi trường
phát triển hiện tại. Hơn thế sử dụng các mô hình đánh giá tiêu chuẩn có thể dễ dàng
đánh giá được hiệu năng của phần mềm, cũng như có được sự so sánh khách quan hơn
giữa các phần mềm.
Trong việc ước lượng chi phí phần mềm, việc đầu tiên ta cần phải xác định

các đối tượng cần ước lượng _ đây là một trong các đặc trưng của phần mềm và dự án
phần mềm như: kích cỡ phần mềm, thời gian phát triển,… để từ đó xác định một hướng
tiếp cận phù hợp cho việc đánh giá.Với hướng tiếp cận đó ta sẽ xác định được mô hình
tiêu chuẩn để thực hiện đánh giá.
Trên thực tế, rất nhiều các mô hình ước lượng chi phí phần mềm đều dựa vào
phép đo kích cỡ vật lý của phần mềm, với hai phép đo phổ biến nhất là số dòng mã
lệnh SLOC (Source line of Code) và phép đo các điểm chức năng FP (Function Points).


Phép đo số dòng mã lệnh SLOC là một phép đo lâu đời nhất để đánh giá kết quả dự án,
và đồng thời cũng là cơ sở của rất nhiều mô hình đánh giá chi phí được phát triển sau
này như: mô hình quản lý vòng đời phần mềm SLIM của Putnam hay mô hình chi phí
xây dựng COCOMO của Boehm. Mặc dù việc đánh giá SLOC sớm và chính xác cao
trong vòng đời phát triển phần mềm không phải là đơn giản, và đòi hỏi kinh nghiệm,
nhưng phép đo SLOC vẫn được áp dụng khá phổ biến để xác định kích cỡ vật lý phần
mềm cho các mô hình ước lượng chi phi phần mềm. Một cải tiến trong phép đo kích cỡ
vật lý của phần mềm là đo theo các điểm chức năng FP được IBM giới thiệu vào những
năm 1979.
Hiện nay, hai phương pháp đo này cùng với các mô hình ước lượng chi phí
phần mềm dựa vào chúng được phổ biến và áp dụng rộng rãi. Tuy nhiên, theo khuyến
cáo của các nhà giới thiệu các mô hình, để có được một kết quả đánh giá khả quan, có
độ chính xác cao, thì mỗi tổ chức phát triển phần mềm đều cần có cách áp dụng và hiệu
chỉnh các tham số cho phù hợp với môi trường phát triển của mình, dựa theo kinh
nghiệm của các dự án tiền nhiệm (đã hoàn thành). Những nghiên cứu chi tiết các mô
hình tiêu chuẩn, và cách thức hiệu chỉnh để áp dụng chưa được chú trọng nhiều, đặc
biệt ở Việt Nam, cho nên hầu hết các đánh giá đều dựa theo các giá trị chuẩn của các
tham số, mà chưa có những sự điều chỉnh cần thiết cho phù hợp với thực tế. Vì vậy, đề
tài này mong muốn góp phần mở ra một sự quan tâm nghiên cứu chi tiết hơn nữa về
vấn đề ước lượng chi phí phần mềm, về các mô hình ước lượng chi phí được áp dụng
và sự ảnh hưởng của các tham số lên ước lượng cũng như vai trò của sự điều chỉnh các

tham số này trong việc nâng cao độ chính xác cho phép ước lượng, góp phần nâng cao
hiệu quả quản lý cũng như hiệu năng và tính kinh tế trong sản xuất phần mềm.


DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ
Viết tắt
A
AA

Viết đầy đủ

AAF

Adaptation
Adjustment Factor

AAM

Adaptation
Adjustment
Multiplier
Analyst Capability
Applications
Experience
Adapted Source
Lines of Code

ACAP
APEX
ASLOC

AT
ATPROD

B

BFC

Assessment
Assimialiton

Automated
Translation
Automated
Translation
Productivity
Ballpark

Base functional
Components
Bottom-up

C
CASE

CCB

Computer Adided
Softeware
Emgineering Case

study
Change Control
Board

Giải thích
Hệ số tuyến tính trong biểu thức tính nỗ lực
& Phần trăm công sức tái sử dụng dành cho việc
đánh giá và đồng bộ phần được tái sử dụng vào
hệ thống
Một thành phần của AAM (Adaptation
Adjustment Multiplier Hệ số nhân điều chỉnh để
thích ứng), phục vụ cho việc định cỡ, tái sử dụng,
bao gồm tác động của các nhân tố phải hiệu chỉnh
như thiết kế, mã nguồn và tích hợp (mô hình tái
sử dụng COCOMO)
Hệ số nhân điều chỉnh để thích ứng), phục vụ cho
việc định cỡ, tái sử dụng (mô hình tái sử dụng
COCOMO)
Hệ số chi phí “năng lực của người phân tích”
Hệ số chi phí “Kinh nghiệm phát triển ứng dụng”
Số dòng lệnh mã nguồn được tích hợp, được
dùng trong định cỡ tái sử dụng (mô hình tái sử
dụng trong COCOMO)
Dịch tự động
Năng suất dịch tự động

Phần cơ sở của hệ số mũ trong biểu thức tính nỗ
lực
Kỹ thuật ước lượng bằng cách đưa ra một dự
đoán xấp xỉ đúng trong một khoảng giới hạn

Các thành phần chức năng cơ bản
Phương pháp tiến hành từ các đơn vị nhỏ hoặc
các đơn vị chi tiết tới các đơn vị lớn hơn. Trong
một cấu trúc phân cấp.
Hệ số tuyến tính trong biểu thức tính thời gian
phát triển
Công nghệ học phần mềm với sự trợ giúp của
máy tính
Nghiên cứu dựa trên đối tượng và hoàn cảnh cụ
thể
Bảng theo dõi thay đổi trong quá trình phát triển


CDR
CMM

COCOMO

COTS
CPLZ
CSDL
CT
D
DATA
DBMS

DD
DET

DI

DM
DOCU

DSI
E
EAF
ED

EI

EIF

Critical Design
Review
Capability
Manarity Model
Constructive Cost
Model
Cost Driver
Comercial-OffThe-Shelf
Product
Compexity
Code & Unit Test

Xem xét lại bản thiết kế quan trọng, then chốt
Mô hình Thước đo Trưởng thành về năng lực của
Công ty (chủ yếu là dành cho phần mềm). Có các
mức từ thấp nhất là 1 đến cao nhất là 5
Mô hình định giá do Bochrn đưa ra năm 1981
Thuộc tính riêng của phát triển phần mềm, có tác

động nhân, làm tăng hoặc giảm lượng nỗ lực.
Phần mềm thương mại được đóng gói
Hệ số chi phí “Độ phức tạp của sản phẩm”
Cơ sở dữ liệu
Pha lập trình và kiểm thử đơn vị trong mô hình
thác nước
Phần cơ sở của hệ số mũ trong biểu thức tính thời
gian phát triển
Hệ số chi phí “Kích thước cơ sở dữ liệu”
Hệ quản trị cơ sở dữ liệu

Database Size
Database
Management
System
Detail Design
Pha thiết kế chi tiết trong mô hình thác nước
Data Element Type Kiểu trường dữ liệu được tham chiếu: Mỗi DET
là một trường duy nhất, không lặp lại mà người
dùng có thể nhận biết được.
Degree of
Mức độ ảnh hưởng
Influence
Percent Design
Phần trăm thiết kế chỉnh sửa trong tái sử dụng
Modified
(Mô hình tái sử dụng COCOMO)
Documenttation
Hệ số chi phí “Tài liệu phù hợp với yêu cầu của
Match to Lifecycle vòng đời phát triển phần mềm”

needs
Deliverable Soure Số lệnh mã nguồn bàn giao
Instrucstions
Hệ số mũ trong biểu thức tính thời gian phát triển
Effort Adjustment Tích của các hệ số nhân công sức
Factor
Early Design
Một cấp cao, được sử dụng trong COCOMO II để
phát hiện ra các khả năng thay thế về kiến trúc và
các chiến lược phát triển gia tăng
External Inputs
Nhập dữ liệu là một tiến trình cơ sở, trong đó dữ
liệu đi từ ngoài vào bên trong phạm vi của ứng
dụng
External Interface File giao tiếp ngoài – là một nhóm dữ liệu mà


Flie

EM

Effort Multiplier

EO

External Outputs

EQ

External InQuiry

ESLOC

Equivalen Source
Lines of Code

F
FCIL
FLEX
FP

FPA
FPC
FTR

Facilities
Development
Flexibility
Function Point

Function Point
Analysis
Function Point
Count
File Type
Referenced

FFP

Full Function

Point

FUR

Functionnal User
Requirement
General System
Charaterisrics
Graphical Interface
High
Intergrated
Computer Aided
Software
Engineering
International

GSC
GUI
H
ICASE

IFPUG

người dùng có thể nhận biết được, có liên hệ với
nhau về mặt lôgíc, chỉ được sử dụng để tham
chiếu
Hệ số nhân công sức – một giá trị gắn với từ hệ
số chi phí
Xuất dữ liệu là một tiến trình cơ sở, trong đó dữ
liệu nhận được chuyển trừ trong ra ngoài phạm vi

của ứng dụng
Truy vấn ngoài là một tiến trình cơ sở với cả hai
thành phần xuất và nhập dữ liệu, có kết quả là dữ
lliệu trả về từ một hoặc một vài file logic trong
(ILF) và File giao tiếp ngoài (ELF)
Số dòng mã nguồn tương đương
Hệ số mũ trong biểu thức tính thời gian phát triển
Hệ số chi phí “Các điều kiện thuận lợi”
Hệ số chi phí “Tính linh hoạt của phát triển”
Điểm chức năng, một đơn vị độ đo trong phần
mềm được xác định bằng cách đếm những chức
năng mà phần mềm cung cấp cho người dùng,
chủ yếu dựa trên thiết kế logic. Khái niệm “người
dùng” ở đây là để chỉ người hiểu về hệ thống từ
góc độ chức năng
Tên đầy đủ của phương pháp phân tích theo điểm
chức năng
Số đếm điểm chức năng
Kiểu File được tham chiếu – Một FTR là một
kiểu file được tham chiếu bởi một giao dịch và
phải là một ILF hoặc ELF
Điểm chức năng đầy đủ, một đo đặc biệt phù hợp
với các hệ thống nhúng và hệ thống thời gian
thực
Yêu cầu về chức năng của người sử dụng
Các đặc trưng chung của hệ thống
Giao diện đồ họa với người dùng
Cấp đọ đánh giá cao
Kỹ nghệ phần mềm được tích hợp với sự hỗ trợ
của máy tính

Một tổ chức phi lợi nhuận, họat động với mục


Function Pont
Users Group
ILF

Internal Logical
Files

IM

Integration
Modified

IN

Inception

IOC

IRR
IT
JAD

KASLOC

KDSI

KSLOC

L
LCA

LCO

đích thúc đẩy việc sử dụng phương pháp phân
tích điểm chức năng và các đọ đo phần mềm
khác.
Các file logic trong – một nhóm dữ liệu mà người
dùng có thể nhận biết được, có liên hệ với nhau
về mặt logic, nằm hoàn toàn trong phạm vi ứng
dụng và được duy trình bởi EL
Phần trăm của tích hợp và kiểm thử phải làm lại
trong quá trình tái sử dụng (mô hình tái sử dụng
trong COCOMO)

Pha khởi đầu, là pha thứ nhất trong quy trình
RUP
Initial Operatinal
Một cột mốc được sử dụng trong quy trình RUP,
Capability
xác định thời điểm đưa ra một sản phẩm có khả
năng vận hành
Inception Readines Một cột mốc trong quy trình RUP, là điều kiện để
Review
chuyển sang pha khởi đầu
Intergration & Test Pha tích hợp và kiểm thử trong mô hình thác
nước

Joint Application
Một phương pháp phân tích và thiết kế hệ thống
Development
được IBM giới thiệu năm 1977, tập trung vào
họat động cộng tác nhóm giữa người tiêu dùng và
kỹ thuật viên. Theo phương pháp này, từng nhóm
nhỏ tiến hành họp để quyết định về những mục
tiêu của hệ thống và các giao dịch nghiệp vụ cần
được hỗ trợ. Họ được điều hành bởi một người có
nhiệm vụ dẫn dắt quá trình tư duy của cả nhóm,
nhằm đi tới những mục tiêu rõ rang, đúng đắn.
Kết quả là đưa ra các mẫu thử của hệ thống/
Thousands of
Số nghìn dòng mã nguồn được tích hợp (Mô hình
Adapted Source
tái sử dụng trong COCOMO)
Lines of Code
Kolo Delivered
Số đếm hàng nghìn dòng mã lệnh đã bàn giao (ví
Source Instructions dụ mã nguồn có 15000 dòng lệnh, hệ số KDSI là
15)
Thousands (K) of
Số nghìn dòng lệnh mã nguồn
Source Lines of
Code
Low
Cấp độ đánh giá thấp
Life Cycle
Một cột mốc trong quy trình RUP
Architecture

review
Life Cycle
Một cột mốc trong quy trình RUP
Objectives review


LOC
LTEX
MAF

Line of Code
Language and Tool
Experince
Maintenance
Adjustment Factor

Só dòng lệnh của mã nguồn sản phẩm.
Hệ số chi phí “Kinh nghiệm sử dụng ngôn ngữ và
công cụ”
Hệ số điều chỉnh trong bảo trì, được sử dụng để
tính đến tác động của sự hiểu biết và tính không
quen thuộc đối với phần mềm (các mô hình tái sử
dụng và bảo trì trong COCOMO)
Kỹ nghệ phần mềm và kiến trúc hóa hệ thống dựa
trên mô hình, là một vận dụng nhỏ của mô hình
xoắn ốc, gồm các pha Khởi đầu (Inception), Phác
thảo (Elaboration), Xây dựng (Construction) và
chuyển giao (Transiton). Mô hình này định nghĩa
một tập các cột mốc chung, đóng vai trò là các
điểm chặn, dựa vào đó mà các ước lượng và đánh

giá thực tế của COCOMO được thực hiện
Nhân tố thay đổi trong bảo trì: phần mã cũ được
chỉnh sửa hoặc thêm mới (mô hình bảo trì trong
COCOMO)
Cấp độ đánh giá trung bình
Phương pháp bình phương cực tiểu thông thường

MBASE

Model-Based
(System)
Architecting
Software
Engineering

MCF

Maintenance
Change Factor

N
OLS
OO
OS
P

Nominal
Ordinary Loast
Square
Object Oriented

Operating System
Productivity

PA

Post Architecture

PCAP

Programmer
Capability
Personel
Hệ số chi phí “tính liên tục về nhân lực”
Continnity
Product Design
Pha thiết kê sản phần trong mô hình thác nước
Platform Difficulty Độ khó về yếu tố nền – hệ số đa hợp trong mô
hình early Design
Product Review
Cột mốc xem xét bản thiết kế dự án
milestone
Personal
Năng lực của nhân viên hệ số đa hợp trong mô
Capability
hình early Design
Platform
Hệ số chi phí “Kinh nghiệm làm việc với yếu tố
Experience
nền”
Person-Months

Một người-tháng là lượng thời gian làm việc của
dự án của một ngưồ, trong một tháng; trong
COCOMO thường giả định là 152 giờ làm việc.
Công sức tính theo người-tháng từ việc dịch tự

PCON
PD
PDLF
PDR
PERS
PLEX
PM

PMAUTO

Hướng đối tượng
Hệ điều hành
Ký hiệu chỉ năng suất lao động, có thể đo bằng
bao nhiêu người-tháng, hoặc ngừơi-giờ để thực
hiện một khối lượng công việc đã định trước
Mô mô hình chi tiết, được sử dụng trong
COCOMO II khi dự án đã sẵn sàng cho phát triển
Hệ số chi phí “Năng lực của lập trình viên”


PMNS
PMAT
POP

Process Maturity

Predictive Object
Point

PREC
PREX

Precedentedness
Personal
Experience
Product Release
Review
Plattorm Volatility
Quality Assurance

PRR
PVOL
QA

QAF

RAD
RCPX
RELY
RESL
RET

REVL

ROI
RQ

RUP

Quality
Adjustement
Factor
Rapid Application
Development
Product Reliability
and Complexity
Required Software
Reliability
Architeeture/Risk
Resolution
Record Element
Type
Requirement
Evolution
Volatility
Return on
Investment
Requirements
Rational Unified
Process

động.
Công sức được ước lượng mà chưa tính đến hệ số
chi phí SCED (thời gian danh nghĩa)
Hệ số chi phí “Độ thuần thục về quy trình”
Là một độ đo do PRICƯ System xây dựng, đặc
biết dành cho các phần mềm hướng đối tượng của

hệ thống Độ đo trung tâm của các phép tính POP
là WMC
Hệ số tính chi phí “Tính tiền lệ của dự án”
Kinh nghiệm của nhân việ - hệ số đa hợp trong
mô hình Early Design
Một cốt mốc trong mô hình RUP
Hệ số chi phí “Tính dễ thay đổi của yêu tốt nền”
Một phòng ban hay một chương trình trong một
tổ chức, tham gia vào quá trình kiểm thử sản
phẩm. QA bảo đảm rằng tất cả các sản phẩm và
hệ thống đều hoạt động đúng như những gì đã đề
ra ban đầu
Hệ số điều chỉnh chất lượng

Phát triển ứng dụng nhanh; áp dụng cho cả thời
gian và nỗ lực thực hiện dự án
Độ phức tạp và độ tin cậy của sản phẩm; hệ số đa
hợp trong mô hình Early Design
Hệ số chi phí “Độ tin cậy phần mềm theo yêu
cầu”
Hệ số chi phí “Giải pháp cho kiến trúc và những
rủi ro đã biết”
Kiểu phần tử bản ghi Một RET là một nhóm nhỏ
các phần tử dữ liệu trong một ILF hoặc một EIF
mà người dùng có thể nhận biết được
Nhân tố điều chỉnh phần trăm kích thước do bổ
sung hoặc thay đổi yêu cầu
Tiền lãi từ việc đầu tư
Pha xác định yêu cầu trong mô hình thác nước
Quy trình hợp nhất của Rational (hang IBM)dùng

riêng cho phát triển phần mềm. Quy trình gồm 4
pha cơ bản: Iception (khởi đầu); Elaboration
(Phân tích, phân rã), Construction (Xây dựng) và
Transition( Bàn giao). Quy trình dành cho quản
lý sản xuất phần mềm theo mô hình lặp, khác với


RUSE
SAR

SCED

SCED%
SDC
SDM

SDP

SEI

SF

SITE
SLIM

SLOC

Developed for
Reuseability
Software

Acceptance
Review milestone
Required
Development
Schedule
Sample Data
Collection
Software
Development
Metries
Software
Development
Process
Software
Engineering
Institute
Scale Factor

Multisite
development
Software Liftcycle Management

TDEV

Source Lines of
Code
Software
requirement
Review
Main Storage

Constrain
Software
Understanding
SoftWare
Transition
Completion
Review
Time to Develop

TEAM

Team Cohension

SRR

STOR
SU
SW
TCR

mô hình thác nức (Waterfall)
Hệ số chi phí “Phát triển nhằm mục đích tái sử
dụng”
Cột mốc xem xét để chấp nhận phần mềm (quy
trình phát triển theo mô hình thác nước)
Thời gian phát triển cần thiết; hệ số chi phí ở mức
dự án
Phần trăm rút ngắn thời gian theo yêu cầu
Bộ sưu tập dữ liệu mẫu
Các độ đo trong phát triển phần mềm

Quy trình phát triển phần mềm

Viện công nghệ học phần mềm, một trung tâm
nghiên cứu và phát triển dưới sự bảo trợ của liên
bang, thuộc đại học Carnegie Mellon, Mỹ
Một thuộc tính riêng của phát triển phần mềm, có
tác động theo hàm mũ, làm tăng hoặc giảm lượng
công sức phát triển
Hệ số tỷ lệ “phát triển đa địa điểm”
Một mô hình định giá dựa trên việc phân tích sự
phân bố công sức thực hiện theo thời gian sản
xuất
Số dòng mã lệnh nguồn.
Cột mốc xem xét những yêu cầu của phần mềm.

Hệ số chi phí “ràng buộc về bộ nhớ chính”
Hệ số chi phí “Khả năng hiểu phần mềm”
Phần mềm
Cột mốc xem xét việc kết thúc quá trình chuyển
giao
Thời gian để phát triển phần mềm (tính theo
tháng)
Hệ số chi phí “Tính gắn kết đội phát triển”


TIME
TOOL

UAF

UML

UNFM
USC

UTC

VAF
VH
VL

WBS
WMC

XH
XL

Execution Time
Constraint
Use of Software
Tools
Top-down

Unadjusted
Function Points
Unified Modelling
Language
Programmer
Unfamiliarity
University of

Southern
California
Unit Test
Completion
milestone
Value Adjustment
Factor
Very High
Very Low
Water Fall
Work Breakdown
Structure
Weighted Methods
per Class

Extra High
Extra Low

Hệ số “ràng buộc về thời gian thực thi”
Hệ số “Mức sử dụng các công cụ phần mềm”
Phương pháp tiến hành từ phần tử lớn, cơ bản đến
phần tử nhỏ và chi tiết hơn trong một hệ thống
phân cấp.
Các điểm chức năng chưa điều chỉnh
Ngôn ngữ mô hình hóa hợp nhất để thể hiện cacs
đặc tả yêu cầu, phân tích, thiết kế sản phẩm phần
mềm.
Tính không thân thuộc của lập trình viên: sử dụng
trong tái sử dụng và bảo trì
Trường đại học nam California

Cột mốc kết thúc giai đoạn kiểm thứ đơn vị

Nhân tố điều chỉnh giá trị - một trong 14 dặc
chưng hệ thống GSCs
Cấp độ đánh giá Rất cao
Cấp độ đánh giá Rất thấp
Mô hình thác nước quản lý vòng đời phát triển
phần mềm
Cấu trúc phân chia công việc.
Độ đo trung tâm được sử dụng trong phép tính
POP, nhận được bằng cách xác định từnglớp ở
mức trên cùng (mỗi đối tượng không trùng lặp
theo quan điểm của người dùng) và gán một trọng
số cho mỗi hành vi của lớp đó
Cấp độ đánh giá Cực cao
Cấp độ đánh giá Cực thấp


CHƯƠNG I: TỔNG QUAN VỀ
ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM
I.

Đối tượng ước lượng và các phương pháp xác định

Mỗi phần mềm đều có rất nhiều thuộc tính đặc trưng mà có thể là đối tượng để đo, để
ước lượng như: kích cỡ, độ phức tạp, độ tin cậy, chất lượng, tính khả dụng.. Do đó để
xây dựng một chương trình đo, ước lượng phần mềm tốt cần xác định rõ các mục tiêu
của dự án cũng như của tổ chức phát triển phần mềm. Các câu hỏi cần được trả lời như:
 Đối tượng của các phép đo là gì?

 Mục tiêu kỳ vọng về sản phẩm, quy trình, các nguồn phát triển sau các phép đo?
 Những độ đo nào thể hiện các mục tiêu đó có đạt được hay không.
Sau đây ta sẽ nghiên cứu một số phương pháp xác định mục tiêu:

1. Phương pháp 1: Hướng tiếp cận các độ đo câu hỏi mục tiêu
(Goal Question Metrics Approach GQM)
GQM là một hướng tiếp cận đc Basilieta đưa ra và được chấp nhận rộng rãi như một
cấu trúc có giá trị để giải đáp cho câu hỏi "đo lường cái gì".Nói tóm lược, GQM đưa ra
định nghĩa về các thông số đo lường chương trình theo một cấu trúc top down như sau:
a. Xác định mục tiêu của sản phẩm, tiến trình, và của nguồn _ đây là các mục tiêu mà
khách hàng của các độ đo hướng tới.
b. Làm rõ những câu hỏi về đặc trưng cách đánh giá phương thức gặt hái những thành tựu.
c. Định nghĩa các độ đo để cung cấp các câu trả lời mang tính số lượng cho từng câu
hỏi.Các độ đo có thể là khách quan (nếu chỉ dựa thuần túy vào đối tượng được đo) hoặc
là chủ quan (nếu dựa vào cả quan điểm đo lường và đối tượng đo).
Xét ví dụ: Ta hãy để ý sự chuyển giao một sản phẩm phần mềm: Người quản lý sản
phẩm/dự án, có thể có những mục tiêu sau cho sản phẩm:
* Mục tiêu là chuyển giao một sản phẩm phần mềm đạt các mong đợi về chức năng của
khách hàng => câu hỏi cần đặt ra là phần mềm chuyển giao cho khách hàng kia đã thay
đổi bao nhiêu so với yêu cầu của khách hàng. Một độ đo cần sử dụng để trả lời cho câu
hỏi đó là: Số những khiếm khuyết phần mềm được đếm. Thông thường, luôn có những
thỏa thuận về việc hình thành các khiếm khuyết, các nhược điểm, thường là dựa trên sự
vận hành của phần mềm đã thay đổi trong sự thỏa thuận chặt chẽ của yêu cầu. Các yêu
cầu càng rõ ràng, thì các độ đo càng khách quan. Ở đây ta cũng có thể sử dụng một độ
đo khác: Là mức độ thỏa mãn của khách hàng dựa theo một số biểu mẫu khảo sát. _


Đây là một độ đo chủ quan, hoàn toàn dựa vào quan điểm của khách hàng.

2. Phương pháp 2: Mô hình tạo quyết định

(Decision Maker Approach)
Một phương thức thứ nữa để tập hợp các độ đo là tập trung vào việc đưa ra các quyết
định của dự án. Các bộ tạo quyết định chính là khách hàng của các độ đo, mà các độ đo
được tạo ra để làm tiện dụng cho các thông tin tới các bộ quyết định. Trong phương
thức này ta cần xác định yêu cầu của bộ tạo quyết định là gì, nhận diện được tác dụng
của chúng. Phương thức này hoàn toàn gắn kết chặt chẽ với GQM với sự chú trọng tới
những quyết định được tạo ra như hình 2.1
Hiểu được các quyết định được tạo ra sẽ giúp cho đặt đúng chỗ việc đo lường dự án hỗ
trợ cho việc đưa ra các quyết định. Ví dụ: Một quản lý dự án cần đưa ra quyết định
phân bố nguồn dựa trên tình trạng hiện thời với mối tương quan của tiến trình dự kiến.
Anh ta cần tính toán về thời gian và cả nỗ lực/nhân lực trong cả vòng đời phát triển.
Một người quản lý kiểm thử cần xác đĩnh xem chất lượng của sản phẩm phần mềm có
đạt được mức có thể chấp nhận được để chuyển giao cho khác hàng không, do đó anh
ta cần đo lường chất lượng hiện tại của sản phẩm và một cái nhìn tổng quan sau thời
gian chỉnh sửa.
Trong phương thức này, cần xem nhu cầu của việc đưa ra các quyết định để xác định
các độ đo cần dùng.

3. Phương pháp 3: Các độ đo các hệ số chuẩn
(Standards Driven Metrics)
Có những tập hợp các độ đo tiêu chuẩn chung cho công nghệ phần mềm cũng như cho
các ứng dụng chuyên biệt. Và một số tổ chức đã sử dụng chúng như chuẩn mực cho
các bộ đo chương trình của họ . Một ví dụ là mô hình phần mềm chính xác của Viện
công nghệ phần mềm SEI (Software Engineering Institute) yêu cầu sự đo lường về kích
cỡ hệ thống, thời gian dự án, mức công sức, và những lỗ hổng của phần mềm. Họ tích


hợp những đơn vị đo này với những yêu cầu tiến trình để hỗ trợ cho việc Quản lý dự án
và Cải thiện liên tục. Cùng với năng suất, chúng ta coi tập hợp độ đo của SEI như tập
hợp gọn nhất cho tổ chức đó là : Kích cỡ hệ thống, thời gian dự án, nhân lực, lỗ hổng,

năng suất.
Mỗi kỹ nghệ khác nhau cần có nhưng tiêu chuẩn riêng về độ đo, độ tin cậy và an toàn.
Ví dụ: Trong công nghệ truyền thông, có tiêu chuẩn TL9000 có định nghĩa dài về độ đo
mà các nhà cung cấp phần mềm phải có và cung cấp cho khách hàng. Còn trong công
nghệ hạt nhân EIC60880:1986-09 định nghĩa các tiêu chuẩn và độ đo cho "Phần mềm
cho máy tính trong hệ thống an toàn của trung tâm năng lượng hạt nhân".
Tóm lại trong phương thức này, ta cần quan tâm tới cả các tiêu chuẩn chung và các tiêu
chuẩn đặc trưng cho từng kỹ nghệ để lựa chọn các độ đo cho phù hợp.

4. Phương pháp 4: Mở rộng GQM: Độ đo kỹ xảo
(Extension to GQM: Metric Mechanism)
Một điều quan trọng cần bổ sung vào các hướng tiếp cận trên cần quan tâm. Kỹ xảo để
thu thập các dữ liệu về độ đo cần hiểu thấu đáo và thống nhất trước khi đưa vào ứng
dụng trong chương trình. Trong sự chấp thuận với những tiền đề của Basili, ta thêm kỹ
xảo vào GQM để có đc GQM2 như sau:
* Mục tiêu (Goal)
* Câu hỏi (Question)
* Độ đo (Metric)
* Kỹ xảo (Mechanism): Bao gồm việc xác định ai sẽ chịu trách nhiệm bảo đảm việc
thu thập và báo cáo các dữ liệu xác thực, tần xuất thu thập dữ liệu, tần xuất báo cáo dữ
liệu, và cơ sở hạ tầng (như các công cụ, nguồn nhân viên....) cần để thu thập và báo cáo
dữ liệu.
Thất bại trong việc hiểu và thống nhất trong "Kỹ xảo" có thể dẫn tới rất nhiều thất bại
trong những độ đo chương trình: Dữ liệu không hoàn thiện hoặc không chuẩn xác là do
không có ai đảm bảo cho nó phải có kịp lúc và đúng kiểu. Dữ liệu cũ, và không còn
hữu dụng cho những quyết định hiện thời. Dữ liệu không có sẵn sàng khi cần tới. Ngân
sách dự án bị thiếu hụt do chi phí cho cơ sở hạ tầng của độ đo chương trình. Kế hoạch
dự án bị phá vớ do không có kế hoạch thời gian dự trù và xác thực.
Kỹ xảo cho độ đo khiếm khuyết: Chủ sở hữu=Quản lý dịch vụ khách hàng, tần xuất
thu thập= lỗ hổng xuất hiện, tần xuất báo cáo= hàng tháng, cơ sở vật chất= hệ thống

công cụ khách hàng hiện có và 0,25 nhân viên văn phòng
Kỹ xảo cho độ đo thỏa dụng khách hàng: Chủ sở hữu = quản lý sản phẩm, tần xuất thu
thập= sau khi chuyển giao từng phần chính của phần mềm, tần xuất báo cáo = quý, cơ sở hạ
tầng = khảo sát khách hàng đã có trong từng lần chuyển giao và 0.1 quản lý sản phẩm.

5. Đối tượng đo lường là một chức năng của thời gian
Một đặc điểm của bất cứ độ đo chương trình nào là chúng đều có chức năng của thời
gian trong ba hình thức:


 Đối tượng đo lường biến đổi dựa trên vị trí hiện thời trong sự phát triển phần mềm
và vòng đời sản phẩm phần mềm. Ví dụ, các độ đo kiểm tra mã nguồn được thu thập và
kiểm soát trong suốt thời gian phát triển mã lệnh của vòng đời. Trong pha kiểm thử,
thời gian phát triển để chuyển giao những vá lỗi có thể đồng nhất với nhu cầu bộ đưa
quyết định cần biết. Độ tin cậy của sản phẩm phần mềm cần được đo trong các bước
sớm trước khi chuyển giao và ứng dụng sản phẩm, trong khi chi phí bảo trì nằm trong
khoảng lợi nhuận khi mà sản phẩm đã nằm ở cuối vòng đời.
 Các doanh nghiệp thay đổi từng giờ tùng phút, và các độ đo chương trình cần có sự
thay đổi thích ứng theo. Ví dụ: Nếu những khảo sát khách hàng chỉ ra rằng họ không
thỏa mãn với độ tin cậy của sản phẩm, một hệ thống độ đo sẵn sàng cần được tạo ra và
giám sát. Nếu các đối thủ cạnh tranh đang tấn công các sản phẩm của ta trên thị trường
bằng các sản phẩm có chức năng tương tự, chúng ta có thể cần tới đo lường tiến trình
phát triển, cho phép ta tập trung phần lớn thời gian vào việc triển khai phát triển cải
tiến.
 Các độ đo, đặc biệt là khi đã được sử dụng như tác nhân trong nhận dạng và đền
bù, có thể sẽ dần mất đi hiệu lực qua thời gian Sự tập trung có thể trở thành gắn kết
trực tiếp đến độ đo và làm cách nào để "quản lý độ đo" Hơn là tối ưu mục tiêu mà dự
án mong đạt tới. Khi đó cần lựa chọn một độ đo khác hỗ trợ cho mục tiêu hoặc thay đổi
cách thức của độ đo hiện có.

6. Tổng kết:
Mỗi dự án phần mềm và mỗi tổ chức đều phải đối mặt với câu hỏi "đo lường cái gì?".
Để trả lời được câu hỏi này chúng ta cần hiểu về khách hàng của mình và mục tiêu của
họ, để sử dụng trong việc điều khiển những định nghĩa xấp xỉ trong đo lường chương
trình. Các tiêu chuẩn cung cấp cách thức và định hướng như mô hình tạo quyết định
hay GQM. Không quá chú trọng tới hướng tiếp cận nào được chọn, định nghĩa các độ
đo chương trình có thể là một phần của bước đầu tiến trình lập kế hoạch dự án. Đạt
được sự thỏa thuận chung của các thành viên ngay khi bắt đầu giúp cho đảm bảo các độ
đo là cần thiết để đưa ra quyết định và ước lượng mục tiêu đạt được ở bất kỳ lúc nào,
nơi nào chúng cần. Mọi độ đo chương trình cần thường xuyên sử dụng và đảm bảo liên
kết chặt chẽ với mọi sự thay đổi trong công việc và nhu cầu của dự án.

II.

Các kỹ thuật ước lượng chi phí phần mềm

Những nghiên cứu đáng kể đưa ra các kỹ thuật ước lượng chi phí phần mềm bắt đầu từ
những năm 1965, với việc nghiên cứu dựa trên tập hợp các dữ liệu mẫu từ 169 dự án
phần mềm, với 104 thuộc tính của phần mềm được khảo sát. Dựa trên những nghiên
cứu này, một vài mô hình ước lượng, dù chưa được hòan chỉnh nhưng khá có giá trị đã
được công bố vào cuối những năm 1960 đầu những năm 1970.
Cho tới cuối những năm 1970, đã có hàng loạt những mô hình mạnh hơn, có độ chính


xác cao hơn được giới thiệu như: SLIM (Putnam và Myers), Checkpoint (Jones),
PRICE-S (Park), SEER (Jensen) và COCOMO (Boehm). Tuy nhiên tất cả các mô hình
này đều gặp vấn đề với các dự án có kích cỡ và tầm quan trọng lớn. Với những phần
mềm quy mô lớn này, thì có độ phức tạp cao, làm cho việc ước lượng chính xác chi phí
vô cùng khó. Đây cũng chính là động lực thúc đẩy các nhà nghiên cứu phát triển thêm
các mô hình cho phù hợp hơn với thực tế.

Với bản chất thay đổi nhanh chóng của phần mềm làm cho việc xây dựng các mô hình
tham số (vốn mang lại độ chính xác cao cho nhiều lĩnh vực trong phát triển phần mềm)
trở nên rất khó khăn. Với mục tiêu xây dựng các mô hình hữu dụng, dựa theo vòng đời
phát triển phần mềm để dự đoán chính xác chi phí phần mềm, trong khoảng hơn hai
thập kỷ gần đây, nhiều mô hình ước lượng chi phí phần mềm đã xuất hiện. Các kỹ
thuật thường được sử dụng nhất trong các mô hình này là các phương pháp tiếp cận đa
hồi quy cổ điển. Ta có thể xếp các kỹ thuật thông dụng nhất hiện nay theo sáu hướng
tiếp cận sau:

Hình 1: các kỹ thuật ước lượng phần mềm
Sau đây ta sẽ nghiên cứu thêm về từng loại kỹ thuật đó.

1. Các kỹ thuật dựa trên mô hình:
Theo nghiên cứu trong thời gian qua không có nhiều các mô hình ước lượng phần mềm
được xây dựng, và hầu hết đều là các mô hình thuộc sở hữu độc quyền do đó khó có
thể so sánh hay đối chiếu về mặt cấu trúc của các mô hình. Tính năng của các mô hình
được xác định thuần túy trên lý thuyết hay qua các thử nghiệm. Sau đây ta sẽ nghiên
cứu về một số mô hình phổ biến.
1.1. Mô hình SLIM của Putnam
Đây là mô hình được Larry Putnam thuộc công ty Quantitative Software Development,
phát triển từ cuối những năm 1970. SLIM là kết quả phân tích của Putnam về vòng đời
phát triển phần mềm, sử dụng đường cong phân bố Rayleigh để ước lượng cống sức,
thời gian và tỷ lệ khiếm khuyến của dự án. Ông sử dụng một chỉ số xây dựng nhân lực
(MBI _ Manpower Buildup Index) và một hệ số năng suất (PF _ Productivity Factor)
để hiệu chỉnh phân bố. SLIM sử dụng các dữ liệu từ các dự án đã hoàn thành để ước
lượng cho dự án mới. Nếu không có các dữ liệu tiền định, thì ta có thể xác định các giá
trị MBI và PF qua việc trả lời một tập các câu hỏi. SLIM sử dụng khái niệm năng suất
P là tỷ lệ giữa kích cỡ phần mềm S và công sức phát triển E.
P = S/E
SLIM có thể thực hiện được với các độ đo kích cỡ phổ biến như số dòng mã lệnh

SLOC, số điểm chức năng Function Points hay kỹ thuật ballpark.
Đường cong Rayleigh được sử dụng để xác định phân bố công sức qua biểu thức vi
phân:
Dy/dt=2Kate-at2

Đây là một ví dụ về phân bố Rayleigh cho mức sử dụng nhân lực trong thời gian phát
triển td với K=1, a=0.02, td=0.18. Với mỗi giá trị K, a và t d khác nhau ta có được đồ thị
phân bố khác nhau. Tuy nhiên phân bố Rayleigh không phải luôn luôn đúng trong thực
tế, ví dụ khi phát triển gia tăng thì phân bố Rayleigh trở thành nằm ngang, hay khi tăng
thời gian thực hiện dự án ta chỉ có thể tiết kiệm nhân lực được một lươngj nhỏ hơn t 4.
Putnam đã đề xuất một số hiệu chỉnh cho các trường hợp đặc biệt đó.
Công ty Quantitative Software Development đã xây dựng một bộ gồm ba công cụ dựa
trên mô hình SLIM là SLIM Estimate hỗ trợ lập kế hoạch dự án, SLIM Control để theo
dõi giám sát dự án và SLIM Metrics để lưu trữ và đánh giá các độ đo phần mềm. Ta có
thể tham khảo thêm thông tin về mô hình SLIM và các công cụ này tại

1.2. Mô hình Checkpoint - điểm kiểm tra
Đây là công cụ ước lượng dự án phần mềm được Software Productivity Research
(SPR) phát triển trên những nghiên cứu của Capers Jones. Checkpoint sử dụng các
điểm chức năng FPs là đầu vào chính về kích cỡ để tiến hành ước lượng với nguồn cơ
sở dữ liệu là hơn 8000 nghìn dự án đã hoàn thiện. Dưới đây là mô hình của Checpoint
với các khái niệm QA_ Quality Assurance đảm bảo chất lượng, JAD _ Joint
Applications Development là tham gia phát triển ứng dụng, SDM _ Software
Development Metrics là các độ đo phát triển phần mềm.


Mô hình này hỗ trợ việc phát triển và củng cố mô hình vòng đời phát triển phần mềm
theo 3 chức năng chính:

 Ước lượng: Dự đoán công sức cần cho dự án théo cả bốn cơ sở: Dự án, các pha
phát triển, các hoạt động và các nhiệm vụ. Ước lượng gồm 5 thành phần: Tài nguyên,
những phần được chuyển giao, các khiếm khuyết, chi phí và thời gian.
 Đo lường: Cho phép người dùng chọn các độ đo để đo lường cho dự án, từ đó phân
tích hiệu năng, xác định kỹ thuật ứng dụng tốt nhất và xây dựng nền tảng tri thức ước
lượng nội bộ (là các mẫu _ templates)
 Đánh giá: Dựa trên các tiêu chuẩn công nghiệp để hỗ trợ việc so sánh đánh giá các
tính năng của dự án với nhu cầu thực tế. Đánh giá ưư nhược điểm của môi trường pháp
triển phần mềm và mô hình hóa các khuyến nghị trong cải thiện quy trình đánh giá.
Ngoài ra SPR còn đưa ra thị trường một số công cụ khác như: Knowledge Plan giúp
đưa ra một ước lượng ban đầu về dự án phần mềm với công sức giới hạn, và hướng dẫn
một quy trình tinh chỉnh qua các thử nghiệm và đánh giá; FP Workbench là công cụ để
phân tích các điểm chức năng có lưu trữ cập nhật và phân tích từng phép đếm.
 Ngoài SPR còn một số tổ chức khác cũng xây dựng mô hình ước lượng dựa trên số
đếm các điểm chức năng. Tiêu biểu như COSMIC -Common Software Mesurement
International Consortium. Là một dự án với kỳ vọng thừa kế tất cả các ưu điểm của các
mô hình ước lượng qua điểm chức năng khác như IFPUG MkII, NESMA.. Do các
điểm chức năng không phù hợp với các hệ thống nhúng và hệ thống thời gian thực, nên
COSMIC FFP v2.2 đã bổ sung để đo kích cỡ theo đơn vị chức năng là các yêu cầu về
chứuc năng của người dùng (FUR-Functional User Requirement). Hiện nay COSMIC
FFP đã được tiêu chuẩn quốc tế hóa.


1.3. PRICE-S
Là mô hình được phát triển đầu tiên ở RCA và được sử dụng nội bộ để ước lượng cho
các dự án phần mềm thuộc bộ quốc phòng mỹ, NASA và các dự án chính phủ Mỹ
khác. Các biểu thức không được công bố mà chỉ một số giải thuật chính được công bố
vào năm 1988. Sau này đã được phổ biến rộng rãi và thương mại hóa bởi công ty
PRICE System. Bao gồm 3 mô hình con:
i. Mô hình thu thập: Dự đoán chi phí và thời gian thực hiện của phần mềm, xây dựng

ứng dụng trên tất cả mọi lĩnh vực: Hệ thống kinh doanh, hệ thống giao tiếp, hệ thống
chỉ huy và điều khiển, hệ thống điện tử hàng không vũ trụ. PRICE-S tập trung vào các
vấn đề: Tái kỹ nghệ, sinh mã nguồn, phát triển xoắn ốc, phát triển nhanh, tạo mẫu thử
nhanh, phát triển hướng đối tượng và đo lường năng suất phần mềm.
ii. Mô hình định cỡ: Hỗ trợ việc ước lượng kích cỡ của phần mềm qua các độ đo như
SLOC, FP hay POP (các điểm đối tượng dự đoán Predictive Object Points) - là độ đo
hướng đối tượng mới của Chidamber.
iii. Mô hình chi phí vòng đời: Ước lượng nhanh chi phí các pha bảo trì và hỗ trợ ở giai
đoạn sớm. Thường được sử dụng kết hợp với mô hình thu thập.
Tham khảo thêm về PRICE-S tại
1.4. SEER-SEM
Là một sản phẩm của công ty Galorath dựa trên mô hình của Jensen. Đây là bộ công cụ
phức hợp hỗ trợ cho các phương pháp ước lượng cả "top-down" và "bottom-up". Các
biểu thức mô hình không công bố, nhưng chúng sử dụng các tham số để ước lượng.
Phạm vi của mô hình rộng, bao trùm tất cả các pha trong vòng đời phát triển dự án
phần mềm: Từ đặc tả yêu cầu, thiết kế, phát triển, triển khai và bảo trì. Có thể hoạt
động trên các nền tảng khác nhau: khách - chủ, đơn lẻ, phân tán, đồ họa v.v.. Áp dụng
rộng rãi cho các chế độ phát triển: hướng đối tượng, tái sử dụng, COTS, xoắn ốc, thác
nước, mẫu thử và gia tăng. Hỗ trợ cho các ngôn ngữ lập trình thế hệ thứ 3, thứ 4 như
C++, FORTRAN, COBOL, ADA... Cũng như các trình tạo ứng dụng khác. Các yếu tố
đầu vào: năng lực nhân viên, các chuẩn về quy trình, yêu cầu về thiết kế, độ rủi ro chấp
nhận được. Hình sau mô tả mô hình các nhóm dữ liệu đầu ra đầu vào của hệ thống.


Các tính năng chính của mô hình SEER - SEM:
 Cho phép nhập độ xác suất ước lượng, ràng buộc về nhân lực và thời gian độc lập
 Cung cấp các tiện ích giúp phân tích các biến động tổng thể và hiệu chỉnh các tham
số đầu vào.
 Tổ chức các thành phần dự án vào cấu trúc phân chia công việc, giúp lập kế hoạch
và kiểm soát thuận tiện hơn.

 Hiển thị các hệ số chi phí của dự án.
 Cho phép lập kế hoạch có tính tương tác giữa các thành phần dự án trên biểu đồ
Gantt.
 Xây dựng ước lượng dựa trên cơ sở tri thức các dự án đã thực hiện, và các tri thức
này có thể hiệu chỉnh được.
Các đặc tả của mô hình bao gồm:
 Các tham số: Bao gồm các nhóm kích cỡ dự án, nhân lực, độ phức tạp, môi trường
và các ràng buộc. Trong mỗi nhóm lại có nhiều tham số riêng
 Các dự đoán: Ước lượng công sức, thời gian thực hiện, nhân lực, các khiếm khuyết
và chi phí. Các ước lượng này có thể bị chi phối bởi thời gian thực hiện hay nhân lực,
có thể chỉ định các ràng buộc về thời gian thực hiện và nhân lực.
 Phân tích rủi ro: Có thể phân tích biến động trên tất cả các giá trị của các tham số
đầu ra (giá trị nhỏ nhất, xác suất gặp cao nhất, giá trị lớn nhất...), định các xác suất cho
từng thành phần trong WBS và có thể điểu chỉnh được các giá trị này, cho phép sắp
xếp các ước lượng theo độ quan trọng của các thành phần trong WBS
 Các phương pháp định cỡ: Theo điểm chức năng theo cả chuẩn của IFPUG và
những cách thức khác , số dòng mã lệnh, cả thêm mới và sử dụng sẵn có.
 Các đầu ra và giao diện: Nhiều độ đo năng lực với hàng trăm báo cáo và biểu đồ,
các phân tích thỏa hiệp cùng với việc so sánh các khả năng thay thế, tích hợp giao diện
các cửa sổ ứng dụng và các giao diện người dùng tùy biến.


Tham khảo thêm chi tiết về SEER-SEM tại
1.5. COCOMO II
Mô hình ước lượng chi phí và thời gian phát triển COCOMO lần đầu được đề cập đến
trong cuốn sách "Kinh tế học công nghệ phần mềm" (Software engineering economics)
của Barry Boehm xuất bản năm 1981 và nhanh chóng trở thành một mô hình ước lượng
chi phí phổ biến trong những năm 1980. Tuy nhiên cùng với sự phát triển của các công
cụ lập trình thì mô hình COCOMO 81 này và bản bổ sung ADA COCOMO cũng
không đáp ứng được yêu cầu ước lượng với độ chính xác cao nữa.

Thế nên năm 1995 mô hình COCOMO II được giới thiệu với 3 mô hình con
"Applications Composition", "Early Design" Và "Post Architecture" Có thể kết hợp
linh hoạt với nhau theo nhiều cách để giải quyết các yêu cầu thực tế.
Trong đó mô hình " Application Composition" được sử dụng để ước lượng công sức và
thời gian cho các dự án có sử dụng các công cụ ICASE để phát triển nhanh ứng dụng.
Các dự án này khá đa dạng nhưng thường ở mức khá đơn giản. Các thành phần thông
thường là các GUI, các trình quản lý đối tượng hay CSDL, phầm mềm trung gian để xử
lý phân tán hay xử lý giao dịch..... Mô hình này dựa trên các điểm đối tượng, với các
đối tượng ở đây là các màn hình, các báo cáo và các module phát triển bởi các ngôn
ngữ lập trình thế hệ thứ 3. Mỗi đối tượng được đếm với một trọng số ảnh hưởng bởi độ
phức tạp (gồm ba mức: đơn giản, trung bình, và phức tạp). Phép ước lượng này phù
hợp với mức độ thông tin có được trong giai đoạn lập kế hoạch dự án.
Mô hình "Early Design" khám phá các khái niệm vận hành và khả năng thay thế về
kiến trúc của hệ thống. Thường mô hình này áp dụng vào giai đoạn sớm, khi chưa có
đủ các thông tin để có thể đưa ra một ước lượng chi tiết. Mô hình này ước lượng dựa
trên số điểm chức năng, hay số dòng mã lệnh SLOC nếu có. Được hiệu chỉnh bởi bộ 5
hệ số tỷ lệ và 7 hệ số nhân công sức.
Mô hình "Post Architecture" ước lượng cho toàn bộ vòng đời phát triển của dự án, mở
rộng chi tiết hơn cho mô hình "Early Design". Thường được áp dụng sau khi đã hoàn
thiện thiết kế ở mức cao nhất, với đấy đủ các thông tin chi tiết về dự án, kiến trúc phần
mềm. Đây là mô hình gần gũi nhất về mặt kiến trúc và biểu thức với COCOMO81 và
ADA COCOMO. Sử dụng các tham số định kích cỡ như LOC hay FP được điều chỉnh
cho phù hợp với trường hợp tái sử dụng và ngắt đoạn. Sử dụng 17 hệ số nhân công sức
và 5 hệ số tỷ lệ để hiệu chỉnh ước lượng.
Mô hình "Post Architecture" có các hệ số điều chỉnh được rút ra từ 161 dự án. Việc
hiệu chỉnh các hệ số của mô hình "Early Design" là sự tổng hợp các hệ số của mô hình
"Post Architecture". Riêng mô hình "Application Composition" thì thiếu các thông tin
chi tiết nên không có sự hiệu chỉnh nào.
Điểm nổi bật và cuốn hút nhất ở các mô hình COCOMO là các biểu thức và giá trị các
tham số hoàn toàn công khai. Có lẽ đây là lý do mà nhiều công cụ ước lượng đã được

phát triển dựa trên mô hình này. Và đây cũng chính là lý do em đã chọn mô hình
COCOMO II để nghiên cứu và xây dựng công cụ hỗ trợ tự động ước lượng chi phí.
1.6. Tổng kết về các kỹ thuật ước lượng dựa trên mô hình

COCOMO II

Số dòng lệnh nguồn
Số điểm chức năng
Các độ đo liên quan tới
OO
Các thuộc tính về
Loại lĩnh vực
chương trình
Độ phức tạp
Ngôn ngữ
Tái sử dụng
Độ tin cậy yêu cầu
Các thuộc tính về
Các ràng buộc về tài
máy tính
nguyên
Tính dễ thay đổi yếu tố nền
Các thuộc tính về con Năng lực nhân viên
người
Tính liên tục về nhân lực
Kinh nghiệm nhân viên
Các thuộc tính dự án Các công cụ và kỹ thuật
Tách đoạn

Các ràng buộc về thời gian
Độ thuần thục quy trình
Tính gắn kết nhóm
Các vấn đề bảo mật
Phát triển đa địa điểm
Khởi tạo
Các họat động bao
Phác thảo
trùm
Xây dựng
Chuyển giao và bảo trì

SEER-SEM

Các thuộc tính về
kích cỡ

PRICES

Nhân tố

Checkpoint

Nhóm

SLIM

Bảng sau tổng kết các tham số và họat động được sử dụng trong các mô hình đã được
đề cập. Nhìn chung các kỹ thuật dựa trên mô hình phù hợp cho việc lập ngân sách,
phân tích sự cân bằng giữa các yếu tố, lập kế hoạch và kiểm soát cũng như phân tích

việc đầu tư trong trường hợp đã có thông tin từ các dự án đã kết thúc. Trong trường
hợp không có tiền lệ thì khó có thể áp dụng các mô hình trên.

Có
Có
Có

Có
Có
Có

Có
Có
Có

Có
Có
Có

Có
Có
Có

Có
Có
Có
Có
?
Có

Có
Có
Có
Có
?
?

Có
Có
Có
Có
Có
Có

Có
Có
Có
Có
Có
Có

Ko
Có
Có
Có
Có
Có

?
Có

?
Có
Có
Có
Có
Có
?
?
?
Có
Có
Có
Có

?
Có
?
Có
Có
Có
Có
Có
Có
?
Có
Có
Có
Có
Có

?
Có
?
Có
Có
Có
Có
?
Có
?
Có
Có
Có
Có
Có

Có
Có
?
Có
Có
Có
Có
Có
Có
Có
Có
Có
Có
Có

Có

Có
Có
Có
Có
Có
Có
Có
Có
Có
Có
Có
Có
Có
Có
Có

Bảng 1: Tổng kết các kỹ thuật dựa trên mô hình