nghiên cứu ước lượng dự án

Phần 2 có nội dung giới thiệu và đánh giá phương pháp ước lượng dự án phần mềm dựa trên Điểm Ca Sử dụng UCP – Use Case Point, là phương pháp rất phù hợp cho những dự án được kĩ nghệ theo

Phần 2 có nội dung giới thiệu và đánh giá phương pháp ước lượng dự án phần mềm dựa trên Điểm Ca Sử dụng (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 Trong phần này, sẽ tiến hành xây dựng một chương trình tính toán hỗ trợ cho việc ước lượng theo phương pháp Điểm

Ca Sử dụng Chương trình được kĩ nghệ theo phương pháp Hướng Đối tượng và tài liệu phân tích của nó lại được dùng cho việc đánh giá thực tế áp dụng phương pháp Điểm Ca Sử dụng

MỤC LỤC

LỜICÁMƠN

TÓMTẮTNỘIDUNG

MỤCLỤC

DANHSÁCHCÁCTỪVIẾTTẮT

DANHSÁCHCÁCBẢNG

DANHSÁCHCÁCHÌNH

PHẦN 1 TỔNG QUAN VỀ PHƯƠNG PHÁP ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM

CHƯƠNG 1 NHỮNGNGUYÊNTẮCCƠBẢNTRONGƯỚCLƯỢNGDỰÁNPHẦN

MỀM

1.1 Tổng quan ước lượng dự án phần mềm 2

1.2 Bốn bước cơ bản trong ước lượng dự án phần mềm 4

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

1.2.2 Ước lượng nỗ lực 5

1.2.2.1 Vấn đề ước lượng nỗ lực trực tiếp 7

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

1.2.4 Ước lượng chi phí 8

CHƯƠNG 2 NGHIÊNCỨUPHƯƠNGPHÁPƯỚCLƯỢNGDỰÁNPHẦNMỀM TRUYỀNTHỐNG 2.1 Phương pháp Phân tích Điểm Chức năng (FPA – Function Points Analysis) 11

2.1.1 Tóm lược 11

2.1.2 Nội dung của phương pháp 11

2.1.3 Đánh giá phương pháp 14

2.2 Mô hình ước lượng giá cấu thành (COCOMO – Constructive Cost Model) 16

2.2.1 Tóm lược 16

2.2.2 Nội dung mô hình 16

2.2.2.1 Mô hình COCOMO cơ sở (basic COCOMO) 16

2.2.2.2 Mô hình COCOMO trung cấp (intermediate COCOMO) 17

2.2.2.3 Mô hình COCOMO nâng cao (advanded COCOMO) 20

2.2.3 Đánh giá mô hình 20

2.3 Kết hợp Phương pháp Phân tích Điểm Chức năng với Mô hình Giá Cấu thành (FPA và COCOMO) 21

2.3.1 Nội dung kết hợp 21

2.3.2 Đánh giá phép kết hợp 22

PHẦN 2 ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM THEO ĐIỂM CA SỬ DỤNG CHƯƠNG 3 GIỚITHIỆUPHƯƠNGPHÁPƯỚCLƯỢNGDỰÁNPHẦNMỀMTHEO ĐIỂMCASỬDỤNG (USECASEPOINT) 3.1 Tóm lược 25

3.2 Nội dung phương pháp 26

3.2.1 Tính số Điểm Ca Sử dụng (UCPs) 26

3.2.1.1 Tính số Điểm Ca Sử dụng Chưa được điều chỉnh (UUCPs – Unadjusted Use Case Points) 27 3.2.1.2 Tính Yếu tố Độ phức tạp Kĩ thuật 31

3.2.1.3 Tính Yếu tố Độ phức tạp Môi trường (ECF – Environmental Complexity Factor) 33

3.2.1.4 Tính số Điểm Ca Sử dụng 36

3.2.2 Ước lượng nỗ lực từ số Điểm Ca Sử dụng 36

CHƯƠNG 4 XÂYDỰNGCHƯƠNGTRÌNHTÍNHTOÁNHỖTRỢƯỚCLƯỢNG UCP ESTIMATOR 4.1 Phát biểu bài toán 38

4.2 Phân tích bài toán 38

4.2.1 Phân tích tổng thể 38

4.2.2 Phân tích cụ thể chức năng 39

4.3 Đặc tả chương trình 39

4.3.1 Biểu đồ ca sử dụng của chương trình 39

4.3.2 Các biểu đồ hoạt động 40

4.3.2.1 Biểu đồ hoạt động của ca sử dụng số 1 40

4.3.2.2 Biểu đồ hoạt động của ca sử dụng số 2 41

4.4 Thiết kế logic hoạt động cho chương trình 42

4.4.1 Xác định các lớp phân tích 42

4.4.2 Các biểu đồ cộng tác 42

4.4.2.1 Biểu đồ cộng tác cho ca sử dụng số 1 42

4.4.2.2 Biểu đồ cộng tác cho ca sử dụng số 2 43

4.4.3 Các biểu đồ tuần tự 44

4.4.3.1 Biểu đồ tuần tự cho ca sử dụng số 1 44

4.4.3.2 Biểu đồ tuần tự cho ca sử dụng số 2 45

4.5 Thiết kế cơ sở dữ liệu 45

4.5.1 Phân tích bài toán để xây dựng cơ sở dữ liệu 45

4.5.2 Xây dựng biểu dồ thực thể - liên kết (E-R) 46

4.5.3 Xây dựng lược đồ quan hệ 49

CHƯƠNG 5 ÁPDỤNGVÀĐÁNHGIÁPHƯƠNGPHÁPƯỚCLƯỢNGĐIỂMCASỬ DỤNG 5.1 Áp dụng thực tế 51

5.1.1 Bài toán số 1 – Dự án xây dựng mô–đun cho máy rút tiền ATM 51

5.1.1.1 Miêu tả dự án 51

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

tính số Điểm Ca Sử dụng 51

5.1.1.3 Ước lượng nỗ lực 53

5.1.2 Bài toán số 2 – Dự án xây dựng chương trình UCP Estimator 53

5.1.2.1 Miêu tả dự án 53

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

tính số Điểm Ca Sử dụng 54

5.1.2.3 Ước lượng nỗ lực 59

5.2 Đánh giá phương pháp 59

5.2.1 Đánh giá quy trình tính toán 59

5.2.1.1 So sánh UCP với FPA 59

5.2.1.2 So sánh UCP với COCOMO 60

5.2.2 Đánh giá trên thực tế 61

5.2.3 Kết luận 62

5.3 Đề xuất hướng phát triển 62

5.3.1 Phát triển lý thuyết chương trình 62

5.3.2 Phát triển chương trình tính toán UCP Estimator 63

PHỤLỤCA.DỰÁNXÂYDỰNGMÔ–ĐUNATM 64

TÀILIỆUTHAMKHẢO 69

DANH SÁCH CÁC TỪ VIẾT TẮT

COCOMO : COnstructive COst MOdel – Mô hình giá cấu thành

EAF : Effort Adjust Factor – yếu tố điều chỉnh nỗ lực

ECF : Environmental Complexity Factor – Yếu tố độ phức tạp môi trường

ER : Effort Rating – tỉ lệ nỗ lực

FP : Function Point – Điểm chức năng

FPA : Function Point Analysis – Phân tích điểm chức năng

FPs : Function Points – số Điểm chức năng

KLOC : Kilo Line Of Code – số nghìn dòng lệnh

LOC : Line Of Code – số dòng lệnh

RUP : Rational Unified Process – Tiến trình thống nhất

TCF : Technical Complexity Factor – Yếu tố độ phức tạp kĩ thuật

UCP : Use Case Point – Điểm ca sử dụng

UCPs : Use Case Points – số Điểm ca sử dụng

UFP : Unadjusted Function Point – Điểm Chức năng chưa được điều chỉnh

UFPs : Unadjusted Function Points – số Điểm Chức năng chưa được điều

chỉnh UML : Unified Modelling Language – ngôn ngữ mô hình hóa thống nhất

UUCP : Unadjusted Use Case Point – Điểm ca sử dụng chưa được điều chỉnh

UUCPs : Unadjusted Use Case Point – số Điểm ca sử dụng chưa được điều

chỉnh WAs : Weighted Actors – số lượng Tác nhân sau khi đánh trọng số

WUCs : Weighted Use Cases – số lượng Ca sử dụng sau khi đánh trọng số

DANH SÁCH CÁC BẢNG

Chương 1:

Chương 2:

Bảng 2-1 Tính UFPs – kích cỡ xử lý thông tin thô – trong FPA

Bảng 2-2 Mười bốn Yếu tố kĩ thuật trong FPA

Bảng 2-3 Phân loại chế độ phát triển sản phẩm trong COCOMO cơ sở

Bảng 2-4 Các Yếu tố điều chỉnh trong COCOMO trung cấp

Bảng 2-5 Phân loại chế độ phát triển trong COCOMO trung cấp

Bảng 2-6 Đề xuất tỉ lệ LOC/FP cho phép kết hợp FPA và COCOMO

Chương 3:

Bảng 3-1 Phân loại và đánh trọng số ca sử dụng trong UCP

Bảng 3-2 Ví dụ đếm số ca sử dụng sau khi đánh trọng số

Bảng 3-3 Phân loại và đánh trọng số tác nhân trong UCP

Bảng 3-4 Ví dụ đếm số tác nhân sau khi đánh trọng số

Bảng 3-5 Trọng số của 13 yếu tố kĩ thuật trong UCP

Bảng 3-6 Ví dụ tính Yếu tố Độ phức tạp Kĩ thuật trong UCP

Bảng 3-7 Trọng số của 8 yếu tố môi trường trong UCP

Bảng 3-8 Ví dụ tính Yếu tố Độ phức tạp Môi trường trong UCP

Chương 4:

Bảng 4-3 Kịch bản ca sử dụng “Thực hiện ước lượng mới” – UCP Estimator

Bảng 4-4 Kịch bản ca sử dụng “Tìm kiếm ước lượng lịch sử” – UCP Estimator

Chương 5:

Bảng 5-5 Đếm WUCs - dự án ATM

Bảng 5-2 Đếm WAs – dự án ATM

Bảng 5-3 Đếm WUCs - dự án UCP Estimator

Bảng 5-4 Đếm WAs - dự án UCP Estimator

Bảng 5-5 Cho điểm các Yếu tố kĩ thuật - dự án UCP Estimator

Bảng 5-6 Cho điểm các Yếu tố môi trường - dự án UCP Estimator

DANH SÁCH CÁC HÌNH

Chương 1:

Hình 1-1 Đồ thị hội tụ ước lượng

Hình 1-2 Tiến trình cơ sở Ước lượng dự án

Chương 2:

Chương 3:

Chương 4:

Hình 4-1 Biểu đồ ca sử dụng tổng thể - UCP Estimator

Hình 4-2 Biểu đồ hoạt động của ca sử dụng "Thực hiện Ước lượng mới" - UCP

1

PHẦN 1 TỔNG QUAN VỀ PHƯƠNG PHÁP ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM

2

Chương 1 NHỮNG NGUYÊN TẮC CƠ BẢN TRONG

ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM

1.1 Tổng quan ước lượng dự án phần mềm

Ước lượng dự án phần mềm hiệu quả là một hoạt động quan trọng, đồng thời cũng là một thách thức trong phát triển phần mềm Ước lượng là một trong những nền tảng cho việc lập lịch dự án một cách hiệu quả: Lập kế hoạch và điều khiển dự án có hiệu quả là không thể nếu không có một ước lượng đầy đủ và đáng tin cậy Nhiều tổ chức phải chịu các tác động tài chính lên công việc của họ, bị mất lợi thế cạnh tranh, và chậm trễ trong việc hưởng lợi từ kế hoạch và các sáng kiến do các các ước lượng xấu Cho đến bây giờ cũng dễ nhận thấy rằng ngành công nghiệp phần mềm nói chung không có nhiều ước lượng dự án tốt và cũng không sử dụng các ước lượng hợp lý Hình 1-1 , tham khảo từ tài liệu ([6] McConnell, 1996) thể hiện độ hội tụ của ước lượng trong vòng đời phát triển dự án của các dự án thực tế, ước lượng chỉ được chính xác hóa dần dần trong quá trình làm mịn dần dự án Từ hình vẽ có thế nhận thấy rằng

để đưa ra được các ước lượng đáng tin cậy và sớm trong vòng đời phát triển của dự án

là rất khó Chúng ta phải chịu nhiều thiệt hại hơn như là một hậu quả, dó đó chúng ta cần tập trung nhiều nỗ lực để giải quyết tình hình

Ước lượng thiếu một dự án dẫn đến (a) việc bố trí thiếu cho dự án (điều mà thường dẫn đến việc vượt quá khả năng làm việc), (b) quản lý thiếu các nỗ lực đảm bảo chất lượng (bỏ sót các nguy cơ rủi ro của sản phẩm kém chất lượng), và (c) tạo ra một lịch trình làm việc quá ngắn (dẫn đến sự mất uy tín do thời hạn thỏa thuận với khách hàng không được tôn trọng)

Còn đối với những người mà mong muốn tránh khỏi tình huống này bằng cách thêm nhiều yếu tố thừa vào ước lượng, thì ước lượng thừa một dự án có thể chỉ làm tồi tệ cho tổ chức Nếu như đưa cho một dự án nhiều tài nguyên hơn mức nó thực sự cần mà không có những điều hành phạm vi đầy đủ, nó sẽ bị dùng hết Điều này giống như là

quy tắc Parkinson được mô tả trong bài viết ([10] What Is Parkinson’s Law in Project

Chương 1

3

Management?, 2010):

“Work expands so as to fill the time available for its completion”

tạm dịch là:“Công việc mở rộng để lấp đầy thời gian có sẵn để hoàn thành”

Dự án khi đó có khả năng phải (a) chi phí nhiều hơn mức cần thiết (một tác động tiêu cực đến tài chính và có thể làm giảm lợi thế cạnh tranh), (b) mất nhiều thời gian hơn

để hoàn thành (dẫn đến đánh mất các cơ hội), và (c) trì hoãn việc sử dụng tài nguyên ở các dự án tiếp theo

Xác định sản phẩm được đồng ý

Đặc tả thiết kế chi tiết

Sản phẩm hoàn thành

Đặc tả thiết kế sản phẩm

Đặc tả yêu cầu

0.6 x

0.8 x 0.85 x 0.9 x 1.0 x

Hình 1-3 Đồ thị hội tụ ước lượng Độ chính xác của ước lượng chỉ được cải tiến chính trong quá trình phát

triển Nguồn tham khảo: ([6] McConnell 1996)

4

1.2 Bốn bước cơ bản trong ước lượng dự án phần mềm

Bốn bước chính trong ước lượng dự án phần mềm là:

1) ước lượng phạm vi của sản phẩm phát triển 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ố ca sử dụng / số kịch bản, số tường thuật người dùng, số phát biểu yêu cầu,

