Quản trị rủi ro kết hợp kỹ thuật trust case xây dựng các ứng dụng hướng dịch vụ

Với mục đích việc mô hình hoá một siêu mô hình mở rộng rủi ro chuyên dụng được định nghĩa, các mẫu rủi ro được đưa ra để biểu diễn rủi ro trong những giới hạn ngữ cảnh chính xác của quy

T¸c gi¶: Đặng Trung Nam QUẢN TRỊ RỦI RO KẾT HỢP KỸ THUẬT TRUST CASE XÂY DỰNG CÁC ỨNG DỤNG HƯỚNG DỊCH VỤ

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi

Kết quả nêu trong luận văn là trung thực và chưa từng được ai công bố trong bất kỳ công trình nào

Tác giả

Đặng Trung Nam

Mục lục

Trang phụ bìa

Lời cảm ơn

Lời cam đoan

Các hình vẽ trong luận văn 4

LỜI MỞ ĐẦU 5

Chương 1 Tổng quan 7

1.1 Rủi ro phần mềm 7

1.2 Rủi ro dịch vụ của hệ thống phần mềm 8

1.3 Quản trị rủi ro 9

1.4 Mô hình tổng quát tiến trình đánh giá rủi ro 11

1.5.Nhiệm vụ trong luận văn và cấu trúc 12

Chương 2 Phân loại rủi ro và mô hình cơ sở tri thức rủi ro 14

2.1 Phân loại rủi ro 14

2.1.1 Định nghĩa rủi ro tiến trình 14

2.1.2 Kỹ thuật biến đổi mô hình quy trình phần mềm mở rộng rủi ro (Risk – extended Software Process Engineering Metamodel) .18

2.1.3 Mô hình xử lý dựa trên việc xác định của sự kiện rủi ro 23

2.1.4 Các mẫu rủi ro (Risk Pattern) 23

2.1.5 Xây dựng các kịch bản rủi ro 24

2.1.5.1 Các kịch bản rủi ro đơn 25

2.1.5.2 Các tình huống rủi ro phức 26

2.2 Mô hình cơ sở tri thức rủi ro 26

2.2.1 Cấu trúc nội dung 28

2.2.2 Quản lý nội dung 30

2.2.2.1 Các hoạt động chung 30

2.2.2.2 Quản lý mô hình xử lý 31

2.2.2.3 Quản lý danh sách kiểm tra và danh sách rủi ro 31

2.3 Kết chương 32

Chương 3 Xác định và phân tích rủi ro dựa trên mô hình tiến trình 34

3.1 Xác định rủi ro 34

3.1.1 Độ đo của cấu trúc mô hình tiến trình 34

3.1.1.1 Các độ đo đối với tầm quan trọng phần tử mô hình 36

3.1.1.2 Các độ đo của rủi ro phần tử mô hình 37

3.1.1.3 Xác định rủi ro bằng các độ đo 38

3.1.2 So sánh các mô hình tiến trình 41

3.1.2.1 So sánh mô hình chính xác 41

3.1.2.2 So sánh mô hình đơn 42

3.1.2.3 Xác định và ghi lại các rủi ro 43

3.1.3 Kỹ thuật xác định rủi ro trong phát triển phần mềm hướng dich vụ 43

3.1.3.1 Lựa chọn các giá trị của người dùng đích 44

3.1.3.2 Xác định các dịch vụ của hệ thống 44

3.1.3.3 Xây dựng một ánh xạ của các kiểu thất bại dịch vụ 44

3.1.3.4 Xác định rủi ro 45

3.1.3.5 Nghiên cứu ứng dụng 46

3.2 Phân tích rủi ro 48

3.2.1 Các ảnh chụp nhanh rủi ro (Risk Snapshot) 48

3.2.2 Phân loại các kịch bản rủi ro 51

3.2.2.1 Kỹ thuật phân loại bởi các dấu hiệu rủi ro 51

3.2.2.2 Kỹ thuật phân loại các kịch bản rủi ro 52

3.3 Kết chương 54

Chương 4 Quy trình đánh giá rủi ro và kỹ thuật Trust Case trong đánh giá dự án CNTT 56

4.1 Các yếu tố trong quy trình đánh giá rủi ro 56

4.1.1 Các sản phẩm nhân tạo (Artifacts) 56

4.1.2 Các vai trò (Roles) 58

4.1.3 Các hoạt động (Activity) 59

4.2 Quy trình đánh giá rủi ro đơn 60

4.3 Quy trình đánh giá rủi ro liên tục 61

4.4 Sử dụng đánh giá rủi ro cho cải tiến quy trình phần mềm 62

4.5 Kỹ thuật Trust Case trong đánh giá dự án Công nghệ Thông tin 62

4.5.1 Khái niệm Trust Case 63

4.5.2 Mô hình tham số Trust Case 63

4.5.3 Các mô hình mẫu tham số Trust Case 66

4.5.4 Nghiên cứu kỹ thuật và phương pháp ứng dụng 69

4.5.4.1 Việc định vị các rủi ro an toàn và các yêu cầu bảo mật 70

4.5.4.2 Việc phát triển các lập luận 72

4.6 Nghiên cứu áp dụng thử nghiệm 73

4.7 Kết chương 75

KẾT LUẬN 76

Tài liệu tham khảo 78

Các hình vẽ trong luận văn

Hình 1: Quy trình cơ bản quản lí rủi ro 10

Hình 2: Mô hình tổng quát của phương thức PMRA 11

Hình 3: Kịch bản rủi ro trong ngữ cảnh đơn tiến trình 15

Hình 4: Kịch bản rủi ro thông qua nhiều tiến trình 16

Hình 5: Cấu trúc bên trong của kịch bản rủi ro trong một tiến trình với các tiến trình con .17

Hình 6: Các phần tử của mô hình xử lý quanh một hoạt động .21

Hình 7: Mô hình RiskSPEM 21

Hình 8: Lược đồ lớp cơ sở tri thức rủi ro 29

Hình 9: Mô hình GQM cho các số đo của cấu trúc mô hình tiến trình 36

Hình 10 Xây dựng các câu hỏi trợ giúp từ các cơ chế thất bại và các dịch vụ .45

Hình 11 Ngữ cảnh của một ảnh chụp nhanh rủi ro .49

Hình 12: Việc xây dựng ảnh chụp nhanh rủi ro thông qua việc kết hợp thông tin rủi ro 50

Hình 13 Mô hình Artifact của quy trình đánh giá rủi ro PMRA 57

Hình 14 Cấu trúc của một nhóm dự án 59

Hình 15 Vòng tròn đánh giá rủi ro 61

Hình 16: Mô hình tham số Trust Case 64

Hình 17: Tham số từ việc phân tich rủi ro 67

Hình 18: Các chi tiết của một Trust case với bằng chứng về việc giảm rủi ro an toàn .72

Hình 19 Phân tích cấu tạo bảo mật của PIPS ở mức cao 73

LỜI MỞ ĐẦU

Hệ thống thông tin được sử dụng hầu như ở khắp mọi nơi, bao gồm các ứng dụng liên quan đến an toàn và quyết định an toàn Thiết kế và thực thi các hệ thống như vậy đòi hỏi một sự quan tâm đặc biệt để xác định các tình huống nguy hiểm mà

có thể dẫn đến những rủi ro và tai nạn gây ra bởi một hệ thống trong môi trường của

nó, như việc triển khai các hệ thống dịch vụ liên quan đến lĩnh vực y tế, quân sự, giao thông… thường yêu cầu các nguyên tắc và các tiêu chuẩn về an toàn của hệ thống Vì vậy trong qui trình phát triển phần mềm, việc áp dụng các kỹ thuật quản trị rủi ro để phân tích và đánh giá các rủi ro có thể gây ra thất bại cho dự án đang ngày được phát triển

Với công việc liên quan đến phát triển phần mềm, qua luận văn tôi muốn tìm hiểu lý thuyết chung về quản trị Công Nghệ Thông Tin(CNTT), quản trị rủi ro trong

dự án xây dựng phần mềm và kỹ thuật Trust Case để áp dụng trong xây dựng các ứng dụng trên nền công nghệ Web, sử dụng kỹ thuật hướng dịch vụ

Mục đích chính trong luận văn là nghiên cứu lý thuyết chung về Quản trị Công nghệ Thông tin và tìm hiểu các kỹ thuât: Quản trị rủi ro trong phát triển phần mềm hướng dịch vụ; Kỹ thuật Trust Case trong đánh giá các dự án Công nghệ Thông tin

và nghiên cứu, xây dựng phương án kết hợp áp dụng hai kỹ thuật trong phát triển phần mềm hướng dịch vụ Thử nghiệm phương án đề xuất trong một số dự án tại Trung tâm Tin học Thống kê

Luận văn trình bày các vấn đề về cơ sở lý thuyết của kỹ thuật quản trị rủi ro trong dự án xây dựng phần mềm, bao gồm các vấn đề về Phân loại rủi ro, Mô hình

cơ sở tri thức rủi ro, Xác định và phân tích rủi ro và qui trình đánh giá rủi ro Trình bày kỹ thuật xác định rủi ro trong phát triển phần mềm hướng dịch vụ và nghiên cứu

ứng dụng Trình bày kỹ thuật Trust Case trong đánh giá dự án Công nghệ Thông tin: Các định nghĩa, mô hình tham số Trust Case, các mẫu tham số Trust Case và nghiên cứu kỹ thuật và phương pháp ứng dụng

