Xây dựng công cụ ước lượng chi phí phát triển phần mềm dựa trên CBR và thử nghiệm ở Công ty Honda Việt Nam

Từ xu hướng đó tác giả đã nghiên cứu một số phương pháp luận thường được sử dụng để ước lượng chi phí phát triển phần mềm, đặc biệt là những phương pháp mô phỏng quá trình lập luận của c

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

LƯƠNG MINH HẢI

XÂY DỰNG CÔNG CỤ ƯỚC LƯỢNG CHI PHÍ PHÁT TRIỂN PHẦN MỀM DỰA TRÊN CBR VÀ THỬ NGHIỆM Ở CÔNG TY HONDA VIETNAM

LUẬN VĂN THẠC SĨ

HÀ NỘI - 2010

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

LƯƠNG MINH HẢI

XÂY DỰNG CÔNG CỤ ƯỚC LƯỢNG CHI PHÍ PHÁT TRIỂN PHẦN MỀM DỰA TRÊN CBR VÀ THỬ NGHIỆM Ở CÔNG TY HONDA VIETNAM

Ngành: CÔNG NGHỆ THÔNG TIN

Chuyên ngành: CÔNG NGHỆ PHẦN MỀM

Mã số: 60 48 10

LUẬN VĂN THẠC SĨ

Người hướng dẫn khoa học

TS Trương Anh Hoàng

HÀ NỘI - 2010

MỤC LỤC

CHƯƠNG 1 – GIỚI THIỆU 1

CHƯƠNG 2 – QUY TRÌNH ƯỚC LƯỢNG CHI PHÍ PHÁT TRIỂN PHẦN MỀM 4

2.1 Tổng quan và mục đích ước lượng 4

2.2 Chi tiết quy trình ước lượng 4

2.2.1 Xác định phạm vi và mục tiêu của dự án 6

2.2.2 Xác định phạm vi kĩ thuật và các giả định 6

2.2.3 Thu thập dữ liệu 6

2.2.4 Xác định kích cỡ phần mềm 7

2.2.5 Chuẩn bị đường mức ước lượng 7

2.2.6 Thẩm định và phân tích các rủi ro 9

2.2.7 Kiểm định kết quả ước lượng 9

2.2.8 Xây dựng kế hoạch thực thi dự án 10

2.2.9 Xây dựng tài liệu cho quá trình ước lượng 10

2.2.10 Đánh giá dự án thông qua quá trình phát triển 11

2.3 Một số phương pháp ước lượng chi phí phát triển phần mềm 11

2.3.1 Mô hình COCOMO 11

2.3.2 Mô hình điểm chức năng (Function Point) 15

2.3.3 Phương pháp chuyên gia 16

CHƯƠNG 3 – PHƯƠNG PHÁP LẬP LUẬN DỰA TRÊN KINH NGHIỆM 19

3.1 Giới thiệu chung 19

3.2 Chi tiết phương pháp lập luận dựa trên kinh nghiệm 19

3.2.1 Tìm kiếm dữ liệu tương tự 22

3.2.2 Sử dụng lại kết quả tìm kiếm 24

3.2.3 Bảo trì cơ sở dữ liệu các ca lập luận 27

3.3 Ưu và nhược điểm của phương pháp CBR 30

3.3.1 Ưu điểm 30

3.3.2 Nhược điểm 30

CHƯƠNG 4: PHÂN TÍCH THIẾT KẾ HỆ THỐNG PC-PACK-CES 32

4.1 Thiết kế hệ thống 32

4.2 Mô hình triển khai 32

4.3 Phân tích kiến trúc hệ thống 33

4.3.1 Phân tích yêu cầu 33

4.3.2 Xác định các gói phân tích 34

4.3.3 Xác định tác nhân 35

4.3.4 Biểu ca ca sử dụng 35

4.3.5 Luồng sự kiện 36

4.4 Phân tích ca sử dụng 40

4.4.1 Đăng nhập vào hệ thống 40

4.4.3 Khai báo yếu tố chi phí 45

4.4.4 Ca sử dụng ước lượng chi phí 48

4.5 Thiết kế cơ sở dữ liệu PC-PACK-CES 50

4.5.1 Sơ đồ logic quan hệ các bảng dữ liệu 50

4.5.2 Mô tả chi tiết các bảng dữ liệu 51

CHƯƠNG 5: ĐÁNH GIÁ KHẢ NĂNG ÁP DỤNG PC-PACK-CES TẠI CÔNG TY HONDA 56

5.1 Giới thiệu các hệ thống phần mềm tại công ty Honda 56

5.2 Quy trình thử nghiệm phần mềm PC-PACK-CES tại công ty Honda 58

5.2.1 Thu thập, phân tích và xử lý dữ liệu 58

5.2.2 Kết quả thử nghiệm chương trình 61

5.3 Đánh giá khả năng áp dụng phần mềm PC-PACK-CES tại công ty Honda 64

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀI 65

TÀI LIỆU THAM KHẢO 66

BẢNG KÝ HIỆU CÁC TỪ VIẾT TẮT

CBR Case based reasoning Phương pháp lập luận dựa trên

kinh nghiệm KNN K nearest Neighbor Thuật toán tìm k người hàng xóm

gần nhất

triển phần mềm tại công ty Honda

DANH MỤC HÌNH VẼ

Hình 2 - 1 Quy trình ước lượng chi phí phát triển dự án phần mềm[5] 5

Hình 3 - 1 Mô hình lập luận dựa trên kinh nghiệm [5] 20

Hình 3 - 2 Sơ đồ phân rã công việc hệ thống CBR[7] 21

Hình 3 - 3 Sơ đồ mô tả quy trình tìm kiếm CBR[7] 23

Hình 3 - 4 Sơ đồ mô tả quá trình hiệu chỉnh giải pháp 26

Hình 3 - 5 Mô tả phạm vi và khả năng tìm ra lời giải của ca lập luận 29

Hình 4 - 1 Thiết kế tổng quan hệ thống 32

Hình 4 - 2 Mô hình triển khai PC-PACK-CES 33

Hình 4 - 3 Sơ đồ các gói chức năng của hệ thống 34

Hình 4 - 4 Mô hình ca sử dụng mức gộp của hệ thống 36

Hình 4 - 5 Biểu đồ phân tích lớp đăng nhập hệ thống 40

Hình 4 - 6 Biểu đồ tuần tự phân tích thực thi ca sử dụng đăng nhập hệ thống 40

Hình 4 - 7 Biểu đồ hoạt động chức năng đăng nhập hệ thống 41

Hình 4 - 8 Màn hình đăng nhập hệ thống PC-PACK-CES 41

Hình 4 - 9 Màn hình chính hệ thống PC-PACK-CES 42

Hình 4 - 10 Biểu đồ lớp phân tích thực thi ca sử dụng khai báo dự án cơ sở lập luận 42

Hình 4 - 11 Biểu đồ tuần tự phân tích thực thi ca sử dụng quản lý danh mục dự án 43

Hình 4 - 12 Biểu đồ hoạt động ca sử dụng quản lý dự án cơ sở lập luận 43

Hình 4 - 13 Màn hình quản lý thông tin dự án cơ sở lập luận 44

Hình 4 - 14 Màn hình khai báo thông tin của dự án mới 44

Hình 4 - 15 Màn hình sửa thông tin dự án 45

Hình 4 - 16 Biểu đồ lớp phân tích thực thi ca sử dụng khai báo yếu tố chi phí 45

Hình 4 - 17 Biểu đồ tuần tự phân tích thực thi ca sử dụng khai báo yếu tố chi phí 46

Hình 4 - 18 Biểu đồ hoạt động ca sử dụng quản lý yếu tố chi phí 46

Hình 4 - 19 Màn hình quản lý danh mục yếu tố chi phí 47

Hình 4 - 20 Màn hình khai báo yếu tố chi phí mới 47

Hình 4 - 21 Màn hình sửa dữ liệu yếu tố chi phí 48

Hình 4 - 22 Biểu đồ phân tích lớp thực thi ca sử dụng ước lượng chi phí 48

Hình 4 - 23 Biểu đồ tuần tự phân tích thực thi ca sử dụng ước lượng chi phí 49

Hình 4 - 24 Biểu đồ hoạt động ca sử dụng ước lượng chi phí 49

Hình 4 - 25 Màn hình ước lượng chi phí phát triển dự án 50

Hình 4 - 26 Quan hệ các bảng dữ liệu 50

Hình 5 - 1 Cơ cấu tổ chức công ty Honda 56

Hình 5 - 2 Kết quả ước lượng bằng phương pháp khoảng cách Euclidean 63

Hình 5 - 3 Kết quả ước lượng bằng phương pháp tính độ tương tự thuộc tính 63

4.3.

DANH MỤC BẢNG

Bảng 2 - 1 Bảng hằng số dùng trong tính toán bằng phương pháp COCOMO cơ bản 12

Bảng 2 - 2 Thang điểm đánh giá các đặc trưng của dự án 14

Bảng 2 - 3 Bảng hệ số tính bằng phương pháp COCOMO trung gian 15

Bảng 2 - 4 Bảng quy đổi số dòng lệnh trong một chức năng của các ngôn ngữ lập trình 15

Bảng 5 - 1 Danh sách các hệ thống phần mềm sử dụng tại Honda 57

Bảng 5 - 2 Đặc trưng thuộc tính của các dự án đã thực hiện thành công 59

Bảng 5 - 3 Danh sách các dự án lưu trong CSDL dùng để lập luận 61

Bảng 5 - 4 Dữ liệu đầu vào của dự án cần ước lượng 62

Bảng 5 - 5 Chi phí dự toán của dự án mới 62

Bảng 5 - 6 Bảng kết quả thử nghiệm ước lượng bằng PC-PACK-CES 64

CHƯƠNG 1 – GIỚI THIỆU

1.1 Đặt vấn đề

Sự thành công hay thất bại của một dự án nói chung và dự án phát triển phần mềm nói riêng phụ thuộc rất nhiều vào những kết quả của quá trình ước lượng, lập dự toán chi phí trước thời điểm triển khai dự án vào thực tế Chủ đề này đã thu hút sự chú của rất nhiều nhà khoa học trên thế giới và đến nay đã có những công trình nghiên cứu

có chất lượng

Từ xu hướng đó tác giả đã nghiên cứu một số phương pháp luận thường được

sử dụng để ước lượng chi phí phát triển phần mềm, đặc biệt là những phương pháp mô phỏng quá trình lập luận của con người Trong số đó, phương pháp lập luận dựa trên kinh nghiệm CBR (Case based reasoning) là một trong những phương pháp có nhiều