…) Một thảo luận về các ưu điểm và nhược điểm của các phương pháp đo kích

cỡ khác nhau sẽ được đề cập ở phần sau

2) ướ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 cỡ của phần mềm và năng suất của đội phát triển

3) ướ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ừ nỗ lực được ước lượng và là một hàm số của 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

4) ướ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 1

5

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à:

1) Cách thứ nhất: bằng 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 ca sử dụng/ 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 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

2) Cách thứ hai: bằng 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, …

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

1) Cách thứ nhất: 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 (a) 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, rằng (b) 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), và rằng (c) 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

2) Cách thứ hai: 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

Chương 1

7

1.2.2.1 Vấn đề ước lượng nỗ lực trực tiếp

Như đã đề cập, nhiều tổ chức trong nền công nhiệp phần mềm không thấy thoải mái với khái niệm ước lượng kích cỡ sản phẩm Không phải là lạ khi nhìn thấy nỗ lực được ước lượng trực tiếp từ một mô tả của sản phẩm/dự án, bỏ qua hoàn toàn ước lượng kích cỡ Trong khi điều này hoàn toàn có thể làm được, nó cũng nảy sinh vấn đề Các ước lượng trực tiếp tới nỗ lực đã ngầm giả định năng suất của đội phát triển cụ thể Khi đó nếu, giống như thường thấy là, ước lượng ban đầu không theo các mục đích của chúng ta, việc làm lại ước lượng để xem điều gì xảy ra với những đội phát triển khác đòi hỏi ước lượng phải được tính lại từ đầu Bằng cách ước lượng kích cỡ trước chúng ta dễ dàng làm lại nhanh ước lượng nỗ lực cho những năng suất làm việc khác nhau của những đội phát triển khác nhau

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

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 ([6] 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 (3.0 * 651/3), từ đó suy đội dự án có 5 hoặc 6 thành viên (65 /12)

Trong ([6] 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

8

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ũ 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 / Số nhân viên = 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, …

Chương 1

9

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

10

Kích cỡ, nỗ lực,chi phí thực tế, …

Ước lượng chi phí

Phê duyệt ước

Các tài nguyên sẵn có

Dữ liệu dự án lịch sử

Hình 1-4 Tiến trình cơ sở Ước lượng dự án Nguồn tham khảo: ([3] Hewson, 2007)

Chương 2 – Khóa luận tốt nghiệp – Nguyễn Trần Việt

11

Chương 2 NGHIÊN CỨU PHƯƠNG PHÁP ƯỚC

LƯỢNG DỰ ÁN PHẦN MỀM

TRUYỀN THỐNG

Đã 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 Trong chương này em sẽ nêu nội dung thuật toán và đánh giá phân tích 2 phương pháp này cũng như

3 bước để tiến hành ước lượng kích cỡ của một hệ thống được xây dựng bằng phương pháp phân tích Điểm Chức năng:

- Xác định kích cỡ xử lý thông tin thô của hệ thống

- Đánh giá Yếu tố Độ phức tạp Kĩ thuật của hệ thống

- Tính toán cuối cùng

Tính toán cụ thể:

12

Bước 1: Xác định kích cỡ xử lý thông tin thô của hệ thống

Kích cỡ xử lý thông được tính bởi phép xác định các thành phần hệ thống như được thấy bởi người dùng cuối, và phân loại chúng thành 5 loại:

- Các đầu vào ngoại vi

- Các đầu ra ngoại vi

- Các truy vấn ngoại vi

- Các file logic nội bộ

- Các giao diện ngoại vi

Mỗi thành phần thuộc mỗi loại lại được đánh giá độ phức tạp là “đơn giản”, “trung bình” hay “phức tạp” phụ thuộc số lượng phần tử dữ liệu mỗi loại và các yếu tố khác Sau đó đánh trọng số (cho điểm) đến từng độ phức tạp của mỗi loại thành phần

Cộng điểm tổng cộng để xác định kích cỡ xử lý thông tin thô, gọi là tổng Điểm Chức năng Chưa được điều chỉnh (UFPs – Unadjusted Function Points)

UFPs = 

j i,

ni, j * Wi, j

trong đó:

UFPs : tổng Điểm Chức năng chưa được điều chỉnh

i : nhận các giá trị từ 1 đến 5, đại diện cho 5 loại chức năng

j : nhận các giá trị từ 1 đến 3, đại diện cho 3 mức độ phức tạp

ni, j : là số lượng thành phần thuộc loại i có độ phức tạp j

Wi, j : là trọng số của loại i có độ phức tạp j

Độ phức tạp Loại chức năng

Đơn giản Trung bình Phức tạp Tổng

File logic nội bộ * 7 = * 10 = * 15 =

Giao diện ngoại vi * 5 = * 7 = * 10 =

Truy vấn ngoại vi * 3 = * 4 = * 6 =

UFPs =

Bảng 2-6 Tính UFPs – kích cỡ xử lý thông tin thô – trong FPA

Chương 2

13

Bước 2: Đánh giá Yếu tố Độ phức tạp Kĩ thuật của hệ thống

Kích cỡ xử lý thông tin thô (UFPs) sẽ được điều chỉnh bởi các yếu tố kĩ thuật, cái mà ảnh hưởng lên quá trình phát triển và thi hành hệ thống

Mã yếu tố Đặc trưng yếu tố Mức độ ảnh hưởng

Bảng 2-7 Mười bốn Yếu tố kĩ thuật trong FPA

không xuất hiện, không ảnh hưởng = 0 ảnh hưởng không đáng kể = 1

ảnh hưởng vừa phải = 2 ảnh hưởng trung bình = 3 ảnh hưởng đáng kể = 4 ảnh hưởng mạnh, khắp nơi = 5

Có 14 yếu tố chuẩn, được tác giả Albretch đề xuất như là 14 “Đặc trưng ứng dụng tổng quát”, sẽ được tính toán để đưa vào một con số được gọi là Yếu tố Độ phức tạp Kĩ thuật (TCF – Technical Complexity Factor) Cụ thể, mức độ của phạm vi ảnh hưởng của mỗi yếu tố được xếp loại và cho điểm từ 0 (không ảnh hưởng) đến 5 (ảnh hưởng mạnh mẽ khắp nơi), như Bảng 2-2 Yếu tố Độ phức tạp Kĩ thuật được tính theo công thức:

TCF = C 1 + C 2 

 14

1

i

F i

trong đó:

Bước 3: Tính toán cuối cùng

Kích cỡ xử lý thông tin của một hệ thống theo số lượng Điểm Chức năng (FPs) được tính theo công thức:

FPs = UFPs * TCF

Trong đó:

FPs : số điểm chức năng của hệ thống

UFPs : số điểm chức năng chưa được điều chỉnh được tính từ bước 1

TCF : yếu tố độ phức tạp kĩ thuật được tính từ bước 2

a) Ưu điểm

FPA đếm số chức năng dựa vào cách nhìn từ bên ngoài vào hệ thống của người dùng cuối Do đó, phương pháp là độc lập về mặt công nghệ, áp dụng phương pháp FPA không yêu cầu 1 cách cụ thể nào của việc mô tả hệ thống hay phát triển hệ thống, ví dụ như, một phương pháp phân tích cụ thể

Phép đo có thể được xác định sớm trong vòng đời phát triển của dự án, chỉ cần có đặc

tả yêu cầu người dùng, cho phép thực hiện ước lượng sớm, hỗ trợ quản trị dự án

b) Nhược điểm

