Sử dụng tri thức trong việc phát triển các dự án công nghệ thông tin luận văn ths công nghệ thông tin 1 01 10 pdf

Là ngành mũi nhọn, tin học, và công nghệ thông tin ngày càng phải đổi mới và phát triển để có được các biện pháp tân tiến và hiệu quả nhất cho việc ước lượng dự án, và quản lý phát triển

LUẬN VĂN THẠCH SỸ

HÀ NỘI 2007

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

THẠCH HÒANG VIỆT

SỬ DỤNG TRÍ THỨC TRONG VIỆC PHÁT TRIỂN CÁC DỰ ÁN

CÔNG NGHỆ THÔNG TIN

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

MÃ SỐ: 0.01.10

Người Hướng Dẫn : PGS TS

HÀ NỘI 2007

MỤC LỤC

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

MỞ ĐẦU 9

CHƯƠNG 1 QUẢN LÝ QUÁ TRÌNH PHÁT TRIỂN DỰ ÁN 10

1.1 Lập kế hoạch dự án 10

1.1.1 Lập kế hoạch dự án 10

1.1.2 Tính toán lợi nhuận của dự án 10

1.2 Lập kế hoạch, quản lý và đánh giá chất lượng 11

1.2.1 Triển khai chức năng chất lượng 11

1.2.2 Chất lượng phần mềm 11

1.2.3 Đặc trưng chất lượng phần mềm 12

1.3 Quản lý tiến trình 14

1.3.1 Tổng quan về lập kế hoạch tiến trình và quản lý tiến độ 14

1.3.2 Lập kế hoạch tiến trình 15

1.3.3 Quản lý tiến trình 16

1.4 Năng suất phần mềm 18

1.4.1 Về ước lượng 18

1.4.2 Các phương pháp ước lượng 18

1.5 Tổ chức phát triển 21

1.5.1 Các phong cách tổ chức 22

1.5.2 Tổ chức phát triển 23

1.6 Kết luận 27

CHƯƠNG 2 LÝ THUYẾT CHẮC CHẮN 28

2.1 Tổng quan về lý thuyết chắc chắn 28

2.1.1 Lập luận không chính xác trong MYCIN 28

2.1.2 Thể hiện dấu hiệu không chắc chắn 29

2.1.3 Thể hiện các luật không chắc chắn 29

2.1.4 Suy luận không chắc chắn 29

2.1.5 Tổ hợp dấu hiệu từ nhiều nguồn 30

2.1.6 Độ tin cậy thực 30

2.1.7 Cơ sở của lý thuyết chắc chắn 31

2.2 Nhân tố chắc chắn dưới khía cạnh xác suất 33

2.2.1 Dấu hiệu không chắc chắn 33

2.2.2 Lan truyền chắc chắn đối với các luật có giả thiết đơn 35

2.2.3 Lan truyền chắc chắn đối với các luật nhiều giả thiết 35

2.2.4 Lan truyền chắc chắn đối với các luật có cùng kết luận 36

2.2.5 Lan truyền chắc chắn đối với các luật phức hợp 39

2.3 Ví dụ về nhân tố chắc chắn 39

2.4 Kết luận 40

CHƯƠNG 3 ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM 42

3.1 Quy trình ước lượng dự án phần mềm 42

3.1.1 Ước lượng cỡ dự án phần mềm 43

3.1.2 Ước lượng khối lượng công việc 44

3.1.3 Ước lượng thời hạn 45

3.1.4 Ước lượng dự toán 45

3.2 Quy trình ước lượng dự án dựa trên cấu trúc phân rã công việc 46 3.2.1 Tổng quan quy trình ước lượng 46

3.2.2 Thiết kế hệ thống 47

3.2.3 Ước lượng mỗi một hệ thống con 48

3.2.4 Kế hoạch công việc 53

3.3 Ước lượng sử dụng mô hình điểm trường hợp sử dụng 55

3.3.1 Ước lượng sử dụng mô hình UCPs 55

3.3.2 Áp dụng mô hình UCPs trong thực tế 59

3.4 Biến đổi quy trình ước lượng dự án phần mềm 62

3.4.1 Phân loại các loại dự án phần mềm cần ước lượng 62

3.4.2 Quy trình ước lượng dự án phần mềm thực tế 63

3.5 Kết luận 76

CHƯƠNG 4 ƯỚC LƯỢNG DỰ ÁN DÙNG LÝ THUYẾT CHẮC CHẮN 77 4.1 Ước lượng cỡ dự án 78

4.1.1 Phân loại dự án theo IBM Rational 78

4.1.2 Phân loại dự án theo quy định của Đề án 112 78

4.1.3 Phân loại dự án theo SLOC 80

4.1.4 Xây dựng bảng nhân tố chắc chắn 81

4.2 Ước lượng khối lượng công việc 82

4.2.1 Phân loại rủi ro 83

4.2.2 Khả năng kết hợp giữa quản lý rủi ro và lý thuyết chắc chắn 84

4.2.3 Áp dụng các luật chắc chắn vào trong ước lượng 85

4.2.4 Dùng các luật để nâng cao khả năng chắc chắn của dự án 89

4.3 Ƣớc lƣợng lịch biểu 92

4.4 Ƣớc lƣợng dự toán 95

4.5 Kết luận 98

KẾT LUẬN 99

TÀI LIỆU THAM KHẢO 101

ECF Nhân tố phức tạp môi trường

5 Effort Tổng thời gian nỗ lực để hoàn thành một

công việc

8 LOC Số dòng lệnh (Line Of Code)

9 PDCA Kế hoạch, thực hiện, kiểm tra, hành động

10 PMI Viện Nghiên cứu quản lý dự án

12 QFD Triển khai chức năng phát triển

18 UCPM Mô hình điểm trường hợp sử dụng

19 UCPs Điểm những trường hợp sử dụng

20 UUCPs Điểm trường hợp sử dụng không thích ứng

21 WBS Cấu trúc phân rã công việc (Work

break-down Structure)

MỞ ĐẦU

Với việc ngày càng có nhiều công ty nước ngoài lựa chọn Việt Nam để đầu

tư vào lĩnh vực gia công phần mềm, và chính phủ cũng đang đầu tư mạnh mẽ cho công nghệ thông tin, các công ty tin học, và công nghệ thông tin luôn phải đối mặt với những thách thức trong việc ước lượng dự án phần mềm, và quản lý phát triển dự án phần mềm Là ngành mũi nhọn, tin học, và công nghệ thông tin ngày càng phải đổi mới và phát triển để có được các biện pháp tân tiến và hiệu quả nhất cho việc ước lượng dự án, và quản lý phát triển dự án phần mềm, nhằm theo kịp và đáp ứng được nhu cầu phát triển của xã hội

Là một phương pháp quản lý có những đặc thù riêng biệt, ước lượng và quản lý dự án phần mềm là một lĩnh vực không quá mới với nhiều thành phần và

kỹ thuật khác nhau Luận văn sẽ trình bày một số vấn đề cơ bản về quá trình quản

lý phát triển dự án phần mềm, đặc biệt là ước lượng dự án phần mềm, với một số phương pháp, kỹ thuật ước lượng như: Ước lượng dựa trên COCOMO, ước lượng dựa trên Cấu trúc phân rã công việc, Ước lượng dựa trên Điểm chức năng, Ước lượng dựa trên Điểm trường hợp sử dụng v.v

Để triển khai thử nghiệm nhằm đánh giá các phương pháp đã trình bày, luận văn tiến hành xây dựng quy trình “Ước lượng dự án phần mềm” Trong quy trình này, có vận dụng phương pháp ước lượng dựa trên Mô hình Cấu trúc phân

rã công việc và dựa trên thực tế áp dụng quy trình phát triển dự án tại công ty Vietsoftware International Quy trình này nhằm đưa ra phương pháp để ước lượng một cách nhanh nhất, đơn giản nhất, và gần với thực tế nhất Trên cơ sở quy trình

đó, luận văn sẽ tiếp tục trình bày việc áp dụng tri thức vào việc phát triển dự án

Nội dung nghiên cứu của đề tài tập trung chủ yếu vào các vấn đề:

 Chương 1: Tập trung vào một số lý lý thuyết liên quan đến quản lý quá trình phát triển dự án phần mềm

 Chương 2: Trình bầy về các khái niệm, luật của lý thuyết chắc chắn

 Chương 3: Phân tích đánh giá một số quy trình ước lượng dự án phần mềm để từ đó đưa ra quy trình ước lượng dự án phần mềm

 Chương 4: Sử dụng tri thức trong việc ước lượng dự án phần mềm

