Ướ lượng giá thành phần mềm khảo sát các mô hình phổ biến và phân tích khả năng ứng dụng tại việt nam

104 Trang 7 DANH MỤC CÁC KÝ HIỆU, TỪ VIẾT TẮT Từ viết tắt Từ viết đầy đủ Mô tảAC Applications Composition Mô hình tổng hợp ứng dụngAFP Adjusted Function Point Số điểm chức hiệu chỉnhA

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

-

BÙI NGỌC HOÀNG

ƯỚC LƯỢNG GIÁ THÀNH PHẦN MỀM: KHẢO SÁT CÁC MÔ HÌNH PHỔ BIẾN VÀ PHÂN TÍCH KHẢ NĂNG

ỨNG DỤNG TẠI VIỆT NAM

LUẬN VĂN THẠC SỸ CÔNG NGHỆ THÔNG TIN

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

BÙI NGỌC HOÀNG

ƯỚC LƯỢNG GIÁ THÀNH PHẦN MỀM: KHẢO SÁT CÁC MÔ HÌNH PHỔ BIẾN VÀ PHÂN TÍCH KHẢ

NĂNG ỨNG DỤNG TẠI VIỆT NAM

NGÀNH: CÔNG NGHỆ THÔNG TIN

LUẬN VĂN THẠC SỸ CÔNG NGHỆ THÔNG TIN

Người hướng dẫn khoa học: TS NGUYỄN KHANH VĂN

LỜI CẢM ƠN

Trước tiên, em xin chân thành cảm ơn TS Nguyễn Khanh Văn trưởng bộ môn Công , Nghệ Phần Mềm trường đại học BKHN đã nhiệt tình hướng dẫn và cung cấp cho em , nhiều tài liệu quý giá để hoàn thành luận văn Xin cảm ơn các anh chị tại trung tâm quản lý chất lượng QA của công ty CMCSoft đã giúp đỡ em rất nhiều trong thu thập số liệu thực nghiệm Cuối cùng, em xin cảm ơn gia đình và bạn bè đã ủng hộ, động viên em hoàn thành tốt luận văn này

Học viên thực hiện

MỤC LỤC

LỜI CẢM ƠN i

MỤC LỤC ii

DANH MỤC CÁC KÝ HIỆU, TỪ VIẾT TẮT v

DANH MỤC CÁC BẢNG BIỂU vii

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ ix

MỞ ĐẦU 1

Chương 1 TỔNG QUAN 3

1.1 Tổng quan về thực trạng vấn đề lượng giá phần mềm ở Việt Nam 3

1.1.1 Lượng giá phần mềm ảnh hưởng đến sự phát triển dự án CNTT ở Việt Nam như thế nào? 3

1.1.2 Những kiến nghị và giải pháp của các nhà quản lý CNTT 4

1.1.3 Những đặc trưng của ngành CNPM Việt Nam ảnh hưởng đến quá trình lượng giá phần mềm 4

1.1.4 Những bất cập của công văn hướng dẫn lượng giá phần mềm 3364 5

1.2 Giới thiệu kiến thức tổng quan về lượng giá phần mềm 6

1.2.1 Giải thích thuật ngữ 6

1.2.2 Vai trò của lượng giá phần mềm 6

1.2.3 Cơ sở xây dựng mô hình lượng giá chi phí 6

1.2.3.1 Đếm số dòng lệnh SLOC 6

1.2.3.2 Điểm chức năng chưa hiệu chỉnh UFP 7

1.2.3.3 Điểm Use case chưa hiệu chỉnhUUCP- 7

1.2.4 Các phương pháp và mô hình lượng giá dự án phần mềm 8

1.2.4.1 Mô hình toán học 8

1.2.4.2 Mô hình chuyên gia 8

1.2.4.3 Mô hình tương tự 8

1.2.4.4 Lượng giá Parkinson 9

1.2.4.5 Mô hình Price- -to Win 9

1.2.4.6 Lượng giá Top Down- 9

1.2.4.7 Lượng giá Bottom Up- 9

1.2.4.8 Đánh giá và so sánh các mô hình lượng giá 9

1.2.5 Quy trình lượng giá dự án phần mềm 10

Chương 2 CÁC MÔ HÌNH LƯỢNG GIÁ THỰC NGHIỆM 14

2.1 Mô hình COCOMO 14

2.1.1 Giới thiệu tổng quan về mô hình COCOMO 14

2.1.2 Mô hình COCOMO cơ bản 14

2.1.3 Mô hình COCOMO trung bình 16

2.1.4 Mô hình COCOMO chi tiết 18

2.2 Mô hình COCOMO II 20

2.2.1 Đặc điểm cơ bản của COCOMO II 21

2.2.2 Ước lượng kích thước dự án 21

2.2.2.1 Hệ số thay đổi yêu cầu REVL 22

2.2.2.2 Ước lượng kích thước cho dự án tái sử dụng mã nguồn 22

2.2.2.3 Ước lượng kích thước cho dự án bảo trì phần mềm 24

2.2.3 Ước lượng công sức phát triển 25

2.2.3.1 Mã được dịch tự động 25

2.2.3.2 Ước lượng phạm vi cho kết quả đầu ra của mô hình 26

2.2.4 Mô hình tổng hợp ứng dụng AC 27

2.2.4.1 Tiếp cận mô hình AC 27

2.2.4.2 Tính điểm đối tượng OP 27

2.2.4.3 Tính toán công sức dựa trên OP 28

2.2.5 Mô hình thiết kế sớm ED 29

2.2.5.1 Tiếp cận mô hình ED 29

2.2.5.2 Ước lượng công sức 29

2.2.5.3 Ước lượng thời gian thực hiện dự án 31

2.2.6 Mô hình hậu kiến trúc 32

2.2.6.1 Tiếp cận mô hình PA 32

2.2.6.2 Ước lượng công sức 32

2.2.6.3 Ước lượng thời gian dự án 35

2.2.7 Quản lý rủi ro chi phí 35

2.2.8 Đánh giá tổng quát các mô hình COCOMO 37

2.3 Mô hình lượng giá điểm chức năng FPA 38

2.3.1 Giới thiệu mô hình FPA 38

2.3.2 Đặc điểm của mô hình FPA 38

2.3.3 Các bước tiếp cận xây dựng mô hình 39

2.3.3.1 Xác định loại dự án cần tính điểm chức năng 40

2.3.3.2 Xác định phạm vi tính toán và biên của ứng dụng 41

2.3.3.3 Tính số điểm chức năng chưa hiệu chỉnh UFP 41

2.3.3.4 Xác định hệ số hiệu chỉnh giá trị VAF 45

2.3.3.5 Tính số điểm chức năng hiệu chỉnh AFP 50

2.3.4 Ước lượng công sức dự án 52

2.3.5 Kết luận và đánh giá mô hình FPA 55

2.4 Mô hình UCP 56

2.4.1 Giới thiệu mô hình 56

2.4.2 Mô hình lượng giá theo UCP 56

2.4.2.1 Tính giá trị UAW của các Actor 57

2.4.2.2 Tính giá trị UUCW của các Use case- 58

2.4.2.3 Tính giá trị Use case chưa hiệu chỉnh UUCP- 58

2.4.2.4 Tính hệ số phức tạp kỹ thuật TCF 58

2.4.2.5 Tính hệ số môi trường EF 60

2.4.2.6 Tính tổng số điểm AUCP 61

2.4.2.7 Ước lượng công sức 61

2.4.3 So sánh mô hình FPA và mô hình UCP 62

2.4.3.1 Sự giống nhau 62

2.4.3.2 Sự khác nhau 62

2.4.4 Kết luận, nhận xét mô hình UCP 63

2.5 Mô hình UCP của Việt Nam 64

2.5.1 Giới thiệu mô hình UCP của Việt Nam 64

2.5.2 So sánh mô hình UCP Việt Nam và mô hình UCP chuẩn 64

2.5.3 Phân tích những điểm bất hợp lý trong mô hình UCP Việt Nam 65

2.5.3.1 Tính điểm cho Use case không dựa vào độ lớn của Use case- - 65

2.5.3.2 Phức tạp hóa mô hình bằng các biểu thức tính toán 66

2.5.3.3 Các hằng số được thêm vào không có cơ sở 66

2.5.3.4 Xác định chi phí nhân công chưa hợp lý 67

2.5.4 Ý kiến đóng góp cho xây dựng mô hình 67

Chương 3 ÁP DỤNG CÁC MÔ HÌNH LƯỢNG GIÁ VÀO THỰC NGHIỆM 68

3.1 Tổng hợp các phương pháp và mô hình lượng giá thực nghiệm 68

3.2 Lượng giá dự án phần mềm: BVPROP 69

3.2.1 Giới thiệu tổng quan về dự án 69

3.2.2 Sử dụng mô hình FPA 69

3.2.3 Sử dụng mô hình COCOMOII 71

3.2.4 Sử dụng mô hình UCP 73

3.3 Lượng giá dự án phần mềm: LKNHCK 75

3.3.1 Giới thiệu dự án 75

3.3.2 Sử dụng mô hình FPA 75

3.3.3 Sử dụng mô hình COCOMOII 77

3.3.4 Sử dụng mô hình UCP 78

3.4 Lượng giá dự án phần mềm: BHXH 2008 Resale 80

3.4.1 Giới thiệu dự án 80

3.4.2 Sử dụng mô hình FPA 81

3.4.3 Sử dụng mô hình COCOMOII 83

3.4.4 Sử dụng mô hình UCP 84

3.5 Đối chiếu và nhận xét kết quả ước lượng 86

Chương 4 CÁC ĐÁNH GIÁ NHẬN XÉT VÀ ĐỀ XUẤT CẢI TIẾN 88

