TÌM HIỂU một số PHƯƠNG PHÁP TIÊN TIẾN TRONG ước LƯỢNG PHẦN mềm

BỘ GIÁO DỤC VÀ ĐÀO TẠO
ĐẠI HỌC HUẾ
TRƯỜNG ĐẠI HỌC KHOA HỌC
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

CHÂU NGỌC PHƯƠNG UYÊN

TÌM HIỂU MỘT SỐ PHƯƠNG PHÁP TIÊN
TIẾN TRONG ƯỚC LƯỢNG PHẦN MỀM

LUẬN VĂN THẠC SĨ KHOA HỌC
CÔNG NGHỆ THÔNG TIN

Thừa Thiên Huế, 2016
BỘ GIÁO DỤC VÀ ĐÀO TẠO
ĐẠI HỌC HUẾ
1


TRƯỜNG ĐẠI HỌC KHOA HỌC

CHÂU NGỌC PHƯƠNG UYÊN

TÌM HIỂU MỘT SỐ PHƯƠNG PHÁP
TIÊN TIẾN TRONG ƯỚC LƯỢNG
PHẦN MỀM
CHUYÊN NGÀNH: KHOA HỌC MÁY TÍNH
MÃ SỐ: 60.48.01.01

LUẬN VĂN THẠC SĨ KHOA HỌC
ĐỊNH HƯỚNG NGHIÊN CỨU

NGƯỜI HƯỚNG DẪN KHOA HỌC
PGS.TS. NGUYỄN MẬU HÂN

Thừa Thiên Huế, 2016

2


LỜI CAM ĐOAN
Tôi xin cam đoan, nội dung trong luận văn này do tôi viết, số liệu thu
thập trong luận văn, các tài liệu nghiên cứu và kết quả đề tài là trung thực.
Những số liệu, tài liệu nghiên cứu do chính tác giả sưu tầm từ các nguồn khác
nhau và có ghi trong phần tài liệu tham khảo.

Huế, ngày

tháng năm 2016
Học viên

Châu Ngọc Phương Uyên


Lời Cảm Ơn
Trước tiên, tôi xin chân thành cảm ơn quý thầy cô giáo Khoa Công nghệ thông
tin và phòng Đào tạo Sau đại học-Trường Đại học Khoa học Huế đã tận tình hướng
dẫn, truyền đạt kiến thức, tạo điều kiện thuận lợi trong quá trình học tập và thực
hiện luận văn tốt nghiệp.
Tôi xin gửi lời trân trọng cám ơn đến thầy giáo PGS.TS. Nguyễn Mậu Hân,
người đã tận tình hướng dẫn và góp ý cho tôi trong suốt quá trình nghiên cứu, cho

tôi nhiều lời động viên cũng như những hướng dẫn quý báu để tôi có thể thực hiện
tốt được đề tài này.
Trong quá trình thực hiện đề tài, không thể không kể đến sự giúp đỡ, đóng góp
ý kiến và những lời động viên từ phía gia đình, người thân, đồng nghiệp và bạn bè
xung quanh, điều này thật sự là động lực lớn giúp tôi hoàn thành tốt đề tài nghiên
cứu của mình.
Xin chân thành cám ơn!
Huế, ngày…..tháng ….. năm 2016
Học viên

Châu Ngọc Phương Uyên


MỤC LỤC
Trang


DANH MỤC CÁC BẢNG
Trang



DANH MỤC CÁC HÌNH
Trang
Hình 1.1. Tiến trình cơ sở Ước lượng dự án (Hewson, 2007)..................................10


DANH SÁCH CÁC TỪ VIẾT TẮT
COCOMO COnstructive COst MOdel
EAF

Effort Adjust Factor

ECF

Environmental Complexity Factor

ER

Effort Rating

FP

Function Point

FPA

Function Point Analysis

FPs

Function Points

KLOC

Kilo Line Of Code

LOC

Line Of Code

RUP

Rational Unified Process

TCF

Technical Complexity Factor

UCP

Use Case Point

UCPs

Use Case Points

UFP

Unadjusted Function Point

UFPs

Unadjusted Function Points

UML

Unified Modelling Language

UUCP

Unadjusted Use Case Point

UUCPs

Unadjusted Use Case Point

WAs

Weighted Actors

WUCs

Weighted Use Cases