ưu điểm, có khả năng áp dụng thành công vào công việc ước lượng chi phí Đã có nhiều sản phẩm phần mềm thực hiện ước lượng bằng phương pháp này, tuy nhiên chưa có tiêu chuẩn cụ thể để đánh giá độ tin cậy kết quả mà những sản phẩm này đưa

ra Vì vậy qua luận văn này tác giả mong muốn:

- Tìm hiểu phương pháp ước lượng dựa trên kinh nghiệm CBR (Case based reasoning)

- Xây dựng một công cụ ước lượng chi phí phát triển phần mềm sử dụng kiến thức đã tìm hiểu được

- Thực nghiệm và đánh giá phương pháp ước lượng chi phí phát triển phần mềm tại phòng Hệ thống - Công ty Honda Vietnam

1.2 Tính cấp thiết của đề tài

Trong quá trình phát triển dự án phần mềm thì quản lý chi phí là một công việc

có tầm quan trọng vô cùng lớn, bao gồm những quy trình đảm bảo cho dự án được hoàn tất trong sự cho phép của ngân sách: lập kế hoạch cho nguồn tài nguyên, ước lượng chi phí, dự toán chi phí, kiểm soát và điều chính chi phí Nếu công việc này không được làm tốt sẽ dẫn tới sự thất bại của dự án và theo số liệu thống kê tại các doanh nghiệp Mỹ do CHAOS thực hiện thì chi phí trung bình vượt quá dự toán ban đầu theo nghiên cứu từ năm 1995 là 189% và giảm xuống còn 145% trong năm 2001 Hậu quả của việc huỷ các dự án Công nghệ thông tin ở Mĩ đã làm tốn trên 81 tỉ đô la (số liệu thống kê năm 1995 do CHAOS thực hiện)[5] Vì vậy, việc ước lượng chính xác chi phí cần thiết để xây dựng các phần mềm là một vấn đề đang được quan tâm hiện nay

Xuất phát từ nhu cầu trên, tính từ năm 1960 cho đến nay đã có nhiều nhà khoa học đã tiến hành những công trình nghiên cứu nhằm tìm ra phương pháp luận chính xác nhất để ước lượng chi phí phát triển phần mềm như: mô hình ước lượng bằng tham

số của Frank Freiman (1970)[7], phương pháp ước tính dựa trên các thông số COCOMO (1977) và COCOMO II (1990) của Barry W Boehm[7], phương pháp ước

tính bằng điểm chức năng của Capres Jones (1980)[7] Tuy nhiên, những phương pháp này còn tồn tại nhiều hạn chế như yêu cầu phải có đủ số thông tin đầu vào để tính toán chính xác, dựa trên một mô hình tính toán được xác định rõ nên khó áp dụng được ở những giai đoạn đầu của quá trình phát triển dự án Để khắc phục những khó khăn đó, Roger Schank và các đồng nghiệp tại đại học Yale đề xuất ước lượng chi phí bằng phương pháp lập luận dựa trên kinh nghiệm CBR (Case base reasoning) năm 1977[4]

Ưu điểm nổi trội của phương pháp này là mô phỏng quá trình lập luận của con người nên dễ hiểu và có thể làm công cụ giải trình hiệu quả cho các thành viên tham gia phát triển dự án phần mềm Ngoài ra, phương pháp cho phép thực hiện ước lượng với tập nhỏ dữ liệu ban đầu, dữ liệu trong tập kinh nghiệm sẽ được cập nhật ở những lần thực hiện ước lượng tiếp theo nên độ chính xác của kết quả ước lượng sẽ tỉ lệ thuận với số lượng dự án được lưu trữ trong cơ sở dữ liệu

1.3 Mục tiêu của đề tài

Mục tiêu của luận văn này nhằm tập trung nghiên cứu về phương pháp ước lượng dựa trên kinh nghiệm qua đó xây dựng một công cụ áp dụng kiến thức đã tìm hiểu được và đánh giá khả năng áp dụng sản phẩm tại phòng Hệ thống – Công ty Honda Vietnam

1.4 Đối tượng và phạm vi nghiên cứu

- Đối tượng: các dự án phần mềm được phát triển tại công ty Honda Vietnam

từ năm 2006 đến nay

- Phạm vi: bài toán ước lượng chi phí phát triển phần mềm tại phòng Hệ thống, công ty Honda Vietnam

1.5 Kết cấu của luận văn

Bố cục của luận văn chia thành 05 chương:

- Chương 1: Giới thiệu

Nội dung chương: Nêu tính cấp thiết của đề tài, mục tiêu và phạm vi nghiên

cứu của luận văn

- Chương 2: Quy trình ước lượng chi phí phát triển phần mềm

Nội dung chương: Mô tả chi tiết các bước của quy trình ước lượng chi phí

phát triển phần mềm và một số phương pháp ước lượng thường sử dụng

- Chương 3: Phương pháp lập luận dựa trên kinh nghiệm

Nội dung chương: Trình bày các bước thực hiện và đánh giá ưu nhược điểm

của phương pháp lập luận dựa trên kinh nghiệm

- Chương 4: Phân tích thiết kế hệ thống PC-PACK-CES

Nội dung chương: Trình bày chi tiết phân tích, thiết kế của hệ thống

PC-PACK-CES (ca sử dụng, biểu đồ tuần tự, thiết kế bảng dữ liệu)

- Chương 5: Đánh giá khả năng áp dụng PC-PACK-CES tại công ty Honda

Vietnam

Nội dung chương: Trình bày kết quả thử nghiệm và đánh giá khả năng áp

dụng hệ thống PC-PACK-CES tại công ty Honda

- Kết luận và hướng phát triển của đề tài

Nội dung chương: Trình bày những kết luận của tác giả sau khi nghiên cứu

và triển khai phần mềm áp dụng phương pháp lập luận dựa trên kinh nghiệm tại công ty Honda Ngoài ra, tác giả cũng đề xuất hướng nghiên cứu và cải tiến chương trình của tác giả trong thời gian tới



CHƯƠNG 2 – QUY TRÌNH ƯỚC LƯỢNG CHI PHÍ

PHÁT TRIỂN PHẦN MỀM

2.1 Tổng quan và mục đích ước lượng

Phần mềm là một sản phẩm đặc thù có quan hệ mật thiết với nguồn ngân sách đầu tư xây dựng hệ thống thông tin của bất kì tổ chức nào Với tính đa dạng của các đặc trưng phần mềm và sự xuất hiện ngày càng nhiều của các công nghệ mới đã dẫn đến sẽ ngày càng khó khăn hơn để ước lượng chính xác chi phí cần thiết để phát triển

dự án phần mềm

Quá trình ước lượng bao gồm việc xác định và thẩm định những yếu tố có liên quan đến quá trình xây dựng một sản phẩm phần mềm Đó có thể là những tiến trình phát triển dự án, nguồn nhân lực và tài nguyên cần để xây dựng và hoàn thiện dự án Đến thời điểm hiện tại, việc ước tính chính xác chi phí cần thiết để hoàn thành một dự

án vẫn là một vấn đề được nhiều nhà nghiên cứu trên thế giới quan tâm

Mục đích của việc ước lượng chi phí phát triển phần nhằm đáp ứng các yêu cầu sau:

- Là cơ sở để xem xét và đánh giá tính khả thi của dự án: bất kì tổ chức nào trước khi quyết định có thực hiện dự án hay không sẽ cần tới kết quả ước lượng chi phí

và nguồn tài nguyên cần để hoàn thành dự án Dựa trên kết quả ước lượng này các tổ chức sẽ xem xét và đánh giá khả năng của mình có thể thực hiện dự án hay không để

từ đó đưa ra quyết định cần thiết

- Là công cụ hỗ trợ quản lý dự án: người quản lý dự án sẽ chịu trách nhiệm lập

kế hoạch và điều hành việc thực thi dự án Nhờ có sự trợ giúp của các kết quả ước lượng dự án, công việc này sẽ đơn giản và hiệu quả hơn vì công việc quản lý có thể dựa trên lịch biểu và nguồn nhân lực đã được ước tính trước đó

- Các thành viên của đội thực hiện dự án sẽ kết hợp với nhau hiệu quả hơn nếu hiểu rõ vai trò của mình và toàn bộ các hoạt động trong dự án Điều này có thể đạt được nếu kết quả ước lượng được áp dụng để xây dựng bảng phân chia nhiệm vụ cho các thành viên trong nhóm phát triển phần mềm

Quá trình ước lượng chi phí có thể được thực hiện nhiều lần trong suốt vòng đời phát triển dự án Lý do là vì trong quá trình xây dựng hệ thống sẽ xuất hiện ngày càng nhiều thông tin hữu ích chưa có tại thời điểm thực hiện ước lượng trước đó và những thông tin này sẽ làm tăng độ chính xác, chi tiết của quá trình ước lượng

2.2 Chi tiết quy trình ước lượng

Nếu quá trình ước lượng chi phí được tích hợp với quá trình phát triển phần mềm thì có thể lập nên các kế hoạch dự án khả thi và đáng tin cậy, giúp thoả mãn các yêu cầu của hệ thống và các cam kết đã đề ra Ngoài ra, quá trình này còn hỗ trợ đắc lực cho hoạt động quản lý dưới hình thức cung cấp những thông tin kế hoạch chính xác và kịp thời

Cấu trúc của dự án được hình thành từ nhiều yếu tố khác nhau bao gồm đặc tả yêu cầu và kiến trúc của hệ thống, yêu cầu chất lượng, kế hoạch sử dụng nguồn nhân lực Tuy nhiên, yếu tố có vai trò quan trọng nhất và có vai trò quyết định tới sự thành công hoặc thất bại của dự án là việc ước lượng phạm vi, yếu tố thời gian và chi phí cần thiết để hoàn thành dự án Quá trình ước lượng có thể tác động tới nhiều khía cạnh của

dự án, ràng buộc các hoạt động có thể được thực hiện trong quá trình phát triển hoặc nâng cấp sản phẩm phần mềm và là cơ sở để lựa chọn những phương án đã lập kế hoạch

Từ những phân tích trên, chúng ta có thể định nghĩa ước lượng là quá trình đưa

ra nhận định về giá trị xấp xỉ, gần đúng của một số thông tin mà ta quan tâm Ước lượng có thể dựa trên miền tri thức hoặc giả định không đầy đủ hay hoàn chỉnh Đã có nhiều công trình nghiên cứu để chuẩn hoá quy trình ước lượng chi phí phát triển phần mềm, tuy nhiên cho đến nay vẫn chưa có một mô hình tiêu chuẩn được thừa nhận và