4.1 Đánh giá nhận xét chung cho các mô hình lượng giá 88

4.2 Những đề xuất cải tiến quy trình ước lượng 89

4.3 Những đề xuất cải tiến cho các mô hình 89

4.3.1 Mô hình COCOMOII 89

4.3.2 Mô hình FPA 91

4.3.3 Mô hình UCP 92

4.4 Đề xuất mô hình tổng hợp 93

KẾT LUẬN 94

TÀI LIỆU THAM KHẢO 95

PHỤ LỤC A - CHECKLIST SLOC 98

PHỤ LỤC B BẢNG QUY ĐỔI GIỮA FP VÀ SLOC– 99

PHỤ LỤC C CÁC CHUẨN ISO CỦA MÔ HÌNH FPA- 100

PHỤ LỤC D – QUY TRÌNH RUP 101

PHỤ LỤC F MỘT SỐ PHƯƠNG PHÁP ƯỚC LƯỢNG BỔ TRỢ– 103

TÓM TẮT LUẬN VĂN 104

ABSTRACT 105

DANH MỤC CÁC KÝ HIỆU, TỪ VIẾT TẮT

AC Applications Composition Mô hình tổng hợp ứng dụng

AFP Adjusted Function Point Số điểm chức hiệu chỉnh

AUCP Adjusted Use Case Point Tổng số điểm Use-case hiệu chỉnh

BVPROP

Dự án xây dựng phần mềm quản lý bảo hiểm phi nhân thọ

Là dự án phần mềm về quản lý nghiệp vụ bảo hiểm phi nhân thọ được ký kết giữa tập đoàn Bảo Việt và cty phần mềm CMCSoft

CNPM Công Nghiệp Phần Mềm Công Nghiệp Phần Mềm

CNTT Công Nghệ Thông Tin Công Nghệ Thông Tin

COCOMO Constructive Cost Model Là mô hình chi phí xây dựng dự án phần mềm

do GS Boehm của đại học Southern California

đề xuất năm 1981

COCOMOII Constructive Cost Model II Là mô hình được cải tiến của mô hình

COCOMO năm 1981 do GS Boehm và cộng

sự của ông tại trung tâm nghiên cứu CSSE xây dựng nên

EAF Effort Adjustment Factor Là hệ số điều chỉnh công sức

EF Environment Factor Hệ số phức tạp môi trường

E IF External Interface File Các thông tin dữ liệu được tham chiếu từ bên

ngoài ứng dụng

FP Function Point Đơn vị đo kích thước phần mềm của FPA.FPA Function Point Analysis Mô hình lượng giá phân tích điểm chức năng.GSC General System

Characterisrics

Các đặc trưng chung của hệ thống

IFPUG International Function

Point Users Group Một tổ chức phi lợi nhuận, họat động với mục đí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

ILF Internal Logic File Các thông tin dữ liệu được sử dụng bên trong ứng dụng

ISBSG

International Software Benchmarking Standard Group

Là tổ chức cung cấp các số liệu thống kê về năng suất làm việc của nguồn nhân lực

KDSI Thousand Delivered

Source Instructions

Số nghìn dòng lệnh bàn giao

KSLOC Thousands of Source Lines Số nghìn dòng lệnh mã nguồn

PMAUTO Person Man- (Automatic

Translation) Công sức tính theo người tháng từ việc dịch tự động

-PMNS Person Man- o n(N mi al) Công sức danh nghĩa của dự án được tính theo

người-tháng

REVL Requirements Evolution and Volatility Hệ số thay đổi yêu cầu

RUP Rational Unified Process

Là quy trình phát triển phần mềm thống nhất được đề xuất bởi Rational Software (nay thuộc IBM Rational)

SLOC Source Lines Of Code Số dòng mã lệnh

TCF Technical Complex Factor Hệ số phức tạp kỹ thuật

TDEV Development Schedule Là thời gian thực hiện dự án (tháng)

TF Transactional Function điểm chức năng giao tác

TT&TT Bộ Thông tin và Truyền thông Bộ Thông tin và Truyền thông

UAW Unadjusted Actor Weight Giá trị của Actor

UCP Use-case Point Mô hình lượng giá dựa trên điểm Use caseUFP Unadjusted Function Point Điểm chức năng chưa được điều chỉnh

-UML Use-case Point Ngôn ngữ mô hình hóa thống nhất

UUCP Unadjusted Use Case Points Số điểm Use case chưa hiệu chỉnh

-UUCW Unadjusted Use Case Weight Giá trị của Use-case

VAF Value Adjustment Factor Hệ số hiệu chỉnh giá trị

Structure Cấu trúc phân chia công việc

DANH MỤC CÁC BẢNG BIỂU

Bảng 1.1: So sánh các mô hình lượng giá (nguồn Boehm 1981) 10

Bảng 1.2: Các bước trong quy trình ước lượng (nguồn Kathleen 1999 ) 12

Bảng 2.1.1: Hằng số phụ thuộc của mô hình COCOMO cơ bản (nguồn Boehm81) 14

Bảng 2.1.2: Các dạng mô hình dự án phát triển của COCOMO (nguồn Boehm81) 15

Bảng 2.1.3: Các hằng số phụ thuộc của COCOMO trung bình (nguồn Boehm81) 16

Bảng 2.1.4: Các yếu tố điều khiển giá của mô hình COCOMO (nguồn Boehm81) 17

Bảng 2.15: Hệ số điều chỉnh công sức EAF của dự án BVPROP 18

Bảng 2.1.6: COCOMO chi tiết: ước lượng công sức ở mức mô đun của BVPROP 20

Bảng 2.1.7: COCOMO chi tiết: kết quả ước lượng công sức của dự án BVPROP 20

Bảng 2.2.1: Hệ số tỷ lệ cho số gia AA (nguồn Boehm 2000) 23

Bảng 2.2.2: Giá trị của số gia hiểu biết phần mềm SU (nguồn Boehm 2000) 23

Bảng 2.2.3: Giá trị của hệ số UNFM (nguồn Boehm 2000) 24

Bảng 2.2.4: Bảng giá trị của hệ số AT (nguồn Boehm 2000) 26

Bảng 2.2.6: Ước lượng phạm vi của mô hình COCOMOII (Nguồn Boehm 2000) 26

Bảng 2.2.5: Độ phức tạp của OP dựa vào số lượng screen và report (Boehm2000) 27

Bảng 2.2.6: Tính giá trị OP từ độ phức tạp của nó (nguồn Boehm2000) 28

Bảng 2.2.7: Thống kê số lượng Screen và Report trong dự án BVPROP 28

Bảng 2.2.8 : Mô hình AC: Giá trị năng suất làm việc PROD (Nguồn Boehm 2000) 28

Bảng 2.2.9: Mô hình ED: Hệ số nhân công sức EM (nguồn Boehm 2000) 30

Bảng 2.2.10: Mô hình ED: hệ số tỷ lệ SF của dự án BVPROP 31

Bảng 2.2.11: Mô hình ED: hệ số nhân công sức EM của dự án BVPROP 31

Bảng 2.2.12: Mức độ yêu cầu lịch trình phát triển 32

Bảng 2.2.13: Mô hình PA: hệ số điều khiển chi phí (Nguồn Boehm 2000) 34

Bảng 2.2.14: Mô hình PA: Hệ số nhân công sức EM của dự án BVPROP 34

Bảng 2.2.15: Mô hình PA: Hệ số EM có tính rủi ro của dự án BVPROP 36

Bảng 2.2.16: Kết quả ước lượng của các mô hình COCOMO (nguồn Boehm 2000) 37

Bảng 2.3.1: Ma trận độ phức tạp của ILF/EIF (nguồn IFPUG) 42

Bảng 2.3.3: độ phức tạp của EI 43

Bảng 2.3.4: độ phức tạp của EO/EQ (nguồn IFPUG) 43

Bảng 2.3.5: Tỷ lệ % của các loại điểm chức năng trong một dự án (GalEva06) 44

Bảng 2.3.5: Số RET và DET của chức năng lập đơn hàng của BVPROP 45

Bảng 2.3.6: Giá trị ảnh hưởng của 14 đặc trưng chung GSC (IFPUG) 49

Bảng 2.3.7: Giá trị ảnh hưởng các đặc trưng trong dự án BVPROP 50

Bảng 2.3.8: Hiệu suất công việc dự án: Web và không dựa nền Web (ISBSG, 2008) 53

Bảng 2.3.9: Thống kê hiệu suất công việc theo ngôn ngữ lập trình 53

Bảng 2.3.10: Thống kê hiệu suất công việc theo platform (ISBSG, 2002) 53

Bảng 2.3.11: Tthống kê hiệu suất công việc theo loại dự án (Shepperd, 2006) 54

Bảng 2.3.12: Hiệu suất công việc (FP/người tháng) phụ thuộc vào quy mô và lĩnh vực -phát triển ứng dụng (Capers Jones,2008) 54

Bảng 2.4.1: Độ phức tạp và trọng số của Actor ( Schneider& Winters 2001) 57

Bảng 2.4.2: Giá trị UAW của chức năng cấp đơn chuyến Hàng nhập 58

Bảng 2.4.3: Độ phức tạp và trọng số của Use-case ( Schneider& Winters 2001) 58

Bảng 2.4.4: Giá trị UUCW của chức năng cấp đơn chuyến Hàng nhập 58

Bảng 2.4.5: Giá trị trọng số của hệ số kỹ thuật TCF 59

Bảng 2.4.6: Giá trị các hệ số kỹ thuật trong dự án BVPROP 60

Bảng 2.4.7: Giá trị của hệ số môi trường EF 60

Bảng 2.4.8: Giá trị các hệ số môi trường EF trong dự án BVPROP 61