MỞ ĐẦU
1. LÝ DO CHỌN ĐỀ TÀI
Trong thời đại công nghệ phát triển, ước lượng phần mềm từ lâu đã được xem
là vấn đề cốt lõi có ảnh hưởng trực tiếp đến sự thành bại của dự án nói chung, hay
dự án phần mềm nói riêng. Chỉ cần giải quyết được bài toán khó này, năng suất dự
án sẽ có thể tăng cao, đồng thời giảm thiểu rủi ro đến mức thấp nhất.
Khi nói đến vấn đề phát triển phần mềm thì không thể không nhắc đề cập đến
quá trình quản lý phần mềm, được bắt đầu và tiếp diễn bằng một chuỗi các hoạt
động ước lượng phần mềm. Thật vậy, trong thực tế, để lấy được dự án phần mềm,
các công ty tham gia đấu thầu phải nộp hồ sơ dự thầu bao gồm cả chi phí, nỗ lực và
thời gian phát triển phần mềm. Hiển nhiên thấy rằng để thắng thầu, các công ty
tham gia dự thầu rất cần phải đưa ra một ước lượng về giá cả, nỗ lực, và thời gian
thực hiện dự án một cách hợp lý. Hợp lý ở đây không có nghĩa là ước lượng giá
thấp hơn thực tế, vì khi đó công ty sẽ không thu được lợi (nếu không muốn nói là

lỗ) khi hoàn tất dự án. Hợp lý cũng không phải là ước lượng giá cao hơn thực tế, vì
khi đó chắc chắn công ty sẽ không thể thắng thầu. Do đó, một bảng lượng giá đề án
được xem là hợp lý chỉ khi nó phản ánh đúng giá trị thật của đề án. Đây là lý do để
tôi chọn đề tài: “TÌM HIỂU MỘT SỐ PHƯƠNG PHÁP TIÊN TIẾN TRONG
ƯỚC LƯỢNG PHẦN MỀM” làm đề tài luận văn của mình.
2. TỔNG QUAN TÀI LIỆU
Đã có một số phương pháp được đề xuất cho việc ước lượng để hỗ trợ quản trị
dự án, trong số đó 2 phương pháp nổi tiếng nhất là phương pháp Phân tích Điểm
Chức năng (FPA) và Mô hình Giá Cấu thành (COCOMO). Hai phương pháp này
còn có thể được kết hợp cùng nhau để ước lượng lượng tài nguyên cần thiết trong
dự án. Ngoài ra còn có một phương pháp ra đời gần đây, phương pháp ước lượng
dự án phần mềm dựa trên Điểm Use Case (UCP – Use Case Point), là phương pháp
rất phù hợp cho những dự án được kĩ nghệ theo phương pháp Hướng Đối tượng,
khắc phục được nhiều nhược điểm của các phương pháp truyền thống.

10


Tuy nhiên, trong một số trường hợp thực tế, dù cho mô hình phù hợp nhưng
nếu người quản lý sử dụng không chính xác thì vẫn có nguy cơ cao dẫn đến sự thất
bại cho dự án. Như vậy, hiểu biết một cách rõ ràng về các phương pháp cũng như
cách thức sử dụng các mô hình ước lượng phần mềm được xem là điều vô cùng
quan trọng và cần thiết.
3. MỤC TIÊU NGHIÊN CỨU
Tìm hiều về ước lượng dự án phần mềm
Tìm hiều về các phương pháp PERT, Đường Gantt, FPA, COCOMO và Điểm
Use Case.
Áp dụng phương pháp Điểm Use Case để ước lượng một dư án phần mềm.
4. ĐỐI TƯỢNG NGHIÊN CỨU
Các phương pháp ước lượng dự án phần mềm.

5. PHƯƠNG PHÁP NGHIÊN CỨU
Lý thuyết:
Tìm hiểu về lý thuyết dựa vào các công trình đăng tải trên các tạp chí có uy tín
trong và ngoài nước, các giáo trình, sách tham khảo được xuất bản bởi những nhà
xuất bản đáng tin cậy.
Thực nghiệm:
Áp dụng phương pháp ước lượng phần mềm đã nghiên cứu
6. BỐ CỤC LUẬN VĂN
Chương 1: Tổng quan về ước lượng phần mềm
Chương 2: Các phương pháp ước lượng phần mềm
Chương 3: Ứng dụng phương pháp Điểm Use Case để ước lượng phần mềm

11