FPA không thể được tính toán một cách tự động, trong quy trình tính toán ta phải đưa

ra nhiều đánh giá chủ quan Cụ thể, mọi đầu vào, đầu ra, truy vấn, file và các giao diện phải được đánh giá thành đơn giản, trung bình hay phức tạp và các yếu tố kĩ thuật cũng được đánh giá bởi cảm nhận của con người.Tuy vậy thì những chuyên gia cũng có thể đưa ra những đánh giá kinh nghiệm có độ chính xác cao

Chương 2

15

Việc đánh giá và cho điểm mức độ phạm vi ảnh của 14 yếu tố kĩ thuật có vẻ khá đơn

sơ Việc xác định mức độ ảnh hưởng của mỗi yếu tố và cho điểm là đúng nhưng vấn

đề là điểm của các yếu tố có khoảng giá trị giống nhau với giá trị nhỏ nhất là 0 và giá trị lớn nhất là 5 Các yếu tố khác nhau thì tầm ảnh hưởng cũng khác nhau, cụ thể, hai yếu tố có thể cùng ảnh hưởng suốt trong quá trình xây dựng hệ thống nhưng mức độ quan trọng của chúng là khác nhau Do đó, nên cho mỗi yếu tố một trọng số ảnh hưởng, sau đó điểm của yếu tố được tính bằng cách nhân điểm tỉ lệ mức độ ảnh hưởng với điểm trọng số để lấy kết quả điểm ảnh hưởng của yếu tố