Bảng 2.5.1: Bảng so sánh các bước ước lượng của UCP Việt Nam và UCP chuẩn 64

Bảng 2.5.2: UCP Việt Nam: bảng giá trị Use case (nguồn công văn 3364)- 65

Bảng 2.5.3: UCP Việt Nam: giá trị Use case ( không phụ thuộc vào độ phức tạp)- 65

Bảng 2.5.4: UCP Việt Nam: giá trị nội suy cho hệ số ES (nguồn công văn 3364) 66

Bảng 3.1: Tổng hợp và đối chiếu kết quả lượng giá của 3 dự án 86

Bảng 3.2: Đối chiếu kết quả lượng giá của 3 dự án (sau khi cộng thêm 10% chi phí quản trị dự án và 15% chi phí chất lượng dự án) 87

Bảng A.1: Checklist SLOC 98

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

Hình 1.3: Lưu đồ quy trình lượng giá dự án phần mềm 13

Hình 2.2.1: Mô hình hoạt động của COCOMOII 21

Hình 2.3.1: Lưu đồ các bước ước lượng công sức của mô hình FPA 39

Hình 2.3.2: Quy trình tính điểm chức năng của mô hình FPA 40

Hình 2.3.3: Quy trình ước lượng cho 3 loại dự án trong FPA 40

Hình 2.3.4: Đường biên ứng dụng 41

Hình 2.4.1: lưu đồ thực hiện ước lượng công sức của mô hình UCP 56

Hình 2.4.2: Mô hình Use-case lập đơn chuyến Hàng nhập 57

Hình 4.1: Nhập chi phí thực tế của dự án BVPROP ngược lại mô hình COCOMOII 90

Hình 4.2: Giá trị hằng số A, B, C, D sau khi điều chỉnh 90

Hình 4.3: Kết quả ước lượng của dự án BVPROP bằng COCOMOII 91

Hình 4.4: Bảng quy đổi giữa UUCP và SLOC (Nguồn: RASS TOOLS 2009) 92

Hình 4.4: Mô hình ước lượng tổng hợp 93

Hình E.1: Biểu đồ mô tả quy trình RUP 101 Hình E.2: Chu trình lặp của các pha trong quy trình RUP Error! Bookmark not defined

MỞ ĐẦU

Lượng giá (hay còn gọi là ước lượng giá thành định giá ước lượng chi phí phần , , ) mềm là một trong những giai đoạn quan trọng trong quá trình quản trị dự án phần mềm Mục tiêu của lượng giá là để xác định quy mô dự án, công sức, thời gian và ngân sách cần thiết để thực hiện dự án Lượng giá càng chính xác thì khả năng thành công của dự án càng lớn

Theo báo cáo tổng kết của nhóm Standish: “Hàng năm nước Mỹ chi hàng tỷ đô la để phát triển hàng trăm ngàn dự án CNTT Theo số liệu thống kê năm nay (2009), nước Mỹ

có 32% trong tổng số dự án là thành công và đúng tiến độ, 44% số dự án là bị chậm tiến độ

và vượt ngân sách, 24% còn lại bị hủy bỏ hoặc được chuyển giao nhưng không được sử dụng” [chao2009] Một trong những nguyên nhân làm cho dự án chậm tiến độ và vượt ngân sách hay bị hủy bỏ thì phải kể đến vai trò của lượng giá dự án chưa tốt, chưa đánh giá đúng quy mô, nguồn lực cũng như chi phí phát triển dự án

Ở Việt Nam, đã thông qua hàng loạt các bài viết: “Triển khai dự án CNTT vì sao bế

tắc?”, “Giá phần mềm tù mù khó định”, “Định giá phần mềm thế nào không đục nước béo

cò?” hay “Định giá phần mềm loay hoay đến bao giờ?” phần nào phản ánh được những bất

cập, tác động cũng như vai trò của lượng giá đối với sự phát triển dự án phần mềm Cho nên, có một cơ chế lượng giá phần mềm chung trở thành niềm mong mỏi của nhiều đơn vị ứng dụng CNTT cũng như các công ty phần mềm ở Việt Nam ước Tr tình hình này, Bộ Thông tin và Truyền th ng (TT&TT) đã ra công văn ô 3364 (ngày 17 tháng 10 năm 2008 về ) việc hướng dẫn lượng giá phần mềm theo mô hình UCP tiên tiến Tuy nhiên, những bất cập của công văn đã làm cho vấn đề lượng giá phần mềm ngày càng trở nên khó khăn phức tạp hơn

Nhận thấy được vai trò quan trọng của định giá phần mềm đối với sự phát triển ngành CNTT nói chung và ngành Công nghệ Phần mềm nói riêng, đề tài tập trung vào nghiên cứu, tìm hiểu cácmô hìnhthực nghiệm trong định giá phần mềm Trong đó, tác giả

tập trung vào 4 mô hình thực nghiệm chính: COCOMO, COCOMOII, FPA và UCP Qua

đó sẽ giúp cho người đọc và cá nhân người viết có thể hiểu , chi tiết hơn về các mô hình ước lượng đã và đang được sử dụng trên thế giới và khả năng vận dụng giải bài toán lượng giá phần mềm cho Việt Nam Mặt khác, để lượng giá một dự án phần mềm không chỉ sử dụng một phương pháp, một mô hình (như công văn hướng dẫn 3364) mà cần từ hai phương pháp trở lên Có như vậy mới đảm bảo được tính chính xác, độ tin cậy của kết quả ước lượng [SEPO99]

Thông qua nghiên cứu các mô hình thực nghiệm trong đó có mô hình UCP mới có cơ

sở khoa học để phân tích và tìm hiểu được những điểm bất cập và không phù hợp của mô hình UCP do Bộ TT&TT đưa ra Dựa trên cơ sở nghiên cứu vấn đề, cùng với việc áp dụng thử nghiệmcác mô hìnhnày vào ước lượng thực tế các dự án đã thực hiện, luận văn đưa ra những nhận xét đánh giá và đề xuất cải tiến phù hợp với ngành Công nghiệp Phần mềm (CNPM Việt Nam như hiện nay)

Nội dung luận văn bao gồm 4 chương Chương 1 giới thiệu tổng quan về định giá phần mềm ở Việt Nam và các kiến thức tổng quan về lượng giá phần mềm Chương tập 2 trung vào trình bày chi tiết 4 mô hình thực nghiệm: COCOMO, COCOMOII, FPA và UCP Sau đó, luận văn giới thiệu về mô hình UCP Việt Nam do bộ TT&TT đề xuất (trong công văn hướng dẫn) Qua đó, luận văn tiến hành so sánh, phân tích những điểm bất hợp lý trong mô hình này và đồng thời đưa ra những kiến nghị đóng góp xây dựng mô hình phù hợp hơn Chương tiến hành áp dụng các 3 mô hình thực nghiệm vào 3 dự án phần mềm thực tế đã được hiện tại công ty CMCSoft Trên cơ sở đó, luận văn đưa ra những đánh giá nhận xét và đề xuất cải tiến cho các mô hình để phù hợp với ngành CNPM Việt Nam hiện nay (chương 4) Cuối cùng, phần kết luận trình bày những công việc đã thực hiện được và đưa ra những định hướng phát triển đề tài trong tương lai

Chương 1 TỔNG QUAN

1.1. Tổng quan về thực trạng vấn đề lượng giá phần mềm ở Việt Nam

1.1.1 L ượng giá phần mềm ảnh hưởng đến sự phát triển dự án CNTT ở Việt Nam

như thế nào?

Những năm gần đây, vấn đề lượng giá phần mềm đã trở thành vấn đề “nóng”, thu hút

sự quan tâm của nhiều ngành, nhiều cấp và đối tượng liên quan tham gia Thực tế đã có nhiều phương án lượng giá phần mềm được đưa ra áp dụng thử, ong vẫn chưa có x một phương pháp nào thực sự thuyết phục để có thể áp dụng thống nhất Vấn đề này đã ảnh hưởng không nhỏ đến tốc độ xây dựng, phê duyệt cũng như giải ngân cho các dự án đầu tư ứng dụng CNTT ở Việt Nam

Tiến độ triển khai ký kết hợp đồng với khách hàng cũng là một vấn đề lớn đối với các doanh nghiệp phần mềm Chưa có một căn cứ chính thức để định giá, iệc thẩm định, vphê duyệt các dự án đầu tư phần mềm thường , là phải lặp lại quy trình rất lâu Thông thường, để triển khai một hợp đồng đầu tư cho phần mềm với quy mô vừa và nhỏ mất vài tháng đến một năm, quy mô lớn thì phải mất đến vài năm[Vnnet0 ].3

Hiện nay trên thực tế tồn tại vấn đề nếu các doanh nghiệp phần mềm đưa ra giá cao , thì khó được thị trường chấp nhận Ngược lại, đưa ra giá quá thấp thì doanh nghiệp không

đủ chi phí dẫn đến việc triển khai dự án cứ “giậm chân tại chỗ” Trong tình hình đó, không

ít doanh nghiệp đã phải đối phó theo kiểu “tát nước theo mưa" [Vnnet03]

Nói đến việc triển khai các dự án CNTT sử dụng vốn ngân sách, các chuyên gia và các nhà quản lý trong ngành đều lắc đầu ngao ngán Các dự án đầu tư ứng dụng và phát triển CNTT mới giải ngân được một phần nhỏ trong tổng số ngân sách chi cho các dự án CNTT Trong số các dự án đầu tư này lại chủ yếu tập trung vào việc mua phần cứng Phần cứng mua về và "đắp chiếu" để đấy còn phần mềm thì phải đợi đơn giá để duyệt chi Một trong những dự án CNTT điển hình cho những sai xót này phải kể đến sự thất bại của dự

án 112 về tin học hoá quản lý hành chính nhà nước [TBVTSG08]