Chương 1. TỔNG QUAN VỀ ƯỚC LƯỢNG PHẦN MỀM
1.1 CÁC PHƯƠNG PHÁP XÂY DỰNG PHẦN MỀM CƠ BẢN
1.1.1 Phương pháp hướng chức năng
Đây là lối tiếp cận truyền thống của ngành Công nghệ phần mềm. Theo lối
tiếp cận này, chúng ta quan tâm chủ yếu tới những thông tin mà hệ thống sẽ giữ gìn.
Chúng ta hỏi người dùng xem họ sẽ cần những thông tin nào, rồi chúng ta thiết kế
ngân hàng dữ liệu để chứa những thông tin đó, cung cấp Forms để nhập thông tin và
in báo cáo để trình bày các thông tin. Nói một cách khác, chúng ta tập trung vào
thông tin và không mấy để ý đến những gì có thể xảy ra với những hệ thống đó và
cách hoạt động (ứng xử) của hệ thống là ra sao. Đây là lối tiệm cận xoay quanh dữ
liệu và đã được áp dụng để tạo nên hàng ngàn hệ thống trong suốt nhiều năm trời.
Ưu điểm:Lối tiếp cận xoay quanh dữ liệu là phương pháp tốt cho việc thiết kế
ngân hàng dữ liệu và nắm bắt thông tin,
Nhược điểm: Nếu áp dụng cho việc thiết kế ứng dụng lại có thể khiến phát
sinh nhiều khó khăn. Một trong những thách thức lớn là yêu cầu đối với các hệ

thống thường xuyên thay đổi.
Một hệ thống xoay quanh dữ liệu có thể dể dàng xử lý việc thay đổi ngân hàng
dữ liệu, nhưng lại khó thực thi những thay đổi trong nguyên tắc nghiệp vụ hay cách
hoạt động của hệ thống.
Phương pháp hướng đối tượng đã được phát triển để trả lời cho vấn đề đó. Với
lối tiếp cận hướng đối tượng, chúng ta tập trung vào cả hai mặt của vấn đề : thông
tin và cách hoạt động.
1.1.2 Phương pháp hướng đối tượng
Hướng đối tượng là thuật ngữ thông dụng hiện thời của ngành công nghiệp
phần mềm. Các công ty đang nhanh chóng tìm cách áp dụng và tích hợp công nghệ
mới này vào các ứng dụng của họ. Thật sự là đa phần các ứng dụng hiện thời đều
mang tính hướng đối tượng. Nhưng hướng đối tượng có nghĩa là gì?

12


Lối tiếp cận hướng đối tượng là một lối tư duy về vấn đề theo lối ánh xạ các
thành phần trong bài toán vào các đối tượng ngoài đời thực. Với lối tiếp cận này,
chúng ta chia ứng dụng thành các thành phần nhỏ, gọi là các đối tượng, chúng
tương đối độc lập với nhau. Sau đó ta có thể xây dựng ứng dụng bằng cách chắp các
đối tượng đó lại với nhau. Hãy nghĩ đến trò chơi xây lâu đài bằng các mẫu gỗ. Bước
đầu tiên là tạo hay mua một vài loại mẫu gỗ căn bản, từ đó tạo nên các khối xây
dựng căn bản của mình. Một khi đã có các khối xây dựng đó, bạn có thể chắp ráp
chúng lại với nhau để tạo lâu đài. Tương tự như vậy một khi đã xây dựng một số đối
tượng căn bản trong thế giới máy tính, bạn có thể chắp chúng lại với nhau để tạo
ứng dụng của mình.
Ưu điểm: Một trong những ưu điểm quan trọng bậc nhất của phương pháp
phân tích và thiết kế hướng đối tượng là tính tái sử dụng: bạn có thể tạo các thành
phần (đối tượng) một lần và dùng chúng nhiều lần sau đó. Để giảm thiểu lỗi và các
khó khăn trong việc bảo trì, giúp tăng tốc độ thiết kế và phát triển phần mềm.

1.2 CÁC BƯỚC CƠ BẢN TRONG ƯỚC LƯỢNG PHẦN MỀM
Bốn bước chính trong ước lượng dự án phần mềm là:
- Ước lượng kích cỡ: Thông thường, điều này luôn yêu cầu một ước lượng của
kích cỡ của phần mềm được phát triển theo số dòng lệnh (LOC – line of code) hoặc
điểm chức năng (FP – Function Point). Trong khi kích cỡ theo LOC là đơn vị kích
cỡ cơ sở được dùng bởi nhiều mô hình tính toán ước lượng hàng đầu, nhiều đội phát
triển lại không thích với những phép đo này và dùng những đơn vị ít chính quy hơn
(số đặc tính, số yêu cầu thay đổi, số Use Case / số kịch bản, số tường thuật người
dùng, số phát biểu yêu cầu, …)
- Ước lượng nỗ lực: Uớc lượng nổ lực theo đơn vị [người – tháng] hoặc
[người – giờ] dùng một mô hình tính toán liên hệ nỗ lực với kích cỡ của phần mềm
và năng lực của đội phát triển.
- Ước lượng thời gian: Uớc lượng lịch trình theo lịch thời gian (tháng/tuần).
Điều này có thể được tính toán từ nhân lực được ước lượng và là một hàm số của