Ngoài ra, trong xem xét điều chỉnh số lượng Điểm Chức năng của hệ thống, đội ngũ kĩ thuật cũng ảnh hưởng lên quá trình phát triển hệ thống, nhưng không được xem xét

trong phương pháp FPA Theo ([9] Symons, 1988), điều này được tác giả của phương

pháp lý giải là để cách ly việc xử lý bên trong với môi trường bên ngoài, tạo thuận lợi cho việc nghiên cứu năng suất làm việc của mỗi đội phát triển cụ thể Điều này không

có nhiều ý nghĩa, vì trong thực tế, các đội phát triển thường thay đổi ở các dự án, có một số lượng người đi và một số lượng người đến, năng suất cụ thể của đội phát triển

cũ không thể áp dụng cho đội phát triển mới

FPA có lẽ là một phương pháp rất tốt ở thời điểm được đưa ra nhưng cho đến bây giờ thì có nhiều điểm không phù hợp

Các hệ thống bây giờ không chỉ phục vụ cho một nhu cầu đơn lẻ mà phục vụ cho nhiều đối tượng Các nhu cầu ấy có thể giống nhau hay khác nhau Hệ thống được chia thành các mô – đun và những phần giống nhau được sử dụng lại chứ không phải xây dựng lại từ đầu (theo quan điểm Hướng đối tượng) Các mô – đun thừa kế từ mô – đun khác Số chức năng của hai mô – đun khác nhau có thể có nhiều chức năng dùng chung từ một mô – đun khác Việc đếm số chức năng dùng chung thật sự là một vấn đề khó khăn Hơn nữa, mỗi mô – đun lại có một kịch bản riêng để kết hợp các chức năng lại với nhau