Cuối năm 2004, khi đánh giá lại kết quả thực hiện các chương trình ứng dụng CNTT

2001 - 2005, mới chỉ có 12% số vốn dự toán được giải ngân…Một trong những nguyên nhân chính là chưa có một quy chế hay quy định về quản lý đầu tư các dự án CNTT cho phù hợp Trong quy chế quản lý dự án đầu tư CNTT thì vấn đề định giá là một trong những vấn đề có thể nói là nhạy cảm và then chốt nhất [Vnnet02]

1.1.2. Những k ến nghị và giải pháp của các nhà quản lý CNTTi

Để giải bài toán định giá phần mềm, nhiều nhà quản lý CNTT đã đưa ra giải pháp là: xác định việc thanh toán đầu tư vào sản phẩm phần mềm thuộc về “hậu kiểm” theo thực chi, hoàn toàn không ên quan li gì tới vấn đề định giá phần mềm [Vnnet05] Giải pháp nàyđưa ra do các nhà quản lý này không thấy được vai trò của lượng giá ảnh hưởng đến tiến

độ thời gian, , ngân sách và chất lượng dự án thực hiện

Ngoài ra, một vài kiến nghị nên xây dựng một cơ sở dữ liệu (CSDL)về mức chi phí của các dự án đã tiến hành, từ đó có thể áp dụng cho các dự án sắp tiến hành [Vnnet05] Đây là phương pháp lượng giá t ng ươ tự Nhưngvới điều kiện là CSDL này phải chuẩn xác

và mang tính chất khuôn mẫu để các dự án gần giống như vậy sẽ được ước lượng chính xác hơn ếu các dự án xây dựng sau là các dự án hoàn toàn mới thì ước lượng như thế Nnào? Vì vậy, suy cho cùng, các dự án vẫn cần một phương pháp định giá chung ngay từ ban đầu

1.1.3. Những đặc trưng của ngành CNPM Việt Nam ảnh hưởng đến quá trình lượng

giá phần mềm

Thế ới có nhiều phương pháp gi và mô hình định giá chi phí dự án phần mềm, tại sao Việt Nam lại không tìm hiểu và áp dụng? Do Việt Nam có những đặc trưng riêng không giống như ngành CNPM thế giới cho nên các phương pháp và mô hình này chưa thật sự phù hợp Nên chúng ta cần phải tìm hiểu những đặc trưng nàyđể có những điều chỉnh hợp

lý về phương pháp và mô hình trước khi đưa vào áp dụng cho bài toán định giá phần mềm của Việt Nam như ối ảnh hiện nay b c

- Năng suất lao động sản xuất phần mềm đạt mức thấp [cnpmvn09]

- Không đồng bộ về trình độ của nhân lực

- Thủ tục về tài chính và thanh toán gây nhiều cản trở cho tiến độ giải ngân dự án phần mềm [Vnnet01]

- Phát triển phần mềm không theo qui trình sản xuất phần mềm chung: khó có thể ápdụng một mô hình định giá nào [VNMed06]

- Môi trường phát triển chủ yếu bằng phần mềm không bản quyền: chi phí cho công

cụ và môi trường phát triển phần mềm không được tính vào chi phí phát triển dự án Hơn nữa, phần mềm không bản quyền ảnh hưởng nhiều đến năng suất làm việc cũng như chất lượng sản phẩm phần mềm [Vinasa07]

Tóm lại, những đặc trưng trên đã ảnh hưởng đến việc xây dựng mô hình lượng giá d ự

án phần mềm theo quy chuẩn của ngành CNPM hiện đại Vì vậy, lời giải cho bài toán định

giá phần mềm không những là thách thức đặt ra cho doanh nghiệp phần mềm mà còn làm đau đầu các nhà quản lý CNTT như hiện nay

1.1.4. Những bất cập của công văn hướng dẫn lượng giá phần mềm 3364

Trước tình hình thực tế đòi hỏi cần phải có một cơ chế chung cho định giá phần mềm, ngày 17 tháng 10 năm 2008, bộ TT & TT ban hành công văn 3364/BTTTT-ƯDCNTT về việc hướng dẫn lượng giá phần mềm Công văn này hướng dẫn lượng giá các

dự án phần mềm theo mô hình UCP đã cải tiến và chỉnh sửa cho phù hợp với ngành CNPM Việt Nam (mô hình UCP Việt Nam) Đây là một trong những mô hình lượng giá phần mềm “hiện đại và được sử dụng khá phổ biến trong thời gian gần đây ”

Tuy nhiên, việc quyết định sử dụng mô hình UCP cho lượng giá dự án phần mềm của bộ lại gây khó khăn cho các đơn vị sản xuất phần mềm Bởi vì, muốn áp dụng phương pháp này thì đòi hỏi các đơn vị phải sử dụng ngôn ngữ mô hình hoá thông nhất UML(Unified Modeling Language để đặc tả yêu cầu người dùng Ngoài ra, mô hình còn hưa ) c

kể đến quy trình phát triển phần mềm phải tuân theo quy trình RUP Trong thực t , các ế kỹ thuật này vẫn chưa được phổ biến ở Việt Nam Vì vậy, công văn hướng dẫn sẽ chỉ được áp dụng cho số ít công ty và doanh nghiệp đủ điều kiện

Ngoài ra, còn nhiều vấn đề bất cập khác của công văn hướng dẫn được nêu ra như :sau:

- Khó hiểu và phức tạp: bảng tính toán giá trị phần mềm “ quá phức tạp để thực hiện” [NDan09]

- Kết quả lượng giá theo công văn hướng dẫn thấp hơn nhiều so với chi phí thực tế Văn bản hướng dẫn cung cấp mô hình ước lượng chưa bao quát hết các khoản chi phí [Pcworld09]

- “ Các hướng dẫn về chi phí khi làm phần mềm trong văn bản này chưa thể đủ được

mà mới chỉ dừng ở mức phát triển phần mềm, còn các công đoạn khác thì chưa tính đến” [NDan09]

- Mức lương lao động bình quân để định giá là quá thấp [Vtv09]

Tóm lại, xa rời thực tế, thiếu tính xác thực là một trong những lý do khiến cho công văn hướng dẫn đưa ra là bất khả thi Mục tiêu của công văn là đưa ra một phương pháp chung cho việc lượng giá dự án phần mềm nhưng với những bất cập này thì các doanh nghiệp, đơn vị sản xuất phần mềm không thể triển khai thực hiện Vì vậy, Các nhà quản lý không thể vội vàng đưa ra một phương pháp lượng giá chung mà không dựa trên những cơ

sở nghiên cứu và ứng dụng thực nghiệm để kiểm nghiệm và điều chỉnh cho phù hợp

Lượng giá là một công việc khó khăn và thiếu chính xác Bởi vì, quá trình ước lượng còn phụ thuộc ào nhiều ân tố khác v nh nhau mà các nhân tố này lại không được tính toán một cách chính xác Vì vậy, lượng giá chỉ là quá trình tính toán một cách phỏng đoán giá trị công sức, thời gian và chi phí để dự án hoàn thành và đạt được mục tiêu đề ra[LaiBre06]

1.2.2. Vai trò của lượng giá phần mềm

Vì sao phải lượng giá chi phí phần mềm? Giống như một người muốn xây dựng môt ngôi nhà, anh ta cần phải tính toán được mình phải tiêu bao tiền Một dự án phần mềm cũng vậy, người quản trị dựa trên những yêu cầu của khách hàng phải ước lượng được cần bao nhiêu công sức và thời gian để hoàn thành mục tiêu dự án đề ra Ước lượng càng chính xác bao nhiêu thì khả năng thành công của dự án đạt được nhiều bấy nhiêu Sự chính xác này thể hiện được khả năng kiểm soát và nắm bắt thực trạng về toàn bộ nguồn tài nguyên dùng cho phát triển ự án d

Nó đóng vai trò quan trọng bởi vì dựa vào ước lượng để tiến hành lập lịch biểu cho các công việc, trình tự thời gian, mức độ quan trọng của từng công việc…Quá trình này nhằm giúp cho người quản trị có thể kiểm soát bao quát được toàn bộ công việc cũng như tiến độ dự án [PPL2002]

Lượng giá để biết được quy mô dự án, để quản trị thời gian, tiến độ và mong muốn hoàn thành dự án đúng kế hoạc Hơn thế nữa, ượng h l giá để nâng cao chất lượng sản phẩm

dự án và nhằm đạt được mục tiêu dự án đề ra “vượt lên” những rủi ro có thể xảy ra

1.2.3. Cơ sở xây dựng mô hình ượng l giá chi phí

COCOMO là một trong những mô hình thực nghiệm điển hình sử dụng phương pháp SLOC Trong mô hình COCOMO, một SLOC là một dòng lệnh chuẩn Cách xác định dòng lệnh chuẩn là rất khó bởi nó còn phụ thuộc vào các từng ngôn ngữ lập trình khác nhau [cocomoII] Để giải quyết vấn đề này, học viện SEI (Software Engineering Institute)

đã chưa ra checklist để xác định SLOC mà không cần quan tâm đến ngôn ngữ lập trình(phụ lục A)

1.2.3.2. Điểm chức năng chưa hiệu chỉnh UFP

Với những ngôn ngữ và kỹ thuật lập trình hiện đại, SLOC không còn phù hợp để đo kích thước phần mềm Thế nên, một trong những hướng tiếp cận mới để xác định kích thước phần mềm là hướng phân tích điểm chức năng FP (Function Point) FP là đơn vị đo kích thước chức năng nghiệp vụ của một hệ thống thông tin người dùng [wiki]