13


kích cỡ đội phát triển. Điều quan trọng là phải nhận thức rõ rằng đây không phải là
một quan hệ tuyến tính và ở một số điểm trong lịch trình dự án không thể rút ngắn
lịch trình bằng cách thêm tài nguyên cho việc phát triển.
- Ước lượng chi phí: Ước lượng chi phí dự án theo đơn vị tiền tệ. Điều này là
một kết hợp của giá nhân công (cái mà có thể được tính toán từ ước lượng nỗ lực)
và giá phi nhân công (ví dụ, giá khấu hao của các phần cứng và phần mềm cần thiết
được cung cấp cho dự án).
1.2.1 Ước lượng kích cỡ
Một ước lượng chính xác của kích cỡ của phần mềm được xây dựng là bước
đầu tiên cho một ước lượng có hiệu quả. Các tài nguyên thông tin về phạm vi của
dự án nên được thu thập bất cứ nơi nào có thể, bắt đầu với những mô tả chính thức
của các yêu cầu – ví dụ, một đặc tả các yêu cầu của khách hàng hoặc yêu cầu cho đề

xuất, một đặc tả hệ thống. Không nên để cho sự thiếu sót về đặc tả phạm vi làm cản
trở việc thực hiện ước lượng. Tài liệu ước lượng cũng không nên chốt cứng.
Trong mọi trường hợp, chúng ta phải xem xét các mức độ rủi ro và không chắc
chắn trong một ước lượng cho mọi khía cạnh và phải thực hiện lại ước lượng cho dự
án ngay khi có thêm thông tin phạm vi được xác định. Nếu chúng ta thực hiện ước
lượng lại một dự án ở những pha sau của vòng đời dự án, các tài liệu thiết kế có thể
được sử dụng để cung cấp thêm thông tin chi tiết.
Hai cách để có thể ước lượng kích cỡ sản phẩm là:
- Phép tương tự
Nếu chúng ta đã hoàn thành một dự án tương tự trong quá khứ và biết thông
tin kích cỡ sản phẩm đã được phát triển, chúng ta có thể ước lượng mỗi phần chính
của của dự án mới như là một phép tính phần trăm của kích cỡ của phần tương tự
của dự án trước. Ước lượng kích cỡ tổng thể của dự án mới bằng cách cộng lại các
kích cỡ được ước lượng của mỗi phần.
Hoặc là, chia sản phẩm thành những phần cấu thành (các đặc tính, các Use
Case/ kịch bản, các yêu cầu người dùng) và đếm chúng. Một số người dùng những

14


phép đếm thô như là một ước lượng trực tiếp của kích cỡ phần mềm, hoặc chúng ta
có thể chuyển chúng thành một đơn vị đo kích cỡ chính thức mà ta biết, theo một
phép tính trung bình, bao nhiêu LOC hoặc FP mà mỗi phần này yêu cầu trong
những dự án trước.
Một người có kinh nghiệm có thể đưa ra những ước lượng kích cỡ tốt, hợp lý
bằng phép tương tự nếu sẵn có các giá trị kích cỡ chuẩn xác cho dự án trước và dự
án mới là gần giống với dự án trước.
- Phép phân tích
Bằng cách đếm các đặc điểm sản phẩm và dùng một phương pháp thuật toán
như là Điểm Chức năng (FP) chúng ta có thể chuyển phép đếm thành một ước

lượng của kích cỡ.
Các đặc tính sản phẩm ở cấp độ vĩ mô có thể chứa số lượng các hệ thống con,
các lớp/ mô – đun, các phương thức/ hàm. Các đặc tính sản phẩm ở mức chi tiết hơn
có thể gồm có số lượng các màn hình, các hộp thoại, các file, các bảng cơ sở dữ
liệu, các báo cáo, các thông điệp…
1.2.2 Ước lượng nỗ lực
Một khi chúng ta có một ước lượng của kích cỡ của sản phẩm, chúng ta có thể
tính toán ước lượng nỗ lực từ nó. Việc chuyển đổi từ kích cỡ phần mềm sang nỗ lực
dự án tổng cộng chỉ có thể làm được nếu chúng ta có một vòng đời phát triển phần
mềm xác định và tiến trình phát triển mà ta sử dụng ổn định trên dự án để phân tích,
thiết kế, phát triển và kiểm thử phần mềm.
Một dự án phát triển phần mềm đòi hỏi nhiều hơn công việc viết mã phần
mềm đơn thuần – trên thực tế, việc mã hóa chỉ chiếm chưa đến