Với các hệ thống gần đây hoạt động trên các hệ cơ sở dữ liệu thì việc đếm số lượng file logic là không hề hợp lý Các hệ cơ sở dữ liệu quản lý các bảng dữ liệu, và như vậy đối tượng có thể đếm là số lượng các thực thể hoặc số lượng các bảng (loại thực thể) chứ không phải là số lượng các file logic trong thao tác của hệ quản trị cơ sở dữ liệu

Một hạn chế nữa của FPA là mặc dù bình thường FPA làm việc cho các ứng dụng nghiệp vụ, nhưng có thể nó không có hiệu lực cho các loại ứng dụng khác, như là khoa

16

học hay công nghệ Điều này phát sinh từ chính khả năng có giới hạn của nó để giải quyết độ phức tạp nội hàm Độ phức tạp nội hàm trong các ứng dụng nghiệp vụ phát sinh chủ yếu từ các tiến trình xác minh và từ các tương tác với dữ liệu được lưu trữ Trong khi các ứng dụng khoa học và kĩ thuật phải giải quyết các thuật toán tính toán nội hàm phức tạp, thì FPA không phải là một cách hợp lý để giải quết những hệ thống như thế

2.2 Mô hình ước lượng giá cấu thành (COCOMO – Constructive Cost Model)

Mô hình COCOMO là mô hình ước lượng giá cấu thành (nỗ lực và thời gian) của phần mềm dựa trên đánh giá kích cỡ của chương trình được phân phối cho người dùng COCOMO được giới thiệu lần đầu tiên năm 1981 trong cuốn sách Software Engineering Economics của tác giả Barry Boehm

Tác giả đã đề xuất ba mức độ của mô hình: Cơ sở, Trung cấp và Nâng cao

2.2.2.1 Mô hình COCOMO cơ sở (basic COCOMO)

Mô hình COCOMO cơ sở tính toán giá (nỗ lực và thời gian) phát triển phần mềm như

là một hàm của kích cỡ chương trình Kích cỡ của chương trình được biểu diễn theo đơn vị nghìn dòng lệnh (KLOC – kilo line of code)

Trước tiên, COCOMO phân biệt 3 phương thức phát triển dự án:

- organic: cho những dự án tương đối nhỏ và đơn giản được phát triển bởi những

đội nhỏ trong môi trường quen thuộc với những yêu cầu không quá cứng nhắc

và có thể là linh động, do đó việc phát triển có thể được hỗ trợ bởi những dự án

đã được thực hiện trước đó

- semi-detached: cho những dự án có mức độ trung bình (về kích cỡ và độ phức

tạp) được phát triển bởi đội phát triển có trình độ khác nhau với những ràng

buộc mạnh mẽ hơn so với phương thức organic, tuy nhiên vẫn có một số linh

động, tức là dự án vẫn có thể được hỗ trợ từ những dự án trước đó nhưng với mức độ ít

Chương 2

17

- embedded: cho những dự án với những ràng buộc chặt chẽ về phần cứng, phần

mềm và thi hành, … Dự án phải phát triển từ đầu và không thể nhận được sự trợ giúp từ những số liệu của các dự án khác

Từ đó các phương trình của mô hình COCOMO cơ sở là:

E : là nỗ lực phát triển dự án theo đơn vị người – tháng,

T : là thời gian phát triển dự án theo tháng,

Bảng 2-3 Phân loại chế độ phát triển sản phẩm trong COCOMO cơ sở

2.2.2.2 Mô hình COCOMO trung cấp (intermediate COCOMO)

Mô hình COCOMO trung cấp là một sự mở rộng của mô hình cơ sở để xem xét thêm một tập các Yếu tố điều chỉnh giá mà được nhóm vào 4 loại chính, mỗi loại lại được phân chia thành các loại con:

18

- Các ràng buộc hiệu năng thời gian thực

- Các ràng buộc bộ nhớ chính

- Biến động môi trường máy ảo

- Thời gian xoay vòng yêu cầu

Nhóm 3:Các thuộc tính nhân lực

- Khả năng phân tích

- Khả năng kĩ nghệ phần mềm