CHƯƠNG 1 QUẢN LÝ QUÁ TRÌNH PHÁT TRIỂN DỰ ÁN

1.1 Lập kế hoạch dự án

Để hoàn thành thành công một dự án phát triển, việc lập kế hoạch và quản

lý dựa trên các kế hoạch là quan trọng Việc chuẩn bị kế hoạch cho phép nhìn toàn cảnh về dự án Dự án cần được phát triển rõ ràng, có khả năng kiểm tra và nghiên cứu trước các vấn đề rủi ro của dự án

Ngoài ra còn cần xem xét mục đích, chức năng và nhìn bao quát về hệ thống, cũng như khối lượng công việc và số nhân công cần cho dự án

1.1.1 Lập kế hoạch dự án

Việc lập kế hoạch dự án được thực hiện, nhằm tạo ra những kết quả :

 Những đầu ra (mã lệnh, chương trình, tài liệu), công việc, lịch biểu, quản lý chất lượng, quản lý rủi ro và những vấn đề khác

 Cơ cấu tổ chức của dự án Cơ cấu gồm những thành viên tham gia dự án

và đóng vai trò nào đó trong dự án Những người có vai trò quản trị dự án, quản trị chất lượng, sẽ đảm nhận cụ thể những công việc gì trong quá trình phát triển và quản lý dự án

 Quy định môi trường phát triển bao gồm phần cứng và phần mềm và các điều kiện khác về an toàn bảo mật trong dự án kèm theo, nếu có

 Chi phí phát triển, bao gồm chi phí cho nhân sự, trang thiết bị, chi tiêu và các chi phí có liên quan khác

Người ta xây dựng kế hoạch chi tiết theo những kết quả trên Những kế hoạch này cung cấp cơ sở để đánh giá tính khả thi triển khai dự án Ngoài ra, kế hoạch được dùng làm mục đích cho việc quản lý dự án, sau khi dự án được phê duyệt

1.1.2 Tính toán lợi nhuận của dự án

Việc phát triển hệ thống được thực hiện như một phần của hoạt động kinh doanh, nên các yêu tố sinh lợi cần được thăm dò sau khi phát triển dự án, một cách tự nhiên Điều này có nghĩa là việc đánh giá chi phí- hiệu quả là cần thiết Nếu việc phát triển hệ thống cho thấy nó không sinh lợi từ giai đoạn lập kế hoạch,

dự án được tiến hành Có thể nói rằng dự án đó có thể là không được thực hiện như đã lập kế hoạch

Do đó việc xem xét lại các kế hoạch trong từng giai đoạn trở thành cần thiết, để duy trì tính sinh lợi Những sửa đổi về các đặc tả phải được phản ánh đúng Cho nên, để an toàn chất lượng, cần phải tiến hành việc quản lý những thay đổi diễn ra trong dự án

1.2 Lập kế hoạch, quản lý và đánh giá chất lƣợng

1.2.1 Triển khai chức năng chất lƣợng

Mục đích chính của kiểm thử phần mềm là loại bỏ các lỗi và duy trì chất lượng đã được thiết kế, QFD là một công nghệ giúp cho phần mềm đạt chất lượng cao hơn QFD được giới thiệu để tăng chất lượng của thiết kế phần cứng Đại cương về QFD là :

Với QFD, chất lượng của phần mềm bao gồm các hệ con và các phân hệ, được biểu diễn như đặc trưng chất lượng Nó cho phép đánh giá và sử dụng cho việc kiểm soát chất lượng của các hệ thống con và các phân hệ bên trong nó

Nói cách khác, nếu có đủ thời gian trong các giai đoạn đầu cho việc kiểm soát và sửa chữa sai sót, thì khối lượng cần sửa đổi trong các giai đoạn sau sẽ được rút bớt lại Thực tế người ta nói : „‟Một giờ được dùng để sửa các khiếm khuyết trong những giai đoạn đầu, tiết kiệm từ ba tới mười giờ làm việc trong những giai đoạn cuối‟‟ Để làm tăng chất lượng phần mềm, người ta thực hiện chu trình :

1.2.3 Đặc trƣng chất lƣợng phần mềm

Có nhiều phương pháp đánh giá phần mềm Ở đây chúng ta cùng xem xét đến sáu mô tả đặc trưng được liệt kê trong ISO/IEC 9126 được nêu trong hình sau

 Chức năng (đặc trưng chức năng)

 Các chức năng cần cho hệ thống được thực hiện (tính thích hợp);

 Độ chính xác chức năng được cung cấp (tính chính xác);

 Các chức năng đáp ứng cho đặc tả (tính tuân thủ);

 Cung cấp sự dễ dàng khi kết nối với các hệ thống khác (tính liên tác);

 Cung cấp tính an ninh cơ bản

Đặc trưng chất lượng

Tính thay đổi được Tính phân tích được

Tính ổn định Tính kiểm thử được Tính thích ứng Tính cài đặt

Tính thay thế được Tính tuân thủ

 Tính tin cậy

 Phần mềm không có lỗi được gọi là chín muồi;

 Một mức độ hệ thống nào đó được duy trì ngay cả khi xuất hiện trục trặc: dung sai;

 Hoạt động bình thường được khôi phục sẵn sàng khi lỗi xuất hiện: tính khôi phục được

 Tính dùng được (dễ dùng)

 Vận hành dễ dàng: Tính hiểu được

 Dễ nhớ: khả năng học hiểu

 Cho phép quản lý thao tác dễ dàng: tính vận hành

Hình 1.2.1: Sáu đặc trưng chất lượng phần mềm

 Tính hiệu quả

 Cung cấp những đáp ứng tố và hiệu năng cao : hành vi thời gian;

 Cho phép dùng hiệu quả các tài nguyên hệ thống: hành vi tài nguyên

 Tính bảo trì

 Cho phép phân tích dễ dàng các tài liệu thiết kế và chương trình khi tìm ra lỗi: khả năng phân tích;

 Cho phép mở rộng và sửa đổi dễ dàng cho hệ thống: tính thay đổi được;

 Việc sửa đổi hệ thống không ảnh hưởng tới các hệ thống khác: tính ổn định;

 Không đòi hỏi kiểm thử mất công sức sau khi tiến hành sửa đổi: tính kiểm thử được

 Tính khả chuyển

 Có tính thích ứng: tính thích ứng;

 Cung cấp công việc thiết đặt dễ dàng: khả năng thiết đặt;

 Tuân thủ các đặc tả chuyển: tính tuân thủ;

 Cho phép dễ dàng thay thế bằng phần mềm khác: khả năng thay thế

1.3 Quản lý tiến trình

Quản lý tiến trình được chia thành lập kế hoạch tiến độ và quản lý tiến trình Ở đây, các đặc trưng, và phương pháp được áp dụng sẽ được giải thích ở dưới đây

1.3.1 Tổng quan về lập kế hoạch tiến trình và quản lý tiến độ

Lập kế hoạch tiến trình xuất hiện khi việc phát triển hệ thống được hoàn thành dựa trên việc hoàn thành các tiến trình khác nhau Một số công việc lớn phải mất nhiều năm để hoàn thành Do đó, việc lập kế hoạch tiến độ chính xác là một việc quan trọng Một dự án phát triển mới gồm nhiều nhân tố không chắc chắn mà không thể nào xác định được chính xác trong giai đoạn lập kế hoạch tiến

độ Do đó, khi tiến độ công việc được thúc đẩy, việc giải quyết linh hoạt cho các tính huống như: làm cho ngày chuyển giao sớm hơn (tùy theo tinh huống), hay tối thiểu hóa việc chậm trễ, trở thành cần thiết

Trong khi đó quản lý tiến trình là việc quản lý quá trình diễn biến của công việc Chúng ta cần kiểm tra lại tiến độ công việc và tiến hành hành động nào đó

đối với công việc có tiến độ bị chậm so với kế hoạch làm việc Hiệu năng công việc phát triển hệ thống bị chia sẻ cho nhiều người Do đó, sự chậm chễ của người này trong công việc dẫn tới sự chậm trễ trong tiến độ của người kia, dẫn tới

sự chậm trễ trong tiến độ của dự án xem như một điều tất yếu Hậu quả là, việc quản lý tiến trình thấu đáo là cần thiết để tối ưu tác động của việc chậm trễ Cũng như để phát hiện ra vấn đề dễ nhất có thể giải quyết được

 Biểu đồ PERT (Program Evaluation and Review Technique) cung cấp một số kỹ thuật để sinh ra lịch biểu đồ cho từng phần công việc (tiến độ) của một dự án, và quản lý chúng dựa trên biểu đồ Dưới đây là một ví dụ của biểu đồ PERT