¼ tổng thể nỗ lực

dự án. Việc viết và thẩm định tài liệu, thi hành các bản mẫu, thiết kế các phiên bản
có thể phân phối, và thẩm định, kiểm thử mã chiếm phần lớn hơn của nỗ lực dự án
tổng thể. Ước lượng nỗ lực dự án yêu cầu ta xác định và ước lượng, và sau đó tổng
hợp lại tất cả các hoạt động ta phải thực hiện để xây dựng một sản phẩm từ kích cỡ
được ước lượng.

15


Hai cách có thể dùng để tính toán nỗ lực từ kích cỡ:
- Dùng dữ liệu lịch sử
Là dùng dữ liệu lịch sử của chính tổ chức để xác định bao nhiêu nỗ lực theo
kích cỡ ước lượng mà các dự án trước dùng đến. Một sơ đồ tính toán mà liên hệ
kích cỡ của sản phẩm và năng suất của đội phát triển với nỗ lực dự án được ước

lượng được sử dụng thường xuyên.
Dĩ nhiên, cách thức này giả định rằng:
+ Tổ chức của chúng ta đã lập tài liệu các kết quả thực tế từ các dự án trước.
+ Chúng ta có ít nhất một dự án trong quá khứ với kích cỡ tương tự (rõ ràng là
tốt hơn nếu chúng ta có nhiều dự án với kích cỡ tương tự để củng cố rằng chúng ta
cần ổn định một mức độ nào đó của nỗ lực để phát triển các dự án của kích cỡ được
đưa ra)
+ Chúng ta sẽ tuân theo một vòng đời phát triển tương tự, sử dụng một
phương pháp phát triển tương tự, các công cụ tương tự, và có một đội phát triển với
các kĩ năng và kinh nghiệm tương tự cho dự án mới.
- Tiếp cận thuật toán
Nếu chúng ta không có dữ liệu lịch sử của chính tổ chức bởi vì chúng ta chưa
bắt đầu thu thập số liệu hoặc vì dự án mới là rất khác, chúng ra có thể sử dụng một
cách tiếp cận thuật toán đã hoàn thiện và đã được công nhận rộng rãi (ví dụ mô hình
COCOMO của Barry Boehm) để chuyển một ước lượng kích cỡ thành một ước
lượng nỗ lực.
Các mô hình này có được từ việc nghiên cứu một số lượng lớn các dự án đã
hoàn thành từ nhiều tổ chức khác nhau để xem xét các kích cỡ dự án ánh xạ như thế
nào với nỗ lực dự án tổng cộng.
Các mô hình “dữ liệu công nghiệp” này có thể không được chuẩn xác như là
dữ liệu lịch sử của chính tổ chức của chúng ta, nhưng chúng có thể cho chúng ta
những ước lượng nỗ lực gần đúng hữu ích.

16


1.2.3 Ước lượng thời gian
Bước thứ ba trong ước lượng một dự án phát triển phần mềm là xác định lịch
trình dự án từ ước lượng nỗ lực. Điều này thường đòi hỏi ước lượng số lượng người
sẽ làm việc trên dự án, cái gì họ sẽ làm (cấu trúc phân cấp chia nhỏ công việc), khi

nào họ sẽ bắt đầu làm việc trên dự án và khi nào họ sẽ kết thúc (cái này là “mô tả
biên chế”). Một khi chúng ta có thông tin này, chúng ta cần tính toán để đưa nó vào
một lịch trình theo lịch thời gian. Ngoài ra, dữ liệu lịch sử từ các dự án trong quá
khứ của tổ chức hoặc các mô hình dữ liệu công nghiệp có thể được sử dụng để dự
đoán số lượng người mà chúng ta cần cho một dự án với kích cỡ cho trước và làm
thế nào công việc có thể chia nhỏ vào lịch trình.
Nếu chúng ta không có gì, một quy tắc ước lượng lịch trình ([9] McConnell, 1996)
có thể được dùng để lấy một ý tưởng thô của thời gian lịch tổng cổng cần thiết:
lịch trình theo tháng = 3.0 * ( nỗ lực[người – tháng] )1/3
Thí dụ, nếu chúng ra đã ước lượng một dự án cần nỗ lực 65 [người – tháng],
biểu thức trên cho thấy rằng cần lịch trình 12 tháng , từ đó suy đội dự án có 5 hoặc 6
thành viên (65/12).
Trong ([9] McConnell. 1996) có nêu vấn đề nhiều đề xuất dùng 2.0 hay 2.5
hay ngay cả 4.0 để thay thế cho giá trị 3.0 – chỉ bằng cách dùng thử ta sẽ thấy nó
như thế nào.
Ước lượng lịch trình dự án là một chủ đề rắc rối bởi vì hầu hết các dự án
thường bị chậm trễ. Sự chậm trễ do nhiều nguyên nhân. Các yêu cầu được phát hiện
dần dần không được quản lý chủ động. Việc điều khiển chất lượng sản phẩm từ sớm
thường không được chú trọng, dẫn đến dự án sẽ bị chậm trễ khi kiểm thử bắt đầu. Ở
những tổ chức chưa có quy trình làm việc chuẩn thì những dự thảo lịch trình thường
bị bỏ qua bởi ngay từ những người điều hành cấp cao.
Xem xét công việc quản trị dự án và công việc ước lượng lịch trình, để ý rằng
công việc ước lượng lịch trình sẽ quan tâm đến việc lên lịch trình ở mức độ cao của
toàn dự án, còn những tính toán chi tiết hơn đòi hỏi các phụ thuộc yếu tố, đội ngũ