Các đóng góp khoa học

- Về mặt nghiên cứu và tổng hợp lý thuyết: Tổng hợp các lý thuyết và áp dụng

về kỹ thuật quản trị rủi ro trong dự án phần mềm, kỹ thuật xác định rủi ro trong phát triển phần mềm hướng dịch vụ, kỹ thuật Trust Case trong đánh giá các dự án Công nghệ Thông tin

¾ Tổng hợp các lý thuyết về các kỹ thuật quản trị rủi ro trong phát triển dự

án phần mềm hướng dịch vụ và kỹ thuật Trust Case trong đánh giá các dự

án Công nghệ Thông tin

¾ Nghiên cứu các ứng dụng hướng dịch vụ áp dụng các kỹ thuật quản trị rủi

ro và kỹ thuật Trust Case trong phát triển phần mềm

- Về mặt triển khai thử nghiệm: Áp dụng thử nghiệm các kỹ thuật đã

nghiên cứu cho dự án Hệ thống Dịch vụ khai thác số liệu báo cáo kinh tế xã hội hàng tháng tại Trung tâm Tin học Thống kê, việc triển khai áp dụng đánh giá gồm:

• Rủi ro về an toàn,

• Rủi ro về bảo mật

Phương pháp nghiên cứu: Tìm hiểu, nghiên cứu dựa trên cơ sở các tài liệu được sưu tầm Trên cơ sở đó phân tích, tổng hợp các kỹ thuật, xây dựng phương án kết hợp và thử nghiệm phương án kết hợp trong một số dự án tại Trung tâm Tin học Thống kê

Chương 1 Tổng quan

Trong những năm gần đây, các dự án phần mềm liên tục cho thấy tỷ lệ thất bại cao, thậm chí xuất hiện còn nghiêm trọng hơn khi được so sánh với các ngành kỹ thuật khác như xây dựng hoặc các ngành cơ khí Việc thực hiện không thành công

từ các dự án phần mềm làm tăng nghiêm trọng sự lãng phí tiền bạc và thời gian, cũng như bỏ lỡ cơ hội kinh doanh và làm tăng sự nghi ngờ của xã hội về ứng dụng Công nghệ Thông tin Có nhiều phương pháp được đề xuất dưới một tiêu chí chung của quản trị rủi ro để tăng cơ hội thành công của các dự án Tuy nhiên, bằng chứng cho thấy hiện nay vẫn còn một khoảng cách lớn giữa những gì chúng ta đang có để

đề phòng rủi ro dự án và những gì chúng ta muốn có Việc nghiên cứu các phương thức cho đánh giá rủi ro dường như đặc biệt có giá trị Rủi ro là yếu tố luôn tồn tại trong mọi hoạt động sản xuất và kinh doanh, trong các dự án phần mềm cũng không ngoại lệ Tuy nhiên, với đặc thù riêng nên việc nhận diện và kiểm soát rủi ro trong các dự án phần mềm là không đơn giản Trong thực tế nhiều dự án đã bỏ qua hoặc kiểm soát rủi ro sơ sài, chiếu lệ dẫn đến kết quả thất bại, khách hàng phàn nàn về chất lượng hoặc lỗ vốn do chi phí tăng cao

Những hệ thống phần mềm lỗi đã dẫn đến một số tai nạn nghiêm trọng trong quá khứ và có khả năng tiếp tục là nguyên nhân của những tai nạn trong tương lai Có lẽ đáng chú ý nhất và tai nạn nổi tiếng với tên lửa Ariane 5, mà phát nổ ngay sau khi bắt đầu do một lỗi phần mềm điều khiển Thảm hoạ này và nhiều người đã cho thấy giải pháp phần mềm có thể đưa ra các kịch bản rủi ro với môi trường vận hành của chúng Các nghiên cứu và kiểm soát rủi ro ngày càng trở nên quan trọng về số lượng, mức độ và tính đa dạng ngày càng tăng nhanh của hệ thống phần mềm đưa vào vận hành mỗi ngày

1.1 Rủi ro phần mềm

Sự phát triển và ứng dụng phần mềm đặt cộng đồng vào nhiều mối đe doạ khác nhau Thứ nhất, sự thất bại của một dự án phần mềm như là công việc kinh doanh

của một doanh nghiệp dẫn đến lãnh phí của cải và thời gian cũng như bỏ lỡ một cơ hội kinh doanh Nguy cơ thất bại như vậy được gọi là rủi ro dự án phần mềm (rủi ro trong phát triển phần mềm, rủi ro dự án CNTT) Một đe doạ khác liên quan đến sự

an toàn của con người và môi trường Sự thất bại của một hệ thống phần mềm có thể dẫn đến tai nạn, mà trong trường hợp xấu có thể dẫn đến việc mất đi mạng sống của con người, điều này gọi là rủi ro an toàn phần mềm Sự đe doạ cuối cùng được cụ thể hoá khi một dịch vụ của hệ thống bị hỏng hoặc tài nguyên thông tin của hệ thống

bị tổn hại hay thao tác bất lợi dẫn tới tính toàn vẹn của hệ thống bị vi phạm thông qua một vài tác động có chủ ý của người tấn công, đe doạ này gọi là rủi ro bảo mật phần mềm

Những người dùng của hệ thống đã có trước một số giá trị, mà họ mong muốn các giá trị đó được bảo vệ Các giá trị khoá của người dùng là sự an toàn và bí mật của họ, việc mất đi các giá trị này ảnh hưởng tới người sử dụng cuối Từ quan điểm này, an toàn bảo mật không phải là tự bản thân giá trị của những người dùng mà là một tính năng của hệ thống, nó là một điều kiện quyết định mạnh mẽ cho hệ thống

đó để bảo vệ các giá trị người dùng thực như sự an toàn và sự bảo mật riêng Để bổ sung giá trị, một hệ thống phải duy trì ít nhất các giá trị của những người sử dụng hoặc cung cấp đủ lợi ích để bù đắp tổn thất về sự mất mát tiềm tàng đến các giá trị này

Rủi ro dịch vụ của hệ thống phần mềm là rủi ro tới các giá trị những người dùng được đưa ra bởi hệ thống đó Hệ thống tiêu cực ảnh hưởng tới những người dùng thông qua các dịch vụ thất bại của hệ thống Một dịch vụ lỗi làm giảm toàn bộ lợi ích từ hệ thống, mà có thể cuối cùng bị hủy bỏ bởi kết quả của sự mất mát từ sự thất bại Việc khảo sát các thất bại dịch vụ dường như là một khởi đầu tốt để xác định các rủi ro liên quan đên CNTT(dịch vụ)

Mặc dù sự tiến bộ nhanh về công nghệ, nhưng các dự án phầm mềm vẫn đối mặt với những vấn đề tương tự như các đây 30 năm Tuy nhiên, các yêu cầu của khách hàng không hiểu sâu sắc, mà dẫn đến việc mở rộng liên tục phạm vi của hệ thống hoặc thậm chí từ chối hệ thống cuối Sự tham gia của con người thường xuyên bổ sung yếu tố tâm trí con người và cá nhân đến những khó khăn kỹ thuật của các dự

án Cuối cùng, phầm mềm là dễ bị lỗi, sự hợp tác giữa các thành viên của dự án là ít thường xuyên Kết quả, là những sự mong đợi của khách hàng không được hài lòng Nhìn chung, các dự án phần mềm yêu cầu một số cải tiến quan trọng tới sự phát triển phần mềm Một trong những cách tiếp cận có sức thuyết phục như vậy được nhận ra bởi bộ sách hướng dẫn kỹ thuật công nghệ phần mềm và sách hướng dẫn quản lý dự án [CMMI 2002, Thayer et al 2002, Pressman 2004, Sommerville

2004, McConnell 2004, SWEBOK 2004, PMBOK 2004] gọi là quản trị rủi ro 1.3 Quản trị rủi ro

Quản trị rủi ro có vai trò khá quan trọng trong toàn bộ tiến trình quản lý dự án Trong cả 2 bộ mô hình và tiêu chuẩn nổi tiếng được ứng dụng nhiều trong dự án phần mềm là CMMI (Capability Maturity Model Integration) của viện Công nghệ Phần mềm Hoa kỳ (SEI) và PMP (Project Management Professional) của viện Quản trị Dự án PMI (Project Management Institude) đều xem quản lý rủi ro là một trong những hoạt động cơ bản nhất của quá trình quản trị dự án [8]

Xác định và kiểm soát tốt rủi ro chỉ bằng kỹ năng và kinh nghiệm cá nhân không chưa đủ, việc kiểm soát rủi ro phải được thực hiện theo một quy trình chặt chẽ và phù hợp với đặc thù, mục tiêu và ngân sách của dự án Tổng quát, quy trình cơ bản quản lý rủi ro bao gồm các bước chính như trong hình 1

Hình 1: Quy trình cơ bản quản lí rủi ro Quản trị rủi ro nhằm mục đích tăng cơ hội thành công của dự án bằng việc xác định

rõ ràng những sự bất chắc trong tương lai Nguyên tắc trong quản trị rủi ro thường bao gồm hai giai đoạn: thứ nhất là đánh giá rủi ro và thứ hai là giảm thiểu rủi ro của

dự án

- Đánh giá rủi ro bao gồm các hoạt động, thực hiện theo thứ tự sau:

• Xác định rủi ro: là việc xác định các sự cố rủi ro đe doạ sự thành công của dựa án cũng như các yếu tố rủi ro của chúng; phát hiện các tình huống rủi ro

• Phân tích rủi ro: là việc chuyển đổi các thông tin ban đầu về rủi ro trở thành một tri thức cho phép quyết định bằng việc phán đoán mức độ tác động rủi ro với một phạm vi đã chọn (ước lượng rủi ro) và sắp xếp các rủi ro theo mức

độ ảnh hưởng (xếp loại rủi ro)

• Đánh giá rủi ro: là việc chấp nhận rủi ro bằng việc đánh giá các rủi ro dựa vào một phạm vi có thể chấp nhận được hoặc một ngưỡng nào đó

- Giai đoạn giảm thiểu rủi ro bao gồm các hoạt động sau:

• Lập kế hoạch các biện pháp kiểm soát rủi ro: lập kết hoạch thực hiện các biện pháp để chủ động giảm thiểu các rủi ro trước khi nó xảy ra

• Thực hiện các biện pháp kiểm soát rủi ro: là thực hiện các công việc phòng ngừa rủi ro đã được định nghĩa trong kế hoạch giảm thiểu rủi ro

• Giám sát: kiểm tra tính hiệu quả của các biện pháp kiểm soát rủi ro đã thực hiện; bao gồm giám sát các kế hoạch thực hiện và việc theo dõi các mức hiện tại của các rủi ro đã được giảm nhẹ

• Kiểm soát: là việc định hướng giảm thiểu rủi ro dựa trên tính hiệu quả thực của các phương pháp kiểm soát rủi ro và các mức rủi ro, việc quyết định đưa

ra các kế hoạch dự phòng và kết thúc một rủi ro được giảm thiểu thành công

• Nghiên cứu rủi ro: là việc rút ra các kinh nghiệm từ việc đánh giá và giảm thiểu rủi ro thành một tri thức tái sử dụng; bao gồm việc ghi lại các rủi ro phụ thuộc ngữ cảnh rất cụ thể cũng như việc áp dụng thành công các biện pháp kiểm soát rủi ro trong một cơ sở tri thức rủi ro

Các hoạt động đánh giá rủi ro và giảm thiểu rủi ro được thực hiện trong một khung công việc cho chuyển hoá rủi ro và tài liệu hoá rủi ro Hai quy trình cốt lõi này bao trùm toàn bộ việc quản lý rủi ro và kết hợp chặt chẽ các hoạt động quản lý rủi ro cụ thể

1.4 Mô hình tổng quát tiến trình đánh giá rủi ro

Mô hình tổng quát tiến trình đánh giá rủi ro theo phương thức đánh giá rủi ro

dựa vào mô hình tiến trình (Process Model-based Risk Assessment, PMRA) được

trình bày trong luận văn như hình 2 dưới đây

Hình 2: Mô hình tổng quát của phương thức PMRA

Theo mô hình trên, phương thức PMRA bao gồm ba bước phương thức chính:

mô hình tiến trình công việc (Model the business process), xác định và biểu diễn rủi

ro (identify and express risk) và phân tích rủi ro (Analyze risk) Mỗi bước chính bao gồm các phương thức cụ thể được áp dụng, và sẽ được trình bày lần lượt trong các chương của luận văn

Hệ thống thông tin được sử dụng hầu như ở khắp mọi nơi, bao gồm các ứng dụng liên quan đến an toàn và quyết định an toàn Thiết kế và thực thi các hệ thống như vậy đòi hỏi một sự quan tâm đặc biệt để xác định các tình huống nguy hiểm mà

có thể dẫn đến những rủi ro và tai nạn gây ra bởi một hệ thống trong môi trường của

nó, như việc triển khai các hệ thống dịch vụ liên quan đến lĩnh vực y tế, quân sự, giao thông… thường yêu cầu các nguyên tắc và các tiêu chuẩn về an toàn của hệ thống Vì vậy trong qui trình phát triển phần mềm, việc áp dụng các kỹ thuật quản trị rủi ro để phân tích và đánh giá các rủi ro có thể gây ra thất bại cho dự án đang ngày được phát triển Trong luận văn này tập chung trình bày hai kỹ thuật; thứ nhất

là quản trị rủi ro trong phát triển phần mềm hướng dịch vụ và kỹ thuật Trust Case trong đánh giá các dự án Công nghệ Thông tin, và phương án kết hợp hai kỹ thuật

đó

1.5.Nhiệm vụ trong luận văn và cấu trúc

Mục đích chính trong luận văn là nghiên cứu lý thuyết chung về Quản trị Công nghệ Thông tin và tìm hiểu các kỹ thuât: Quản trị rủi ro trong phát triển phần mềm hướng dịch vụ; Kỹ thuật Trust Case trong đánh giá các dự án Công nghệ Thông tin

và nghiên cứu, xây dựng phương án kết hợp áp dụng hai kỹ thuật trong phát triển phần mềm hướng dịch vụ Thử nghiệm phương án đề xuất trong một số dự án tại Trung tâm Tin học Thống kê

Luận văn được cấu trúc theo các chương:

Chương 2: Trình bày một mô hình rủi ro dự án phần mềm mới dựa vào mô hình tiến trình Với mục đích việc mô hình hoá một siêu mô hình mở rộng rủi ro chuyên dụng được định nghĩa, các mẫu rủi ro được đưa ra để biểu diễn rủi ro trong những giới hạn ngữ cảnh chính xác của quy trình phần mềm Các mẫu rủi ro cơ sở được kết

hợp với nhau tạo thành các kịch bản rủi ro để biểu diễn những chuỗi nhân quả của các sự kiện rủi ro và định nghĩa một dạng ngữ pháp của các kịch bản rủi ro Trong chương này cũng mô tả cấu trúc và cơ chế quản lý nội dung của một cơ sở tri thức rủi ro

Chương 3: Trình bày một phương pháp xác định rủi ro dựa trên mô hình tiến trình sử dụng phương thức PMRA [6], bao gồm hai kỹ thuật xác định rủi ro là sử dụng độ đo cấu trúc mô hình tiến trình và so sánh các mô hình tiến trình và kỹ thuật xác định rủi ro trong phát triển phần mềm hướng dịch vụ Rủi ro được xác định từ khía cạnh các dịch vụ được cung cấp bởi một hệ thống phần mềm đến người dùng, xác định rủi ro dựa trên dịch vụ được bổ sung với những danh sách kiểm tra được trích rút từ các tiêu chuẩn và các kỹ thuật kinh điển của việc phân tích an toàn, an ninh Tiếp theo mô tả các kỹ thuật phân tích rủi ro được áp dụng trong mô hình tiến trình dựa trên phương pháp đánh giá rủi ro Trước tiên, khái niệm về ảnh chụp nhanh rủi ro (risk snapshot) được đưa ra cung cấp không gian làm việc cho việc phân tích rủi ro Sau đó là hai kỹ thuật sắp xếp rủi ro được trình bày, các kỹ thuật bao trùm việc xử lý thông tin ban đầu trên các rủi ro đã xác định với các ảnh chụp nhanh rủi ro, quan hệ thứ bậc và phân tích tổng thể các rủi ro

Chương 4: Chương này trình bày định nghĩa về quy trình đánh giá rủi ro kết hợp với các mô hình và các kỹ thuật đã được giới thiệu thành một phương thức đánh giá rủi ro nhất quán Các phần tử tiến trình được định nghĩa trong các phạm vi của các sản phẩm (artifact), vai trò (role), thao tác (activity) và các mối quan hệ của chúng Việc cài đặt quy trình được đề xuất với một thủ tục đánh giá rủi ro đơn và một quy trình đánh giá rủi ro liên tục (continuous risk assessment process) được mở rộng hơn và cuối cùng khái niệm của việc xây dựng quy trình đánh giá rủi ro thành một

sự mở rộng quy trình phần mềm liên tục thực hành rộng hơn được đưa ra Trình bày khái niệm Trust Case, ngôn ngữ Trust Case, mô hình Trust Case và các nghiên cứu

áp dụng kỹ thuật Trust Case trong đánh giá các dự án CNTT

Chương 2 Phân loại rủi ro và mô hình cơ sở tri thức rủi ro

2.1 Phân loại rủi ro

Trong phần này giới thiệu định nghĩa rủi ro cho mô hình xử lý dựa vào phương thức đánh giá rủi ro Đầu tiên, việc định nghĩa chung được đưa ra và một rủi ro được

mở rộng trong xử lý phần mềm theo kiểu siêu mô hình cho ngữ cảnh của rủi ro tiến trình được đề xuất Sau đó, mô hình xử lý dựa vào định nghĩa của rủi ro được trình bày, tiếp theo là đề xuất các mẫu rủi ro để biểu diễn rủi ro tiến trình Cuối cùng, một

kỹ thuật xây dựng kịch bản rủi ro được định nghĩa

2.1.1 Định nghĩa rủi ro tiến trình

Định nghĩa này sử dụng khái niệm của sự thất bại, nơi mà sự thất bại được định nghĩa như một trạng thái của hệ thống, mà hệ thống không cung cấp chính xác các dich vụ (không hoàn thành nhiệm vụ của nó) [6] Liên quan đến một quá trình kinh doanh, thất bại xảy ra khi quá trình không đạt được các mục tiêu mong đợi của nó (tiện ích của quá trình ra bị giảm) Trạng thái đó, các quá trình không có khả năng cung cấp đúng dịch vụ Rủi ro tiến trình được gây ra bởi một lỗi xảy ra trong tiến trình Một lỗi là sự sai lệch trong tiến trình thực thi mà nó có thể dẫn đến sự thất bại của tiến trình, một lỗi lan truyền trong tiến trình thông qua các thao tác của tiến trình hợp thành mà nó được chuyển thành các lỗi khác Một lỗi không gây ra thất bại dịch