- Kinh nghiệm ứng dụng

- Kinh nghiệm máy ảo

- Kinh nghiệm ngôn ngữ lập trình

Nhóm 4:Các thuộc tính dự án

- Việc dùng các công cụ phần mềm

- Ứng dụng của các phương pháp kĩ nghệ phần mềm

- Lịch trình phát triển được yêu cầu

Mỗi Yếu tố trong số 15 yếu tố trên được đánh tỉ lệ theo một thang có 6 mức Dựa trên việc xem xét tỉ lệ, một thừa số nỗ lực được xác định theo kinh nghiệm như bảng dưới Tích của tất cả các thừa số nỗ lực được gọi là Yếu tố Điều chỉnh Nỗ lực (EAF – Effort Adjust Factor) Giá trị của EAF dao động từ 0.9 tới 1.4

F EAF

trong đó:

EAF : Yếu tố Điều chỉnh Nỗ lực

F i : Yếu tố thứ i, có giá trị như Bảng 2-4

Chương 2

19

Tỉ lệ Các thuộc tính Rất thấp Thấp Bình

thường

Cao Rất

cao

Đặc biệt cao

Kinh nghiệm máy ảo 1.21 1.10 1.00 0.90

Kinh nghiệm ngôn ngữ

20

Công thức COCOMO cơ sở bây giờ chuyển thành dạng:

E = a i * (KLOC)b i * EAF

trong đó:

EAF : là yếu tố điều chỉnh nỗ lực được tính như ở trên

a i và b i : là các hệ số được đưa ra như bảng sau:

Phương thức a b

Bảng 2-5 Phân loại chế độ phát triển trong COCOMO trung cấp

2.2.2.3 Mô hình COCOMO nâng cao (advanded COCOMO)

Mô hình COCOMO nâng cao kết hợp tất cả các đặc tính của COCOMO trung cấp với một đánh giá ảnh hưởng của thuộc tính điều chỉnh giá vào từng pha (phân tích, thiết kế,…) trong tiến trình kĩ nghệ phần mềm

COCOMO nâng cao cũng được gọi là Ada COCOMO

a) Ưu điểm

Mô hình có thuật toán rất rõ ràng, và chúng ta có thể xem cách nó hoạt động cụ thể như thế nào để tự động hóa quá trình đánh giá

Các Yếu tố điều chỉnh là khá đầy đủ, có tính đến cả các yếu tố Nhân lực thực hiện dự

án, một bổ sung so với FPA Các Yếu tố được cho điểm chi tiết, điều này giúp ích tốt cho việc đánh giá mức độ ảnh hưởng của mỗi yếu tố để điều chỉnh giá của dự án

Chương 2

21

nhận được sự hỗ trợ rất lớn từ nhiều công cụ kéo thả giao diện Đánh giá số dòng lệnh

để ước lượng giá theo mô hình COCOMO trong trường hợp này không còn đúng nữa

vì các lệnh được sinh ra tự động chứ không phải do con người viết

Mô hình COCOMO chỉ quan tâm đến số lượng dòng lệnh để tính toán Tức là với một

số lượng dòng lệnh cho trước, dù là thuộc ngôn ngữ nào, sẽ cho một giá sản phẩm (nỗ lực và thời gian phát triển) cụ thể, dù giá này có thể được điều chỉnh bằng các yếu tố điều chỉnh, thì giá trị điều chỉnh là không đáng kể Điều này là không hợp lý khi lượng tri thức chứa trong một số lượng dòng lệnh cho trước của các ngôn ngữ khác nhau là rất khác nhau, dẫn đến nỗ lực phát triển lượng dòng lệnh đó bởi các ngôn ngữ khác nhau là khác nhau Hơn nữa, ngay cả trong cùng 1 ngôn ngữ thì các đoạn mã khác nhau mà có cùng số lượng dòng cũng chứa lượng tri thức khác nhau, tức là nỗ lực phát triển khác nhau

Việc phân biệt 3 phương thức phát triển dự án có lẽ là hợp lý ở thời điểm mà COCOMO được đưa ra nhưng hiện nay, cách phân biệt như vậy là không rõ ràng và dễ gây nhầm lẫn Cụ thể, có thể có những dự án nhỏ, có lẽ thuộc chế độ organic, nhưng lại có những yêu cầu khắt khe và dự án phải xây dựng một cách cẩn thận từ đầu mà không nhận được sự hỗ trợ từ dữ liệu lịch sử, giống với kiểu embedded

2.3 Kết hợp Phương pháp Phân tích Điểm Chức năng với Mô hình Giá Cấu thành (FPA và COCOMO)

Khi phân tích yêu cầu thì có thể tính được FP nhưng chưa có thông tin về LOC Phương pháp FPA có thể được dùng cùng với mô hình COCOMO để ước lượng các tài nguyên cần thiết cho việc phát triển Điều này được thực hiện trước hết xác định xem bao nhiêu dòng lệnh cần thiết để xây dựng một điểm chức năng (tức tỉ lệ LOC/FP) Sau đó nhân giá trị này với số điểm chức năng của hệ thống để có được tổng

số dòng lệnh (LOC hay KLOC) của hệ thống, cái mà có thể dùng trong COCOMO Đối với mỗi điểm chức năng, số dòng lệnh để thi hành nó lại phụ thuộc vào môi trường lập trình và vào những năm 90, các thống kê đã được tiến hành và thấy rằng tỉ

lệ LOC/FP trung bình trên một số dự án đưa ra như trong Bảng 2-6

Bảng 2-6 Tỉ lệ LOC/FP cho phép kết hợp FPA và COCOMO Nguồn:[11] Trương Ninh

Thuận, slide bài giảng môn Kỹ nghệ phần mềm cho lớp K51CD, chương 3b

2.3.2 Đánh giá phép kết hợp