17


nhân viên sẵn có, và mức độ tài nguyên, phân công cho từng người sẽ được thực
hiện bởi công việc quản trị dự án.

Nếu ước lượng theo biểu thức tính lịch trình ở trên, ta ước lượng thời gian lịch trình
trước rồi mới chỉ định số nhân viên. Nhưng nếu được chỉ định một đội phát triển trước,
một biểu thức cơ bản cho việc ước lượng lịch trình của bất kỳ hoạt động quản lý là:
Nỗ lực[người – tháng] / Số nhân viên[người] = Lượng thời gian
Dùng biểu thức tổng quát này, một hoạt động mà yêu cầu 8 [người – tháng]
của nỗ lực và có 4 người được chỉ định tham gia có thể được hoàn thành trong thời
gian 2 tháng.
8 [người – tháng] / 4 [người] = 2 [tháng]
Thực tế thì việc ước lượng lịch trình sẽ khó hơn rất nhiều. Nó liên quan đến
nhiều yếu tố như:
+ Các phụ thuộc của một hoạt động với các hoạt động trước
+ Các hoạt động đan xen hay đồng thời
+ Đường găng xuyên suốt chuỗi công việc
+ Số ca làm việc mỗi ngày, số giờ làm việc hiệu quả trong mỗi ca
+ Những gián đoạn như là du lịch, hội nghị, đào tạo hay nghỉ ốm,…
+ Số lượng vùng thời gian cho các dự án đối với các công ty đa quốc gia
Như vậy công việc quản trị dự án và công việc ước lượng lịch trình có nhiều
mối liên hệ và được thực hiện theo sự tinh tế của từng người quản lý.
1.2.4 Ước lượng chi phí
Có nhiều yếu tố để quan tâm khi ước lượng chi phí tổng cộng của một dự án.
Bao gồm giá nhân công, giá mua hay giá thuê phần cứng và phần mềm, việc đi lại
cho mục đích gặp gỡ hay kiểm thử, các giao tiếp (thí dụ, các cuộc gọi điện thoại
đường dài, hội thảo video từ xa, …), các khóa đào tạo, không gian văn phòng, …

18


Giá nhân công thì có thể được xác định một cách đơn giản nhất bằng phép
nhân ước lượng nỗ lực của dự án (theo giờ) với lương nhân công tính trung bình
tổng quát. Một chi phí nhân công chuẩn xác hơn lấy kết quả từ việc sử dụng lương

nhân công rõ ràng cho mỗi vị trí (thí dụ, vị trí kĩ thuật, quản lý chất lượng, quản lý
dự án, người lập tài liệu, cộng tác viên, …). Chúng ra sẽ phải xác định xem bao
nhiêu phần trăm của nỗ lực dự án tổng cộng cần được cấp phát cho mỗi vị trí. Khi
này dữ liệu lịch sử hoặc các mô hình dữ liệu công nghiệp lại có thể trợ giúp.
Qua việc nghiên cứu 4 bước trong phép ước lượng như trên, đề xuất một tiến
trình cơ sở cho việc ước lượng như được mô tả trong sơ đồ ở Hình 1.1:
Thu thập các yêu cầu ban đầu

Ước lượng kích cỡ sản phẩm

Dữ liệu dự án
Ước lượng nỗ lực

lịch sử
Các tài nguyên

Đưa ra lịch trình

sãn có
Dữ liệu giá hiện
thời

Ước lượng chi phí

Ước lượng phê
duyệt