vụ (duy trì bên trong tiến trình) cho tới khi nó trở nên rõ ràng ở giao diện dịch vụ của tiến trình Những sự kiện như trường hợp sử dụng các mô hình phân tích công việc kinh doanh sai có thể coi là một ví dụ của lỗi

Một lỗi được gây ra bởi một khuyết điểm của sự hoạt động, một khuyết điểm là một trạng thái của một thành phần tiến trình đó có khả năng gây ra lỗi Một khuyết điểm đó sinh ra lỗi hoạt động, nếu không thì nó là không hoạt động Khuyết điểm có thể ở trong hoặc ngoài tiến trình Khuyết điểm bên trong là khuyết điểm trong các thực thể nội bộ của tiến trình hoặc việc thiết kế tiến trình Khuyết điểm bên ngoài là khuyết điểm trong các thực thể đưa vào tiến trình Một khuyết điểm bên trong được

kích hoạt thông qua một chuỗi các sự kiện được gọi là mẫu kích hoạt Một khuyết điểm bên ngoài là hoạt động mặc định Các khuyết điểm áp dụng đối với các nhân

tố, các tài nguyên và các dịch vụ (như mọi thứ trong tiến trình) và thường được thể hiện trong các giới hạn của trạng thái

Ánh xạ tới các khái niệm cơ bản về xác định rủi ro Các khuyết điểm và các lỗi đều là các nhân tố rủi ro, trừ khi chỉ định rõ ràng, các giới hạn khác biệt giữa khuyết điểm và lỗi sẽ được sử dụng thay vì một giới hạn chung của nhân tố rủi ro để phân biệt “kiểu khuyết điểm” các nhân tố rủi ro (ví dụ: các nhân tố rủi ro của việc tồn tại một số khuyết điểm trong tiến trình) từ “kiểu lỗi” các nhân tố rủi ro (ví dụ: làm một điều gì sai trong lúc xử lý) Sự khác biệt này đặc biệt hữu ích trong việc nghiên cứu các mối quan hệ nhân quả của các nhân tố rủi ro và việc chứng minh bằng tài liệu rõ ràng của chúng

Các khuyết điểm, các lỗi và các thất bại thường được đặt tên là các sự kiện rủi ro (risk events) Các khái niệm của khuyết điểm, lỗi và sự thất bại đã được định nghĩa trong các phần trước, một kịch bản rủi ro có thể được định nghĩa rõ ràng hơn như sau: Kịch bản rủi ro là một chuỗi các sự kiện từ khuyết điểm ban đầu thông qua các lỗi được kích hoạt dẫn đến tiến trình thất bại

Trong ngữ cảnh của một tiến trình đặc biệt kịch bản rủi ro được biểu diễn theo một chuỗi của các sự kiện rủi ro liên quan đến việc làn truyền lỗi cục bộ bên trong một tiến trình:

Hình 3: Kịch bản rủi ro trong ngữ cảnh đơn tiến trình Việc xem xét đầu ra từ một tiến trình như một dịch vụ được sử dụng bởi một tiến trình khác, sự thất bại của các kết quả tiến trình cung cấp trong việc thực hiện một dịch vụ không đúng, mà đại diện cho một khuyết điểm bên ngoài tới tiến trình của người dùng Từ một góc nhìn xa hơn, một kịch bản rủi ro bên trong một tiến trình

mở rộng hơn nữa vào các khuyết điểm, các lỗi và các thất bại Như hình 4 dưới đây cho ta thấy sự lan truyền bên ngoài của một lỗi từ tiến trình A đến tiến trình B và

tiếp tục tiến trình khác thông qua các giao diện dịch vụ của các tiến trình và các khuyết điểm bên ngoài

Hình 4: Kịch bản rủi ro thông qua nhiều tiến trình Các quan hệ nhân quả của quá trình chuyển đổi giữa khuyết điểm, lỗi và thất bại cần được làm rõ thêm Một khuyết điểm có thể gây ra một lỗi vì nó cần kích hoạt Tương tự, một lỗi có thể gây ra thất bại vì nó cần được lan truyền tới giao diện dịch

vụ Tuy nhiên, một khuyết điểm luôn luôn gây ra thất bại Thực tế, sự thất bại là một

sự chuyển trạng thái từ dịch vụ đúng tới dịch vụ sai Tiến trình lỗi được bắt nguồn

từ một dịch vụ sai, mà từ quan điểm của tiến trình người sử dụng nó chứa đựng một sai lầm bên ngoài

Một tình huống rủi ro trong ngữ cảnh của một tiến trình nhận được có thể được thể hiện chi tiết hơn bằng việc khảo sát các thành phần tiến trình con (sub-process) theo ngữ cảnh của tiến trình cha (super-process) Sự lan truyền lỗi cục bộ trong một tiến trình nhận được có thể được ánh xạ đến sự lan truyền lỗi bên ngoài giữa các tiến trình con của tiến trình đó Một lỗi trong tiến trình con cũng là một lỗi trong tiến trình cha của nó Khi một lỗi trong tiến trình con là nguyên nhân dẫn đến tiến trình con này thất bại, sự thất bại còn tồn tại bên trong tiến trình cha, trừ khi trạng thái bến ngoài của tiến trình con đó là một phần của trang thái bên ngoài tiến trình cha

nó Trong trường hợp ngược lại, lỗi liên quan đến giao diện dịch vụ của tiến trình cha và dẫn đến sự thất bại tiến trình Cấu trúc bên trong của tình huống rủi ro được ánh xạ đến các tiến trình con của một tiến trình được chỉ ra trong hình 5

Hình 5: Cấu trúc bên trong của kịch bản rủi ro trong một tiến trình với các tiến trình

Error: nhà phân tích kinh doanh làm mô hình sai một trường hợp sử dụng

Ở đây một sự phân tích chuỗi Fault – Error – Failure được chi tiết hơn có thể được thực hiện, tức là chi tiết hơn các khuyết điểm, các lỗi và các thất bại có thể được phân biệt Điểm bắt đầu là để phân biệt một tiến trình con đến một tiến trình

đã phân tích Việc mô hình hoá một trường hợp sử dụng có thể được phân biệt như một tiến trình con với việc coi một trường hợp sử dụng như một (artifact) sản phẩm đầu ra của nó Sau đó, các lỗi thu được ở trên gây ra sự thất bại của tiến trình con này, mà được cụ thể hoá như một khuyết điểm trong trường hợp sử dụng được sinh

ra Trong cùng thời điểm này, khuyết điểm được đưa vào mô hình kinh doanh thành một khối

Lỗi vẫn còn lại bên trong tiến trình mô hình hoá kinh doanh cho tới khi mô hình kinh doanh được cung cấp như một dịch vụ của tiến trình Lỗi không gây ra thất bại tiến trình nếu trường hợp sử dụng sai không được cung cấp như một phần của mô hình kinh doanh, ví dụ như: do một vài hoạt động khắc phục sau khi xem xét đã phát hiện ra lỗi Nếu không, lỗi dẫn đến tiến trình mô hình hoá kinh doanh không cung cấp các dịch vụ đúng

Failure: tiến trình mô hình hoá kinh doanh cung cấp mô hình kinh doanh không chính xác

Khuyết điểm trong mô hình kinh doanh là khuyết điểm bên ngoài đối với các tiến trình sử dụng mô hình đó, ví dụ như: các yêu cầu định danh Khuyết điểm vẫn tiềm tàng cho tới khi một tiến trình thực sử dụng mô hình Sau đó, do khuyết điểm này có thể phát sinh ra lỗi trong tiến trình đó và cuối cùng dẫn đến thất bại tiến trình Như vậy, lỗi lan truyền thông qua mối liên hệ với các tiến trình con cuối cùng

có thể dẫn đến sự thất bại của toàn bộ quá trình phát triển phần mềm

2.1.2 Kỹ thuật biến đổi mô hình quy trình phần mềm mở rộng rủi ro (Risk –

extended Software Process Engineering Metamodel)

Để có thể nói về rủi ro, ngữ cảnh của rủi ro phải được thiết lập đầu tiên để cung cấp các giới hạn cần thiết để các sự kiện rủi ro có thể tham chiếu Trong trường hợp rủi ro dự án phần mềm, quy trình phần mềm tạo thành ngữ cảnh được xem xét và

mô hình của nó đã được chọn làm mô hình ngữ cảnh cho các rủi ro dự án phần mềm Kỹ thuật biến đổi mô hình quy trình phần mềm (Software Process Engineering Metamodel, SPEM) đã được áp dụng như một cơ sở và tiếp tục mở rộng để hỗ trợ mô hình hoá cho phép rủi ro của quy trình phần mềm

Sự mở rộng đầu tiên của SPEM giả định rằng các phần tử cấu trúc có thể được phân tích đệ qui Để quản lý và sử dụng mô hình dễ dàng hơn, mô hình tốt cần được cấu trúc thành sự nhất quán các mức chi tiết tăng dần Các mức sau đây được đề xuất:

• Mức tổng quát: mô hình quy trình tổng quát nhất bao gồm phạm vi hoạt động quy trình, sản phẩm nhân tạo và vai trò nhân viên

• Mức tổ chức: các quy tắc hoặc vùng trong quy trình làm mẫu

• Mức thủ tục: các quá trình con đặc biệt của các quy tắc để xác định các cách của việc hoàn thành các mục tiêu của các quy tắc, tức là cung cấp giá trị bổ sung dễ quan sát đến quy trình tổng thể

• Mức thực thi: các quy trình con nguyên thuỷ của các thủ tục có thể được phân biệt trong quy trình như vẫn được cung cấp giá trị bổ sung dễ thấy Các mức đã đề xuất ở trên nên được coi như một sự hướng dẫn hơn là một quy tắc nhỏ Mô hình quy trình có thể không bao gồm tất cả 4 mức đã được đề xuất và vẫn được xem xét đủ đối với việc phân tích rủi ro Quy trình phát triển phần mềm nên được luôn luôn chỉ rõ đến chi tiết các mức tương ứng với các khía cạnh xác định rủi ro hiện tại

Các phần tử cấu trúc phân tích đệ quy chia thành hai loại:

• Các phần tử cấu trúc trừu tượng: các lớp của các phần tử cấu trúc cơ bản được giới thiệu cho việc nhóm các mục đích để tạo thuận lợi cho quản lý mô hình

• Các phần tử cấu trúc không trừu tượng: có thể phân biệt được trong cấu trúc

xử lý nhưng các phần tử cấu trúc hợp thành của nó cũng nên được phân biệt cho các mục đích quản lý rủi ro

Các phần tử đã phân tích được xem như phần tử chứa đựng và các phần tử đó được phân tích và gọi là các phần tử cấu thành

Các siêu mô hình SPEM được tiếp tục mở rộng bằng việc đưa ra các phần tử siêu mô hình mới được gọi là các phần tử đặc trưng liên quan tới các phần tử cấu trúc nói trên Các phần tử đặc trưng sẽ mô tả các đầu ra dự kiến (dịch vụ) và liên quan tới các đặc trưng mong muôn của các phần tử cấu trúc Các phần tử đặc trưng được định nghĩa cho các phần tử cấu trúc SPEM là:

• Thao tác quen thuộc: phương pháp yêu cầu của việc thực hiện các nhiệm vụ trong một thao tác nhằm đạt được mục tiêu của thao tác đó

• Khả năng của vai trò: đặc tính của yếu tố con người thực hiện vai trò

• Tính năng của sản phẩm tạo ra: thuộc tính của sản phẩm

Khả năng hay năng lực bao gồm các đặc điểm khác nhau của yếu tố con người

mà ảnh hưởng tới hiệu quả thực thi của nó trong một vai trò nhất định Các đặc điểm được mô hình hoá với khả năng bao gồm:

• Tri thức (thực tế và lý thuyết): một người đã quen thuộc với đối tượng, có hiểu về đối tượng hoặc quan sát vài đối tượng nào đó nhưng không có cơ hội thực hiện nó Tri thức không bao hàm khả năng để thực hiện nhiệm vụ

• Khả năng (thể chất và tinh thần): một người có thể thực hiện nhiệm vụ của một phạm trù nhất định Khả năng để hoàn thành một nhiệm vụ dưới sự giám sát của một người có nhiều kinh nghiệm hơn

• Kỹ năng: một người có thể thực hiện nhiệm vụ cụ thể mang tính tự động, nghĩa là một người có thể được giao nhiệm vụ và thực hiện thành công việc

• Phạm vi: các phần tử cấu trúc của một sản phẩm nhân tạo, như phân tích các yêu cầu chi tiết liên quan tới phần mềm

• Chất lượng: chất lượng các thuộc tính của sản phẩm như tính toàn vẹn và tính

rõ ràng

Cấu trúc và đặc tính của các phần tử siêu mô hình cũng như các mối quan hệ của

nó có thể hình dung quanh một hoạt động trong hình 6

Hình 6: Các phần tử của mô hình xử lý quanh một hoạt động

Các siêu mô hình SPEM gốc cùng với các phần mở rộng hình thành một siêu mô hình mới của quy trình phát triển phần mềm gọi là kỹ thuật biến đổi mô hình quy trình phát triển phần mềm mở rộng rủi ro (RiskSPEM), được biểu diễn trong hình 7

Hình 7: Mô hình RiskSPEM Các siêu mô hình RiskSPEM có thể được sử dụng để biểu diễn các mô hình xử

lý khác nhau Khi được định nghĩa, như mô hình cung cấp ngữ cảnh để mô tả rủi ro Đáng chú ý rằng một mô hình xử lý là sự định nghĩa bởi sự đơn giản hoá của xử lý thực và chỉ cho phép đặc điểm của rủi ro duy nhất đến mức chi tiết của các phần tử

mô hình Tuy nhiên, mô hình xử lý có thể cải tiến các phần tử mới để biểu diễn tốt hơn mô hình thực tế

Ví dụ 2.2

Như chúng ta đã biết mô hình tham chiếu nổi tiếng là Rational Unified Process (RUP) Nó được biểu diễn dễ dàng trong các thuật ngữ của siêu mô hình RiskSPEM, nó định nghĩa trực tiếp các hoạt động, các sản phẩm nhân tạo và các vai trò Các luồng công việc, chi tiết công việc, các tập sản phẩn nhân tạo và các vai trò của các mức trừu tượng cao hơn trong mô hình Những thực tiễn, tính năng và khẳ năng được trích từ các mô tả của các phần tử mô hình RUP

Ở mức tổng quát của mô hình xử lý không được phát biểu rõ ràng trong RUP các phần tử mô hình sau đây có thể được định nghĩa:

• Vai trò (Role): nhân viên (Personnel)

• Hoạt động (Activity) : dự án phần mềm

• Nhân tạo (Artifact) : sản phẩm

Các phần tử mô hình tổng quát được phân tích thành các phần tử mô hình mức Framework nơi mà các tập vai trò của RUP được thừa nhận như các vai trò (Role), luồng công việc (Workflow) như các hoạt động, đổi tên và các tập nhân tạo được làm nổi bật như các sản phẩm nhân tạo (Artifact) Hơn nữa, các phần tử mô hình mức framework được tách thành các phần tử mô hình mức thủ tục nơi mà các vai trò của RUP được đặt trực tiếp, các chi tiết luồng công việc được chấp nhận thành các hoạt động và các sản phẩm nhân tạo trừu tượng mới được giới thiệu Cuối cùng, tại mức thực hiện RUP các hoạt động và các sản phẩm nhân tạo gốc được định vị trực tiếp

Mô hình RUP thích nghi được trình bày trong ví dụ 2.2 có thể được mở rộng thêm khi cần thiết bởi một dự án phần mềm cụ thể Để thêm các phần tử cấu trúc mới, RUP phải thiết lập vị trí của chúng trong hệ thống phân cấp của các phần tử cùng loại, cũng như định nghĩa các mối quan hệ với các phần tử cấu trúc của các loại khác đã tồn tại Ngoài ra, một số yếu tố đặc trưng cho phần tử cấu trúc mới nên

được định nghĩa Điều này có thể hữu dụng để tham chiếu đến các yếu tố đặc trưng của các phần tử cấu trúc đã được định nghĩa

2.1.3 Mô hình xử lý dựa trên việc xác định của sự kiện rủi ro

Ánh xạ tới mô hình của một dự án phần mềm, một sự kiện rủi ro được miêu tả thay vì một sự vi phạm cụ thể của mô hình bởi tiến trình hiện tại Mô hình xử lý được giả định rằng để biểu diễn quy trình thay vì thực hiện nó để giảm thiểu rủi ro tiến trình Các sự vi phạm có thể của mô hình bao gồm việc bỏ đi một phần tử của

mô hình và không tuân thủ mối quan hệ giữa các phần tử mô hình

Ngoài ra còn có hai loại rủi ro sự kiện đặc biệt thường được sử dụng mà không ánh xạ trực tiếp tới sự vi phạm cấu trúc mô hình: việc vượt qúa thời gian hoạt động

dự kiến của một hoạt động và vượt chi phí thực hiện của hoạt động Nó được giả định rằng các sự kiện này cũng tạo thành sự vi phạm mô hình

2.1.4 Các mẫu rủi ro (Risk Pattern)

Sau khi kiểm tra tất cả các thực thể và các mối quan hệ trong siêu mô hình RiskSPEM, một tập các mẫu sự kiện rủi ro được định nghĩa Một ký hiệu đặc biệt cho các mẫu rủi ro được đề xuất là tên một đối tượng được in đậm và theo sau là siêu lớp (meta class) được đặt trong ngoặc nhọn và in nghiêng như sau:

• A <activity> không được thực hiện

• A <activity> mất nhiều thời gian hơn dự kiến

• A <activity> chi phí nhiều hơn dự kiến

• A <activity> mất (loses) P <practice>: nghĩa là P không được thực hiện

• Ar <artifact> mất F <feature>: nghĩa là Ar biểu thị F thấp hơn dự kiến

• Ar <atifact> mất nhiệm vụ R <role>: nghĩa là R không được giao nhiệm vụ

cho Ar

• R <role> không được gán

• R <role> mất C <capability>: nghĩa là R biểu thị C thấp hơn dự kiến

Ví dụ 2.3: một số ví dụ về các sự kiện rủi ro được thể hiện với mẫu rủi ro như sau