Phép chuyển đơn vị tự FP sang LOC để dùng trong COCOMO giúp cho có thể áp dụng COCOMO sớm trong vòng đời phát triển dự án Nhưng để có được ước lượng đáng tin cậy thì cũng rất khó Trước hết là việc xác định tỉ lệ LOC/FP, dùng cho phép chuyển đơn vị kích cỡ Giá trị đề xuất chỉ là giá trị trung bình theo kinh nghiệm và ở trong mỗi hệ thống thì giá trị này có thể thay đổi rất lớn tùy theo độ phức tạp của xử lý bên trong của mỗi chức năng Thứ hai, quay trở lại vấn đề lượng tri thức chứa trong một số lượng dòng lệnh ở các ngôn ngữ khác nhau đã đề cập ở đánh giá mô hình COCOMO, lại nảy sinh vấn đề không hợp lý Ta có thể thấy rằng với cùng một FP thì

có số lượng LOC rất khác nhau đối với các ngôn ngữ khác nhau, dẫn đến các kết quả theo COCOMO cũng rất khác nhau, trong khi lượng tri thức trong chúng là như nhau Trong phép kết hợp thì có thể dùng COCOMO cơ sở hoặc COCOMO trung cấp, còn COCOMO nâng cao thực chất chỉ là COCOMO trung cấp ở từng pha phát triển

Chương 2

23

Nếu ta dùng COCOMO cơ sở cho phép kết hợp, thì các giá trị kết quả không thay đổi nhiều ý nghĩa so với đơn vị FP của FPA, do không có yếu tố điều chỉnh Tức là, phép kết hợp vẫn có bản chất là phép FPA Do đó, những điểm yếu của FPA vẫn giữ nguyên

mà lại phải quan tâm đến những khó khăn trong việc chuyển đơn vị kích cỡ từ FP sang LOC như đã nêu ở trên

Nếu ta dùng COCOMO trung cấp cho phép kết hợp, thì ta đã xét thêm các yếu tố môi trường cho FPA, mà vốn nó là thiếu, nhưng những điểm yếu khác của cả FPA và COCOMO đã nêu trong đánh giá của 2 phương pháp thì vẫn tồn tại

Như vậy cách kếp hợp FPA và COCOMO chỉ giúp chuyển đơn vị kích cỡ FPs của phép phân tích FPA sang một phép tính toán số học để ước lượng giá (nỗ lực và thời gian) giúp cho việc quản trị dự án, chứ không khắc phục được những nhược điểm thuộc về bản chất của mỗi thành phần Tuy vậy, cách dùng kết hợp vẫn là một gợi ý tốt

để đưa ra các giá trị gợi ý cho việc quản trị, theo một phương pháp đã được hiệu chỉnh, giúp cho việc lập lịch và lên kế hoạch, hơn là việc tính toán không có phương pháp hoặc không có một phép tính toán nào trợ giúp

24

PHẦN 2 ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM

THEO ĐIỂM CA SỬ DỤNG

Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt

25

Chương 3 GIỚI THIỆU PHƯƠNG PHÁP ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM THEO

ĐIỂM CA SỬ DỤNG (USE CASE POINT)

3.1 Tóm lược

Vào đầu những năm 1990, James Rambough, Grady Booch và Ivar Jacobson đã nghiên cứu và xây dựng nên những thành phần của phương pháp kĩ nghệ phần mềm Hướng đối tượng Sau đó vài năm Ngôn ngữ Mô hình hóa Thống nhất (UML) đã ra đời có các kí pháp và phương thức phục vụ cho việc phát triển phần mềm hướng đối tượng UML đã được đưa vào Quy trình thống nhất (RUP – Rational Unified Process) UML xác định các yêu cầu cho sản phẩm phần mềm với các ca sử dụng

Như được đặc tả trong ([4] Jacobson, 2005), ca sử dụng mô tả những cái mà tác nhân muốn hệ thống thực hiện Các ca sử dụng bao gồm các mục tiêu chiến lược và các kịch bản chi tiết thực hiện trên lĩnh vực nghiệp vụ, nên chúng cũng có thể cung cấp cái nhìn vào tính phức tạp của một ứng dụng Thu được một ước lượng tin cậy của cỡ và nỗ lực

mà một ứng dụng cần, là có thể bằng cách xem xét các tác nhân và các kịch bản của một ca sử dụng

Năm 1993, Gustav Karner đã sáng tạo ra kĩ thuật ước lượng Điểm Ca Sử dụng (UCP – Use Case Point), tài liệu ([5] Karner, 1993), dựa theo phương pháp Phân tích Điểm Chức năng của Abretch Điểm ca sử dụng phân tích các tác nhân, các kịch bản và các yếu tố môi trường và kĩ thuật và đưa chúng vào một phương trình Đây là một kĩ thuật ước lượng tốt khi phát triển dự án theo phương pháp hướng đối tượng nhưng chưa được phổ biến Đó là bởi vì phương pháp Hướng đối tượng chỉ thực sự trở thành phổ biến trong những năm gần đây và các phương pháp ước lượng cũ đã quá nổi tiếng trong ngành công nghiệp phần mềm

26

Kĩ thuật ước lượng của Karner hiện nay đã được đưa vào RUP, ([1] Carroll, 2005) Gần đây một số đội kĩ nghệ của sự phối hợp của Agilis Solutions và FPT Software, Hanoi, Vietnam, đã áp dụng phương pháp của Karner và đưa ra được những ước lượng đáng tin cậy sớm trong vòng đời dự án

3.2 Nội dung phương pháp

Phương pháp ước lượng UCP đánh giá kích cỡ của dự án theo một đơn vị gọi là Điểm

Ca Sử dụng Số Điểm Ca Sử dụng đưa cho ta một ước lượng của kích cỡ mà có thể được ánh xạ sang đơn vị [người – giờ] để phát triển các pha khác nhau theo quy trình Hướng đối tượng hay toàn bộ hệ thống