Phê duyệt ước lượng

Kích cỡ, nỗ lực,

chi phí thực tế

Hình
1.1. Tiến trình cơ sở Ước lượng dự án (Hewson,
2007)
Phân tích
tiến trình ước lượng
Phát triển
sản phẩm

19


1.3 TIỂU KẾT CHƯƠNG 1
Trong chương 1 trình bày tổng quan về ước lượng phần mềm, nêu ra hai
phương pháp xây dựng phần mềm cơ bản để đánh giá ưu nhược điểm của từng
phương pháp. Tóm tắt lại bốn bước để ước lượng phần mềm để thấy rõ tầm quan
trọng của từng giai đoạn.

20


Chương 2. CÁC PHƯƠNG PHÁP ƯỚC LƯỢNG PHẦN MỀM
2.1 PHƯƠNG PHÁP SƠ ĐỒ MẠNG LƯỚI PERT VÀ PHƯƠNG PHÁP SƠ
ĐỒ GANTT
2.1.1 Phương pháp sơ đồ mạng lưới PERT
a. Tóm lược
Kỹ thuật tổng quan và đánh giá dự án PERT (Program and Evaluation Review
Technique) là một công cụ thống kê được sử dụng trong quản lý dự án, được thiết
kế để phân tích và ước tính thời lượng thực hiện công tác (công việc) trong các dự

án mà công tác (công việc) có thời lượng không xác định trước. (thời lượng công
việc là yếu tố công việc tham gia vào việc hoàn thành toàn bộ dự án).
b. Nội dung phương pháp
Về phương pháp thực hiện, Pert có 6 bước cơ bản:
- Xác định các công việc (nhiệm vụ) cần thực hiện của các dự án
- Xác định mối quan hệ và trình tự thực hiện các công việc
- Vẽ sơ đồ mạng công việc
- Tính toán thời gian và chi phí cho từng công việc của dự án
- Xác định thời gian dự trữ của các công việc và sự kiện
- Xác định đường găng
Để lập sơ đồ PERT cần phải biết độ dài của các công việc và mối liên hệ của
các công việc đó. Khi lập sơ dồ PERT cần tuân theo những nguyên tắc sau:
- Một sơ đồ PERT chỉ có một điểm đầu và một điểm cuối.
- Mỗi công việc được biểu diễn chỉ bằng một cung có mũi tên chỉ hướng trên
sơ đồ mạng, có độ dài tương ứng với thời gian thực hiện công việc đó.
* Ví dụ: Cần phải thực hiện 4 công việc, công việc a có độ dài 5 ngày, công
việc b có độ dài 3 ngày, công việc c có độ dài 4 ngày, công việc d có độ dài 5 ngày,

21


công việc b và c được tiến hành sau công việc a, công việc d chỉ được tiến hành sau
khi b và c đã kết thúc.

Hình 2.1. Biểu diễn một mạng các công việc
Trong đó:
+ a(5): công việc a có độ dài 5
+

1

2

: sự kiện bắt đầu và kết thúc công việc a

+ a(5), b(3): hai công việc a,b nối tiếp
+b(3), c(4): hai công việc song song
+c(4),e(0): hai công việc hội tụ
- Do yêu cầu của việc trình bày mối quan hệ trước sau giữa các công việc, đôi
khi bắt buộc phải đưa vào các công việc giả có độ dài bằng 0 (e(0) Hình 2.1):
- Các yếu tố thời gian của các sự kiện trong mạng công việc được thể hiện như sau:

Hình 2.2. Biểu diễn các yếu tố thời gian của sự kiện

22


Trong đó:
+ i,j : Các sự kiện i,j và sự kiện i trước sự kiện j
+ : Thời gian xuất hiện sớm của sự kiện i, j
+ : Thời gian xuất hiện muộn của sự kiện i,j
+ : Thời gian thực hiện công việc i,j
+ : Thời gian dự trữ của i,j
+ : Thời gian dự trữ (dự trữ chung) của công việc i,j
Tính thời gian xuất hiện sớm của các sự kiện: Thời gian xuất hiện sớm của sự
kiện j là thời gian sớm nhất kể từ khi bắt đầu dự án đến khi đạt tới sự kiện j
- Thời gian xuất hiện sớm của các sự kiện được tính từ trái sang phải, với sự
kiện bắt đầu, thời gian xuất hiện sớm bằng 0.
Tính thời gian xuất hiện muộn của các sự kiện: Thời gian xuất hiện muộn của
sự kiện i là thời gian chậm nhất phải đạt tới sự kiện i nếu không muốn kéo dài toàn