Hình 1.3.1: Sơ đồ Gantt

 Biểu đồ PERT có thể giải quyết việc phát triển các hệ thống quy mô lớn và phức tạp

 Nó có khả năng tính toán tổng số ngày cần thiết (tổng số ngày tối thiểu)

 Thứ tự công việc cần được thực hiện được biểu diễn rõ ràng làm sáng tỏ các điểm quản lý quan trọng

 Số ngày và thứ tự thực hiện được thể hiện trên các cạnh Các nút là số các công việc cần thực hiện được đánh số từ 1 tới n (n là tổng số công việc cần thực hiện trong dự án)

Đường đi được sinh ra bằng cách nối các nút, với từng nút mà thời gian sớm nhất có thể và thời gian muộn nhất có thể là như nhau (không được phép thay đổi hay co dãn) được gọi là đường Gantt Công việc trên đường này là quan trọng nhất trong tiến trình quản lý

1.3.3 Quản lý tiến trình

Việc quản lý tiến trình được tiến hành theo hai quan điểm sau:

1 Định thời gian bắt đầu và kết thúc của từng phần việc

2 Trạng thái tiến độ của công việc cá nhân của từng người

Quản lý việc định thời gian bắt đầu và kết thúc của từng việc

Việc quản lý được tiến hành sao cho từng phần việc được bắt đầu như đã được xác định trong bản kế hoạch và được kết thúc như được xác định bằng mọi phương pháp, bằng cách kiểm tra trang thái tiến độ tức khắc của từng phần việc

và bằng cách lấy những cách đo thích hợp dựa trên trạng thái đó

Sau đây ta xét các lý do cho việc chậm trễ trong công việc:

 Kỹ năng của các kỹ sư liên quan không đủ;

 Việc lập kế hoạch và mục tiêu không được xem xét thích hợp;

Hình 1.3.2: Biểu đồ PERT

Để tạo khả năng cho các biện pháp như vậy, mọi thành viên lực lượng lao động phải báo cáo trang thái tiến độ của công việc của mình một cách đều đặn thông qua nhật ký công việc hay báo cáo công việc tuần Nói riêng, khi một tình huống bất ngờ xuất hiện, người đó phải báo cáo sớm nhất có thể

Lập lịch

Lập lịch cho từng thành viên lực lượng lao động: Việc lập lịch được dùng

để phân bổ công việc của từng tiến trình cho từng thành viên lực lương lao động

để quyết định thứ tự của từng phần việc được tiến hành, và để quản lý trang thái tiến độ công việc trên cơ sở hàng ngày Việc lập lịch cũng có hiệu quả để làm cho thời gian chuyển giao sơm hơn và tối thiểu việc chậm trễ

Ví dụ: Thiết kế ngoài, cho việc thiết kế tổng thể một hệ thống, bao gồm nhiều phần việc trong đó có một số lớn các kỹ sư hệ thống (Ses) có tham dự vào Trong ví dụ này, việc lập lịch trở thành như sau khi được xem xét theo quản điểm người lãnh đão và quan điểm của thành viên lực lượng lao động, tương ứng:

1 Người lãnh đạo dự án

 Công việc thiết kế hệ thống được chia thành một số việc nhỏ

 Mỗi việc được phân bổ cho từng thành viên tùy theo mức độ kỹ năng của người đó

 Việc lập lịch cho từng thành viên (từng công việc) được thực hiên

 Hướng dẫn phân bổ công việc được trao cho từng thành viên

 Việc hoàn thành của từng công việc được kiểm tra bằng cách đọc nhật ký công việc hay báo cáo tuần của từng thành viên

 Tiến hành những biện pháp linh hoạt, như thay đổi kế hoạch nếu cần, khi phát hiện ra chậm trễ trong công việc

2 Thành viên phát triển dự án

 Người đó tự quản lý mình bằng cách so sánh trạng thái tiến độ công việc với lịch công việc đã được phân bố và cố gắng giữ thời gian kết thúc như kế hoạch

 Người đó báo cáo về trạng thái tiến độ công việc thông qua nhật ký công việc hay báo cáo tuần, bên cạnh việc báo cáo khi công việc hoàn thành xong

Như đã mô tả ở trên, quản lý tiến trình được tiến hành bằng việc tổ hợp kế hoạch tiến trình thô và lập lịch chi tiết

1.4 Năng suất phần mềm

Để đánh giá năng suất phần mềm, phải đánh giá được quy mô phần mềm Việc phát triển phần mềm bao gồm nhiều đầu ra khác nhau tuỳ theo từng tiến trình, như cá đề án, đặc tả yêu cầu, đặc tả thiết kế, đặc tả thiết kế, đặc tả chương trình, và chương trình nguồn Tuy nhiên, phần nhiều trong chúng được tạo ra bằng công việc kiểu thủ công, tùy thuộc phần lớn vào kinh nghiệm và cảm giác con người Do đó, việc ước lượng chi phí cũng phụ thuộc chủ yếu vào kinh nghiệm và cảm giác để cải thiện tình hình này, người ta đề nghị dùng kỹ nghệ phần mềm Sau đó nhiều phương pháp ước lượng chi phí đã được đề nghị, và một số trong chúng bây giờ đang được dùng

1.4.1 Về ước lượng

Chẳng hạn cần ước lượng chi phí để xây dựng một căn nhà Mái, cửa và cửa sổ tất cả đều thấy được Do đó nếu bản thiết kế sơ bộ được thiết kế thì chi phí có thể được ước lượng dựa trên không gian sàn nhà và các nhân tố khác

Tuy nhiên, tệp, cơ sở dữ liệu và chương trình phần mềm tất cả đều không nhìn thấy được (tài sản vô hình) Do đó, các ước lượng trong giai đoạn thiết kế chi tiết trở thành khác biệt lớn với các ước lượng trong giai đoạn lập kế hoạch cơ sở Hậu quả là ước lượng về phát triển nên được tiến hành trong nhiều giai đoạn được mô tả như sau:

 Trong giai đoạn lập kế hoạch cơ sở;

 Trong giai đoạn thiết kế ngoài;

 Trong giai đoạn thiết kế trong

1.4.2 Các phương pháp ước lượng

Có một số phương pháp sau đây để ước lượng tỉ lệ phát triển:

Ước lượng dựa theo dữ liệu quá khứ

Trong phương pháp này, các ước lượng về hệ thống được phát triển và suy ra dựa trên dữ liệu thực của hệ thống tương tự đã xây dựng trong quá khứ

Có hai cách để làm ước lượng

 Toàn bộ tiến trình phát triển hệ thống được phân hoạch thành một số bước, và các ước lượng được suy dẫn ra dựa trên dữ liệu thực cho công việc tương tự

 Hệ thống được phân hoạch thành một số module chương trình, và các ước lượng được suy ra dựa trên dữ liệu thực tế cho các module chương trình tương tự

Với hệ thống tương tự trong quá khứ, các lỗi cơ sở khó mà bị bao hàm vào nhiệm vụ ước lượng là tương đói đơn giản Số lỗi trong các ước lượng trở nên lớn hơn nếu hệ thống quá khứ thích hợp không được chọn cho công việc ước lượng

Phương pháp áp dụng dựa trên LOC

Phương pháp dựa trên LOC là hay được dùng nhất làm phương pháp cho việc ước lượng kích cỡ phát triển Với phương pháp này, kích cỡ phát triển được ước lượng bằng số dòng mã, và dựa trên dữ liệu này, khối lượng tài nguyên cần thiết được ước lượng ra

 Thủ tục:

 Hệ thống được diễn tả như một tập các module chương trình;

 Các chức năng hệ thống được phân hoạch thành các module chương trình, với mối quan hệ giữa chúng được chỉ ra bằng biểu đồ khối cấu trúc hay các phương tiện khác;

 Tính toán kích cỡ của từng chương trình;

 Số các LOC trong từng module chương trình trong biểu đồ được ước lượng Rồi tổng số cá LOC được tính toán;

 Ước lượng nhân lực cho tất cả các chương trình cần làm;

 Tổng số các LOC được chuyển thành tổng nhân lực, như dữ liệu và tháng (số người cần thiết nhân với số tháng cần thiết) Chẳng hạn, nếu việc

 Ước lượng về nhân lực gián tiếp: trọng số nhân lực đối với các công việc như phân tích và thiết kế hệ thống, và trọng số cho nhân lực đối với công việc hành chính sẽ được quyết định;

 Tổng nhân lực ướng lượng: Tổng nhân lực được tính bằng việc kết tập dữ liệu nhân lực cho từng tiến trình;

 Về đặc trưng nó cung cấp phương pháp tiêu biểu nhất