sử dụng rộng rãi Mỗi một tổ chức sẽ có một mô hình ước tính chi phí của riêng mình, nhưng nhìn chung những mô hình đó bao gồm những bước chính sau:

Hình 2 - 1 Quy trình ước lượng chi phí phát triển dự án phần mềm[5]

2.2.1 Xác định phạm vi và mục tiêu của dự án

Những yêu cầu ở thời điểm bắt đầu thực hiện dự án cần định nghĩa và lập tài liệu với nội dung thể hiện những mong muốn vào kết quả ước lượng Nếu tất cả các thành viên tham gia dự án có thể hiểu rõ phạm vi và mục tiêu của quá trình ước lượng thì sẽ hình thành đường mức cơ sở và có thể dựa vào đó để đánh giá tác động của những thay đổi của dự án trong tương lai Ngoài ra, công việc này còn giúp các thành viên của dự án có thể thấy được những hiểu lầm và làm sáng tỏ các giả định trái ngược nhau về những gì được mong đợi của các nhóm tham gia dự án

Bằng việc lập tài liệu đặc tả ứng dụng bao gồm các chi tiết mang tính kĩ thuật, các mối phụ thuộc bên ngoài dự án và các yêu cầu nghiệp vụ sẽ cung cấp thông tin đầu vào có giá trị để ước lượng nguồn tài nguyên cần thiết để hoàn thành dự án Trong đó, những đặc tính mang tính chất kĩ thuật nếu càng được mô tả chi tiết sẽ càng có giá trị Sau khi các yêu cầu đã được làm rõ thì lúc đó mới có thể xác định chi phí khả thi của

dự án

Quá trình ước lượng cần được cập nhật thường xuyên trong suốt vòng đời phát triển dự án Để đảm bảo tính toàn vẹn của dự án, khi có bất kì sự thay đổi nào của dữ liệu hoặc sự xuất hiện của những thông tin hữu ích thì cần phải lưu trữ lại và sẽ là một yếu tố tham gia quá trình ước lượng

2.2.2 Xác định phạm vi kĩ thuật và các giả định

Chúng ta cần xác định rõ các chức năng có trong quá trình ước lượng để thiếp lập đường mức kĩ thuật hợp lý Trong trường hợp không xác định được các yếu tố chức năng của ước lượng thì các quy luật nền tảng và các giả định cần nêu rõ những gì

có và không có trong quá trình ước lượng Những vấn đề liên quan đến sử dụng lại và những giả định khác cũng cần lập tài liệu để theo dõi

Mặc dù các quy luật nền tảng và các giả định là cơ sở của quá trình ước lượng nhưng chúng ta phải nhận thức rằng các quy luật và giả định này chưa hoàn thiện và còn chứa đựng nhiều yếu tố không chắc chắn ở giai đoạn đầu của ước lượng Do đó, cùng với việc thường xuyên thực hiện ước lượng lại cũng cần phải tiến hành xem xét

và định nghĩa lại các giả định trong dự án

2.2.3 Thu thập dữ liệu

Theo định nghĩa thì bất kì quá trình ước lượng nào cũng bao gồm những yếu tố không chắc chắn nên chúng ta thường biểu diễn những yếu tố đầu vào dưới dạng khoảng giá trị thay vì những dữ liệu cụ thể Điều này sẽ giúp chúng ta có thể thực hiện quá trình ước lượng ngay cả khi chưa xác định đầy đủ phạm vi của hệ thống đang lập

dự toán

Tuy nhiên, để đạt được kết quả ước lượng nhất quán đòi hỏi chúng ta phải xác định được những thông tin cốt lõi Dữ liệu có liên quan đến dự án không chỉ đến từ một nguồn duy nhất và cũng không xuất hiện tại cùng một thời điểm nên nếu chúng ta

sử dụng một mẫu biểu tập hợp dữ liệu hoàn chỉnh sẽ có tác dụng tích cực cho công

việc thu thập dữ liệu vì khi tìm ra thông tin mới, có giá trị thì đã có sẵn một hình thức

tổ chức và quản lý dữ liệu của toàn bộ dự án

2.2.4 Xác định kích cỡ phần mềm

Trong điều kiện tối ưu các tổ chức nên thực hiện toàn bộ những bước thuộc quy trình ước lượng chi phí phát triển phần mềm đã mô tả ở hình 2-2 để có thể đạt được kết quả ước lượng chính xác và đáng tin cậy Tuy nhiên, nếu yếu tố thời gian không cho phép thì nên tập trung vào bước xác định kích cỡ phần mềm Bằng việc sử dụng những công cụ tự động ước tính chi phí và lịch biểu thời gian có thể cung cấp dữ liệu cho những người chịu trách nhiệm phân tích dự án

Kích cỡ phần mềm là yếu tố có ảnh hưởng rất lớn tới việc xác định chi phí và lịch biểu thời gian phát triển dự án Phạm vi của dự án phần mềm được định nghĩa bởi việc xác định không chỉ những thông tin liên quan đến dự án được phát triển mới mà còn bao gồm dữ liệu của những hệ thống đã có sẽ được tích hợp vào hệ thống mới Ngoài ra, để ước lượng kích cỡ phần mềm chúng ta cần xác định những yếu tố như số dòng lệnh (SLOC – Source lines of code), số điểm chức năng hoặc bất kì cách tính đơn vị chương trình nào đang được sử dụng để thống kê Thông thường, để có thể đưa

ra thông tin tổng thể kích cỡ phần mềm, kết quả ước lượng kích cỡ được biểu diễn dưới dạng phạm vi chặn trên và chặn dưới Danh sách bên dưới là một số hình thức ước lượng kích cỡ phần mềm thường được các tổ chức sử dụng:

tin tập hợp lại của các dự án đã thực hiện trước đó và những giả định có thể diễn ra với hệ thống mới kết hợp với kinh nghiệm của các chuyên gia thuộc lĩnh vực

thể dựa trên một số đặc trưng nhất định Kết quả so sánh ở dạng giá trị xấp

xỉ nên có thể hiệu chỉnh các đặc trưng so sánh với thực thể tương đồng tìm được để tăng độ chính xác của phương pháp

cụ tự động hoặc các thuật toán được xác định trước như hình thức đếm số lượng các hệ thống con hoặc các lớp con và chuyển đổi thành các điểm chức năng

dưới dạng khoảng giới hạn cận trên và cận dưới

2.2.5 Chuẩn bị đường mức ước lượng

Kết quả của quá trình ước lượng có vai trò quyết định tới độ chính xác của ngân sách và lịch biểu thời gian phát triển dự án Do đó, để đảm bảo tính chính xác và hiệu quả của kết quả ước lượng chúng ta cần xem xét một số yếu tố sau:

- Chỉ các chuyên gia được đào tạo, có kinh nghiệm và tay nghề được giao nhiệm vụ xác định kích cỡ phần mềm và tham gia vào quá trình ước lượng

- Những chuyên gia này cần được trang bị công cụ và công nghệ phù hợp

- Người quản lý dự án cần xây dựng và chịu trách nhiệm hiệu chỉnh quy trình ước lượng thống nhất trong toàn bộ vòng đời phát triển dự án

Hiện nay, có nhiều phương pháp khác nhau để chuẩn bị đường mức ước lượng

có thể là phương pháp tiếp cận từ dưới lên (Bottom-Up), phương pháp đánh giá của chuyên gia và mô hình chi phí…

bao gồm việc phân rã hệ thống tới mức thấp nhất dạng chức năng hay nhiệm

vụ ở nút lá Chi phí để thực hiện các thực thể ở trên khác nút lá sẽ bằng tổng chi phí thực hiện của các phần tử nút lá thuộc thực thể này Quá trình này sẽ được lặp lại đến khi gặp thực thể ở mức cao nhất và giá trị tổng chi phí tính được sẽ là chi phí để thực hiện dự án Phương pháp này khá hiệu quả để ước tính chi phí cho các hệ thống cỡ nhỏ vì những hệ thống này sẽ thuận lợi cho việc phân rã nhỏ thành các module chức năng

yêu cầu thông tin đầu vào khác nhau Tuy nhiên, đa số các mô hình đều yêu cầu người sử dụng cung cấp những đặc trưng của dự án dưới dạng các tham

số đầu vào để thực hiện tính toán Những thông tin này có thể là thông tin

mô tả, các đặc trưng của dự án, kinh nghiệm và trình độ đào tạo của đội ngũ phát triển dự án, phương thức và công cụ được sử dụng để hoàn thiện dự án Các mô hình chi phí dạng thông số cung cấp các phương tiện để áp dụng một phương thức thống nhất cho mục đích chuyển đổi các tình huống không

rõ ràng thành các phân tích thống kê toán học chính xác Do đó, nhiều nhà nghiên cứu đã thừa nhận những mô hình chi phí phần mềm có tính bao quát hơn so với các kĩ thuật ước lượng khác và giúp giảm thiểu sai số khi thực hiện ước lượng chi phí phần mềm Ngoài ra, mô hình còn được sử dụng như một phương tiện để quản lý thông tin có tính chất mô tả dự án, hỗ trợ quá trình phân tích và xác định những rủi ro có thể xảy ra

được sử dụng để ước lượng các thành phần khác nhau của dự án phần mềm được bắt đầu từ các đặc tả yêu cầu và quy mô của dự án Những thông tin này sẽ được dùng để xác định những hạng mục công việc cần thực hiện để

từ đó tính toán ra toàn bộ nỗ lực cần thiết để hoàn thành dự án Kết quả của quá trình sẽ cung cấp cho chúng ta bảng phân rã công việc thể hiện cách thức tổ chức và thực hiện công việc cần thiết Tài liệu này sẽ được sử dụng

để lập kế hoạch cho dự án và cung cấp thông tin nhiệm vụ cụ thể cần được triển khai Tuy nhiên, chúng ta cần lưu ý là tài liệu này không thể hiện dạng danh mục những việc cần phải làm mà nội dung của nó thể hiện kiến trúc các nhiệm vụ cần thực hiện Khi toàn bộ những nhiệm vụ này được thực hiện thì kết quả tương ứng với việc thoả mãn tất cả những thoả thuận ban đầu được đưa ra

2.2.6 Thẩm định và phân tích các rủi ro

Chúng ta phải thừa nhận rằng luôn luôn tiềm ẩn những rủi ro không thể lường trước được trong quá trình thực hiện bất kì dự án nào Tuy nhiên, vấn đề chúng ta cần quan tâm là việc phân định rõ thế nào là rủi ro và rủi ro là gì Với những vấn đề dễ dàng được nhận diện và xử lý thì không cần đánh giá đó là mối đe doạ cho dự án Rủi