Để làm ví dụ này chúng ta sử dụng các phần tử của mô hình xử lý thích nghi RUP được phác thảo trong ví dụ 2.2 Các sự kiện được chia theo mức chi tiết của

mô hình xử lý

Mức tổng quát:

• Dự án phần mềm <activity> chi phí nhiều hơn dự kiến

• Sản phẩm <activity> mất chất lượng <feature>

• Nhân viên <role> mất động cơ thúc đẩy <capability>

• Danh sách các ý tưởng thử nghiệm <artifact> mất sự mô tả của tất cả các

rủi ro đặc trưng <feature>

2.1.5 Xây dựng các kịch bản rủi ro

Các sự kiện rủi ro được thể hiện với các mẫu rủi ro có thể được kết hợp để xây

dựng các kịch bản rủi ro rõ ràng với việc sử dụng các cấu trúc If … then và các toán

tử logic and, or, not Mối quan hệ If … then được đề suất là không nhân quả nghĩa là

một nguyên nhân của sự thực hiện làm tăng khả năng xảy ra nhưng không đưa ra hậu quả của sự kiện

Các kịch bản rủi ro rõ ràng có thể chia thành các kịch bản rủi ro đơn và các kịch bản rủi ro phức phụ thuộc và các cấu trúc các ngôn ngữ thực hiện

2.1.5.1 Các kịch bản rủi ro đơn

Một kịch bản rủi ro đơn chỉ bao gồm hai sự kiện rủi ro, một sự kiện nguyên nhân

và mộ sự kiện kết quả kết hợp với cấu trúc If … then Tất cả các mẫu có thể của kịch

bản rủi ro đơn có thể được sinh ra khi tất cả các mẫu rủi ro được hình thành từng đôi

trong cấu trúc If … then Một số cặp không có ý nghĩa với các phần tử thực của một

mô hình dự án phần mềm (chúng không thể hiện giá trị của các kịch bản rủi ro) và không được chấp nhận ở mức cú pháp Một số cặp có ý nghĩa khi và chỉ khi các phần tử mô hình thực tế tham chiếu đến các mẫu rủi ro được giới hạn

Mộ số ví dụ về kịch bản rủi ro đơn như sau:

- If A1 <activity> không thực hiện then A2 <activity> mất nhiều thời gian hơn

dự kiến

- If A <activity> mất nhiều thời gian hơn then R <role> mất C <capability>

- If A <activity> chi phí nhiều hơn dự kiến then A <activity> mất P

<practice>

- If A <activity> mất R <role> then A <activity> mất nhiều thời gian hơn dự

kiến

- If A <activity> mất P <practice> then Ar <artifact> mất F <feature>

- If R <role> không được giao nhiệm vụ then A <activity> không thực hiện

- …

Chú ý rằng một vài mẫu kịch bản rủi ro đơn không chính xác về cú pháp đối với các hoạt động, các vai trò, các artifact, những thực tiễn, các khả năng và các tính năng giống nhau đưa vào các biến trong các mẫu rủi ro Như trong danh sách trên mẫu đầu tiên đòi hỏi phải hai hoạt động khác nhau, vì với cùng các phần tử thì mẫu

đó sẽ là vô nghĩa Theo nguyên tắc, ít nhất một phần tử phải khác trong một kịch bản rủi ro đơn bao gồm các mẫu rủi ro như nhau

2.1.5.2 Các tình huống rủi ro phức

Các tình huống rủi ro phức thực hiện ghép lại nguyên nhân các sự kiện rủi ro kết hợp với các toán tử logic cũng như tạo thành các chuỗi của kết quả các sự kiện rủi

ro được xây dựng với cấu trúc …and then…

Một số ví dụ về các tình huống rủi ro đơn và rủi ro phức, sử dụng lại mô hình xử

lý RUP thích nghi trong ví dụ 3.2 với các mức chi tiết như sau

• Mức tổng quát:

- If Nhân viên <role> mất sự thúc đẩy <capability> then dự án phần mềm

<activity> mất nhiều thời gian hơn dự kiến

- If Nhân viên <role> mất sự thúc đẩy <capability> and dự án phần mềm

<activity> mất việc giải quyết xung đột giữa các nhóm <practice> then dự

án phần mềm <activity> mất nhiều thời gian hơn dự kiến

- …

• Mức framework:

- If tài liệu mô hình kinh doanh <artifact> mất sự phù hợp đối với kinh

doanh <feature> then sản phẩm <artifact> mất chất lượng <feature>

- If mô hình kinh doanh <activity> mất sự nắm bắt hiểu biết chung của

lĩnh vực kinh doanh hiện tại <practice> then tài liệu mô hình kinh doanh

<artifact> mất tính thích hợp đối với việc kinh doanh <feature> and then sản phẩm <artifact> mất chất lượng <feature>

- …

2.2 Mô hình cơ sở tri thức rủi ro

Cơ sở chi thức rủi ro (RiskKB) được định nghĩa như một kho lưu trữ cấu trúc của các thông tin tham chiếu về rủi ro

Mục đích chính của việc xây dựng một cơ sở tri thức là để thu thập các thông tin quá khứ về những rủi ro đã biết đối với công việc kinh doanh cụ thể và sau đó sử dụng thông tin đó trong việc quản lý các rủi ro của công việc kinh doanh mới

Một cơ sở tri thức rủi ro tổng quát bao gồm:

• Các rủi ro đã biết tiêu biểu,

• Các biện pháp chung làm giảm các rủi ro đã biết,

• Cung cấp tài liệu hỗ trợ trong việc quản lý rủi ro

Cơ sở tri thức có thể được xây dựng dựa trên một vùng, một doanh nghiệp hoặc mức dự án Trong trường hợp đầu tiên, nội dung RiskKB là đủ tổng quát để sử dụng cho bất kỳ một dự án trong một vùng cụ thể Trong trường hợp thứ hai, nội dung đề cập đến các đặc thù của một doanh nghiệp nhất định mang tính chi tiết hơn nhưng khó sử dụng lại ngoài doanh nghiệp đó Trong trường hợp cuối cùng, cơ sở tri thức lưu trữ các thông tin tham chiếu về rủi ro trong một dự án cụ thể, mà nó đề cập đến các chi tiết của dự án đó, vì vậy chỉ là di chuyển cục bộ tới dự án khác trong cùng một doanh nghiệp

Việc sử dụng hiệu quả cơ sở tri thức rủi ro yêu cầu một nội dung cấu trúc được thiết kế cẩn thận, mà sẽ cho phép việc xử lí phân tích của thông tin được lưu trữ Việc duy trì một mạng lưới dày đặc các tham chiếu chéo các mục thông tin dường như là quan trọng nhất đối với khả năng phân tích của một cơ sở tri thức

Một cơ sở tri thức rủi ro chung sẽ hiếm khi phù hợp hoàn toàn với các nhu cầu của một dự án cụ thể Thứ nhất, nó có thể đưa ra quá rộng trong phạm vi với thông tin không hợp lệ hoặc không áp dụng đối với dự án đích Trong trương hợp đó, nội dung nên được thay đổi để tránh những lỗ lực không cần thiết của việc xử lý và lọc

ra những thông tin không liên quan trong quy trình quản lý rủi ro Thứ hai, cơ sở tri thức rủi ro có thể được đánh giá quá chung hoặc quá hẹp trong phạm vi so với những kiến thức và nhu cầu của người sử dụng Sau đó, nội dung sẽ được mở rộng với các thông tin bổ sung Ngoài ra, các rủi ro mới sẽ được xác định, các biện pháp khắc phục mới được đề xuất và một số tài liệu hỗ trợ bổ sung được cung cấp trong suốt quy trình quản lý rủi ro Cơ sở tri thức rủi ro phải có khả năng hấp thụ tất cả những thông tin mới được học

Tóm lại, một cơ sở tri thức rủi ro nên có các thuộc tính sau:

• Cấu trúc cho phép việc xử lý phân tích thông tin

• Tính tuỳ biến được (việc biến đổi, thay đổi)

• Tính mở rộng (việc học)

Việc thiết kế cơ sở tri thức rủi ro cho mô hình xử lý dựa vào việc đánh giá rủi ro được chi tiết trong các phần sau Việc thiết kế cơ sở tri thức rủi ro (RiskKB) theo

mô hình của hệ thống phân tích và thiết kế hướng đối tượng Vì vậy, RiskKB là việc xây dựng các đối tượng có các thuộc tính và hoạt động cụ thể Các đối tượng với các thuộc tính và các hoạt động của nớ được định nghĩa bởi các lớp Sau khi tạo thành, các đối tượng trở thành các mẫu cho việc định nghĩa các lớp Các lớp có thể hình thành một hệ thống phân cấp thừa kế, trong đó một lớp thiết kế cho mục đích riêng thừa kế từ một lớp tổng quát

2.2.1 Cấu trúc nội dung

Dưới đây là thông tin các lớp được đề xuất đã bao gồm trong cơ sở tri thức rủi ro;

• Các mô hình xử lý: các mô hình xử lý cho phép rủi ro được thể hiện trong

các thuật ngữ của siêu mô hình RiskSPEM được giới thiệu trong mục 2.1.2

• Các danh sách kiểm tra: các bảng câu hỏi hỗ trợ cho việc xác định rủi ro

• Các danh sách rủi ro: dễ dàng để sử dụng để tham chiếu các danh sách của các nhân tố rủi ro

