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ụ

Bộ GIáO DụC Và ĐàO TạO
Trờng đại học bách khoa hà nội
đ

ếếếếếếếếế

Tác giả: ng Trung Nam
QUN TR RI RO KT HP K THUT TRUST CASE
XY DNG CC NG DNG HNG DCH V
Chuyên ngành: Công nghệ thông tin

LUậN VĂN THạC Sĩ KHOA HọC
CÔNG NGHệ THÔNG TIN

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

PGS.TS Huỳnh Quyết Thắng

Hà nội Năm 2010


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


Luận văn thạc sỹ CNTT

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

Trang 1/78


Luận văn thạc sỹ CNTT

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

Trang 2/78


Luận văn thạc sỹ CNTT

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

Trang 3/78


Luận văn thạc sỹ CNTT

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

Trang 4/78


Luận văn thạc sỹ CNTT

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

Trang 5/78


Luận văn thạc sỹ CNTT

ứ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ê.

Trang 6/78


Luận văn thạc sỹ CNTT

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

Trang 7/78


Luận văn thạc sỹ CNTT

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.
1.2. Rủi ro dịch vụ của hệ thống phần mềm
Các hệ thống phần mềm được thiết kế và xây dựng để phân phát các dịch vụ tới
các người dùng của hệ thống. Một dịch vụ không phải là một thực thi bất kỳ nào của
hệ thống, nó như một sự thực thi mà bổ sung giá trị hiện tại đến người dùng. Những
người dùng đánh giá đầu ra của hệ thống dựa vào các tiêu chuẩn thàng công của họ
mà định nghĩa bổ sung giá trị người dùng mong đợi từ dịch vụ. Một dịch vụ của hệ
thống được cho là đúng nếu nó hội đủ tất cả các tiêu chuẩn thành công của mọi
người dùng dịch vụ. Nếu không, dịch vụ đó biểu lộ một sự thất bại, làm giảm tính
năng của dịch vụ. Dịch vụ tiện ích là một ước lượng chủ quản của người dùng về
giá trị thực tế được phát bởi dịch vụ tới người dùng.
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.

Trang 8/78


Luận văn thạc sỹ CNTT

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.

Trang 9/78


Luận văn thạc sỹ CNTT

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.

Trang 10/78


Luận văn thạc sỹ CNTT

• 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

Trang 11/78


Luận văn thạc sỹ CNTT

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

Trang 12/78


Luận văn thạc sỹ CNTT

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.

Trang 13/78


Luận văn thạc sỹ 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

Trang 14/78


Luận văn thạc sỹ CNTT

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à

Trang 15/78


Luận văn thạc sỹ CNTT

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.

Trang 16/78


Luận văn thạc sỹ CNTT

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.
Ví dụ 2.1:
Để chúng ta thấy một quy trình của việc mô hình hoá kinh doanh được đưa ra
bởi các nhà phân tích kinh doanh. Mục đích của quy trình này là để đưa ra được một
mô hình kinh doanh. Sự thất bại của quy trình mô hình hoá kinh doanh là việc có
liên quan tới rủi ro đã xem xét.
Một sự dẫn chứng về kịch bản rủi ro Fault – Error – Failure mà dẫn đến việc liên
quan rủi ro đã xét có thể bắt đầu từ một khuyết điểm bên ngoài.
Fault: Sự thiếu khả năng của các nhà phân tích kinh doanh trong việc mô hình hoá
trường hợp sử dụng.
Khuyết điểm vẫn tiềm tàng cho tới khi nhà phân tích làm mô hình các trường
hợp sử dụng, sau đó nó gây lỗi.
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

Trang 17/78


Luận văn thạc sỹ CNTT

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:

Trang 18/78


Luận văn thạc sỹ CNTT

• 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 đó.

Trang 19/78


Luận văn thạc sỹ CNTT

• 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
đó.
• Thành thạo: khả năng sử dụng thực tiễn đầy đủ các kỹ năng và tri thức để
hoàn thành nhiệm vụ nhất định.
Tính năng bao gồm các thuộc tính khác nhau của một sản phầm nhân tạo được
phân biệt để đánh giá các tiện ích của sản phẩm đó. Các thuộc tính được mô hình
hoá với tính năng có thể đưa ra như sau:
• 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.

Trang 20/78


Luận văn thạc sỹ CNTT

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ử

Trang 21/78


Luận văn thạc sỹ CNTT

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

Trang 22/78


Luận văn thạc sỹ CNTT

đượ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 : nghĩa là P không được thực hiện
trong A
• A <activity> mất (loses) R <role>: nghĩa là R không được tham gia trong
tình huống của A
• A <activity> mất nhiệm vụ R <role> nghĩa là R không được giao nhiệm vụ
cho A
• A <activity> mất Ar <artifact>: nghĩa là Ar không được sử dụng trong ngữ
cảnh của A
• Ar <artifact> không được phát triển

Trang 23/78