Các yêu cầu của người dùng sẽ được phân phân tích sơ bộ để đưa ra danh sách các chức năng nghiệp vụ Sau đó, c ác chức năng này sẽ được phân loại và xác định độ phức tạp Tương ứng với mỗi độ phức tạp là các trọng số chức năng ổng T các chức năng theo trọng số là số điểm chức năng chưa hiệu chỉnh UFP (Unadjust Funtion Point) của phần mềm Từ UFP có thể quy đối sang SLOC qua bảng B.1 (phụ lục B)

1.2.3.3. Điểm Use case chưa hiệu chỉnhUUCP

-Với mong muốn có thể lượng giá ở giai đoạn sớm của dự án và kết hợp với sự phát triển của ngôn ngữ mô hình hóa UML ngày càng được sử dụng phổ biến, Karner (1993) đã dựa vào giá trị tác nhân và giá trị use-case trong mô hình Use case để - tính số điểm Use-case chưa hiệu chỉnh UUCP (Unadjusted Use Case Points) Đây là cơ sở tính kích thước và chi phí phát triển dự án [appUC]

UUCP = tổng giá trị use-case tổng giá trị tác nhân+

Giá trị tác nhân

Tác nhân (actor) là kh i niệm trừu tượng về một đối tượng tương tác với hệ thống áTác nhân có trao đổi thông tin với hệ thống hay hưởng lợi từ hệ thống và phải có sự tự trị trong quyết định [uml2]

Các tác nhân được phân loại theo độ phức tạp khác nhau: đơn giản, trung bình và phức tạp Tương ứng với mỗi độ phức tạp là một giá trị trọng số Tổng các tác nhân theo trọng số là giá trị tác nhân

Giá trị Use-case

Use-case là cơ sở thứ 2 để đánh giá kích thước dự án qua mô hình Use case Một use-case là một biểu diễn của tập hợp các chuỗi hành động mà hệ thống thực hiện nhằm cung cấp một kết quả cụ thể cho một tác nhân [uml2]

-Tương tự như tác nhân, các use-case cũng được phân loại theo độ phức Độ phức tạp được xác định dựa vào số giao tác (transaction) hay số class của use case Mỗi giao tác -được định nghĩa là một nhóm các hành động để thực hiện đầy đủ một công việc [ibm09]

Giá trị Use case bằng tổng các Use- -case theo trọng số

1.2.4. Các phương pháp và mô hình lượng giá dự án phần mềm

Theo thống kê của Beohm trong tài liệu [cocomo81] có 7 mô hình lượng giá phần mềm chính sau:

1.2.4.1 Mô hình toán học

Mô hình này đưa ra các công thức toán học dưới dạng các hàm số Các công thứcnày được xây dựng từ phương pháp thống kê số liệu của các dự án đã thực hiện trước đó [odu] C bi s là c ác ến ố ác tham số đầu ào Qua quá trình tính toán sẽ cho ra kết quả lượng vgiá tương ứng với mỗi giá trị đầu vào Hầu hết các mô hình dạng này đều sử dụng tham số đầu vào là SLOC Mô hình COCOMO là một trong những ví dụ điển hình cho mô hình toán học [LaiBre06]

1.2.4.2 Mô hình chuyên gia

Mô hình được xây dựng dựa trên những kinh nghiệm và tri thức của chuyên gia để đưa ra các ước lượng về chi phí của dự án Mô hình lấy ý kiến của một hay nhiều chuyên gia Quá trình này sẽ lặp lại nhiều lần đến khi nào đạt được sự đồng thuận ý kiến kết luận chung về dự đoán

Mô hình có nhược điểm là phụ thuộc vào khả năng đánh giá chủ quan của chuyên gia nên rủi ro cao Tuy nhiên, mô hình có ưu điểm là chi phí ước lượng thấp và đạt được kết quả chính xác cao nếu các chuyên gia là người có kinh nghiệm về hệ thống đang thực hiện [odu]

1.2.4.3. Mô hình tương tự

Mô hình này được xây dựng bằng cách so sánh dự án cần ước lượng với các dự án tương tự đã thực hiện Đây là một trong những mô hình ước lượng giản đơn nh ưng mang lại hiệu quả cho những dự án đã từng được thực hiện trước đó

Để sử dụng mô hình này đòi hỏi người ước lượng phải có kinh nghiệm và hiểu biết , nhiều về dự án hiện tại và các dự án đã làm trong quá khứ Vì như vậy, người ước lượng mới xác định sự khác nhau cơ bản giữa các dự án với nhau [LaiBre06]

1.2.4.4. Lượng giá Parkinson

Mô hình này xây dựng dựa trên luật Parkinson (1957): “công việc luôn tự mở rộng ra

để chiếm đủ thời gian được ấn định cho nó” [cocomo81] Công sức được đánh giá ngang với nguồn lực được đưa ra trước đó Vì vậy, mô hình không được xem là một bản ước lượng mà chỉ đơn thuần là một bản hợp đồng công việc Cho nên, mô hình không được sử dụng trên thực tế để ước lượng

1.2.4.5 Mô hình Price to Win

-Mục đích của mô hình đưa ra giá để nhằm thắng thầu, đạt được hợp đồng mà không dựa trên các yêu cầu chức năng của dự án Giá trị ước lượng thường thấp hơn so với thực

tế Khách hàng chấp nhận dự án tiến hành bởi họ mong muốn chi phí thấp Mức chi phí này không phản ảnh chính xác được yêu cầu ra cho dự án ì vậyV , sẽ ảnh hưởng đến chất lượng dự án xây dựng sau này

1.2.4.6. Lượng giá Top Down

-Chi phí cho toàn bộ dự án được tổng hợp từ các chức năng tổng thể của sản phẩm phần mềm hi phí này sẽ được phân ra cụ thể cho từng thành phần chức năng nhỏ hơnC Điều này giúp người quản lý c được những cái nhìn tổng quát hơn về hệ thống sẽ xây ó dựng Cả 3 mô hình ước lượng trên: tương tự, price- -to win và Parkinson là ví dụ của mô hình Top-down

1.2.4.7 Lượng giá Bottom Up

-Dự án được phân tách thành các thành phần chức năng nhỏ hơn sau đó lượng giá các thành phần này bằng mô hình ước lượng giống nhau Chi phí ước lượng cho toàn dự án là tổng chi phí các thành phần chức năng nhỏ hơn này

1.2.4.8. Đánh giá và so sánh các mô hình ượng giá l

Boehm khẳng định rằng: không có mô hình lượng giá nào là hơn hẳn mô hình khác “

về mọi mặt” [cocomo81] Các mô hình có ưu điểm, nhược điểm riêng và chúng bổ sung cho nhau Vì vậy, Boehm đề xuất nên kết hợp nhiều mô hình cùng ước lượng để thu được

kết quả ước lượng tốt nhất

- Trong mô hình top-down, sử dụng thêm mô hình chuyên gia để lấy ý kiến chuyên gia và mô hình tuần tự để so sánh với các dự án có sẵn trước đó

- Hiệu quả đánh giá tốt, phù hợp cho các phân tích định tính

- Các tham số của hệ thống dần được điều chỉnh chính xác hơn một khi dữ liệu của dự án ngày càng được thu thập nhiều hơn

- Cần có thông số đầu vào chính xác cho mô hình

- Khó ứng dụng cho các trường hợp riêng biệt

- Chỉ được xác định để đánh giá những dự án đã qua trong quá khứ mà không áp dụng cho các dự án sẽ xây dựng

Chuyên gia tức thời, các ngoại lệ - Đánh giá được các tình huống gia vào dự án như những thành viên - Các chuyên gia đánh giá tốt đã tham

Tương ự t tương tự - Dựa vào thông tin của các dự án hiện trước đó - Cần phải có dự án tương tự đã thực

P kinson ar - Liên quan đến kinh nghiệm - Khả năng ứng dụng thực tế kém

Price to- - Win - Dễ kiếm hợp đồng với dự kiến - T hường bị vượt quá ngân sách so

Top-down - Tập trung được ở mức hệ thống,

- Có nhiều cơ sở để cam kết hơn

- Có thể gây ra định giá cao hơn chi phí thực

- Tốn nhiều công sức cho ước lượng

Bảng 1.1: So sánh các mô hình lượng giá (nguồn Boehm 1981)

1.2.5. Quy trình lượng giá dự án phần mềm

Lượng giá dự án phần mềm là một hoạt động được thực hiện lặp đi lặp lại nhiều lần trong suốt quá trình phát triển dự án Từ giai đoạn sớm của dự án, lượng giá đóng vai trò quan trọng trong việc ước lượng kích thước, công sức, thời gian và chi phí để phát triển dự

án Kết quả lượng giá ban đầu này chưa thật sự chính xác ời vì những căn cứ cơ sở cho bước lượng còn rất ít, hiểu biết về dự án còn hạn chế ì vậy, trong suốt thời gian thực thi V

dự án, ta cần đối chiếu kết quả ước lượng này để cập nhật và điều chỉnh cho phù hợp với chi phí thực tế Sau khi dự án hoàn thành, số liệu thực tế sẽ được lưu trữ vào cơ sở dữ liệu

để phục vụ cho ước lượng các dự án sau này Ngoài ra, trong quá trình ước lượng cũng cần

có bước xác định rủi ro để kết quả ước lượng sẽ không bị sai lệch nhiều so với thực tế

SEPO chia quy trình lượng giá dự án thành 8 bước [SEPO99]: Ước lượng kích thước, chi phí và công sức lịch trình, , tài nguyên máy tính, đánh giá rủi ro, kiểm tra và phê duyệt, theo dõi và báo cáo, đánh giá và cải tiến quy trình

Trong khi đó, Galorath & Evans đưa ra quy trình ước lượng 10 bước Trong đó bao gồm cả các bước chuẩn bị như: thiết lập phạm vi và mục đích ước lượng, thu thập dữ