• Các mẫu rủi ro: các mẫu của các sự kiện rủi ro cho một rủi ro tiến trình được định nghĩa trong mục 2.1.1

• Các biện pháp khắc phục: các thủ tục và thực tiễn của việc đối phó với các rủi ro cụ thể

Mô hình tĩnh của cơ sở tri thức rủi ro được thể hiện trong hình 8

Hình 8: Lược đồ lớp cơ sở tri thức rủi ro

Cơ sở tri thức rủi ro được lưu trữ thành hai danh sách kiểm tra:

• Các danh sách kiểm tra tông quát: không phải thiết kế cho bất kỳ một tiến trình cụ thể nào mà là việc diễn tả một tri thức chung từ một lĩnh vực nhất định; bao gồm các câu hỏi chung được biểu diễn bằng ngôn ngữ tự nhiên kết hợp với các câu trả lời về các phạm vi khác nhau Những câu trả lời có thể được kết hợp với các tình huống rủi ro nghĩa là các tình huống rủi ro này có thể được chỉ định (xác định) có thể có trong một dự án cụ thể khi một câu trả lời cụ thể được đưa ra Đây là loại chung nhất của danh sách kiểm tra có thể đại diện cho nhiều danh sách kiểm tra đã có sẵn

• Các danh sách kiểm tra mẫu: được thiết kế cho một tiến trình cụ thể và được sinh ra từ mô hình xử lý với các câu hỏi mẫu tham chiếu trực tiếp tới các phần tử mẫu cụ thể

Danh sách rủi ro được lưu trữ trong RiskKB cũng được chia làm hai loại

• Các danh sách rủi ro chung: tương tự như danh sách kiểm tra chung, nó không phải được thiết kế cho bất kỳ một tiến trình cụ thể nào và bao gồm các tình huống rủi ro chung được biểu diễn trong ngôn ngữ tự nhiên và được

phân loại thành các phạm vi rủi ro chung Đây là loại danh sách rủi ro phổ biến nhất mà có thể đại diện cho nhiều loại danh sách rủi ro đã tồn tại sẵn

• Các danh sách rủi ro mẫu: được thiết kế cho một tiến trình cụ thể và bao gồm các tình huống rủi ro mẫu được xây dựng cho các sự kiện rủi ro tham chiếu đến các phần tử mẫu cụ thể và được thể hiện trong các thuật ngữ của các mẫu rủi ro đã nói ở trên Để cung cấp cho việc giao tiếp dễ dàng và tương thích với các danh sách rủi ro chung, các tình huống rủi ro mẫu được bổ sung với những giải thích ngôn ngữ tự nhiên Việc phân loại các tình huống rủi ro mẫu thành các phạm vi rủi ro được thực hiện bằng việc kết hợp một tình huống với yếu tố cấu trúc chứa đựng của các yếu tố được nêu trong tình huống Sự phân loại này là không xác định, vì vậy nó không được hỗ trợ bởi bất kỳ thủ tục xác định nào và để lại cho việc quản lý nội dụng của cơ sở tri thức rủi ro

Cơ sở tri thức rủi ro bao gồm một danh sách các biện pháp khắc phục đã biết cho các tình huống rủi ro cụ thể Nhìn chung, các biện pháp khắc phục được mô tả bằng ngôn ngữ tự nhiên mà không định nghĩa hoàn toàn trong cấu trúc Tuy nhiên, một loại biện pháp khắc phục được phân biệt rõ ràng, cụ thể là một kiểu quản lý rủi ro (risk manegement pattern) Nó được đề xuất bởi Cockburn [6] Trong cơ sở tri thức rủi ro, kiểu quản lý rủi ro được trình bày bởi các mô hình xử lý chính thức xác định kiểu xử lý trong các thuật ngữ của siêu mô hình RiskSPEM Các kiểu quản lý rủi ro được kết hợp với các tình huống rủi ro mẫu Như bất kỳ biện pháp khắc phục khác, một kiểu quản lý rủi ro được bổ sung với một mô tả trong ngôn ngữ tự nhiên

2.2.2 Quản lý nội dung

Quản lý nội dung cơ sở tri thức cơ bản đòi hỏi việc tạo ra nội dung mới, việc sửa đổi nội dung đã có, cũng như xoá bỏ nội dung Những phần tiếp theo sẽ định nghĩa chung cũng như các hoạt động dành riêng và các cơ chế quản lý các loại khác nhau của nội dung RiskKB

2.2.2.1 Các hoạt động chung

Các hoạt động quản lý nội dung chung được định nghĩa cho tất cả các loại trong cấu trúc RiskKB như sau:

• Tạo mới: dẫn ra một thể hiện của một lớp mới

• Chỉnh sửa: thay đổi nội dung được lưu trữ bởi một thể hiện của lớp

• Xoá: xoá đi thể hiện của lớp

• Sao chép: tạo ra một thể hiện mới của một lớp gần giống nội dung của thể hiện khác của lớp đó

2.2.2.2 Quản lý mô hình xử lý

Các lớp phần tử mô hình của RiskKB cung cấp một tập các hoạt động được dành riêng cho việc quản lý mô hình xử lý và được thừa kế bởi tất cả lớp riêng của mô hình xư lý Các hoạt động này bao gồm:

• Nhân bản: sao chép một phần tử cấu trúc cùng với các yếu tố liên quan đến đặc trưng của nó

• Ánh xạ: tạo một ánh xạ giữa hai phần tử mô hình

• Bỏ ánh xạ: xoá một ánh xạ giữa hai phần tử mô hình

• Thừa kế: chép phần tử cấu trúc và thiết lập thừa kế giữa phần tử gốc và bản sao của nó

• Tuỳ chỉnh: hạn chế các phần tử đặc trưng của một phần tử cấu trúc con được thừa kế

2.2.2.3 Quản lý danh sách kiểm tra và danh sách rủi ro

Hai khái niệm thiết kế đặc biết được sử dụng quản lý danh sách rủi ro và danh sách kiểm tra

• Xác định phiên bản đối tượng

• Ba trạng thái đối tượng

Việc xác định phiên bản đối tượng cho rằng một đối tượng được kết hợp với một danh sách các phiên bản của nó được tạo ra trong khi chỉnh sửa đối tượng để lưu lại trạng thái trước đó của đối tượng Mục tiêu đầu tiên của việc xác định phiên bản đối tượng là cho phép hoàn tác các thay đổi đối với các đối tượng và những phân tích liên quan đến quá khứ

Ba trạng thái của đối tượng liên quan tới việc đóng gói tất cả các trạng thái của một đối tượng trong một trạng thái cao hơn gọi là “hoạt động (active)”, trong đó đối

tượng được phép thay đổi các trạng thái và bổ sung một trạng thái “không hoạt động (inactive)”, trong đó đối tượng không thể thay đổi trạng thái Mục đích của ba trạng thái của đối tượng là để phân biệt giữa các đối tượng không hoạt động và đối tượng không tồn tại và để giữ cho đối tượng ở trạng thái cuối cùng của chúng trong khi không cho phép đối tượng đó thay đổi thêm trạng thái của đó

Ngoài các trạng thái chung đã được trình bày, bốn trạng thái đặc biệt được định nghĩa cho các câu hỏi danh sách kiểm tra và các tình huống danh sách rủi ro dựa vào các khái niệm được định nghĩa ở trên

• Bao gồm: thay đổi trạng thái của một câu hỏi ba trạng thái hoặc tình huống rủi ro đến hoạt động và làm cho nó có thể xác định được trực tiếp từ một danh sách kiểm tra/danh sách rủi ro

• Loại trừ: thay đổi trạng thái của một câu hỏi ba trạng thái hoặc tình huống rủi

ro đến không hoạt động và làm cho nó không thể xác định được trực tiếp từ một danh sách kiểm tra/danh sách rủi ro

• Cập nhật: thay đổi đối tượng bằng một phiên bản mới trong khi vẫn giữ trạng thái cũ trong một phiên bản cũ

• Phục hồi: lấy lại phiên bản trước đó

Các hoạt động loại trừ và phục hồi bổ sung cho các hoạt động bao gồm và cập nhật theo thứ tự

2.3 Kết chương

Tóm lại chương 2 định nghĩa khái niệm về rủi ro tiến trình liên quan đến mô hình của tiến tình phân tích và trình bày cấu trúc, cơ chế quản lý đối với cơ sở tri thức rủi ro theo phương thức PMRA Siêu mô hình RiskSPEM xuất phát từ Software Process Engineering Metamodel [6], xây dựng ánh xạ từ định nghĩa rủi ro tiến trình đến siêu mô hình RiskSPEM Dựa trên sự định nghĩa này, một tập các mẫu rủi ro được sinh ra, các mẫu rủi ro chuẩn hoá các lớp có thể của các sự kiện rủi

ro mà có thể xảy ra đối với tiến trình Các mẫu rủi ro được kết hợp cả kịch bản rủi ro đơn và kịch bản rủi ro phức theo một ngữ pháp chuẩn của các kịch bản rủi ro cũng được định nghĩa trong chương này Chi tiết hơn về các mẫu rủi ro và siêu mô hình