ro là những vấn đề khiến chúng ta phải dành thời gian, chi phí để xử lý hoặc trầm trọng hơn là mất sự kiểm soát những gì đang diễn ra

Thông thường, sự kiện rủi ro có xẩy ra hay không được biểu diễn dưới dạng xác suất sự kiện Giá trị này được thể hiện bằng hai giá trị logic sau: 0 – không thể xảy ra

và 1 – chắc chắn sẽ xảy ra Khi xác suất của rủi ro có giá trị bằng 1 thì rủi ro trở thành vấn đề cần giải quyết vì nó chắc chắn sẽ xảy ra và sẽ ảnh hưởng tới quá trình phát triển

dự án Với mỗi rủi ro chúng ta cần xác định những việc cần làm để giảm thiểu hoặc tránh được ảnh hưởng của chúng Quản lý rủi ro sẽ bao gồm những hành động cần thực hiện để hạn chế hoặc loại bỏ rủi ro có thể xảy ra

Quá trình quản lý rủi ro giúp chúng ta có thể xác định rõ những mối đe doạ có thể xuất phát từ bên trong hoặc bắt nguồn từ các yếu tố ngoại cảnh tới quá trình thực hiện dự án Với những vấn đề có liên quan đến việc xác định kích cỡ và ước lượng phần mềm sẽ có những ảnh hưởng tiêu cực Nhiệm vụ của người quản lý dự án là đánh giá triệt để các mối đe doạ tiềm ẩn để từ đó có thể xây dựng đối sách cần thiết nhằm giảm thiểu hoặc hạn chế tác động khi vấn đề nảy sinh

2.2.7 Kiểm định kết quả ƣớc lƣợng

Nếu xét đến vị trí trong quy trình mô tả ở hình 2-1 thì đến bước này kết quả ước lượng được đảm bảo là chính xác và đáng tin cậy Tuy nhiên, chúng ta vẫn cần thẩm định lại phương pháp đã sử dụng và kết quả ước lượng nhằm đảm bảo tính thống nhất của quá trình ước lượng Việc làm này sẽ giúp chúng ta tin tưởng hơn vào độ chính xác của dữ liệu ước lượng, khẳng định tính hiệu quả của phương pháp và quan trọng hơn là chúng ta đã đi đúng lộ trình

Có nhiều phương pháp khác nhau thực hiện thẩm định quá trình ước lượng Đối tượng cần đánh giá sẽ là quy trình xây dựng kế hoạch ước lượng và bản thân quá trình ước lượng Thông thường, để đảm bảo tính khách quan khi thẩm định công việc này sẽ

do một thành viên không tham gia quá trình ước lượng chi phí dự án thực hiện Nhằm tăng tính chính xác cho công việc thẩm định, cần sử dụng nhiều phương pháp và công

cụ khác nhau để thực hiện các bước so sánh kết quả phân tích

Chúng ta cần dựa vào những giả định được sử dụng trong quá trình ước lượng

để thẩm định phương pháp ước tính Ngoài ra, chúng ta cũng cần đảm bảo là các quy tắc nghiệp vụ được sử dụng thống nhất trong toàn bộ quá trình ước lượng Nếu chúng

ta ước tính chi phí thấp và không lường hết các rủi ro có liên quan đến những yêu cầu đặc biệt sẽ dẫn tới việc đánh giá thấp hoặc coi nhẹ những yếu tố này

Những giả định sai lầm, dữ liệu không đáng tin cậy và độ lệch ước lượng sẽ được phát hiện thông qua quy trình thẩm định hợp lý Điều này sẽ giúp chúng ta hiểu

rõ hơn những rủi ro gắn liền với bản kế hoạch thực hiện ước lượng chi phí phần mềm Thông qua việc tách những vấn đề từ nguồn gốc phát sinh ra chúng, chúng ta có thể xây dựng kế hoạch để ngăn chặn những rủi ro có liên quan đến những vấn đề đó, đồng thời chúng ta có thể xác định rõ những nhiệm vụ cần thực hiện để hoàn thành dự án với nguồn lực cho trước

2.2.8 Xây dựng kế hoạch thực thi dự án

Quá trình xây dựng kế hoạch thực thi dự án bao gồm việc sử dụng kết quả ước tính và việc phân bổ chi phí, lịch biểu thời gian thành các chức năng và cấu trúc phân chia công việc thành từng nhiệm vụ

Sự thành bại của một dự án chịu ảnh hưởng rất lớn bởi vai trò của người quản

lý dự án Người quản lý dự án cần phải dám đối mặt và kịp thời thiết lập đối sách cho những thách thức của hiện tại để có thể loại bỏ những rủi ro có thể xảy ra ở tương lai Một người quản lý dự án được đánh giá là thực hiện tốt nhiệm vụ của mình nếu sở hữu kinh nghiệm phong phú về lĩnh vực và kĩ thuật phát triển phần mềm, là người có khả năng lãnh đạo các thành viên trong nhóm, có khả năng phân tích những vấn đề tiềm ẩn

và có thể xây dựng kế hoạch hoạt động của dự án nhằm đạt tới mục tiêu hoàn thành dự

án đúng tiến độ, với nguồn chi phí cho trước

2.2.9 Xây dựng tài liệu cho quá trình ƣớc lƣợng

Ở thời điểm kết thúc quá trình phát triển dự án phần mềm, chúng ta nên lập tài liệu nhằm lưu lại những thông tin quan trọng tạo nên quá trình ước lượng cũng như những bài học rút ra được từ việc thực hiện ước lượng chi phí phần mềm Việc làm này sẽ là căn cứ chứng minh rằng những hạng mục công việc chúng ta thực hiện là hợp lệ, kết quả của quá trình ước lượng là đáng tin cậy Nội dung của tài liệu này là những quyết định quan trọng được đưa ra trong quá trình xây dựng quy trình ước lượng, kết quả và những tác động của những hoạt động đã được thực hiện Tài liệu này cũng nên đề cập tới những thông tin còn thiếu, những rủi ro, những vấn đề phức tạp đã nảy sinh trong quá trình ước lượng Cuối cùng, trong tài liệu này cũng không thể thiếu thông tin mô tả quá trình kết hợp của các thành viên trong đội ước lượng, quá trình trao đổi với khách hàng, sự đánh đổi mà chúng ta đã thực hiện để làm rõ các vấn đề phát sinh trong quá trình ước tính chi phí dự án

Thời điểm thích hợp nhất để đánh giá, tổng kết để rút ra những bài học kinh nghiệm từ dự án là ngay khi quá trình phát triển dự án kết thúc vì khi đó các thành viên tham gia vẫn còn có thể nhớ chi tiết các vấn đề đã diễn ra Quá trình họp đánh giá

có thể chỉ là tiến hành ở mức nhỏ chỉ có ít nhất hai thành viên phát triển dự án tham gia cho đến mức cao hơn là những buổi họp có sự tham gia của các thành viên tham gia trả lời phiếu điều tra, khảo sát nhằm tiến tới thống nhất những vấn đề chính yếu có ảnh hưởng tới quy trình ước lượng chi phí phát triển dự án phần mềm Dự án phát triển phần mềm được xem như là cơ hội tốt để tổ chức cải tiến quy trình ước lượng chi phí

và là cơ sở để chuẩn bị tốt hơn nữa cho những dự án tiếp theo

2.2.10 Đánh giá dự án thông qua quá trình phát triển

Những thông tin liên quan đến quá trình phát triển dự án cần được tập hợp lại làm cơ sở để so sánh với kế hoạch ban đầu Chúng ta cần xem xét lại toàn bộ quy trình ước lượng trong trường hợp chi phí thực tế cần để hoàn thành dự án khác xa so với kế hoạch đã đề ra Thông thường, chúng ta cần thu thập lại dữ liệu của những đặc trưng sau của dự án:

- Yếu tố chi phí ở khía cạnh nỗ lực của nhân viên, nỗ lực ở từng giai đoạn và

nỗ lực tổng thể của dự án

- Những thiếu sót được tìm ra và đối sách và chi phí để khắc phục chúng

- Đặc trưng của quy trình phát triển dự án như ngôn ngữ lập trình, mô hình phát triển và công nghệ

- Những thay đổi về đặc tả yêu cầu, lịch biểu phát triển

- Kiến trúc phần mềm ở khía cạnh quy mô và độ phức tạp

Công việc ước tính chi phí phần mềm, lập kế hoạch thực hiện và xác định rủi ro

là những công việc khó khăn nhưng có ảnh hưởng rất lớn tới sự thành công của dự án Kết quả công việc sẽ hiệu quả nếu chúng ta xây dựng tiêu chuẩn hoá cho quy trình ước lượng và được kiểm nghiệm ở nhiều dự án khác nhau Quy trình ước lượng mô tả ở hình 2-2 sẽ thay đổi theo nhu cầu thực tế của từng tổ chức, tuỳ theo quan điểm đánh giá những hạng mục công việc được cho là quan trọng, cần tập trung thời gian và nhân lực để thực hiện

2.3 Một số phương pháp ước lượng chi phí phát triển phần mềm

Hiện nay, trên thế giới có nhiều phương pháp ước lượng chi phí khác nhau được

sử dụng nhưng nhìn chung các phương pháp này thuộc một trong ba nhóm phương pháp sau:

học và các tham số đầu vào để tính toán nỗ lực và thời gian cần thiết để hoàn thành dự án Những mô hình toán học phổ biến gồm có mô hình COCOMO (Constructive COst MOdel) (Boehm 1981) và kĩ thuật phân tích điểm chức năng (Albrecht & Gaffney 1983) [3]

phí dựa trên kinh nghiệm và kĩ năng của một hoặc nhiều chuyên gia phần mềm

dự án cần ước tính với những dự án đã thực hiện và hoàn thành trước đó để tìm ra các dự án tương tự làm cơ sở để ước lượng chi phí cần thiết hoàn thành dự án mới

2.3.1 Mô hình COCOMO

COCOMO là mô hình do Barry Boehm thiết kế nhằm ước tính công sức, thời gian và số người-tháng (man-month) cần thiết để phát triển dự án dựa trên kích cỡ

phần mềm Mô hình này rất phù hợp để ước tính cho các phần mềm kích cỡ lớn Mô hình này dựa trên kết quả khảo sát 60 dự án tại các công ty TRW, Northrop Grumman

từ năm 2002[7] Kết quả nghiên cứu đã được xây dựng thành chương trình viết bằng ngôn ngữ PL/I và bao gồm hơn 100,000 dòng lệnh

Mô hình COCOMO gồm có 3 dạng sau:

lượng dòng lệnh tạo nên phần mềm

 COCOMO trung gian: chi phí được tính theo độ lớn phần mềm theo số

dòng lệnh và cộng thêm đánh giá sản phẩm, phần cứng, nguồn nhân lực và các thuộc tính của dự án

gian nhưng có bổ sung thêm đánh giá của chi phí ảnh hưởng trong mỗi giai đoạn của quy trình công nghệ phần mềm

2.3.1.1 COCOMO cơ bản

Mô hình có thể áp dụng cho ba lớp dự án phần mềm

đội ngũ tham gia phát triển nhỏ, có kinh nghiệm phát triển ứng dụng cùng loại và làm việc trên môi trường với những yêu cầu không quá khắt khe

về nhiều lĩnh vực khác nhau và làm viêc trên môi trường với những yêu cầu không quá khắt khe

mềm và có cả những ràng buộc về điều kiện vận hành

Công thức tính toán của mô hình COCOMO cơ bản có dạng:

D E P E c D KLOC a

b b

Trong đó:

E - ước tính người/tháng

D - thời gian triển khai, tính theo tháng

KLOC – ước tính số dòng lệnh (đơn vị = 1000 dòng lệnh) của sản phẩm

dự án phần mềm

P – số lượng người cần cho dự án

Hệ số ab, bb, cb, db được cho bởi bảng sau đây:

Mô hình COCOMO cơ bản rất phù hợp cho ước tính thô vì dễ dàng và thực hiện nhanh Tuy nhiên, kết quả tính toán có độ chính xác không cao vì thiếu một số nhân tố, chưa kể đến sự khác nhau trong ràng buộc về phần cứng, kinh nghiệm và khả năng chuyên nghiệp của con người Ngoài ra, việc sử dụng các công cụ hiện đại và các đặc trưng khác cũng sẽ ảnh hưởng tới độ chính xác của kết quả ước lượng

2.3.1.2 COCOMO trung gian

Mô hình COCOMO trung gian là sự cải tiến của mô hình COCOMO cơ bản và được dùng để ước tính thời gian lập trình trong triển khai sản phẩm phần mềm Sự cải tiến này nếu xem xét trên một tập hợp “Chi phí của các đặc trưng các bộ phận điều phối” thì được chia thành 4 nhóm sau:

- Tính không ổn định của môi trường máy ảo

- Yêu cầu về thời gian chuyển hướng (turnabout time)

 Đặc trưng về chuyên gia

- Khả năng phân tích vấn đề

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

- Kinh nghiệm phát triển ứng dụng

- Kinh nghiệm về máy ảo

- Kinh nghiệm sử dụng ngôn ngữ lập trình

 Đặc trưng về dự án

- Sử dụng các công cụ phần mềm

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

- Yêu cầu về lịch biểu triển khai dự án

Mỗi đặc trưng trên sẽ được đánh giá và cho điểm theo thang điểm có 6 mức từ rất chậm đến quá cao Dựa trên thang điểm, hệ số nỗ lực sẽ được tính theo bảng xếp hạng sau:

Rất chậm

Đặc trưng của phần mềm

Yêu cầu về độ tin cậy của phần

mềm

0.75 0.88 1.00 1.15 1.40

Yêu cầu về thời gian chuyển hướng 0.87 1.00 1.07 1.15

Đặc trưng về chuyên gia

Khả năng phân tích vấn đề 1.46 1.19 1.00 0.86 0.71

Khả năng kĩ nghệ phần mềm 1.29 1.13 1.00 0.91 0.82

Kinh nghiệm phát triển ứng dụng 1.42 1.17 1.00 0.86 0.70

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

Kinh nghiệm sử dụng ngôn ngữ lập

Bảng 2 - 2 Thang điểm đánh giá các đặc trưng của dự án

Công thức tính toán của mô hình COCOMO trung gian có dạng

xEAF KLOC

a

Trong đó:

E – ước tính người/tháng

KLOC – ước tính số dòng lệnh (đơn vị = 1000 dòng lệnh) của sản phẩm

dự án phần mềm

EAF (Effort Adjustment Factor) – được tính theo bảng trên

Hệ số ai và bi được cho bởi bảng sau:

Dự án phần mềm a i b i

Bảng 2 - 3 Bảng hệ số tính bằng phương pháp COCOMO trung gian

2.3.2 Mô hình điểm chức năng (Function Point)

Mô hình điểm chức năng là kết quả nghiên cứu của A.Albrecht với mục đích để ước tính số dòng lệnh tạo nên phần mềm và dựa trên cơ sở đó để ước tính kích cỡ của phần mềm Điểm chức năng tính kích cỡ phần mềm bằng phương pháp xác định số lượng các chức năng mà hệ thống cung cấp cho người sử dụng dựa trên các yếu tố thiết kế logic và đặc tả chức năng

Số lượng dòng lệnh (LOC – Lines of Code) được tính theo công thức sau:

LOC = FPs của hệ thống * LOC/FP của ngôn ngữ

Bảng 2 - 4 Bảng quy đổi số dòng lệnh trong một chức năng của các ngôn ngữ lập trình

Mô hình điểm chức năng gồm những bước sau:

Bước 1: tính điểm chức năng của 5 loại tiêu biểu

- Số kiểu người dùng nhập dữ liệu vào (kí hiệu là I – External Input)

- Số kiểu người dùng xuất dữ liệu ra (kí hiệu là O – External Output)

- Số kiểu người dùng yêu cầu (kí hiệu là E – External Inquiry)

- Số giao diện ngoại vi (kí hiệu là F – External Interface Files)

- Số file liên quan (kí hiệu là L – Internal Logical Files)

Bước 2: với mỗi kiểu chức năng, thực hiện ước lượng độ phức tạp của nó và nhân với

hệ số đặc trưng và cộng lại

- Độ phức tạp có 3 mức: đơn giản, trung bình và phức tạp

- Xác định và tính trọng số điều chỉnh cho mỗi loại (Fi) dựa trên kinh nghiệm tổ chức

- Tính tổng của toàn bộ số điều chỉnh điểm chức năng (F i)

Bước 3: ước lượng hệ số điều chỉnh (Fi, i = 1 14) bằng cách trả lời các câu hỏi:

- Hệ thống có yêu cầu lưu trữ và phục hồi với độ tin cậy cao không?

- Có cần những dữ liệu giao tiếp không?

- Có các chức năng phân tán không?

- Việc thực hiện có đạt yêu cầu không?

- Hệ thống có vận hành trên một môi trường đã tồn tại không?

- Hệ thống có yêu cầu nhập dữ liệu trực tuyến không?

- Có cần xây dựng nhiều màn hình và chức năng để nhập dữ liệu trực tuyến không?

- Các file dữ liệu có được cập nhật trực tuyến không?

- Việc nhập, xuất và truy vấn dữ liệu có phức tạp không?

- Logic nghiệp vụ bên trong có phức tạp không?

- Có dùng lại được mã lệnh thiết kế chương trình không?

- Sự chuyển đổi và cài đặt có bao gồm trong thiết kế hay không?

- Hệ thống có cho phép tạo nhiều bộ cài đặt cho các tổ chức khác nhau không?

- Thiết kế của hệ thống có dễ sử dụng, dễ sửa đổi không?

Sau đó, mỗi câu trả lời cho những câu hỏi trên sẽ được cho điểm từ 0 (N/A) đến 5 (Absolutely Essential) Cuối cùng, thực hiện tính tổng giá trị điều chỉnh F i

Bước 4: tính điểm chức năng theo công thức sau

FPs = Tổng điểm * (0.65 + 0.01*F i)

Trong đó: 0.65 và 0.01 là hệ số theo kinh nghiệm

2.3.3 Phương pháp chuyên gia

Dự báo có vai trò rất quan trọng trong quá trình ra quyết định quản lý với bất kì lĩnh vực nào, ngành nào trong nền kinh tế quốc dân trong đó có ngành Công nghệ thông tin Với những bài toán không thể thu thập được các số liệu lịch sử, việc sử dụng các phương pháp dự báo dựa trên các công cụ chính xác của toán học không giải quyết được và khi đó phương pháp chuyên gia được các nhà dự báo tập trung nghiên cứu và coi như con đường đúng đắn để có thể đi đến mục tiêu Phương pháp chuyên gia là

phương pháp dự báo sẽ đưa ra những dự báo khách quan về tương lai phát triển của lĩnh vực hẹp của khoa học kĩ thuật hoặc sản xuất dựa trên việc xử lý các đánh giá của chuyên gia Ưu điểm của phương pháp là thực hiện nhanh, chi phí thấp Tuy nhiên, nhược điểm của phương pháp là độ chính xác phụ thuộc vào trình độ chuyên môn của các chuyên gia dự đoán và bài toán cụ thể

Chi tiết các bước thực hiện như sau:

Bước 1: Lựa chọn và thành lập nhóm chuyên gia dự báo và nhóm các nhà phân tích

Các chuyên gia công nghệ phần mềm nghiên cứu tài liệu và đưa ra những đánh giá dự báo Đây là các chuyên gia có trình độ hiểu biết chung tương đối cao ngoài lĩnh vực hẹp của mình, có kiến thức chuyên sâu về lĩnh vực dự báo, có lập trường khoa học

và có khả năng tiên đoán thể hiện ở sự phản ánh nhất quán xu thế phát triển của đối tượng dự báo và có định hướng, suy nghĩ về tương lai trong lĩnh vực mình quan tâm

Nhóm chuyên gia phân tích còn gọi là nhóm các nhà quản lý bao gồm những nguời có cương vị lãnh dạo, những nguời có quyền quyết định chọn phương pháp dự báo Ðây cũng là các chuyên gia có trình độ chuyên môn cao về vấn dề cần dự báo, có kiến thức về dự báo và chuyên gia phân tích còn phải có lòng kiên nhẫn, tính lịch thiệp

do quá trình tiếp xúc và hợp tác với các chuyên gia là một quá trình phức tạp

Bước 2: Trưng cầu ý kiến của các chuyên gia

Trưng cầu ý kiến của các chuyên gia là một giai đoạn của phương pháp chuyên gia Tùy theo đặc điểm thu nhận và xử lý thông tin mà chọn những phương pháp trưng cầu cơ bản như: trưng cầu ý kiến theo nhóm và cá nhân, trung cầu vắng mặt và có mặt

và trưng cầu trực tiếp hay gián tiếp Nếu ý kiến đánh giá của các chuyên gia có sự khác biệt đáng kể thì cần tiến hành thảo luận lại và đưa ra đánh giá mới

Bước 3: Xử lý ý kiến chuyên gia