Nếu có các chuẩn rõ ràng để ước lượng chương trình LOC và để chuyển chúng thành khối lượng nhân lực, thì tính toán được tổng giá trị dự án là khá đơn giản

Phương pháp dựa trên nhiệm vụ chuẩn

Với phương pháp dựa trên nhiệm vụ chuẩn, công việc được chia ra trên cở

sở đầu ra hay trên cơ sở xử lý bằng WBS (Work Breakdown Structure) Sau đó ước lượng chi tiết đwocj thực hiện cho từng đơn vịvà ước lượng kết quả được tích luỹ theo phương pháp bottom-up

 Kiểm tra đầu ra và công việc được yêu cầu

 Hệ thống được chia ra thành một cấu trúc phân cấp dựa trên WBS, và tất cả các đầu ra sản phẩm cần được phát triển trong dự án được liệt kê

ra Sau đó tất cả những công việc cần thực hiện để làm ra sản phẩm này được chọn

 Kích cỡ của từng công việc được chuyển thành khối lượng nhân lực

 Khối lượng nhân lực cần cho từng đơn vị công việc được chọn được đưa ra ước lượng theo những chuẩn nào đó, như dữ liệu thực tế cho chuẩn đã có tác dụng trong quá khứ

 Kết tập toàn bộ nhân lực

 Khối lượng nhân lực cần cho từng đơn vị công việc được tính tổng lại

Phương pháp dựa trên điểm chức năng (Function Point)

Với phương pháp FP, từng chức năng được đưa vào trong hệ thống sẽ được diễn đạt đinh lượng bằng một phương pháp nàp đó, và do vậy dữ liệu được biểu diễn theo định lượng được dùng như cách đo ước lượng

Phương pháp này khác cơ bản với ba phương pháp trên trong việc dùng từng chức năng được cung cấp cho khách hàng và xem nó như đơn vị đo

Phương pháp dựa trên Mô hình Dự toán Thành Phẩm (COnstruction COst MOdel)

Mô hình COCOMO, một phương pháp ước lượng do Boehm đề xuất, phù hợp với việc ước lượng cá hệ thống cỡ trung và lớn

Với mô hình COCOMO, hệ thống được phân lớp dựa trên ba mô hình: cỡ nhỏ, cỡ bình thường, cỡ lớn Sau đó từng mô hình, nhân lực phát triển tổng cộng

và thời kỳ phát triển được tính toán từ số các câu lệnh được dự kiến vào lúc hệ thống được trao cho người dung

Phương pháp dựa trên mô hình Use Case Point (UCP- điểm trường hợp sử dụng)

Với phương pháp UCP, từng trường hợp sử dụng UC được đưa vào trong

hệ thống sẽ được diễn đạt định lượng bằng một phương pháp nào đó, và do vậy

dữ liệu được biểu diễn theo định lượng được dùng như cách đo ước lượng Phương pháp này gần như tương tự với phương pháp FP ở trên nhưng khác ở chỗ sử dụng các Use Case Point như là những đơn vị cơ bản nhất để đo lường và đánh giá Use Case là đơn vị cơ sở và cơ bản thể hiện các trường hợp sử dụng được mô tả lại dưới dạng tài liệu nhằm thỏa mãn và thống nhất cách thức hoạt động của nó trong các trường hợp cụ thể Use Case là thành phần không thể thiếu đối với các hệ thống phân tích thiết kế hướng đối tượng

1.5 Tổ chức phát triển

Có nhiều điểm đóng góp cho sự thành công của việc phát triển hệ thống,

kể cả các khoản mục liên quan tới quản lý công việc đa dạng như sau:

 Sự tham gia tích cực của người dùng (thiết lập tổ chức phát triển);

 Quản lý tiến trình kỹ lưỡng và quản lý tiến trình của công việc từng người;

 Quản lý chất lượng hệ thống kỹ lưỡng

Việc phát triển hệ thống quy mô lớn cần thời gian phát triển lâu (đôi khi nhiều năm), và đòi hỏi số tiền và tài nguyên nhân lực rất lớn

Tuy nhiên, không phải bi quan rằng việc phát triển hệ thống thất bại trong giai đoạn lập kế hoạch cơ sở hay giai đoạn thiết kế hay việc phát triển được hoàn tất nhưng chất lượng lại quá nghèo nàn không dùng được trong vận hành thực tế

Một cách tự nhiên, công việc phát triển được quản lý bởi một người quản

lý, chẳng hạn, người quản lý dự án Tuy nhiên, việc quản lý đúng công việc của riêng từng thành viên phát triển và tạo ra đầu ra chất lượng cao là nhân tố quan trọng dẫn đến việc phát triển hệ thống tới thành công

Điều quan trong thứ nhất để đưa việc phát triển hệ thống tới thành công là thiết lập một tổ chức phát triển vững chắc Làm tiến độ công việc đúng theo lịch phát triển hệ thống (lịch mức cao nhất) đã tạo ra trong giai đoạn lập kế hoạch cơ

sở là điều tiên quyết lớn nhất cho sự thành công Hơn nữa, liệu công việc có tiến hành trôi chảy hay không cũng có thể được nói là tùy thuộc phần lớn vào công việc hợp tác của các thành viên lực lượng lao động

1.5.1 Các phong cách tổ chức

Kiểu phong cách tổ chức phát triển nào nên được dùng còn tùy theo quy

mô phát triển hay những người nào là nòng cốt của đội phát triển Tuy nhiên, sự tham dự của người dùng là không thể thiểu được trong bất kỳ tổ chức nào Trong nhiều việc phát triển hệ thống thành công, tổ chức của người dùng tham dự vào việc lập kế hoạch cở sở và thiết kế ngoài

Hơn nữa việc phát triển hệ thống thường xuyên được tiến hành trong sự hợp tác với các công ty phát triển bên ngoài Chẳng hạn, việc bắt đầu cho giai đoạn thiết kế được thực hiện nội bộ, còn việc lập trình thì thuê khoán ngoài với các công ty khác

Ví dụ về tổ chức phát triển dưới đây chỉ ra một tổ chức cho một dự án quy

mô nhỏ, trong khi hình tiếp theo nêu ra một tổ chức cho dự án quy mô lớn

Ví dụ: dự án quy mô nhỏ:

Trao đổi

1.5.2 Tổ chức phát triển

Tổ chức phát triển nhận các yêu cầu hệ thống hóa từ người dùng và tiến hành công việc về lập kế hoạch cơ sở, các kiểu thiết kế, lập trình và các kiểu kiểm thử Gần đây, trong nhiều trường hợp các tổ dự án nội bộ thực hiện công việc về lập kế hoạch cơ sở và thiết kế, còn lập trình và kiểm thử được ủy quyền cho các

Hình 1.5.1: Sơ đồ tổ chức dự án quy mô nhỏ

Hình 1.5.2: Sơ đồ tổ chức dự án quy mô lớn

Có 3 kiểu tổ dự án điển hình đó là: Tổ người lập trình chính, Tổ chuyên gia,

Tổ phân cấp

 Tổ người lập trình chính:

Tổ người lập trình chính là một tổ dự án bao gồm một số tương đối nhỏ tối

đa mười thành viên, với người lập trình chính có hoàn toàn trách nhiệm thực hiện quyền lãnh đạo trong việc phân bổ công việc cho từng thành viên một cách rõ ràng và làm tăng năng suất và chất lượng

Người lập trình chính

Người lập trình dự phòng

Hình 1.5.3: Sơ đồ tổ chức Người lập trình chính

Người lập trình chính

Chuyên gia ngôn ngữ

Chuyên gia tài liệu

Chuyên gia Kiểm Thử

Chuyên gia Phân

Chuyên gia Chất lượng

 Tổ phân cấp: bao gồm một người quản lý dự án, nhiều người lãnh đạo

Thành viên Thành viên Thành viên

Hình 1.5.5: Sơ đồ tổ chức Tổ phân cấp Hình 1.5.4: Sơ đồ tổ chức Tổ chuyên gia

Kiểu tổ chức này được sử dụng rộng rãi ở Nhật :

 Nó được chấp nhận trong việc phát triển phần mềm quy mô tương đối lớn

 Trao đổi trở nên kém thích hợp hơn, nếu só với tổ người lập trình chính