Phương pháp bắt đầu với việc đo chức năng của hệ thống dựa trên biểu đồ ca sử dụng, đưa ra kết quả là một số được gọi là Điểm Ca Sử dụng Chưa được điều chỉnh (UUCPs – Unadjusted Use Case Points) Các Yếu tố Kĩ thuật liên quan trong việc phát triển chức năng được đánh giá, tương tự như trong Phân tích Điểm Chức năng, để đưa ra kết quả là Yếu tố Độ phức tạp Kĩ thuật Bước cuối cùng trong ước lượng là một tính toán khác với phương pháp Điểm Chức năng và đưa ra một yếu tố mới được gọi là Yếu tố

Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt

27

3.2.1.1 Tính số Điểm Ca Sử dụng Chưa được điều chỉnh (UUCPs –

Unadjusted Use Case Points)

Số Điểm Ca Sử dụng Chưa được Điều chỉnh (UUCPs - Unadjusted Use Case Points) được tính dựa trên hai tính toán sau:

- Đếm số Ca Sử dụng sau khi đánh Trọng số (WUCs – Weighted Use Cases) dựa trên tổng số các hoạt động (hoặc các bước) được tính đến trong tất cả các kịch bản ca sử dụng

- Đếm số Tác nhân sau khi đánh Trọng số (WAs – Weight Actors) dựa trên độ phức tạp kết hợp của tất cả các Tác nhân Ca sử dụng

Tính toán cụ thể:

Bước 1: Đếm số Ca Sử dụng sau khi đánh Trọng số (WUCs)

Các ca sử dụng riêng lẻ được phân loại thành Đơn giản, Trung bình hay Phức tạp, và được đánh trọng số phụ thuộc vào số các giao dịch mà chúng chứa, Bảng 3-1 Chỉ có các ca sử dụng cụ thể được đếm, tức là không tính đến các một ca sử dụng đóng vai trò giao diện

Đơn giản Một ca sử dụng là đơn giản nếu kịch bản

của nó có tới 3 giao dịch hoặc ít hơn; ta

có thể thực thi hành nó với tới ít hơn 5 lớp phân tích

5

Bình thường Một ca sử dụng là trung bình nếu kịch

bản của nó có từ 4 đến 7 giao dịch; sự thi hành của nó đòi hỏi từ 5 đến 10 lớp phân tích

Bảng 3-1 Phân loại và đánh trọng số ca sử dụng trong UCP

Một “giao dịch” của ca sử dụng là một tập các hành động được thực hiện trọn vẹn hoặc hoàn toàn không được thực hiện Nó không đơn thuần là khái niệm “giao dịch” như trong cơ sở dữ liệu Một giao dịch use case có thể chứa các thao tác cơ sở dữ liệu, nhưng ngoài ra nó còn chứa thêm các hoạt động khác nữa, ví dụ các kích thích của tác

28

nhân, các thao tác khác của hệ thống Theo mô tả của ([2] Collaris, 2009), một giao dịch là một “vòng tròn” hành động từ người dùng tới hệ thống quay lại người dùng Một “giao dịch” không phải là một bước của ca sử dụng, một kích thích từ tác nhân (có thể có nhiều kích thích từ tác nhân tới hệ thống nhưng không có chiều ngược lại), một bước hệ thống hay một giao dịch cơ sở dữ liệu Giữ giao dịch ở cấp độ hợp lý sẽ cho ước lượng chính xác hơn, điều này có được nhờ kinh nghiệm áp dụng trong quá khứ

WUCs được tính bằng cách đếm số lượng ca sử dụng thuộc mỗi loại, nhân số lượng mỗi loại ca sử dụng với trọng số của nó và cộng các tích

i

i

i W n WUCs

trong đó:

WUCs : số lượng Ca Sử dụng đếm được sau khi đánh Trọng số

n i : số lượng ca sử dụng loại thứ i (đơn giản, trung bình, phức tạp)

Đơn giản Một ca sử dụng là đơn giản nếu

kịch bản của nó có tới 3 giao dịch hoặc ít hơn; ta có thể thực thi hành nó với tới ít hơn 5 lớp phân tích

Bình

thường

Một ca sử dụng là trung bình nếu kịch bản của nó có từ 4 đến 7 giao dịch; sự thi hành của nó đòi hỏi từ

Bảng 3-2 Ví dụ đếm số ca sử dụng sau khi đánh trọng số

Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt

29

Bước 2: Đếm số Tác nhân sau khi đánh Trọng số (WAs)

Theo một lối quen thuộc, các Tác nhân được phân loại thành Đơn giản, Bình thường hay Phức tạp dựa trên các tương tác của chúng Chỉ có các tác nhân cụ thể được tính, không đếm tác nhân đóng vai trò giao diện

Đơn giản Một tác nhân là đơn giản nếu nó biểu

diễn một hệ thống khác với một API xác định (Application Programming Interface)

1

Bình thường Một tác nhân là trung bình nếu nó là:

1 Một tương tác với một hệ thống khác thông qua một giao thức, ví dụ TCP

2 Một tương tác con người với một giao diện dòng lệnh

Bảng 3-3 Phân loại và đánh trọng số tác nhân trong UCP

WAs được tính bằng cách đếm số lượng tác nhân thuộc mỗi loại, nhân số lượng mỗi loại tác nhân với trọng số của nó và cộng các tích

trong đó:

WAs : tổng số lượng Tác nhân sau khi đánh Trọng số

ni : số lượng tác nhân loại thứ i (đơn giản, trung bình, phức tạp)

Wi : trọng số của loại tác nhân thứ i

Tiếp tục ví dụ ở phần trước, đếm số lượng tác nhân sau khi đánh trọng số ở Bảng 3-4

Đơn giản Một tác nhân là đơn giản nếu nó

biểu diễn một hệ thống khác với một API xác định (Application Programming Interface)

UUCPs  

trong đó:

UUCPs: số Điểm Ca Sử dụng Chưa được điều chỉnh

WUCs : số Ca Sử dụng sau khi đánh Trọng số

WAs : số Tác nhân sau khi đánh Trọng số

Đối với ví dụ đưa ra trong Bảng 3-2 và Bảng 3-4:

UUCPs = 220 + 44 = 264