liệu…Cuối mỗi quy trình ước lượng có bước lập tài liệu ước lượng và rút ra bài học kinh nghiệm [GalEva06 ]

Giống như Galorath & Evans, các tác giả của Học viện Công nghệ California đưa ra quy trình ước lượng chi tiết 11 bước Trong đó, có hai bước chuẩn bị cho ước lượng: thu thập, phân tích các chức năng phần mềm và các yêu cầu lập trình, xác định mục tiêu và công việc cần thực hiện [hbookSCE]

, Như vậy, qua phân tích các quy trình ước lượng trên ta có thể nhận thấy quy trình ước lượng chi phí có thể được chia làm 3 giai đoạn: giai đoạn chuẩn bị (thu thập dữ liệu), giai đoạn ước lượng (ước lượng kích thước, công sức, thời gian và chi phí) và giai đoạn sau ước lượng (xem xét, phê duyệt, theo dõi và lưu dữ liệu ước lượng) Các bước này cũng gần với quy trình ước lượng của Kathleen đưa ra, bao gồm 9 bước cụ thể như sau [Kathleen99]:

TT Bước thực hiện Mô tả Thành phần tham gia Mục tiêu đầu ra

Quản trị dự án,

kỹ sư hiểu biết liên quan

Các phương thức được sử dụng để ước lượng, tổng số SLOC, UFP hay UUCP

3 Ước lượng công sức (Estimate the

effort)

Chuyển đổi kích thước

dự án sang công sức phát triển dự án

Quản trị dự án,

kỹ sư hiểu biết liên quan, người ước lượng

Các phương thức được sử dụng để ước lượng công sức, tổng công sức cần thực hiện

Quản trị dự án,

kỹ sư hiểu biết liên quan, người ước lượng

Lịch trình các công việc cần làm, mốc thời gian, ngày xét duyệt