Vai trò của các thành viên trong tổ chức

 Người chịu trách nhiệm tổ chức phát triển (người quản lý dự án):

Trong nhiều trường hợp người chịu trách nhiệm của tổ chức phát triển trở thành người quản lý dự án Người quản lý, tại một vị trí quan trọng, hoàn toàn chịu trách nhiệm cho dự án phát triển

Người quản lý dự án không chỉ có kỹ năng công nghệ thông tin mức cao,

mà còn phải có khả năng quản lý dự án và khả năng lập kế hoạch Thêm vào đó, việc duy trì trao đổi đúng đắn bên trong công ty và với các bên ở ngoài công ty là một vai trò quan trọng của người quản lý

Người quản lý dự án có vai trò:

 Lập kế hoạch, soạn thảo kế hoạch, thực hiện và ước lượng dự án

 Trao đổi với người dung và các tổ chức có liên quan (kể cả bên trong và bên ngoài công ty)

 Tạo nguồn lực cho công việc và dự án (kể cả việc triển khai nhân sự và tạo quyền lực)

 Công việc quản lý khác

 Người lãnh đạo dự án:

Người lãnh đạo dự án đóng vai trò phân bổ người quản lý dự án, đặt hoạt động tổ chức nhóm vào trật tự, hay hành dodọng như người đứng giữa các thành viên phát triển và người quản lý dự án

Một tổ chức được người lãnh đạo điều khiển được gọi là nhóm dự án con, thực hiện công việc phát triển thực tại hay công việc hỗ trợ phát triển (kỹ thuật kiểm thử, chuẩn hóa hay các công việc khác)

Được chỉ dẫn bởi người lãnh đạo dự án, các thành viên phát triển thực hiện các công việc phát triển thực tế (thiết kế, lập trình, ) hay công việc hỗ trợ phát triển

 Người chịu trách nhiệm của tổ chức người dùng

Người chịu trách nhiệm của tổ chức người dùng có quyền lớn nhất trong mọi giai đoạn từ khía cạnh ngân sách tới việc thúc đẩy dự án phát triển hệ thống hiện đại Với người chịu trách nhiệm của tổ chức người dùng, người đó cũng được yêu cầu rằng người đó phải làm nỗ lực tối đa để làm tăng tỉ lệ hiệu quả - đầu tư bằng việc thực hiện nhiều kế hoạch khác (như tổ chức các khoá huấn luyện) như người lãnh đạo

 Tổ chức khởi xướng phát triển

Tổ chức khởi xướng phát triển được tổ chức với những người có trách nhiệm (những người ở vị trí quản lý) trong tổ chức người dùng làm cốt lõi, và đưa

ra sự chấp thuận các đầu ra từ việc phát triển hệ thống Tuy nhiên điều đó không liên quan tới chi tiết hệ thống

 Người dùng

Người dùng thực tế sử dụng hệ thống Vậy nên khi người dùng tham gia vào việc phát triển hệ thống cho lời khuyên về nhiều hoạt động đa dạng Do đó, người dùng tham gia nên quen các tiến trình nghiệp vụ

1.6 Kết luận

Chương này đã trình bày những phần quan trọng nhất trong quá trình quản

lý quá trình phát triển dự án, một trong những nhân tố quan trọng nhất mang lại thành công cho dự án Việc đề cập đến những lý thuyết cơ bản nhất trong quá trình quản lý phát triển dự án như: Lập kế hoạch dự án, quản lý kế hoạch và đánh giá chất lượng, quản lý tiến trình, năng suất phần mềm và tố chức phát triển đã đem đến cài nhìn rõ hơn về những lý thuyết cơ bản liên quan đến quá trình vận hành phát triển dự án trong thực tế

CHƯƠNG 2 LÝ THUYẾT CHẮC CHẮN

2.1 Tổng quan về lý thuyết chắc chắn

Các chuyên gia thường đánh giá, suy xét khi giải quyết vấn đề Thông tinh

về vấn đề có thể không đầy đủ và một vài tri thức có thể không xác thực Do vậy

mà họ cần thích nghi với tình trạng này và tiếp tục lập luận thông minh Đây chỉ là một trong các khó khăn thôi, vì việc quản lý lập luận không chính xác cũng không

dễ dàng

Người ta có thể dùng lý thuyết xác suất Dù rằng chặt chẽ về toán học, kĩ thuật này đòi hỏi cơ sở thống kê mà ít loại bài toán trong hệ chuyên gia đáp ứng được Chẳng hạn khi xác định người bệnh có đau nặng hay không, người ta thu được kết luậnvới tin cậy 0.7 Do thiếu cơ sở thống kê nene những thông tin để giúp phán đoán không dùng được trong các luật của hệ chuyên gia mà chỉ dùng

để giải thích; và vì vậy không thể suy luận xác suất bằng kỹ thuật Bayes được

Tuy nhiên nếu xem hệ chuyên gia như cơ chế giải vấn đề may rủi thì người

ta có thể dùng các kỹ thuật lập luận không chính xác như trong MYCIN

2.1.1 Lập luận không chính xác trong MYCIN

MYCIN là hệ chuyên gia được phát triển để cho lời khuyên khi chẩn đoán các bênh nhân nhiễm trùng máu Đây là bài toán điển hình trong nhiều lĩnh vực, những bệnh nhân có ý nghĩa đặc biệt trong lĩnh vực y học do các rang buộc về thời gian Trong phòng cấp cứu cần thiết có các hành động đúng và nhanh Đối với các bệnh đe dọa đến tính mạng, thầy thuốc có thể tiến hành các xét nghiệm trước đó để có các thông tin đầy đủ và chính xác Nhưng đối với ca cấp cứu, các bác sĩ buộc phải xử lý với tình trạng thông tin không chính xác Nhưng đối với ca cấp cứu, các bác sĩ buộc phải xử lý với tình trạng thông tin không chính xác và phải có chẩn đoán tốt nhất

Về suy luận không chính xác trong lĩnh vực y học, người ta thấy có nhiều luật không chính xác Một số ít luật có thể giúp chẩn đoán tốt cho ca bệnh, nhưng những luật này ít được dùng đến Phần lớn các luật dùng trong y học ở dạng không chính xác Chẳng hạn thầy thuốc phát biểu: „ Nếu thấy triệu chứng A và B thì có vài chỉ định liên quan đến bệnh này, bệnh nọ‟

Nhóm MYCIN ghi nhận rằng kỹ thuật lập luận không chính xác cần được tích hợp vào hệ thống Họ cũng thấy được tính không phù hợp của tiếp cận xác suất vì không đáp ứng được các thông tin thống kê về vấn đề Để quản lý tình trạng này, nhóm MYCIN quyết định nới lỏng các yêu cầu chặt chẽ của kỹ thuật xác suất cổ điển và tìm tiếp cận đơn giản hơn Trước tiên họ quyết định đặt các câu hỏi liên quan đến điều họ muốn kỹ thuật lập luận không chính xác thực hiện, chứ không hỏi về cách thức thực hiện Họ cảm thấy việc quan sát các chuyên gia làm trên thông tin không chính xác sẽ nhìn thấu đủ để phát triển các yêu cầu kỹ thuật của kỹ thuật lập luận không chính xác

2.1.2 Thể hiện dấu hiệu không chắc chắn

Nhóm MYCIN quan sát thấy thầy thuốc làm việc với ca cấp cứu thường dùng thông tin không chắc chắn, thậm chí không rõ Họ ghi nhận rằng dưới điều kiện như vậy, thầy thuốc thường phân tích thông tin sẵn có với thuật ngữ định tính như „có thể‟, „ có vẻ như‟, „ hầu như chắc chắn rằng ‟

Đối với dấu hiệu không chắc chắn, nhóm MYCIN quyết định gán một nhân

tố chắc chắn „CF‟ để thể hiện độ tin cậy của thầy thuốc vào dấu hiệu đó Số này chạy từ -1, ứng với sai hoàn toàn, đến +1, ứng với đúng hoàn toàn Số dương thể hiện sự tin cậy, số âm thể hiện sự không tin cậy Chẳng hạn thầy thuốc phát biểu rằng dấu hiệu nào đó có thể đúng, thì giá trị CF=0.6 được gán cho dấu hiệu đó

2.1.3 Thể hiện các luật không chắc chắn

Nhóm MYCIN cũng quan sát thấy các thầy thuốc thường dùng suy luận không chính xác trên các thông tin có sẵn Tức là thầy thuốc chỉ tin một phần vào