RiskSPEM có thể tham khảo trong [6] Các cơ sở tri thức rủi ro được thiết kế mang tính toàn diện và tính linh hoạt Cơ sở tri thức rủi ro bao gồm các mô hình tiến trình, các câu hỏi tham chiếu và các danh sách rủi ro, các mẫu rủi ro cũng như cách khắc phục Các hoạt động quản lý nội dung cho phép áp dụng dễ dàng các kỹ thuật xác định và phân tích rủi ro dựa trên mô hình tiến trình sẽ được trình bày trong chương

3

Chương 3 Xác định và phân tích rủi ro dựa trên mô hình tiến trình

3.1.1 Độ đo của cấu trúc mô hình tiến trình

Kỹ thuật này bao gồm việc phát hiện một số sự thiếu cân đối trong cấu trúc xử lý

mà có thể chỉ ra rủi ro để thực hiện xử lý chính xác và khảo sát thêm với một tập các câu hỏi tổng quát Những sự thiếu cân đối được đưa vào tính toán bao gồm:

• Số lượng lớn của các phần tử khác được liên kết với một phần tử mô hình đã cho (sự ghép nối cao),

• Mở rộng đầu ra từ một phần tử được so sánh với đầu vào phần tử này (sự thực hiện bên trong cao), ví dụ như: một hoạt động được định nghĩa để sinh

ra 10 artifact đầu ra của một artifact đầu vào

Độ đo của cấu trúc mô hình tiến trình được đưa vào để làm nổi bật những thiếu sót tiềm ẩn trong thiết kế tiến trình, tập trung sự chú ý của người phân tích và cung cấp những gợi ý trong việc tìm kiếm của các rủi ro phá hoại tiến trình Độ đo được định nghĩa theo kiểu Goal\Question\Metric (GQM) [6] Mục đích phép đo được biểu diễn với một mẫu GQM được định nghĩa như sau:

Mô hình tiến trình phân tích cho mục đích xác định rủi ro với khía cạnh để hoàn thiện cấu trúc tiến trình theo quan điểm người quản trị dự án trong ngữ cảnh của sự quản trị rủi ro dự án

Với mục đích đưa ra ở trên được hỗ trợ bởi hai câu hỏi:

• Q1: Các phần tử quan trọng đối với tiến trình là gì? (activities, artifacts, roles),

• Q2: Các phần tử tiến trình được thiết kế có tương xứng đối với tầm quan trọng của chúng không?

Với Q1 nói đến sự không cân đối của sự ghép nối cao và Q2 nói đến sự thực hiện bên trong cao Các câu trả lời cho các câu hỏi này đưa ra một tập các số liệu đo các thuộc tính cấu trúc của mô hình tiến trình Các số liệu được xác định cho mỗi câu hỏi như sau:

• Q1: Các phần tử quan trọng đối với tiến trình là gì? (activities, artifacts, roles),

¾ M1.1: Số các hoạt động tham gia một artifact đã cho ở đầu vào

¾ M1.2a: Số artifact đầu vào của một hoạt động đã thực hiện

¾ M1.2b: Tổng số sự quan trọng (được đo với M1.1) của tất cả artifact đầu ra với một hoạt động đã thực hiện

¾ M1.3: Số các hoạt động, trong đó có một vai trò nhất định tham gia

• Q2: Các phần tử tiến trình được thiết kế có tương xứng đối với tầm quan trọng của chúng không?

¾ M2.1: Tỷ lệ của hoạt động quan trọng đối với số lượng các hoạt động thực tiễn của hoạt động này

¾ M2.2: Tỷ lệ của artifact quan trọng đối với số lượng các tính năng của artifact này

¾ M2.3: Tỷ lệ số lượng các tính năng của một artifact ở đầu ra từ một hoạt động đến tổng số các phần tử chất lượng ở đầu vào đối với hoạt động này

¾ M2.4: Tỷ lệ của vai trò quan trọng đối với số các khẳ năng của vai trò này

Mô hình tổng thể GQM của cấu trúc mô hình tiến trình được biểu diễn trong hình 9 dưới đây

Hình 9: Mô hình GQM cho các số đo của cấu trúc mô hình tiến trình

Với mục đích của việc định nghĩa số liệu, các tập sau được định nghĩa có liên quan tới các mối quan hệ giữa các phần tử mô hình trong siêu mô hình RiskSPEM

• Ain(Ar) - Tập các hoạt động có artifact Ar như đầu vào,

• Aout(Ar) - Tập các hoạt động có artifact Ar như đầu ra,

• Apart(R) - Tập các hoạt động trong đó vai trò R tham gia,

• Arin(A) - Tập các artifact đầu vào của hoạt động A,

• Arout(A) - Tập các artifact đầu ra của hoạt động A,

• Rpart(A) - Tập các vai trò tham gia trong hoạt động A,

• P(A) - Tập các thực hành có bởi hoạt động A,

• F(Ar) - Tập các tính năng có bởi artifact A,

• C(R) - Tập các khả năng có bởi vai trò R

3.1.1.1 Các độ đo đối với tầm quan trọng phần tử mô hình

Tầm quan trọng của phần tử mô hình được định nghĩa như một tiêu chuẩn để đánh giá tầm ảnh hưởng của sự thất bại phần tử đó trên toàn bộ tiến trình

Các độ đo của cấu trúc mô hình cho thấy tầm quan trọng các lớp khác nhau của các phần tử mô hình được định nghĩa như sau:

M1.1: Tầm quan trọng của artifact Ar, ký hiệu I(Ar) là số các hoạt động mà có

artifact Ar như đầu vào

I(Ar) = | Ain(Ar) |, I(Ar)∈ N (1)

Độ đo này cho phép một giả thiết rằng tác động của một thất bại artifact tỷ lệ với

sô hoạt động tham gia trực tiếp artifact đó lúc vào Điều này được khẳng định bởi

thực tế rằng nhiều hoạt động tham gia một artifact thất bại như đầu vào, theo thống

kê sự thất bại artifact sẽ ảnh hưởng nhiều đến các hoạt động và các artifact khác

M1.2: Tầm quan trọng của hoạt động A, ký hiệu I(A):

I(A): là tổng số sự quan trọng của tất cả các artifact đầu ra từ hoạt động A tính theo công thức sau:

Độ đo này giả thiết rằng tác động trực tiếp của một hoạt động thất bại tỷ lệ với

số các artifact đầu ra của hoạt động đó

I(A): là số các artifact đầu vào của hoạt động A, như công thức sau

I(A) = | Arin(A) |, I(A) ∈ N (3)

M1.3: Tầm quan trọng của vai trò R, ký hiệu I(R) là số các hoạt động trong đó vai

trò R tham gia, như công thức sau:

I(R) = |Apart(R)|, I(R) ∈ N (4)

3.1.1.2 Các độ đo của rủi ro phần tử mô hình

Rủi ro phần tử mô hình (Risk element model) được định nghĩa như thước đo khả năng có thể của sự thất bại phần tử và tác động của thất bại đó trên toàn bộ tiến trình

M2.1: Rủi ro của hoạt động A, ký hiệu R(A) bằng tầm quan trọng của hoạt động A

được chia cho số các hành động thực tiễn của hoạt động A, theo công thức sau:

R(A) =

| P(A)

| I(A) , R(A) ∈R+ ∪{ }0 (5) Rủi ro của hoạt động A là không xác định, nếu hoạt động A không có bất kỳ một hành động thực tiễn nào (|P(A)| = 0)

M2.2: Rủi ro của artifact đầu vào, ký hiệu Rin(Ar) là tầm quan trọng của artifact đầu vào chia cho số các thuộc tính của artifact Ar

Rin(Ar) =

| F(Ar)

| I(Ar) , Rin(Ar) ∈R+ ∪{ }0 (6)

Độ đo này đưa vào coi như sự kiện rủi ro mà artifact Ar thất bại Artifact thất bại

có nghĩa là artifact đầu vào thiếu một vài tính năng và gây ra những cản trở việc thực thi mong đợi của các hoạt động mà nó đảm nhiệm ở đầu vào

M2.3: Rủi ro của artifact đầu ra, ký hiệu Rout(Ar) với hai cách xác định sau:

Rout(Ar, A) bằng rủi ro của artifact đang phát triển bởi hoạt động A được mô hình hoá như số các tính năng của artifact A chia cho tổng số các tính năng của tất

cả các artifact đầu vào của hoạt động A, công với số các hành động thực tiễn của hoạt động A, cộng với tổng số các khả năng có thể của tất cả các vai trò đang tham gia trong hoạt động A Như công thức sau:

Rout(Ar) là tổng số rủi ro của sự phát triển của artifact đối với tất cả các hoạt động mà có artifact như đầu ra

M2.4: Rủi ro của vai trò R, ký hiệu R(R) là tầm quan trọng của vai trò R chia cho số

các khả năng có thể của vai trò R

R(R) =

| C(R)

| I(R) , R(R) ∈R+ ∪{ }0 (9)

3.1.1.3 Xác định rủi ro bằng các độ đo

Việc định nghĩa một qui trình xác định rủi ro sử dụng các độ đo của cấu trúc mô hình, chúng ta giả thiết rằng mô hình tiến trình đã được xây dựng dưới dạng siêu mô hình RiskSPEM Qui trình bao gồm theo các bước chi tiết sau:

Bước 1: Việc tính toán các độ đo mô hình

Đầu tiên, các độ đo đối với rủi ro phần tử mô hình sẽ được tính toán cho tất cả các phần tử Như vậy các độ đo này được sử dụng đối với tầm quan trọng phần tử

mô hình, việc tính toán cho tất cả các phần tử đã được định nghĩa trong các phần trên