5 Ước lượng chi phí (Estimate the

Quản trị dự án,

kỹ sư hiểu biết liên quan, người ước lượng

Danh sách các rủi ro,

phương thức xác định rủi ro, kích thước, công sức và chi phí được điều chỉnh

Những cá nhân trên, giám đốc dự

án

Các lỗi được tìm thấy trong bản ước lượng; kích thước, công sức, lịch trình, chi phí được xem xét chỉnh sửa và phê duyệt

Quản trị dự án,

kỹ sư hiểu biết liên quan, người ước lượng, giám đốc dự án

Kết qủa của các bước trên,

số liệu thực tế, đánh giá và cải tiến quy trình

Tài liệu ước lượng được tạo hay cập nhật từ những bước trên của toàn bộ dự án

Bảng 1.2 C: ác bước trong quy trình ước lượng (nguồn Kathleen 1999 )

Hình 1.3 L: ưu đồ quy trình lượng giá dự án phần mềm

Phân tích tiến trình ước lượng

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

Chi phí thực tế

Ước lượng công sức

Xem xét và phê duyệt ước lượng

Đánh giá rủi ro

Ước lượng chi phí

Ước lượng thời gian thực hiện

Phát triển dự án

Dữ liệu dự án

đã thực hiện

Chi phí nhân công hiện tại

Nhân lực sẵn có

Lập tài liệu ước lượng

và rút ra bài học kinh nghiệm

Chương 2 CÁC MÔ HÌNH LƯỢNG GIÁ THỰC NGHIỆM

2.1 Mô hình COCOMO

2.1.1. Giới thiệu tổng quan về mô hình COCOMO

Mô hình COCOMO (COnstructive COst MOdel) là mô hình chi phí xây dựng dự án phần mềm được Giáo sư Barry Boehm của đại học Southern California đề xuất lần đầu , tiên trong cuốn “Software Engineering Economics” (1981) COCOMO là mô hình ước lượng toán học sử dụng độ đo là số , nghìn dòng mã lệnh (KSLOC) Mô hình dùng để ước lượng công sức (effort), chi phí (cost) và lịch trình (schedule) dự án phần mềm COCOMO được xem là mô hình ước lượng kinh nghiệm Bởi vì, mô hình này được Boehm xây dựng

từ dữ liệu thống kê của 63 dự án khác nhau

Mô hình COCOMO (1981) gồm sự phân cấp của 3 mô hình con: cơ bản (basic), trung bình (intermediate) và chi tiết (detailed) Mỗi mô hình con này phụ thuộc vào dạng 3

mô hình dự án phát triển là organic, semi-detached và embedded, tương ứng với cách xếp loại sản phẩm phần mềm đơn giản, trung bình và phức tạp

2.1.2. Mô hình COCOMO cơ bản

Đây là mô hình ước lượng cho dự án nhỏ và cần ước lượng nhanh nên không quan tâm nhiều đến các yếu tố ảnh hưởng đến độ dự án Ngoài việc xác định loại mô hình phát triển của dự án ham số đầu vào cho mô hình cơ bản chỉ là số dòng mã lệnh, t

MM = a x (KDSI)b ( 2.1) TDEV = c x (MM d ( 2.2) )Trong đó:

- MM (Man months) : l công sức thực- à hiện để ho àn thành ự án Đơn vị tính là d người- áng, th là công việc của một người phải làm trong 1 tháng

- KDSI (Thousand Delivered Source Instructions): số nghìn dòng lệnh bàn giao

- TDEV (Development Schedule): là tổng thời gian của dự án (tính bằng tháng)

- Các hệ số , b, c, và d phụ thuộc vào dạng mô hình phát triển: a

Các dạng mô hình phát triển sẽ được định nghĩa như sau:

+ Mô hình Organic: là mô hình áp dụng cho những dự án giản đơn, các ứng dụng dễ hiểu Đội dự án nhỏ nhưng các thành viên đã làm việc cùng nhau và có nhiều kinh nghiệm

về dự án

+ Mô hình Semi detached: là mô hình áp dụng cho những dự án phức tạp hơn, các ứng dụng tương đối phức tạp Đội dự án trung bình, tất cả các thành viên có thể đều có kinh nghiệm hoặc một số có kinh nghiệm về lĩnh vực ứng dụng phát triển

-+ Mô hình Embedded: là mô hình áp dụng cho những dự án phức tạp, các ứng dụng phức tạp và khó hiểu Đội dự án lớn nhưng các thành viên không có nhiều kinh nghiệm về

dự án Dự án đòi hỏi nhiều sự sáng tạovà nhiều quy định ràng buộc chặt chẽ

Bảng 2 khái quát chung về đặc điểm của 3 dạng mô hình phát triển như sau:2

Đặc điểm

Mô hình Organic detached Semi- Embedded Hiểu biết về nghiệp vụ của dự án thực

Kinh nghiệm liên quan đến hệ thống

Cần thiết phải tương thích phần mềm

bằng thiết lập trước các yêu cầu Ít Tương đối Đầy đủCần thiết phải tương thích phần mềm

Cần thiết phải phát triển đồng thời giữa

phần cứng mới và các thủ tục điều hành Thấp Trung bình Nhiều Sáng kiến về thuật toán, kiến trúc xử lý

thước

Bảng 2.1.2: Các dạng mô hình dự án phát triển của COCOMO (nguồn Boehm81)

Ví dụ 2.1: Dự án BVPROP là dự án quản lý bảo hiểm phi nhân thọ Đây là dự án phức tạp vì lĩnh vực chuyên môn khá phức tạp đòi hỏi hiểu biết và có kiến thức liên quan đến lĩnh vực chuyên môn Đội dự án lại không có nhiều kinh nghiệm hay chuyên môn về lĩnh vực này Hơn nữa, sản phẩm dự án đòi hỏi sự ràng buộc chặt chẽ về thời gian, quy trình từ khảo sát, phân tích, thiết kế đến thực thi dự án Yêu cầu cao về kiến trúc xử lý thiết

kế dữ liệu để đảm bảo: an toàn, bảo mật và hiệu năng cao Kích thước dự án lên đến 100 KDSI Do đó, BVPROP được xếp vào loại mô hình Embedded

Áp dụng công thức (2.3), (2.4), bảng 1 để tính công sức và thời gian dự án:2

MM = 3,6 x (100)1,2 = 904 (người-tháng)TDEV = 2,5 x (904)0,32 22 (tháng) =

Số thành viên dự án trung bình: 904/22 41 ≈ (người)

2.1.3 Mô hình COCOMO trung bình

Mô hình trung gian có tính đến dạng mô hình dự án phần mềm sẽ phát triển:

MM = EAF x a x (KDSI)b ( 2.5) TDEV = c x (MM d ) ( 2.6) Các hệ số a, b, c, và d phụ thuộc vào dạng mô hình phát triển:

Bảng 2.1.3 Các h: ằng số phụ thuộc của COCOMO trung bình (nguồn Boehm81)

EAF (Effort Adjustment Factor) là hệ số điều chỉnh công sức phụ thuộc vào giá trị của 20 yếu tố điều khiển giá(cost driver)được chia thành nhóm yếu tố chính: sản phẩm, 4 máy tính, con người và dự án Các yếu tố này được phân thành 5 mức khác nhau từ rất thấp đến cực cao

EAF = ∏ (yếu tố điều khiển giá)

Các yếu tố điều khiển giá

(cost driver)

R ấtthấp Thấp

Thông thường Cao

R ấtcao Cực cao

Thuộc tính của máy tính

Ràng buộc về thời gian thực thi xecution (E

Ràng buộc về bộ nhớ lưu trữ chính (Main

Tính thay đổi của flatform (Virtual machine

Thời gian h ồi đáp (Computer turnaround

Thuộc tính của nhân lực

Năng lực phân tích (Analyst capability -

Kinh nghiệm về flatform sẽ phát triển ứng

dụng (Virtual machine experience – VEXP) 1,21 1,1 1 0,9

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

(Programming Language experience -

LEXP)

1,14 1,07 1 0,95

Thuộc tính của dự án

Dùng các kỹ năng lập trình hiện đại

(Modern Programming Practice MODP - ) 1,24 1,1 1 0,91 0,82 Mức độ sử dụng công cụ phần mềm để phát

triển ứng dụng (Software tools - TOOL) 1,24 1,1 1 0,86 0,83 Ràng buộc về lịch trình phát triển dự án

(Development schedule - SCED) 1,23 1,08 1 1,04 1,1

Bảng 2.1.4: Các yếu tố điều khiển giá của mô hình COCOMO (nguồn Boehm81)

Thuộc tính của sản phẩm

Thuộc tính của máy tính

Thuộc tính của nhân lực

Kinh nghiệm về flatform sẽ phát triển ứng dụng (VEXP) Cao 0,9

Thuộc tính của dự án

Dùng các kỹ năng lập trình hiện đại (MODP) Trung bình 1 Mức độ sử dụng công cụ để phát triển ứng dụng(TOOL) Cao 0,86 Ràng buộc về lịch trình phát triển dự án (SCED) Trung bình 1

Bảng 2.15 H: ệ số điều chỉnh công sức EAF của dự án BVPROP

Áp dụng công thức (2.1.5), để tính công sức dự án:

MM = 0,99 x 2,8 x (100)1,2 698 = (người-tháng) Ước lượng thời gian dự án(2.1.6) và bảng 2.1.4

TDEV = 2,5 x (698)0,32 20 (tháng) =

Số thành viên dự án trung bình: 698 0 34 /2 ≈ (người)

2.1.4 Mô hình COCOMO chi tiết

Boehm với tiêu chí đặt ra là: dữ liệu đầu vào càng chi tiết bao nhiêu thì kết quả ước lượng thu được sẽ càng chính xác bấy nhiêu [cocomo81] Tiêu chí này được thể hiện thông qua việc phân cấp hệ thống trong mô hình chi tiết

Trong khi cả hai mô hình cơ bản và trung bình ước lượng chi phí dự án ở mức hệ thống tổng thể thì mô hình chi tiết lại phân ra các mức con (sub system) để tiến hành ước lượng Vì rõ ràng các hệ thống con sẽ, có điều kiện và đặc điểm khác nhau nên việc chia nhỏ hệ thống ra làm tăng tính chính xác của kết quả ước lượng Mức hệ thống con sẽ tiếp được chia tiếp thành các mô đun (module) dựa vào các yếu tố điều khiển giá: độ phức tạp của mô đun và khả năng tích hợp vào hệ thống có sẵn(CPLX), năng lực lập trình (PCAP , )kinh nghiệm về ngôn ngữ lập trình (LEXP và môi trường flatform (VEXP) ) cho ứng dụng được xây dựng

Mức hệ thống con được phân cấp dựa vào các yếu tố điều khiển giá còn lại như: ràng buộc về thời gian, bộ nhớ lưu trữ, năng lực phân tích, công cụ, lịch trình…

Ngoài ra, mỗi mô đun hay mỗi hệ thống con được chia thành 4 pha khác nhau: thiết

kế sản phẩm PD(Product Design), thiết kế chi tiết DD(Detailed Design), lập trình và kiểm thử đơn vị CUT ode and nit (C U Test), tích hợp và kiểm thử IT (Integration and Test) Vì mỗi pha này đòi hỏi năng lực khác nhau nên hệ số điều khiển giá và tỷ lệ công sức khác nhau

Ví dụ 2.1.3: Sử dụng mô hình COCOMO chi tiết để ước lượng công sức, thời gian và

nhân lực cho dự án BVPROP 100 KSLOC ở ví dụ 2.1.1

Trước tiên, ta sẽ tiến hành phân tích và phân chia hệ thống thành 3 hệ thống con: QUERY, UPDATE và UTILITIES Từ mức hệ thống con sẽ tiếp tục chia thành các mô đun:

+ QUERY gồm 3 mô đun: Qedit, Search, Output

+ UPDATE gồm 2 mô đun: Upedit, Modify

+ UTILITIES có 1 mô đun: Utils

- Qúa trình xây dựng dự án được chia thành 4 pha chính:

+ Lập trình và kiểm thử đơn vị CUT : 40 %

+ Tích hợp và kiểm thử IT : 19 %

- Sau đây là bảng ước lượng chi tiết ở mức mô đun:

Hệ thống con Mô đun Pha Hệ số hướng dẫn chi phí EAF

(m) MM (m) Stt tên KSLOC tên KSLOC tên tỷ lệ CPLX PCAP VEXP LEXP

IT 0,19 1,15 1,00 0,90 0,95 0,98 19,0

Search 6

PD 0,16 1,15 1,17 1,10 1,07 1,58 25,8

DD 0,25 1,15 1,17 1,10 1,00 1,48 37,7 CUT 0,16 1,15 1,17 1,10 1,07 1,58 34,5

IT 0,25 1,15 1,00 1,10 1,00 1,27 19,0

Output 9

PD 0,16 1,15 1,17 1,10 1,07 1,58 25,8

DD 0,25 1,15 1,00 1,00 0,95 1,09 27,8 CUT 0,40 1,00 0,86 0,90 0,95 0,74 30,0

IT 0,19 1,15 0,86 0,90 0,95 0,85 16,4

Bảng 2.1.6: COCOMOchi tiết: ước lượng công sức ở mức mô đun của BVPROP

- Kết quả ước lượng ở mức hệ thống con:

Stt con HT Pha Hệ số điều khiển giá EAF (ss) MM (m) MM (ss)

RELY DATA STOR VIRT TURN ACAP AEXP MODP TOOL SCED

IT 1,15 1,16 1,00 1,15 0,87 1,19 1,00 1,00 1,00 1,00 1,59 37,6 59,7

Bảng 2.1.7: COCOMO chi tiết: k ết quả ước lượng công sức của dự án BVPROP

Ước lượng thời gian dự án(2.1.6) và bảng 2.1.4

Hình 2.2.1: Mô hình hoạt động của COCOMOII

Mô hình COCOMOII có ba mô hình con:

- Mô hình tổng hợp ứng dụng (Applications Composition)

- Mô hình thiết kế sớm (Early Design)

- Mô hình hậu kiến trúc (Post Architecture)

2.2.1. Đặc điểm cơ bản của COCOMO II

Tại sao phải xây dựng COCOMO II? Bởi vì, mô hình COCOMO 81 (mô hình thác nước) không còn phù hợp với mô hình phát triển phần mềm tiến (mô hình xoắn ốc) Vì vậy, COCOMOII ra đời nhằm khác phục những nhược điểm của COCOM81 đồng thời nhằm để phù hợp với tiến trình phần mềm hiện đại

Hơn nữa, COCOMO II phù hợp với quy trình phát triển nhanh và không tuyến tính, tái kĩ nghệ, các phương pháp tái sử dụng, các phương pháp hướng đối tượng mà mô hình COCOMO trước chưa làm được Một trong những đặc điểm đáng chú ý của COCOMO II

là hỗ trợ tham số đầu vào gồm cả FP, điểm đối OP và SLOC

2.2.2. Ước lượng kích thước dự án

Ước lượng kích thước (sizing) dự án ban đầu càng chuẩn xác bao nhiêu thì kết quả ước lượng chung của dự án càng chính xác bấy nhiêu Kích thước có thể được đếm trực tiếp số SLOC bằng cách dựa vào bảng checklist phụ l( ục A) để xác định được câu lệnh nguồn Hoặc sử dụng phương pháp FP để tính số điểm chức năng chưa hiệu chỉnh UFP rồi quy đổi sang SLOC qua bảng B.1 (phụ lục B)

Ngoài ra, khi ước lượng kích thước cần xét đến các tình huống tái sử dụng tái ỹ : , knghệ, số dòng lệnh bị loại bỏ do thay đổi yêu cầu Tất cả tình huống này đều có thể xảy ra cho một dự án khi tiến hành thực hiện Vì vậy, người chịu trách nhiệm ước lượng chi phí cho dự án cần phải hiểu tìm hiểu rõ dự án trước khi bắt tay vào thực hiện ước lượng

Mô hình COCOMO

II

Kích thước

phần mềm ước lượng

Hệ số nhân công sức EM:

hệ số điều khiển giá của sản phẩm,

COCOMO II hiệu chuẩn lại dữ liệu của cty

2.2.2.1. Hệ số thay đổi yêu cầu REVL

Mô hình COCOMO II sử dụng hệ số REVL (Requirements Evolution and Volatility)

để chỉ phần trăm số dòng lệnh nguồn bị loại bỏ do thay đổi yêu cầu Việc thay đổi này thường là bắt nguồn từ phía khách hàng hoặc do nâng cấp công nghệ… Số dòng lệnh bị loại bỏ này cũng là công sức của dự án đã thực hiện nên kích thước để tính chi phí của dự

án theo công thức sau:

DSizeREVLSize ×

)(

105100100

2.2.2.2 Ước lượng kích thước cho dự án tái sử dụng mã nguồn

Mô hình COCOMO II tính số mã tái sử dụng mã re( used code) qua biểu thức sau:

AAMAT

≤

×

×+

×+

=

50,

100

)(

50,

100

)]

02.01([

AAFUNFMSU

AAFAA

AAFUNFM

SUAAF

AA

- EKSLOC là số KSLOC tương đương (Equivalent) cho dự án tái sử dụng

- AKSLOC là số KSLOC được hiệu chỉnh để thích ứng (Adapted) với dự án hiện tại

- AAF (Adaptation Adjustment Factor) là hệ số tỷ lệ điều chỉnh thích ứng Hệ số này phù thuộc vào 3 hệ số tỷ lệ :

- DM (Design Modified) là phần trăm thiết kế được chỉnh sửa

- CM (Code Modified) là phần trăm code được hỉnh sửac

- IM (Integration Required) là phần trăm nỗ lực để tích hợp phần mềm tái sử dụng mã

- AAM (Adaptation Adjustment Modifie ) là hệ số r hiệu chỉnh thích ứng Hệ số này phụ thuộc vào hệ số AAF, AA, SU, UNFM

- Số gia AA (Assessment and Assimilation) nhằm đánh giá mức độ đồng hóa của

mô đun tái sử dụng:

2 Tìm kiếm mô đun cơ bản và tài liệu hóa mô đun tái sử dụng

4 Một vài kiểm thử và đánh giá môđun, tài liệu hóa mô đun

6 Khá nhiều kiểm thử và đánh giá môđun, tài liệu hóa mô đun

8 Kiểm thử và đánh giá mô đun toàn diện, tài liệu hóa mô đun

Bảng 2.2.1: Hệ số tỷ lệ cho số gia AA (nguồn Boehm 2000)

Số gia hiểu biết phần mềm (SU Software Understanding) được mô tả trong bảng - Đơn vị đo của SU là phần trăm Ngoài ra, DM và CM có liên quan trực tiếp đến số gia SU Nếu không có DM hay CM tức là tái sử dụng mà không phải chỉnh sửa code thì không có

Có cấu trúc khá

rõ ràng, tuy nhiên vẫn còn một số điểm yếu

Tính liên kết cao, tính phụ thuộc thấp

Module hóa cao ,thông tin được

ẩn bên trong cấu trúc dữ liệu

Sự tương quan giữa chương trình và ứng dụng ở mức độ vừa phải

Chương trình và ứng dụng tương quan với nhau ở mức cao

Có sự tương quan hoàn toàn giữa chương trình và ứng dụng

Tính

tự mô

tả

Code tối nghĩa;

tài liệu vừa thiếu

vừa tối nghĩa

hoặc không phù

hợp

Một ít code cóchú thích và header; một ít tài liệu hữu ích

Chú thích code, các header và tài liệu ở mức

độ vừa phải

Chú thích code

và header rõ ràng; tài liệu hữu ích; vẫn còn một

Bảng 2.2.2: Giá trị của số gia hiểu biết phần mềm SU (nguồn Boehm 2000)

Bảng 2.2.3: Giá trị của hệ số UNFM (nguồn Boehm 2000)

Trong biểu thức 2.2.2, giá trị AT (Automatically Translated Code) là tham số liên quan đến mã lệnh dịch tự động, sẽ được đề cập chi tiết trong phần sau

Ví dụ 2.2.2:

Dự án BVPROP được phát triển từ nền kiến trúc ứng dụng IAA của IBM, sử dụng 20% mã nguồn tái sử dụng trên tổng số 100 KSLOC của cả dự án Trong đó, các giá trị hiệu chỉnh: DM = 20%, CM = 10%; IM = 15% Các mô đun được tái sử dụng được tái sử dụng được kiểm thử và đánh giá khá nhiều (AA=6) Đa phần mô đun tái sử dụng có tính dễ hiểu cao (SU=20%) và có phần quen thuộc với lập trình viên (UNFM=0,4) Ngoài ra, dự

án không có code được dịch tự động nên AT=0

Để tính kích thước tương đương EKSLOC của 20% mã nguồn tái sử dụng, tương ứng kích thước thích ứng AKSLOC = 20% x 100 = 20 KSLOC, trước hết ta phải xác định

≈

×

×+

×+

=AAM

Vì vậy, kích thước tương đương EKSLOC cần ước lượng là:

)(

8,424,0100

01

2.2.2.3. Ước lượng kích thước cho dự án bảo trì phần mềm

Kích thước dự án qua quá trình bảo trì(Maintenance)được tính như sau:

MAFMCF

zeBaseCodeSiSize)M =[( )× ]×

Trong đó, MCF (Maintenance Change Factor) là hêsố thay đổi bảo trì thể hiện phần , trăm mã ban đầu (BaseCodeSize) so với lượng mã được thêm vào (SizeAdded) và được chỉnh sửa (SizeModified):

zeBaseCodeSi

edSizeModifiSizeAdded

Thay (2.2.6) vào (2.2.5) ta được:

MAFed

SizeModifiSizeAdded

= SU UNFM MAF

án bắt đầu nên trong giai đoạn bảo trì số gia hiểu biết SU và hệ số không quen thuộc UNFM cũng có sự thay đổi: SU=10% (rất cao); UNFM = 0 (hoàn toàn quen thuộc)

Hệ số điều chỉnh bảo trì MAF:

1 0 100

Vì vậy, kích thước dự án qua quá trình bảo trì:

)(

201)515()(SizeM = + × = KSLOC2.2.3 Ước lượng công sức phát triển

2.2.3.1. Mã được dịch tự động

Quá trình chuyển đổi một ngôn ngữ lập trình sang một ngôn ngữ khác gọi là quá trình tái kỹ nghệ phần mềm ( -engineering)re , được thực hiện bằng các công cụ dịch mã nguồn tự tự động (Automatically Translated Code) Các công cụ này có thể tái kỹ nghệ một lượng lớn mã nguồn nhưng công sức bỏ ra lại thấp

ATPROD

AT ASLOC

Bảng 2.2.4: Bảng giá trị của hệ số AT (nguồn Boehm 2000) ATPROD (Automatic Translation Productivity) là hệ số chỉ năng suất dịch tự động Theo nghiên cứu của NIST, giá trị mặc định cho ATPROD = 2400, tức là năng suất của dịch tự động là 2400 dòng lệnh/người tháng Giá trị này có thể thay đổi tuỳ thuộc vào kỹ -thuật sử dụng khác nhau

Dịch tự động được xem là hoạt động tách biệt trong quá trình phát triển phần mềm

Vì vậy, phần công sức PMAutokhông được đưa vào tính thời gian phát triển dựa án

Ví dụ 2.2.4:

Giả sử dự án BVPROP có AKSLOC =15 KSLOC được tái kỹ nghệ bằng công nghệ

xử lý theo lô (AT=96%)

Công sức bỏ ra cho chuyển đổi tự động 15 KSLOC là:

( ) 0,006

2400

1009615

2.2.3.2. Ước lượng phạm cho kết quả đầu ra của mô hìnhvi

Mô hình COCOMOII sử dụng phương pháp ước lượng phạm vi cho kết quả đầu ra của mô hình Ba giai đoạn cho phép tuỳ biến phạm vi của ước lượng đầu ra sẽ tương ứng với 3 mô hình: Tổng hợp ứng dụng, Thiết kế sớm, Hậu kiến trúc sẽ khảo sát ở phần tiếp theo Các phạm vi tùy biến này tạo ra một tập các ước lượng lạc quan (Optimistic) và bi quan (Pessimistic), thể hiện một độ lệch chuẩn xung quanh giá trị cần ước lượng (E), được tính toán như sau:

Giai đoạn (mô hình) Ước lượng lạc quan Ước lượng bi quan

cụ thể nào Trong giai đoạn này, mô hình AC sử dụng ước lượng điểm đối tượng OP(Object Point để tiếp cận xác định kích thước của phần mềm Điểm đối tượng là một phép ) đếm các màn hình, các báo cáo và các module ngôn ngữ lập trình thế hệ thứ 3 (3GL) được phát triển trong ứng dụng

2.2.4.2 T ính điểm đối tượng OP

OP được xem là đơn vị đo kích thước của dự án (không phải SLOC) trong mô hình tổng hợp ứng dụng Cách tính điểm OP dựa vào các yếu tố sau:

- Số lượng và độ phức tạp của màn hình (screen)

- Số lượng và độ phức tạp của báo cáo (report)

- Tổng số mã tái sử dụng

- Kinh nghiệm của lập trình viên

Tính độ phức tạp và giá trị của OP dựa vào số lượng screen và report và số lượng table trong CSLD Các bảng này được xét trên hai yếu tố:

- srvr (server): Số lượng các bảng trong CSDL trên các máy server mà screen hay report tham chiếu đến

- clnt (client): Số lượng các bảng dữ liệu trong CSDL trên máy client mà screen hay report tham chiếu đến

Cụ thể cách tính độ phức tạp của OP thể hiện qua bảng sau:

≥8 (>3srvr

>5clnt)

<4 (<2srvr

<3clnt)

<8 (2÷3srvr 3÷5clnt)

≥8 (>3srvr

Bảng 2.2.7 T: hống kê số lượng Screen và Report trong dự án BVPROP

Từ bảng 2.2.3 ta có số điểm đối tượng OP:

OP = 52 x 1 + 100 x 2 + 200 x 3 + 200 x 5 + 400 x 8 + 6220 x 10 = 11.272 2.2.4.3. Tính toán công sức dựa trên OP

Đánh giá công sức PM (Person-months):

- r là phần trăm code tái dử dụng

- PROD là năng suất làm việc (Productivity), phụ thuộc vào khả năng và kinh nghiệm của lập trình viên

Năng lực và kinh nghiệm của

2.2.5.1. Tiếp cận mô hình ED

Mô hình ED (Early Design) được sử dụng ở giai đoạn sớm của dự án, khi biết rất ít thông tin về dự án Để áp dụng mô hình ED vào ước lượng, ta cần xác định một bộ gồm 5

hệ số tỉ lệ SF (Scale factor) cùng 7 hệ số nhân công sứcEM (Effort Multiplier)

2.2.5.2. Ước lượng công sức

Công sức trong mô hình ED được ước lượng như sau:

Auto

NS PMPM

Auto i

SizeA

=100

101,0

j jSFB