Sau khi thu thập ý kiến của các chuyên gia, cần phải tiến hành một loạt các biện pháp xử lý các ý kiến này Ðây là bước quan trọng để đưa ra kết quả dự báo Nói chung có hai dạng vấn dề cần giải quyết khi xử lý ý kiến chuyên gia:

- Ðánh giá thời gian hoàn thành sự kiện

- Ðánh giá tầm quan trọng tương đối giữa các sự kiện, chẳng hạn như đánh giá vai trò của các yếu tố chi phí đối với quy trình ước lượng

Nếu đánh giá mới không sai khác nhiều với kết quả trước đó thì quá trình này

sẽ dừng lại Ngược lại, quay lại bước 2

2.4 Tóm tắt chương

Phần mềm máy tính đóng vai trò vô cùng quan trọng đối với hệ thống máy tình

và ngày càng trở nên đắt đỏ so với phần cứng Chúng ta cũng đã thấy các phần mềm máy tính là rất đa dạng và phong phú, chúng thuộc rất nhiều lĩnh vực khác nhau và hầu như thâm nhập vào mọi hoạt động của đời sống xã hội loài người Tuy đã đạt được những thành tựu đáng kể nhưng rất nhiều dự án phần mềm lớn vẫn bị chậm và vượt quá dự toán ngân sách ban đầu Do nhu cầu của thực tiễn, ngành công nghiệp phần mềm đang đứng trước thách thức vô cùng to lớn, đó là làm sao xây dựng được các

phần mềm tốt theo một lịch trình và kinh phí định trước, đáp ứng được yêu cầu thực tiễn sự tiến hóa của phần cứng và những đòi hỏi đa dạng của người dùng Để làm được điều này, mỗi doanh nghiệp phần mềm cần xây dựng cho mình một quy trình tiêu chuẩn nhằm thực hiện ước tính chi phí phát triển phần mềm và cần tuyệt đối tuân thủ trong suốt quá trình thực hiện dự án Các doanh nghiệp có thể lựa chọn cho mình phương pháp hỗ trợ cho công việc ước lượng tùy theo năng lực và kinh nghiệm của mình Những dữ liệu có liên quan đến quy trình ước lượng cũng cần được lưu giữ lại làm tài liệu tham khảo hữu ích cho những dự án tiếp theo



CHƯƠNG 3 – PHƯƠNG PHÁP LẬP LUẬN

DỰA TRÊN KINH NGHIỆM

3.1 Giới thiệu chung

Lập luận dựa trên kinh nghiệm (CBR-Case based reasoning) có nguồn gốc từ những công trình nghiên cứu về khoa học nhận thức Phương pháp này được mọi người biết đến qua những kết quả nghiên cứu của Roger Schank và đồng nghiệp thực hiện tại trường đại học Yale[7] Trong khoảng thời gian từ năm 1977-1993, CBR được mọi người biết tới như một mô hình ở mức cao của quy trình xử lý nhận thức Phương pháp tập trung vào những vấn đề như con người học các kĩ năng mới như thế nào và cách thức con người lập luận cho vấn đề mới dựa trên những kinh nghiệm họ đã từng trải qua Mục tiêu của những nghiên cứu dựa trên nhận thức là xây dựng các hệ thống

hỗ trợ quyết định để giúp con người có thể học những vấn đề khác nhau trong cuộc sống của mình Trong những năm tiếp theo đã ghi nhận sự ra đời của rất nhiều hệ thống mô phỏng lý thuyết CBR như hệ thống Cyrus, Mediator, Persuader, Chef, Julia

Sự kiện 3 cuộc hội thảo do Viện nghiên cứu chiến lược thuộc Bộ quốc phòng Mĩ tổ chức trong những năm 1988, 1989 và 1991 đã chính thức đánh dấu sự ra đời phương pháp CBR Đến năm 1993, một cuộc hội thảo quy mô lớn được tổ chức tại thành phố Kaiserslautern với sự tham gia của hơn 120 đoàn và hơn 80 phát biểu chuyên đề đã được thực hiện thành công tốt đẹp [7] Cho đến thời điểm hiện tại, những buổi hội thảo

về CBR đã được tiến hành định kì ở nhiều quốc gia khác nhau trên thế giới đã chứng minh mối quan tâm của các nhà khoa học dành cho CBR ngày càng tăng

Hiện nay, có nhiều định nghĩa khác nhau về phương pháp nhưng chúng ta có

thể hiểu “Lập luận dựa trên kinh nghiệm là phương pháp giải quyết vấn đề dựa trên

việc áp dụng lời giải của các bài toán cũ vào bài toán mới có dữ kiện tương tự Trong quá trình áp dụng, lời giải cũ có thể được hiệu chỉnh để phù hợp với bài toán mới”

[10] Lập luận dựa trên kinh nghiệm đang thu hút mối quan tâm ngày càng lớn do có nhiều điểm tương đồng với cách giải quyết vấn đề của con người Phương pháp này tỏ

ra ưu việt so với các phương pháp lập luận truyền thống dựa trên luật (rule-based reasoning) trong những bài toán có miền tri thức rộng hay các bài toán không có những quy luật tổng quát hoặc có quá nhiều luật

3.2 Chi tiết phương pháp lập luận dựa trên kinh nghiệm

Quy trình lập luận dựa trên kinh nghiệm gồm 4 bước cơ bản sau:

Hình 3 - 1 Mô hình lập luận dựa trên kinh nghiệm [5]

 Tìm kiếm dữ liệu tương tự (RETRIEVE): là công việc tìm kiếm trong bộ nhớ

lời giải của những bài toán cũ tương tự với bài toán đích Có một số hình thức tính độ tương tự giữa bài toán đích và những bài toán trong CSDL như khoảng

cách Euclidean, khoảng cách Mahattan, độ tương tự theo thuộc tính,…

 Sử dụng lại (REUSE): ánh xạ lời giải của bài toán tương tự cho bài toán đích,

điều này có thể dẫn đến việc điều chỉnh lời giải sao cho phù hợp với đặc trưng

của bài toán đích

 Điều chỉnh (REVISE): sau khi ánh xạ lời giải của bài toán tương tự cho bài

toán đích, tiến hành kiểm tra lời giải mới trong thế giới thực (hoặc giả lập) và

sửa lại nếu cần thiết

 Lưu lại (RETAIN): sau khi lời giải được điều chỉnh thành công cho bài toán

đích, thực hiện đánh giá và lưu trữ kinh nghiệm thu được vào bộ nhớ dưới dạng

một tình huống mới

Trước một bài toán mới, hệ thống sẽ tìm kiếm lại một hoặc một vài ca lập luận tương tự với nó từ tập các ca lập luận đã có trong CSDL Nếu lời giải của ca lập luận tìm được phù hợp với bài toán mới thì được sử dụng lại ngay Ngược lại, hệ thống sẽ

tìm cách hiệu chỉnh lời giải cũ để đưa ra một lời giải mới Việc hiệu chỉnh phụ thuộc nhiều vào miền ứng dụng và mỗi hệ thống CBR sẽ có một cơ chế hiệu chỉnh riêng Quá trình xem xét lại lời giải sẽ xác minh xem lời giải có thực sự phù hợp khi áp dụng vào thực tế hay không Việc xác minh thường được thực hiện thông qua một hệ thống giả lập môi trường để kiểm chứng lời giải hoặc do người dùng trực tiếp kiểm tra và hiệu chỉnh Cuối cùng nếu cần thiết hệ thống sẽ lưu lại ca lập luận mới để phục vụ cho việc giải các bài toán trong tương lai

Trong nhiều ứng dụng thực tế, các nhà nghiên cứu thường gộp hai bước tái sử dụng và điều chỉnh làm một và gọi chung là giai đoạn thích nghi Cho đến nay quá trình này vẫn là một đề tài thu hút sự quan tâm vì đặc tính phức tạp, đa dạng của những phương pháp có thể áp dụng Yêu cầu này dẫn đến nhu cầu thiết lập mô hình nguyên nhân, kết quả cho không gian vấn đề (là không gian biểu diễn đặc tả của vấn đề) và không gian giải pháp (là không gian biểu diễn các đặc trưng của giải pháp)

Thông thường, những ca lập luận được bổ sung vào CSDL bằng tri thức tổng quát và phụ thuộc vào miền lĩnh vực Vì vậy, hệ thống CBR có thể hỗ trợ lập luận cho những vấn đề thuộc phạm vi có ràng buộc yếu cho đến ràng buộc chặt chẽ Ví dụ: bằng việc phân tích, thu thập dữ liệu triệu chứng của bệnh nhân, chúng ta có thể tạo ra

mô hình nguyên nhân-kết quả cho chuyên ngành nghiên cứu giải phẫu học và tạo thành tri thức tổng quát ở dạng tập các luật IF-THEN hoặc tiền điều kiện của các ca lập luận cho hệ thống CBR Chi tiết các công việc cần thực hiện để hoàn thành các bước của phương pháp CBR được mô tả như hình dưới đây:

Hình 3 - 2 Sơ đồ phân rã công việc hệ thống CBR[7]

Những công việc cần thực hiện để triển khai phương pháp CBR sẽ phụ thuộc vào mục tiêu của hệ thống và một công việc sẽ được thực hiện bởi một hoặc nhiều phương thức khác nhau Trên hình 3-2 công việc được thể hiện ở vị trí các nút, những phương thức thực hiện công việc được thể hiện ở dạng chữ nghiêng, đường thẳng nét

liền thể hiện sự phân rã một công việc thành nhiều nhiệm vụ nhỏ hơn…Ví dụ: công việc truy lục dữ liệu sẽ được chia thành những nhiệm vụ nhỏ hơn như xác định các đặc trưng mô tả thích hợp, nhiệm vụ tìm những ca lập luận tương tự trong CSDL Những phương thức thực hiện nhiệm vụ được thể hiện bằng đường thẳng nét đứt Mỗi phương thức sẽ tương ứng với một thuật toán dùng để xác định và điều khiển quá trình thực thi của một nhiệm vụ con Phương thức nào được lựa chọn để áp dụng sẽ phụ thuộc vào đặc tả vấn đề và yêu cầu tri thức của miền ứng dụng

3.2.1 Tìm kiếm dữ liệu tương tự

Đơn vị tri thức của hệ thống lập luận theo kinh nghiệm là các ca lập luận (cases) Một cách tổng quát bao giờ một ca lập luận cũng được mô tả như một bộ gồm

2 thành phần:

(i) Đặc tả bài toán: mỗi ca lập luận được biểu diễn dưới dạng các vector