sự suy xết trên dấu hiệu nào đó Đối với suy luận không chính xác, cần gán giá trị

CF cho mỗi luật

Ví dụ: Có luật: IF có dấu hiệu thương tổn AND hình thái khuẩn cầu AND hình thể trên vết thương là chuỗi THEN chỉ định bị khuẩn cầu chuỗi với CF=0.7

Nếu kết luận chỉ phụ thuộc một phần vào một trong các giả thiết trong luật thì CF có thể dùng cho riêng giả thiết đó Khi đó luật có dạng IF E1 AND E2 AND AND En THEN H CF=CFi

2.1.4 Suy luận không chắc chắn

Người ta cũng thấy rằng khi độ tin cậy của thầy thuốc vào dấu hiệu đang có

là nhỏ hơn sự chắc chắn thì độ tin cậy này trong suy luận liên quan cũng giảm đi Chẳng hạn luật đầu tiên kết luận về việc chỉ ra tổ chức bị viêm dạng hạt, người ta dùng giả thiết không chắc chắn, CF (Ei)<1 và mức độ tin cậy trong kết luận giảm,

CF (H)<0.7 Hệ thống MYCIN áp dụng suy luận không chắc chắn theo kỹ thuật này

2.1.5 Tổ hợp dấu hiệu từ nhiều nguồn

Khi thầy thuốc nhận thông tin trợ giúp để kết luận từ nhiều nguồn, người ta thấy rằng kết luận có độ tin cậy lớn hơn Do vậy lý thuyết chắc chắn cần tăng độ tin cậy về kết luận khi nhận trợ giúp từ nhiều luật:

Ví dụ:

Luật R1 IF A AND B THEN Z CF=0.8

Luật R2 IF C AND D THEN Z CF=0.7

Cả hai luật đều kết luận về sự kiện Z, nhưng với giá trị CF khác nhau Nếu hai luật đều chạy thì người ta thu được hai độ tin cậy về Z Ở đây người ta cần kết hợp hai luật, tức kết hợp hai nhận đinh „có khả năng‟ và „ có thể‟

Trong MYCIN, thay vì dùng công thức người ta quyết định hỏi Sau đó người ta không dùng công thức chính xác mà áp một số thuộc tính để công thức phải thỏa mãn trong một số trường hợp Hai thuộc tính được chọn là tráo đổi và tiệm cận

Thuộc tính tráo đổi quan trọng ở chỗ tránh được sự phụ thuộc về thứ tự áp dụng luật Chẳng hạn khi có hai luật có cùng độ tin cậy về quyết định cuối cùng, thì áp dụng luật nào đầu tiên cũng như vậy Còn thuộc tính tiệm cận cho phép tổ hợp theo nghĩa tiệm cận về kết luận hợp lý, trừ khi người ta có giải pháp đưa ra lời giải đúng Với cách làm này, kết luận sẽ có độ tin cậy tăng từng phần

2.1.6 Độ tin cậy thực

Thông thường thày thuốc sẽ cân đối độ tin cậy về giả thuyết cho cả dấu hiệu dương tính và dấu hiệu âm tính Tùy theo trường hợp mà dấu hiệu được chấp nhận hay bị loại Vấn đề đặt ra là độ tin cậy thực là bao nhiêu?

Đối với trường hợp này, MYCIN quyết định tạo độ tin cậy thực trong giả thuyết của luật Trước hết người ta tập hợp tất cả thông tin trợ giúp và gọi nó là độ

đo tin cậy MB (measure of belief) trong giả thuyết Việc tập hợp tiến hành theo cách hoán đổi và tiệm cận Tiếp theo, các thông tin loại bỏ giả thuyết được tập hợp lại theo cách tiệm cần và hoán đổi và gọi là độ đo không tin MD (measure of disbelief) Độ tin cậy thực hay CF trong giả thuyết được tính bằng độ lệch giữa hai giá trị độ đo này

Ví dụ: Một vài thông tin hô trợ giả thuyết với độ MB (H)=0.8 trong khi dấu hiệu khác loại trừ H cho giá trị MD (H)=0.2 Trong trường hợp này, độ tin cậy thực

về H được tính CF (H)=0.8-0.2=0.6 Lúc này H được xem là có khả năng đúng

2.1.7 Cơ sở của lý thuyết chắc chắn

Phần trên đã nêu lên sự cần thiết về mô hình chắc chắn Nhu cầu này sinh

ra một cách tự nhiên khi thầy thuốc quản lý thông tin không chính xác Dù vậy nhưng cần khẳng định rằng mô hình này không hoàn toàn dựa vào lý thuyết xác suất mà chỉ theo lý thuyết này khi thành lập mô hình

Lý thuyết chắc chắn giải thiết rằng xác suất trước của giả thuyết H, p (H) thể hiện độ tin cậy được giám định của chuyên gia về H Độ không tin cậy p (~H)=1 Ngoài ra còn giả thiết rằng nếu chuyên gia quan sát dấu hiệu thấy: xác suất về giả thuyết có dấu hiệu (tức là xác suất có điều kiện p (H|E)) lớn hơn xác suất trước (tức p (H)), tức là p (H|E)>p (H) đúng, thì độ tin cậy của chuyên gia về giả thuyết tăng tỉ lệ thuận đến (p (H|E)-p (H))/ (1-p (H))

Mặt khác nếu p (H|E)<p (H) thì độ tin cậy của chuyên gia về giả thuyết sẽ giảm tỉ lệ thuận về (p (H)-p (H|E))/p (H)

Cái chính của lý thuyết này là khi có một chút dấu hiệu, độ tin cậy của chuyên gia về giả thuyết có thể tăng hay giảm chút ít Ý này được phát triển gắn với độ đo MB và MD

 Độ đo tin cậy MB giá trị bằng số thể hiện độ tin cậy tăng lên về giả thuyết

H dựa trên dấu hiệu E

 Độ đo không tin cậy MD giá trị bằng số thể hiện độ không tin tăng lên vè giả thuyết H dựa trên dấu hiệu E

Các giá trị này thỏa mãn 0≤MD,MD≤1 Chúng được xác định hình thức theo xác suất trước có điều kiện theo các công thức MB (H,E)=1 nếu p (H)=1

Ngược lại thì MB (H,E)= (max{p (H|E),p (H)}-p (H))/ (1-p (H))

MD (H,E)=1 nếu p (H)=0

Ngược lại thì MD (H,E)= (min{p (H|E),p (H)}-p (H))/ (-p (H))

Do người ta quan sát một vài thông tin, thông tin này làm thay đổi độ tin cậy hay độ không tin vào giả thuyết cho nên người ta kết hợp hai giá trị trên vào giá trị

độ tin cậy chung, CF=MB-MD; -1≤CF≤1

 Nhân tố tin cậy (Certainty Factor-CF) giá trị bằng số thể hiện mức độ tin cậy thực vào giả thuyết khi có thông tin

Giá trị -1 của CF thể hiện „sai chắc chắn‟ và +1 thể hiện „đúng chắc chắn‟ giá trị 0 cho biết „không biết‟, giá trị âm thể hiện độ không tin vào giả thuyết trong khi giá trị dương ngược lại

Không có thể

Có thể Không biết

Tùy theo tình huống thực tế, cố một số trường hợp điển hình xảy ra như sau:

 Trường hợp 1 Dấu hiệu khẳng định hoàn toàn giả thuyết

 Nếu dấu hiệu đã có E khẳng định hoàn toàn giả thuyết H thì p (H|E)=1

Do vậy MB (H,E)=1, MD (H,E)=0, và tính được CF (H,E)=1 Do vậy khi E hoàn toàn xác định H, theo sơ đồ về giá trị CF thì H là đúng chắc chắn

 Trường hợp 2 Dấu hiệu hoàn toàn không xác định giả thuyết Khi p (~H|E)=1 thì p (H|E)=1-p (~H|E)=0 Vậy MB (H,E)=0, MD (H,E)=1 nên tính được CF (H,E)=-1, tức H sai chắc chắn

 Trường hợp 3 Thiếu dấu hiệu Nếu dấu hiệu đã có E là độc lập với giả thuyết thì không khẳng định hay phủ nhận được H, tức p (H|E)=p (H) Theo công thức tính MB, MD thì MB (H,E)=MD (H,E)=0, vậy tính được

CF (H,E)=0 Trường hợp này có nghĩa nếu H và E độc lập thì H được xem như không biết