bộ thời gian hoàn thành dự án.

- Để xác định thời hạn muộn nhất của sự kiện i trước hết phải xác định giới
hạn kết thúc của toàn bộ dự án và xuất phát từ đó thời gian xuất hiện muộn của các
sự kiện được tính từ phải sang trái. Với sự kiện kết thúc ta có thời gian xuất hiện
sớm bằng thời gian xuất hiện muộn.
Xác định các sự kiện găng và những công việc găng:
- Những sự kiện găng là những sự kiện có thời gian xuất hiện sớm bằng thời
gian xuất hiện muộn. Đường găng là đường đi qua các sự kiện găng.
- Những công việc găng là những công việc nằm trên đường găng.
Xác định thời gian dự trữ của các công việc: Đối với mỗi công việc người ta
xác định 3 loại thời gian dự trữ sau:

23


- Thời gian dự trữ tự do của công việc ij:
- Thời gian dự trữ hoàn toàn của công việc ij:
- Thời gian dự trữ chắc chắn của công việc ij:
c. Đánh giá phương pháp
Ưu điểm:
Khi sử dụng PERT sẽ bắt buộc các quản trị viên luôn lập kế hoạch thực hiện.
Tạo điều kiện cho các quản trị viên tìm ra các khâu trọng yếu cần phải tác
động trong suốt quá trình thực hiện.
Thông qua sơ đồ PERT chúng ta có thể xác định dễ dàng những yếu tố phụ
thuộc cần tác động vào những thời điểm thích hợp để hoàn thành kế hoạch một cách
nhanh chóng.
Theo dõi diễn biến của quá trình thực hiện dự án
Xác định đường tới hạn và lựa chọn con đường thích hợp nhất.
Nhược điểm:

Sơ đồ PERT chỉ phản ánh chủ yếu về tiến độ thực hiện dự án chứ chưa phản
ánh chi phí cần thiết để thực hiện dự án, từ đó có thể thấy rằng phương pháp này chỉ
có tác dụng lớn trong việc kiểm soát tiến độ, thời gian thực hiện và bỏ qua yếu tố
chi phí.
2.1.2 Phương pháp sơ đồ Gantt
a. Tóm lược:
Sơ đồ Gantt được xây dựng vào năm 1915 bởi Henry L.Gantt, một trong
những nhà tiên phong về lĩnh vực quản lý khoa học. Đây là một trong những công
cụ cổ điển nhất nhưng vẫn được sử dụng phổ biến trong quản lý tiến độ thực hiện
dự án (việc thực hiện một đề tài NCKH cũng có thể xem là một dự án). Nó biểu
diễn thời gian thực hiện các nhiệm vụ trong dự án, giúp cho các nhà quản lý dự án
theo dõi và quản lý công việc dễ dàng hơn.

24


Nhìn vào biểu đồ Gantt, người quản lý dự án, cũng như các thành viên thực
hiện dự án biết được:
- Trình tự thực hiện mỗi nhiệm vụ.
- Tiến độ dự án: biết được mình đã làm được gì và tiếp tục phải thực hiện công việc
đó thế nào, bởi vì mỗi công việc được giao phải hoàn thành trong thời gian đã định.
- Thấy sự phụ thuộc lẫn nhau giữa các công việc.
b. Nội dung phương pháp
Trong sơ đồ Gantt:
- Các công tác được biếu diễn trên trục tung.
- Thời gian tương ứng được thể hiện trên trục hoành – đó là những đoạn thẳng nằm
ngang có độ dài nhất định chỉ thời điểm bắt đầu, thời gian thực hiện, thời điểm kết thúc.
Các bước cơ bản trong khi tiến hành xây dựng sơ đồ Gantt:
- Định nghĩa các hoạt động.
- Tính toán thời gian cần thiết để hoàn thành công việc cho mỗi hoạt động, tùy

thuộc vào khối lượng công việc, nguồn lực cho phép, tổng thời gian để hoàn thành.
- Xác định mối liên hệ giữa các hoạt động.
- Vẽ lịch thực hiện đề tài (mỗi công việc được biểu diễn bằng một thanh ngang
theo trục hoành thời gian).
- Điều chỉnh thời gian các tất cả các công việc cho đến khi hoàn thành lịch
trình (sắp xếp các hoạt động sao cho thời điểm hoàn thành của chúng không vượt
quá thời điểm hoàn thành đề tài đã được định trước).
Ví dụ:Một công việc X được thực hiện trong 15 tuần, bao gồm 6 nhiệm vụ với
các thông tin chi tiết sau:

Bảng 2.1. Danh sách các công việc

25