thuộc tính-giá trị có dạng a = (a1, a2,…, an), với n là số các thuộc tính biểu diễn cho ca lập luận

(ii) Lời giải: là giá trị β thể hiện giải pháp của vấn đề hay lời giải tương ứng

cho ca lập luận với vector thuộc tính a = (a1, a2,…, an)

Tìm kiếm tập các ca lập luận tương tự với ca lập luận mới được nhiều nhà nghiên cứu đánh giá là công việc có ảnh hưởng rất lớn đến hiệu quả và độ chính xác của hệ thống lập luận dựa trên kinh nghiệm Khái niệm tương tự phụ thuộc vào ngữ cảnh cụ thể của ứng dụng và không thể hiện một đặc tính cố định có thể áp dụng cho bất kì một ngữ cảnh tương đối Hiện nay, có nhiều phương pháp tính độ tương tự là dựa trên các độ đo khoảng cách như khoảng cách Euclidean, khoảng cách Mahattan, các khoảng cách mờ Theo các phương pháp này, độ tương tự giữa các ca lập luận được tính là tổng có trọng số độ tương tự giữa các cặp thuộc tính bởi một hàm số gọi

là hàm tương tự Mỗi trọng số tương ứng với mỗi thuộc tính trong hàm tương tự thể hiện tầm quan trọng của mỗi thuộc tính trong đặc tả ca lập luận và thông thường thuộc tính nào có giá trị trọng số lớn sẽ có tầm quan trọng cao hơn những thuộc tính có giá trị trọng số nhỏ hơn Có nhiều phương pháp khác nhau cho phép gán trọng số cho các thuộc tính nhưng phổ biến là hai hình thức sau

 Các chuyên gia miền bài toán sẽ dựa trên kinh nghiệm của mình để gán giá trị trọng số cho các thuộc tính của ca lập luận Phương pháp này có ưu điểm

là dễ thực hiện nhưng chưa có cở sở để đánh giá độ chính xác được gán giá trị một cách cảm tính bởi các chuyên gia

 Sử dụng các hệ thống có khả năng tự học như mạng nơron nhân tạo để tính toán bộ trọng số tối ưu cho các thuộc tính của ca lập luận Ở thời điểm ban đầu, các thuộc tính được gán trọng số ngẫu nhiên, hệ thống được huấn luyện bằng một tập các ca sử dụng mẫu Quá trình huấn luyện mạng nơron sẽ được thực hiện nhiều lần và dừng lại khi sai khác của kết quả giữa các lần vận hành của hệ thống không thay đổi Khi đó, bộ trọng số thu được sẽ là bộ

trọng số tối ưu thể hiện tầm quan trọng của thuộc tính trong đặc tả ca lập luận

Thuật toán thường được các nhà nghiên cứu sử dụng để tìm kiếm dữ liệu tương

tự là thuật toán k láng giềng gần nhất (knn – k nearest neighbor)[13] Nguyên lý làm việc của thuật toán này là tìm kiếm k ca lập luận có khoảng cách tới ca lập luận cần xử

lý là nhỏ hơn khoảng cách tới các ca lập luận còn lại Khoảng cách giữa các ca lập luận thường được tính bằng khoảng cách Euclidean, khoảng cách Mahattan[7], khoảng cách độ đo mờ Sau khi kết thúc quá trình tìm kiếm, chúng ta cần thực hiện phân tích

để đánh giá độ tương tự của các ca lập luận hệ thống tìm được với ca lập luận mới có đáp ứng được yêu cầu không và ngược lại có cần sửa tham số tìm kiếm và thực hiện lại quá trình tìm kiếm hay không

Hình 3 - 3 Sơ đồ mô tả quy trình tìm kiếm CBR[7]

3.2.1.1 Tính độ tương tự các ca lập luận dựa trên khoảng cách Euclidean

Một trong những phương pháp phổ biến dùng tính độ tương tự giữa các ca lập luận là dựa trên cách tính khoảng cách giữa các thực thể trong không gian Euclidean

Giả sử có tập n ca lập luận trong CSDL là CB = {e 1 , e 2 ,…,e n}, ca lập luận thứ i là

vector (n+1) phần tử có dạng e i = (e i1 , e i2 ,…, e in , β i ) với x ij là giá trị tập thuộc tính {F j,

(j=1, 2,…,n))}, β i là giá trị giải pháp tương ứng Mỗi thuộc tính e i sẽ được gán giá trị

w i  [0, 1] thể hiện tầm quan trọng của thuộc tính Khi đó, độ tương tự giữa hai ca lập

luận e p và e q được tính theo công trình tự sau:

Đặc tả ca lập luận

Truy vấn

Ca lập luận

CSDL các ca lập luận

Tìm kiếm ca lập luận tương

tự Hiệu chỉnh

phù hợp

Hiệu chỉnh giải pháp tìm được

Không tìm được ca lập luận tương tự

- Tính khoảng cách d giữa hai ca lập luận p và q bằng công thức:

[7]

) ( pj qj

j  x x

Nếu giá trị khoảng cách ( w)

pq

d lớn thì độ tương tự giữa hai ca lập luận p và q sẽ giảm đi

- Tính độ tương tự giữa hai ca lập luận:

[7]

với α là hằng số do người dùng xác định

3.2.1.2 Tính độ tương tự dựa trên phương pháp tính độ tương tự các thuộc tính

Cho tập các ca lập luận CB = {e 1 , e 2 ,…,e n }, f =(f 1 , f 2 ,…, f n) là tập các thuộc tính

mô tả ca lập luận, w =(w 1 , w 2 ,…, w n) là tập giá trị trọng số tương ứng của tập thuộc

tính f =(f 1 , f 2 ,…, f n) ca lập luận Khi đó, độ tương tự hai ca lập luận được tính bằng công thức sau:

[1]

trong đó: + f I , f R là tập thuộc tính của hai ca lập luận I và R

+ sim(f i I,f i R)là công thức tính độ tương tự thuộc tính thứ i của I và R

+ Range(f i ) là giá trị phạm vi của thuộc tính fi

giá trị trọng số W

3.2.2 Sử dụng lại kết quả tìm kiếm

Giai đoạn sử dụng lại kết quả tìm kiếm là quá trình hiệu chỉnh giải pháp tìm được thành giải pháp phù hợp cho ca lập luận mới Nhiều nhà nghiên cứu đánh giá đây

là giai đoạn quan trọng nhất của phương pháp lập luận dựa trên kinh nghiệm, được thực hiện bằng một số hình thức sau:

3.2.2.1 Sao chép và áp dụng giải pháp

Giải pháp tìm được không cần thay đổi gì và sẽ được áp dụng trực tiếp cho ca lập luận mới hoặc giải pháp này sẽ được thay đổi ở một số điểm được đánh giá là chưa phù hợp với ca lập luận mới Ưu điểm của phương pháp là chi phí tính toán thấp và người sử dụng được cung cấp giải pháp nhanh chóng Hiệu quả của phương pháp sẽ phụ thuộc vào công thức tính toán độ tương tự giữa các ca lập luận và ngưỡng giá trị tìm kiếm Nếu độ tương tự lớn hơn giá trị ngưỡng tìm kiếm thì giải pháp sẽ được sao

2 / 1

1

2 2 2

/ 1

1

2 2

) ( ) (

j

qj pj j q

p w w

q

w q

w pq

n

R i I i i n

i i

n

i

R i I i i

R I

w

f Range

f f w w

f f sim w W

f f SM

1 1

2

1

)(

*)

,(

*)