Hình 2.1.1: Giá trị của nhân tố tin cậy CF

 Trường hợp 4 Dấu hiệu dương Nếu dấu hiệu đã có E xác định một phần giả thuyết H thì p (H)<p (H|E)<1 và tính các độ đô theo MB (H,E)= (p (H|E)-p (H)); MD (H,E)=0 Do đó CF (H,E)=MB (H,E)

 Vậy khi E xác định H một phần thì theo sở đồ CF, CF (H,E) thuộc miền dương, tức miền tin cậy vào giả thiết H

 Trường hợp 5 Dấu hiệu âm Nếu dấu hiệu đã có E không xác định một phần giả thuyết H thì 0<p (H|E)<p (H) Do vậy MB (H,E)=0 và MD (H,E)= (p (H)-p (H|E))/p (H)

 Vậy CF (H,E)=-MD (H,E) Do vậy khi E không xác định từng phần giả thuyết H thì CF (H,E) thuộc miền âm trong sơ đồ CF

 Trường hợp 6 Nguồn mang nhiều khẳng định nhưng cũng có điều không khẳng định

Theo nhiều nguồn xác định giả thuyết thì giá trị MB sẽ hội tụ đến 1, tức MB (H,E1,E2, )-> Nhưng nếu có một nguồn phủ đinhk giả thuyết này thì có I để MD (H,Ei)>0, chẳng hạn MD (H,Ei)=0.8 Giả sử MB (H,E1,E2, )=0.999 thì CF (H,E)=0.199 Trong thực tế điều này không phù hợp; nhiều điều khẳng định đã bị một điều áp đảo và giá trị tin cậy về H quá thấp Người ta xử lý trường hợp này bằng cách sử dụng cách tính CF (H,E)= (MB (H,E)-MD (H,E))/ (1-min{MB (H,E),MD (H,E)})

Trong thí dụ này người ta thu được CF (H,E)=0.995 Cách tính này có tác dụng ngược lại so với cách tính trước; nó giảm tác dụng của một số nhỏ ý kiến trái ngược

Trong hầu hết các vấn đề, việc đánh giá CF nhờ các chuyên gia không phải

là dễ dàng Việc dùng CF thực chất thay cho độ đo p (H) và p (H|E)

2.2 Nhân tố chắc chắn dưới khía cạnh xác suất

Nhiều năm qua, mô hình chắc chắn đã phát triển thành kỹ thuật thực tế để quản lý lập luận không chính xác trong hệ chuyên gia Tuy các khái niệm về MB,

MD và CF vẫn được sử dụng, nhưng mới ở mức đơn giản Sau đây là dạng sử dụng hiện thời của mô hình chắc chắn

2.2.1 Dấu hiệu không chắc chắn

Các hệ thống dùng lập luận không chính xác cần có cách thể hiện các dấu hiệu không chắc chắn Chẳng hạn „ hôm nay có khả năng mưa‟ là câu có độ không chắc chắn do „ có khả năng…‟

 Các luật không chắc chắn:

CF dùng cho câu và cho cả các luật để thê hiện quan hệ không chắc chắn giữa dấu hiệu E trong giả thuyết của luật gia và giả thuyết H trong phần kết luận của luật Cấu trúc cơ bản của luật dùng trong mô hình chắc chắn có dạng IF E

2.2.2 Lan truyền chắc chắn đối với các luật có giả thiết đơn

Lan truyền nhân tố chắc chắn liên quan đến việc thiết lập mức độ tin cậy vào kết luận của luật trong trường hợp dấu hiệu trong giả thiết là không chắc chắn Đối với luật có phần giả thiết đơn, người ta tính CF (H,E)=CF (E)*CF (luật)

Theo ví dụ trên nhưng có dấu hiệu thuận về E, tức CF (E)=0.5 thì CF (H,E)=0.5*0.8=0.4 Điều này có nghĩa „Có thể mưa‟ Nếu người ta có dấu hiệu không thuận về E, tức CF (E)=-0.5 thì CF (H,E)=-0.4; có nghĩa „có thể không mưa‟

Ví dụ cho thấy dấu hiệu bổ sung tính tin cậy hay không tin cậy về một giả thiết

2.2.3 Lan truyền chắc chắn đối với các luật nhiều giả thiết

Trong trường hợp luật có nhiều giả thiết, nhân tố chắc chắn đối với kết luận của luật được lập luận theo cách tương tự như cách dùng trong hệ thống PROSPECTOR Như nhóm MYCIN thì người ta giả sử có độc lập điều kiện của dấu hiệu theo dạng AND hay OR khi xét độ tin cậy vào giả thiết

2.2.3.1 Các luật AND

Mô hình chắc chắn dùng các luật có dạng

IF E1 AND E2 AND … AND En THEN H CF (luật)

CF (H,E1 AND…AND En)=min{CF (Ei)}*CF (luật)

Ví dụ

IF trời tối AND gió mạnh dần THEN sẽ mưa CF=0.8

Giả thiết rằng CF (trời tối)=1.0 và CF (gió mạnh dần)=0.7 thì

CF (sẽ mưa)=min{1.0,0.7}*0.8=0.56; có nghĩa „có khả năng mưa‟

2.2.3.2 Các luật OR

Các luật trong mô hình này có dạng

IF E1 OR E2 OR En THEN H CF (luật)

CF (H,E1 OR E2 OR…OR En)=max{CF (Ei)}*CF (luật)

Ví dụ IF trời tối OR gió mạnh dần THEN sẽ mưa CF=0.9

Giả thiết rằng CF (trời tối)=1.0và CF (gió mạnh dần)=0.7 thì