,,(

chép và áp dụng trực tiếp cho ca lập luận mới Tóm lại, các bước thực hiện của phương pháp này như sau:

Bước 1: lựa chọn phương thức tính toán độ tương tự và giá trị ngưỡng tìm kiếm thích

hợp (là giá trị thu được qua những lần thực nghiệm)

Bước 2: sử dụng kết quả của bước 1 để tìm tập các ca lập luận tương tự

Bước 3: nếu các ca lập luận tìm được có độ tương tự lớn hơn ngưỡng tìm kiếm và

không có ràng buộc nào được đưa ra thì giải pháp sẽ được sao chép và áp dụng cho ca

lập luận mới

3.2.2.2 Thay thế thuộc tính của giải pháp

Thay thế một số phần tử của giải pháp tìm được nếu nó mâu thuẫn hoặc trái ngược với yêu cầu của ca lập luận mới Ví dụ, trong điều trị y học các thành phần của mỗi loại thuốc muốn sử dụng lại được thì cần phải thay đổi (bổ sung, loại bỏ một số thành phần không cần thiết,…) để điều trị các chứng bệnh mới

muốn, thường được thể hiện bằng một số cấu trúc biểu diễn tri thức như bảng quyết định, tập hợp các luật dạng IF-THEN…Cấu trúc này được tạo ra bằng cách thu thập ý kiến của các chuyên gia lĩnh vực Yếu tố của giải pháp cần hiệu chỉnh sẽ được xác định bằng cách tìm trên cấu trúc biểu diễn tri thức tương ứng Chi tiết các bước thực hiện như sau:

Bước 1: tìm tập các ca lập luận tương tự với ca lập luận mới

Bước 2: kiểm tra xem có thành phần nào vi phạm các ràng buộc của hệ

thống

Bước 3: thay thế thành phần yếu tố vi phạm ràng buộc bằng yếu tố tìm trên

cấu trúc biểu diễn tri thức

Bước 4: thực hiện thay thế yếu tố của giải pháp và nếu cần thì đánh giá lại

giải pháp

 Sử dụng phản hồi của người dùng: phương pháp này sẽ được thực hiện

dưới dạng vòng lặp thay thế các yếu tố của giải pháp dựa trên ý kiến phản hồi của người sử dụng Nếu giải pháp mà hệ thống đưa ra không đáp ứng được yêu cầu của người sử dụng thì cần phải phân tích nguyên nhân, sau đó

sẽ thay đổi quy trình hiệu chỉnh giải pháp hệ thống đưa ra Ưu điểm của phương pháp là quá trình thay đổi các thành phần của giải pháp là một chu trình lặp có sự tham gia đánh giá của người sử dụng Hệ thống sẽ cung cấp những giải pháp dựa trên nhu cầu và mong muốn của người sử dụng do đó

sẽ dễ được người dùng chấp nhận hơn các hình thức khác Chi tiết các bước thực hiện như sau:

Bước 1: tìm tập các ca lập luận tương tự với ca lập luận mới

Bước 2: thu thập ý kiến phản hồi của người sử dụng về giải pháp hệ thống

đưa ra

Bước 3: thực hiện phân tích giải pháp hệ thống đưa ra và xác định nguyên

nhân của việc người sử dụng chưa thoả mãn giải pháp này

Bước 4: thực hiện thay thế yếu tố của giải pháp dựa trên ý kiến phản hồi của

người sử dụng và nếu cần thì đánh giá lại giải pháp

3.2.2.3 Phương án thay thế thành phần giải pháp

Phương án thay thế thành phần của giải pháp chỉ được áp dụng khi chúng ta không thể tìm được phần tử của giải pháp cần hiệu chỉnh để phù hợp với ca lập luận mới Giải pháp phù hợp sẽ được sinh ra dựa trên các ràng buộc và đặc điểm của giải pháp mong muốn Mỗi ràng buộc sẽ mô tả các thuộc tính nên có hoặc không nên có trong giải pháp - kết quả của bước tìm ca lập luận tương tự Thông thường, các ràng buộc được tạo ra bằng ý kiến của chuyên gia lĩnh vực bài toán

Chi tiết các bước thực hiện công việc này gồm:

Bước 1: tìm tập các ca lập luận tương tự tương tự ca lập luận mới

Bước 2: dựa trên tập các ca lập luận tương tự, xem xét tính hợp lý của giải pháp tìm

được để quyết định có áp dụng giải pháp này hay không

Bước 3: nếu cần hiệu chỉnh giải pháp tìm được thì tìm yếu tố thuộc giải pháp có thể

thay bằng thành phần thích hợp hơn

Bước 4: bổ sung giải pháp thu được vào tập cấu trúc tri thức để sử dụng trong những

lần lập luận tiếp theo

Hình 3 - 4 Sơ đồ mô tả quá trình hiệu chỉnh giải pháp

CSDL các ca lập luận

Tập các ca lập luận tương tự

Hiệu chỉnh giải pháp tìm được

Tham chiếu

Người sử dụng đánh giá giải pháp Giải pháp được

chấp nhận

Giải pháp không thoả mãn y/c

Đề xuất giải pháp

3.2.3 Bảo trì cơ sở dữ liệu các ca lập luận

Hoạt động bảo trì cơ sở dữ liệu các ca lập luận bao gồm các chính sách và kĩ thuật cập nhật (thêm, sửa, xóa) các ca lập luận, chỉ số và những kiến trúc tri thức dùng

để tính toán độ tương tự, hiệu chỉnh kết quả lập luận trong hệ thống CBR để đảm bảo hiệu quả sử dụng Công việc này có thể chia thành hai nhóm sau:

3.2.3.1 Bảo trì về mặt số lƣợng

Là hoạt động nhằm đảm bảo hiệu quả xử lý vấn đề của hệ thống CBR như thời gian xử lý dữ liệu trung bình, quản lý số lượng các ca lập luận lưu trong CSDL và tổ chức lại cấu trúc chỉ số Hoạt động này có thể bao gồm một số hạng mục sau:

hệ thống lập luận bằng phương pháp CBR có thể tăng lên rất nhanh và ảnh hưởng tới tốc độ truy vấn dữ liệu Hiển nhiên là việc bổ sung càng nhiều các

ca lập luận vào CSDL cũng chưa thể đảm bảo là giải pháp tìm được sẽ tốt hơn Mặt khác, nếu xoá quá đi quá nhiều các ca lập luận cũng ảnh hưởng tới tính hoàn thiện dữ liệu của hệ thống CBR Vì vậy, luôn luôn có sự đánh đổi giữa số lượng các ca lập luận trong CSDL và tính hoàn thiện dữ liệu của nó Điều đó đồng nghĩa với yêu cầu lưu trữ số lượng tối thiểu các ca lập luận mà vẫn thoả mãn tính chất hoàn thiện dữ liệu của hệ thống

được thẩm định và cập nhật định kì do có sự thay đổi của miền tri thức bài toán Ngoài ra, khi bổ sung ca lập luận vào CSDL cũng cần sửa đổi cấu trúc chỉ số, trọng số các đặc tính để đảm bảo hệ thống làm việc ổn định và hiệu quả

tin hiệu năng làm việc của hệ thống để có thể lập kế hoạch và đánh giá các hoạt động bảo trì hiệu quả, ví dụ chi phí tài nguyên để truy vấn dữ liệu, tần suất truy cập của các ca lập luận Những thông tin này sẽ hữu ích để điều chỉnh hoạt động của hệ thống CBR, ví dụ những ca lập luận thường được truy cập sẽ được lưu trên ổ đĩa cứng có tốc độ làm việc cao hơn ổ đĩa hiện thời

gian sẽ có những ca lập luận không còn giá trị sử dụng trong hệ thống CBR, cũng như giải pháp của những ca lập luận này không còn hợp lý Hoạt động bảo trì có nhiệm vụ phân tích và tìm ra những ca lập luận này để loại bỏ khỏi CSDL nhằm đảm bảo tính chính xác, hiệu quả của giải pháp mà hệ thống CBR đưa ra

lập luận không chính xác hoặc thiếu dữ liệu là tình trạng chung của rất nhiều

hệ thống CBR vì chúng được nhập vào bởi rất nhiều người và nguồn dữ liệu khác nhau Hoạt động bảo trì là công việc nhằm loại bỏ dữ liệu không chính

xác và bổ sung thông tin còn thiếu cho các ca lập luận từ đó nâng cao hiệu quả làm việc của hệ thống

pháp CBR là nó không hoàn toàn dựa trên lý thuyết miền lĩnh vực Khả năng lập luận của hệ thống dựa trên giả định về độ tương đồng là các vấn đề

có đặc tả giống nhau thì sẽ có giải pháp tương tự nhau Trong nhiều trường hợp thực tế, những giả thuyết về độ tương đồng cần phải thẩm định và đánh giá thường xuyên bởi người sử dụng Những ý kiến phản hồi của người sử dụng sẽ là cơ sở để người thiết kế hệ thống xem xét và chỉnh sửa lại những thiết kế trên hệ thống của mình

3.2.3.2 Bảo trì chất lƣợng thông tin

Là hoạt động nhằm đảm bảo tính hiệu quả của hệ thống CBR, bao gồm những

tiêu chuẩn như tính chính xác, tính toàn vẹn, tính hoàn thiện của dữ liệu hệ thống

 Tính chính xác: độ chính xác của hệ thống CBR là khả năng giải quyết vấn

đề mà người sử dụng yêu cầu Ví dụ trong những bài toán phân loại vấn đề như hệ thống chuẩn đoán bệnh, phân tích lỗi thiết bị thì mỗi ca lập luận sẽ được so sánh với những ca lập luận trong CSDL nhằm xác định nhóm dữ liệu chứa ca lập luận này Vì vậy, độ chính xác của hệ thống CBR có thể xác định dựa trên mức độ thành công của việc phân nhóm tập các ca lập luận Ngoài ra, nếu giải pháp là các giá trị số giá thuê hoặc mua nhà thì độ chính xác của hệ thống CBR có thể xác định bởi số phần trăm khác biệt giữa giá

mua nhà ước tính và giá trị thực của nó

 Tính toàn vẹn: điều này được thể hiện bằng chất lượng của giải pháp mà hệ

thống cung cấp không mâu thuẫn nhau khi lập luận cùng một vấn đề Thông thường, một hệ thống CBR sẽ bị coi là không toàn vẹn khi bên trong CSDL

chứa một trong những loại ca lập luận sau:

- Tập các ca lập luận dư thừa: nếu hai ca lập luận có những đặc điểm giống

hệt nhau hoặc nếu một ca lập luận có thể gộp lại những ca lập luận khác thì

có thể xoá một trong hai ca lập luận đó mà không ảnh hưởng tới khả suy diễn của hệ thống Ý nghĩa của việc gộp các ca lập luận có thể giải thích như sau: cho hai ca lập luận ep và eq, ca lập luận ep có thể gộp lại với ca lập luận

eq nếu chúng ta có thể dựa vào ca lập luận luận ep để xử lý nhiều tình huống suy diễn hơn eq Khi đó, ca lập luận eq được xét là ca lập luận dư thừa và có thể xoá khỏi CSDL

- Tập các ca lập luận mâu thuấn nhau: là tập các ca lập luận có tập các

thuộc tính giống nhau nhưng giải pháp lại mâu thuẫn nhau Nguyên nhân là

do việc nhập sai giá trị cho các thuộc tính hoặc do hệ thống sửa giá trị của giải pháp trong nhiều lần thực hiện suy diễn

- Tập các ca lập luận không được sử dụng: một ca lập luận không được sử

dụng nếu nó không bao giờ có trong tập kết quả tìm kiếm của hệ thống

Nguyên nhân có thể là những thuộc tính quan trọng không có hoặc thông tin không chính xác

Khi đó, tính không toàn vẹn được xem như là các yếu tố bất thường và có thể chứa các rủi ro tiềm ẩn Vì vậy, việc phân tích và phát hiện các yếu tố rủi ro tiềm

ẩn này là một công việc rất quan trọng trong việc xây dựng và bảo trì hệ thống lập luận

dựa trên kinh nghiệm

 Tính hoàn thiện: là tính chất của hệ thống CBR liên quan đến phạm vi của

không gian các vấn đề trong miền lĩnh vực lập luận hoặc có thể hiểu theo nghĩa hệ thống CBR đã có tất cả các ca lập luận quan trọng nên có thể cung cấp giải pháp trong mọi lần thực hiện suy diễn Trong quá trình xây dựng hệ thống CBR, các ca lập luận sẽ được bổ sung dần dần vào CSDL Tuy nhiên, việc bổ sung các ca lập luận không đảm bảo sẽ nâng cao tính hoàn thiện của

hệ thống Vì vậy, nhiệm vụ xác định các ca lập luận quan trọng và tri thức còn thiếu là nhiệm vụ chính để xây dựng một hệ thống CBR thoả mãn tính hoàn thiện của tập dữ liệu lập luận Điều này được thể hiện ở hai đặc điểm

sau:

- Phạm vi của một ca lập luận: là tập các bài toán đích mà ca lập luận vừa

đề cập có thể sử dụng để giải quyết

- Khả năng tìm ra lời giải của bài toán đích: là tập tất cả các ca lập luận

được sử dụng để tìm ra lời giải cho bài toán đích

Hình 3 - 5 Mô tả phạm vi và khả năng tìm ra lời giải của ca lập luận

Trong hình 3-5, các tập A và B lần lượt biểu diễn cho phạm vi vùng có thể xác định lời giải cho ca lập luận e Tập C (giao giữa hai tập A và B) thể hiện tập các ca lập luận có thể tìm ra lời giải bằng ca lập luận e và cũng là tập có thể dựa vào để tìm được