CF (sẽ mưa)=max (1.0,0.7Ư*0.9=0.9; có nghĩa là „hầu như chắc chắn là mưa‟

2.2.4 Lan truyền chắc chắn đối với các luật có cùng kết luận

Trong một vài ứng dụng người ta có thể viết nhiều luật về cùng một kết luận Chẳng hạn để tin rằng trời sắp mưa, người ta căn cứ vào ý kiến của nhà dự báo khí tượng hay vào nông dân

 Luật 1 IF nhà dự báo nói sắp mưa, E1 THEN sắp mưa, H với CF (luật 1)=0.8

 Luật 2 IF nông dân nói sắp mưa, E2 THEN sắp mưa, với CF (luật 2)=0.8

Hai luật dựa trên hai nguồn, có cùng giá trị CF Về tâm lý thì khi có nhiều nguồn khẳng định một kết luận, người ta sẽ cảm thấy tin tưởng hơn, chẳng hạn tin hơn vào trời sẽ mưa nếu được khẳng định của cả dự báo thời tiết và nông dân Nhóm MYCIN dùng ý tưởng này trong kỹ thuật „dấu hiệu thu thập nhiều lên‟ để kết hợp các giá trị tin cậy và phản bác của các luật về cùng một kết luận

Chẳng hạn có luật 1: IF E1 THEN H và luật 2

IF E2 THEN H, dạng nguyên bản của đẳng thức dùng trong kỹ thuật này

do Shortlife và Buchanan đưa ra năm 1975 là:

 MB (H,E1&E2)=0 nếu MD (H,E1&E2)=1, hoặc

MB (H,E1&E2)=MB (H,E1)+MB (H,E2)* (1-MB (H,E1) nếu ngược lại

 MD (H,E1&E2)=0 nếu MB (H,E1&E2)=1, hoặc

MD (H,E1&E2)=MD (H,E1)+MD (H,E2)* (1-MD (H,E1)) nếu ngược lại

Các đăng thức khẳng định rằng các dấu hiệu bổ sung E2 sẽ làm tăng các giá trị do dấu hiệu E1 đã xác định Các MD và MB được cập nhất sẽ cho phép tính nhân tố tin cậy theo CF=MB-MD

Trong một vài ứng dụng, nên tính đến MD và MB như các trợ giúp thêm khi

có thêm thông tin Nhưng trong vài ứng dụng khác, người ta chỉ quản lý một bản ghi về giá trị CF được cập nhật Đối với các ứng dụng này, người ta có thể dùng đẳng thức

CF (kết hợp)=CF1+CF2 (1-CF1) khi cả 2 CFi là dương

CF (kết hợp)=CF1+CF2 (1+CF1) khi cả 2 CFi là âm; và

CF (kết hợp)= (CF1+CF2)/ (1-min{|CF1|,|CF2|}),trong đó CFi thê hienẹ tin cậy vào H theo luật thứ i

Các đẳng thức tính MD,MB và CF trong mô hình chắc chắn có thuộc tính hoán đổi tiệm cận

2.2.4.1 Hoán đổi

Tính chất hoán đổi cho phép thay đổi trật tự sử dụng luật Mô hình chắc chắn cần tính chất này để thu thập các dấu hiệu theo trật tự tùy ý Tức là nếu có nhiều luật thu thập thông tin thì giá trị tổng hợp CF không bị lệ thuộc vào thứ tự xử

lý luật

2.2.4.2 Tiệm cận

Tính chất tiệm cận khẳng định tri thức càng được thu thập sẽ càng làm đúng giả thuyết Người ta cần tính chất tiệm cận bởi hai lí do Trước hết nó phản ánh cách mà thầy thuốc thu thập độ tin cậy về giả thuyết nào đó từ nhiều nguồn thông tin Trong số nhiều nguồn khẳng định giả thuyết thì người ta cảm thấy tin ở một nguồn nào đó, và ứng với nó là độ tin cậy cao hơn Thứ hai, tính chất này đảm bảo tổng hợp các độ tin cậy không vượt quá 1, mà chỉ tiệm cận về 1

Giả sử tiếp tục hai luật trên về dự báo mưa Người ta thấy có các trường hợp xảy ra như sau:

Trường hợp này cho biết cách tăng nhân tố chắc chắn nhờ dấu hiệu của cả hai luật đối với cùng một giả thuyết Thực tế cũng cho thấy khi có nhiều khẳng định thì người ta tin tưởng hơn

 Trường hợp 2

Nhà dự báo khẳng định mưa, còn người nông dân thì không Tức là

CF (E1)=1.0, CF (E2)=-1.0

CF1=CF1 (H,E1)=CF (E1)*CF (luật 1)=1.0*0.8=0.8

CF2=CF2 (H,E2)=CF (E2)*CF (luật 2)=-1.0*0.8=-0.8

CF1=CF1 (H,E1)=CF (E1)*CF (luật 1)=-0.8*0.8=-0.64

CF2=CF2 (H,E2)=CF (E2)*CF (luật 2)=-0.6*0.8=-0.48

CF này thể hiện độ tin cậy tổng hợp về mưa từ các nguồn thông tin cũ Nếu

có nguồn mới có độ tin cậy CFmới=-0.8 Theo công thức tính CF kết hợp:

CFkết hợp (CFcũ,CFmới)= (CFcũ+CFmới)/ (1-min{|CFcũ|,|CFmới|})=0.995

Kết quả cho thấy một dấu hiệu phản bác không tác động nhiều lắm so với nhiều dấu hiệu khẳng định

2.2.5 Lan truyền chắc chắn đối với các luật phức hợp

Một số ứng dụng có thể có các luật dùng dạng hỗ hợp AND và OR, chẳng hạn IF E1 AND E2 OR E3 AND E4 THEN H CF=CF (luật) Người ta quản lý lan truyền đối với các luật loai này bằng cách kết hợp cách tính đối với luật AND và luật OR, chẳng hạn luật trên có

CF (H)=max{min{CF (E1),CF (E2)},min{CF (E3),CF (E4)}}*CF (luật)

2.3 Ví dụ về nhân tố chắc chắn

Ví dụ này nhằm minh họa việc lan truyền các nhân tố chắc chắn Người ta cần biết thời tiết ra sao trước khi chơi bong Giả sử có giả thuyết „Mơ không chơi bong được‟ và tập các luật sau:

 Luật 1 CF (luật 1)=0.9 IF trời ảm đạm (sự kiện E1) OR Mơ buồn (sự kiên E2) THEN Mở không chơi bong (tức giả thuyết H)

 Luật 2 CF (luật 2)=0.8 IF Mơ tin là sắp mưa, E3 THEN trời ảm đạm, E1

 Luật 3 CF (luật 3)=0.9 IF Mơ tin là săp mưa, E3 AND nhà dự báo nói rằng sắp mưa, E4 THEN Mơ buồn, E2

 Luật 4 CF (luật 4)=0.7 IF nhà dự báo nói rằng sắp mưa, E4 THEN trời

ảm đạm, E1

 Luật 5 CF (luật 5)=0.95 IF nhà dự báo nói rằng sắp mưa, E4 THEN trời

ảm đạm, E1 THEN Mơ buồn, E2

Giả sử rằng người ta nhập vào các nhân tố chắc chắn ban đầu, ở dạng các

sơ khởi gồm:

 Nhà dự báo tin rằng sắp mưa, CF (E4)=0.85

 Mơ tin sắp mưa, CF (E3)=0.95

Ngoài ra giả sử theo hệ thống thực hiện suy luận quay lui, xuất phát từ đích H1 „Mơ không chơi bóng‟, và các luật được sử dụng hết

 Bước 1 Xét giả thuyết của luật 1 thấy „trời ảm đạm‟, E1 Các luật 2 và luật 4 đều kết luận về E1

 Bước 2 Xét luật 2 Có nhận xét ở đây: hệ thống xét luật này trước tiên vì nó

có giá trị cao hơn luật 4 Theo đẳng thức đã có, CF (E1,E3)=CF (E3)*CF (luật 2)=0.95*0.8=0.76

 Bước 3 Xét luật 4 Cf (E1,E4)=CF (E4)*CF (luật 4)=0.85*0.7=0.6

 Bước 4 Có hai khẳng đinh đối với E1, tức „trời ảm đạm‟ từ bước 2 và 3 Người ta kết hiựp chúng theo tiếp cận làm tăng các dấu hiệu

 CF (E1)=CF (E1,E3)+CF (E1,E4)* (1-CF (E1,E3))=0.76+0.6* (1-0.76)= 0.9

 Bước 5 Xét giả thiết 2 trong luật 1 „Mơ buồn‟, tức E2 Lưu ý luật 3 và luật 5 kết luận về E2

 Bước 6 Xét luật 5 Nhận xét rằng hệ thống dùng luật này trước do có CF cao hơn

 CF (E2,E1)=CF (E1)*CF (luật 5)=0.9*0.95=0.86

 Bước 7 Xét luật 3 CF (E2,E3, AND E4)=min{CF (E3),CF (E4)}*CF (luật 3)=min{0.95,0.85}*0.9=0.77

 Bước 8 Người ta có hai khẳng đinh đối với E2, „ Mơ buồn‟ từ bước 6 và 7 Lại dùng tiếp cận tăng dấu hiệu, người ta có:

 CF (E2)=CF (E2,E1)+CF (E2,E3 AND E4)* CF (E2,E1))=0.86+0.77* 0.86)=0.97

(1- Bước 9 Quay lại luật 1 CF (H1,E1 OR E2) =max{CF (E1),CF (E2)}* CF (luật 1) =max{0.9,0.97}*0.9=0.87 Đó chính là CF (Mơ không chơi bóng)

2.4 Kết luận

Lý thuyết chắc chắn đảm bảo tiếp cận thực tế cho lý thuyết xác suất trong việc quản lý lập luận không chính xác trong hệ thống chuyên gia Nó dựa trên các giá trị tin cậy và phù hợp với các bài toán không nhiều dữ liệu thống kê Mặc dù thiếu nền tảng hình thức, kỹ thuật này cung cấp cho người ta một cách đơn gian

và trong nhiều ứng dụng có thể thu được kết quả chấp nhận được

Phần trên đã đề cập các nội dung sau:

 Lý thuyết chắc chắn cung cấp tiếp cận kiểm chứng các suy luận không chính xác

 „Độ đo tin cậy‟ MB là con số phản ánh mức độ tin cậy tăng về giả thuyết

H khi có dấu hiệu E

 „Độ đo phản bác‟ MD là con số phản ánh mức độ không tin vào H khi có dấu hiệu E

 „Nhân tố chắc chắn‟ CF là số phản ánh mức độ tinh về độ tin cậy vào H, CF=MB-MD

 Lý thuyết chắc chắn dùng các luật có dạng IF E THEN H CF (luật)

 Với các luật AND thì CF (H,E1 AND E2 AND )=min{CF (Ei)}*CF (luật)

 Với các luật OR thì CF (H,E1 OR E2 OR )=max{CF (Ei)}*CF (luật)

 Đối với trường hợp nhiều luật kết luận về một giả thuyết thì các giá trị CF được kết hợp lại theo kỹ thuật „thu thập thêm dấu hiệu‟

 Giá trị CF có thể được dùng để hướng dẫn tìm kiếm

 Giá trị CF cũng được dùng để chấm dứt quá trình tìm kiếm khi quá trình này không đáp ứng đích

 Các giả thuyết có thể được sắp xếp theo CF